A painted treasure chest concept image on the left, an arrow, and the textured 3D chest model generated from it on the right
← Project archive
Project 005 Games / AI

Local Asset Forge

Can I make game-ready 3D models, sound effects, and music on my own hardware? A local pipeline from idea to something playable in Unity.

Where the idea came from

While building game prototypes, I kept running into the same problem: a game needs a lot of stuff. Models, sounds, and music all take time to find or make. I started wondering how much of that I could generate locally, on my own hardware, and whether the results could be good enough for an actual game.

The pipeline

The path starts with a brief and a concept image, then removes the background, turns it into a 3D model, cleans and optimizes the mesh, and finally checks it in Unity at game scale. Sound effects and music follow a similar path of generating candidates, listening, trimming, and checking them in the game’s mix.

My Mac handles the authoring, Blender, and Unity. A Windows laptop with an RTX 4080 runs the GPU-heavy generation. Relic Siege, one of my game prototypes, is the test bed.

What counts as done

A good-looking preview doesn’t mean an asset is useful. It only counts if it exports, fits a polygon budget, and holds up in Unity at the size players will see it. I keep the failures and raw output too, because the measured misses are as interesting as the wins.

Where it stands

It’s working, with mixed results. The technical chain from image to Unity works, and some assets are promising. The local image quality is the hard part, and where I’m spending most of my effort. I’m still building and testing this one.

Project timeline

Along the way

  1. Testing a lighter sword

    A revised local sword — one guard gem, a clean cutout, and a lighter blade — made it through reconstruction, export, and an equal-height comparison in Unity. The blade reads better than the darker version, and a test build rendered it held and registered a melee hit. It is a candidate, not a replacement. The sword already in the game stays until facing, alignment, and performance check out.

  2. A better local image model

    FLUX.2 Klein produced a better local chest than my earlier image model, and its export got a positive review when I looked at it in the game. A local shield made it through the same path. The sword concepts still needed revision before going to 3D, so the model is now the Studio starting choice with the earlier ones kept around.

  3. The local images weren't good enough

    In a matched chest comparison, the chest built from a fully local concept image didn't meet my bar for the game. Until a local source survives that test, the game uses a reviewed reference — sometimes from outside the local stack — with its origin recorded. The pipeline works, but a working pipeline isn't the same as a good-looking asset.

  4. Sound, rigging, and a Studio to run it all

    I added local sound-effect and music trials, and picked a generated hit and a combat loop to try in the game. A goblin auto-rig pilot produced a skinned model with test animations. To stop running everything from scripts, I built Asset Studio, a local app that runs each stage one job at a time and keeps a gallery of every run, including the failures.

  5. Starting with one question

    While working on game ideas I wondered how far I could get making the assets myself on local hardware, instead of hunting for them. The first version took an image to a 3D model using my Mac and a Windows laptop with an RTX 4080 doing the GPU work over SSH. A stylized boulder and a stone golem were the first models I imported into Unity.