1. topology you can deform
a sculpt has millions of triangles in whatever arrangement zbrush left them. that is fine for a render and useless for a game. the deliverable you want is a retopologized mesh: quads where the model bends, edge loops following the shape, and n-gons only where nothing will ever deform.
the tell is simple — ask for a wireframe screenshot. if the elbow, knee and shoulder do not have loops running around them, that character will pinch the first time it is animated.
2. a budget that was agreed first
"low poly" is not a number. a triangle budget is. agree one before anyone models, and tie it to where the asset actually sits:
| where it sits | how to think about it |
|---|---|
| background set dressing | as cheap as it can be and still read at distance. |
| handheld / first person | spend here — it is on screen constantly and close. |
| npc crowd | the budget is per-instance, so multiply by the crowd before you agree it. |
| hero character | the one place a higher budget usually pays for itself. |
3. consistent texel density
texel density is how many texture pixels cover a unit of surface. when it varies across a set, one asset looks crisp and its neighbour looks blurry — and no amount of retexturing the blurry one fixes it, because the problem is the uv layout.
for a set that ships together, agree one density and hold every piece to it. this is the single most common reason a commissioned pack looks "off" when it lands in-engine, and it is invisible in a beauty render.
4. pivots, scale and orientation
- pivot at the point the object rotates around — the hinge of a door, the grip of a weapon — not at the world origin.
- real-world scale, so the asset drops in next to your existing content without a fudge factor.
- a consistent forward axis across the whole delivery, so nothing needs a rotation offset in code.
- clean transforms: scale applied, no leftover parent rotations baked into the object.
none of this shows up in a portfolio shot, and all of it costs you an afternoon per asset when it is wrong.
5. a rig that has been tested in-engine
a rig that works in blender is a rig that works in blender. on roblox the test is whether it behaves in studio: weights that hold at extreme poses, no candy-wrapper twist at the wrists, attachments where the engine expects them, and the right rig type for your game — r6 or r15, decided before modelling starts, not after.
if the artist cannot show it moving in your engine, it has not been tested in your engine.
what to ask for on delivery
| item | why |
|---|---|
| source file (.blend) | so the next change does not mean rebuilding from scratch. |
| game-ready export (.fbx / .rbxm) | the thing that actually drops into the engine. |
| texture set at agreed resolution | with the maps your shader needs, named consistently. |
| wireframe + tri count | proof the budget was hit, not asserted. |
| in-engine screenshot or clip | proof it survived the trip. |