Publish the frame budget or don't ship the scene

A 3D product page fails in one of two ways. It never ships, because it never felt fast enough. Or it ships, drops to 22 fps on the phones half the traffic arrives on, and gets quietly removed two quarters later while everyone agrees that 3D 'didn't work for us'.

Both failures come from the same root: nobody wrote down what fast enough meant before the modelling started. Art direction proceeds against an aesthetic target, engineering optimises against whatever arrives, and the argument happens at the end when changing anything is expensive.

So we set the budget first, in the feasibility sprint, on real hardware. Triangles, draw calls, texture memory, payload bytes, and time to first interactive frame. The budget is a build gate: exceed it and the pipeline fails the release, naming the part that did it.

The number that surprises people is texture memory. Triangle counts are what everyone watches, and on mobile they are rarely the binding constraint — a mid-range phone will push 200k triangles happily and then fall over on 200 MB of uncompressed textures. KTX2 is not an optimisation, it is the entry ticket.

The second surprise is that draw calls matter more than either. A 40k-triangle scene with 400 draw calls will lose to a 180k-triangle scene with 30. Instancing and atlasing are where the real wins live, and both are pipeline decisions, not modelling decisions.

We publish these numbers on every case study and every demo on this site. If a vendor will not tell you their p75 frame rate on a named device, they have not measured it.