I've been building nine, an experimental graphics engine centered around a language I created called HVSL (Hierarchical Vector Shading Language).
The idea is different from the usual AI image-generation pipeline.
Instead of generating an image directly as a grid of pixels, I use an LLM to construct a symbolic scene description. My own compiler and renderer then turn that description into an image using geometric operations and signed distance functions (SDFs).
The result is an image generated from editable, human-readable scene code rather than a single flattened bitmap.
HOW THE PIPELINE WORKS
- Natural language to symbolic geometry
The first AI model takes a text prompt and generates an .hvsl scene script.
The language uses a palette declaration (@PAL) and an ordered scene definition (@SCENE) containing geometric primitives and their parameters.
The model's job is to describe the scene. It doesn't directly draw the pixels.
- A custom mathematical rasterizer
I implemented a Python and NumPy rendering engine based on signed distance functions and geometric calculations.
The renderer evaluates shapes in pixel space, calculates coverage around their boundaries, and blends them into the output image.
Because the scene is represented symbolically, it can be rendered at different resolutions, including 4K, without enlarging a low-resolution source image.
- A second AI model checks the result
One challenge with LLM-generated geometry is that syntactically valid coordinates don't necessarily produce a visually correct image.
To address this, nine uses a second multimodal model as a visual critic. It examines a preview render, evaluates the result, and identifies defects.
The system then attempts targeted corrections to the existing scene instead of regenerating the entire image.
- The output remains editable
An HVSL scene is text, not just pixels. I can adjust a coordinate, change a palette color, or modify a shape in the symbolic editor and rerender the result without another LLM call.
That makes the representation inspectable and gives the developer direct control over the generated geometry.
WHY BUILD THIS INSTEAD OF USING A DIFFUSION MODEL?
I'm not claiming that symbolic rendering is better for every kind of image.
Diffusion models are powerful for photorealism and complex visual textures. My experiment explores a different trade-off: generating graphics through explicit geometry and a deterministic rendering engine.
This approach is particularly interesting for editable illustrations, geometric artwork, icons, and other visuals where control over the underlying representation matters.
It also creates a different set of engineering problems:
- Designing a formal scene language that an LLM can reliably generate.
- Converting geometric descriptions into clean raster output.
- Handling malformed or degenerate geometry.
- Detecting visual defects and correcting them without damaging working parts of the scene.
- Keeping rendering performance practical as resolution and scene complexity increase.
These are the areas I'm continuing to explore.
WHAT ABOUT THE ANIMATION AT THE END?
The animation tests shown near the end of the video use procedural motion applied to pre-rendered HVSL assets.
Native video generation directly from the symbolic language is a future direction I'm investigating, not a feature I'm claiming is already complete.
CURRENT STATUS
nine and HVSL are still experimental projects. I'm continuing to develop the language, renderer, and AI-assisted refinement pipeline.
I'd appreciate technical feedback, especially from people working on graphics engines, computational geometry, programming languages, rendering systems, or AI-assisted development tools.
If you were developing this, what would you improve first: the language and compiler, the rasterizer, or the visual correction loop?
Top comments (0)