HashLips and Orion Art Engine: community, layers, and animation
My path through the HashLips community and the development of my own engine for complex layer combinations and animated collections.
My involvement with HashLips began on Discord. I joined the community very early, when Daniel was setting up the server, and offered to help build it. I had been using Discord since 2016 and already knew the platform well. That was the first way I found to contribute.
Over time, I also helped plan and implement improvements to the Art Engine. Later, I developed my own version, Orion Art Engine (opens in a new tab), with additional features for more complex layer combinations and animated collections.
This story brings together two important parts of my experience: building tools and participating in a community where people learned and worked together.
A community that went beyond code
Our work at HashLips involved much more than generating images. We helped people study, find work in Web3, and connect with committed developers. We also supported enthusiasts who had an idea but needed to find someone who could build it.
There were also situations where we helped people recover lost funds. That support was part of a broader collective effort that cannot be captured by a repository's feature list alone.
Sharing open-source code and encouraging people to study were central to that work. My technical involvement grew in that environment, through conversations, questions, and the needs of people trying to create something.
From image composition to combination rules
The original HashLips Art Engine (opens in a new tab) is the foundation of my fork. Its generation workflow combines images organized into layers, selects traits according to the configuration, and produces artwork with its metadata.
A composition might bring together a background, body, outfit, and accessories. Different selections let the engine produce different characters from a set of previously drawn elements.
But some collections require more complex relationships. One layer may need to change its appearance according to the selected skin; another may depend on both the skin and the outfit. Simply choosing a random image from each folder is no longer enough to represent those relationships.
Advanced layer management became one of the most important parts of my version.
Layers that depend on earlier choices
In my implementation, the conditionalOn option allows one or more earlier layers to act as conditions for a later layer.
Imagine a character with three choices: skin, outfit, and action. The action needs to preserve the appearance of the skin and outfit already selected. The engine looks up the visual variant that matches that combination.
The configuration expresses this dependency:
layersOrder: [
{ name: "Skin" },
{ name: "Outfit" },
{
name: "Action",
options: {
conditionalOn: ["Skin", "Outfit"],
},
},
]Variants are organized in a folder structure that represents those conditions. This separates the selected trait from the image used to draw it in a particular context: the same action can have different visual representations depending on the character's other parts.
Example from the Orion Art Engine documentation: original screenshot (opens in a new tab).
That control allowed me to build much more complex combinations than I could represent with the original workflow. The artwork was still composed of layers, but the relationships between them became part of the configuration.
In GridTurnWorld, this attention to relationships between rules appears in another context: perception, movement, and turns must work together to produce creature behavior.
Composing animations alongside static images
The other feature I consider especially important is GIF generation. Each layer could be a different GIF, making it possible to combine independent animations in the final output.
As an illustrative example, blinking eyes, moving clothing, and an animated background can be prepared separately. The engine brings those parts together, rather than requiring a complete animation drawn for every possible combination.
This expands the composition problem: besides selecting and stacking traits, the engine needs to combine their frames throughout the animation. The version available in the repository also supports mixing PNG and GIF layers.
The output frame count is defined by numberOfFrames. Each GIF's frames are spread across that total. For example, in an output configured for 60 frames, a GIF layer containing only two frames holds its first frame for the first 30 output frames and its second frame for the last 30. This lets animations with different frame counts fit the same output sequence.
Together with conditional layers, this made it possible to work with characters whose appearance and animation vary according to the selected traits.
See the original GIF (opens in a new tab) and the separate traits (opens in a new tab) in the project's public documentation.
Tools around the generation process
Orion Art Engine also includes rarity controls, incompatibility rules, forced combinations, and utilities for metadata and collection recovery.
One part of the workflow separates metadata generation from image rendering. This makes it possible to review combinations and their distribution before rendering the entire collection. Generation data can also be reused to regenerate images.
Those features are documented in the repository. This account focuses on layer management and GIFs because they best represent what I wanted to add to the tool.
A project within a collective story
My version preserves attribution to HashLips Art Engine, which remains its foundation. The extensions represent the work I developed around it and the possibilities I wanted to explore.
When I think about this experience, I remember both the technical solutions and the people who joined the community to learn, find collaborators, or start working in development.
The Orion Art Engine source code is available on GitHub (opens in a new tab), including configuration, utilities, and examples of layer organization.