3D in a playable ad is not automatically better, and it is not automatically expensive either. It buys two specific things — the ability to turn an object over and look at it, and a sense of depth that flat art cannot fake — and it costs geometry, textures, and a meaningful share of your frame budget on the mid-range phones most of your audience is holding. Whether that is a good trade depends almost entirely on what you are advertising.
What 3D actually buys
Product rotation is the strongest case. If the thing being advertised is a physical object — furniture, a vehicle, a piece of hardware, a shoe — letting the viewer orbit it does something no amount of 2D artwork does: it answers the question "what does this look like from the other side", which is exactly the question that stops people buying.
Depth and scale is the second. Racing, endless runners, tower builders and anything where the player is judging distance are genuinely easier to communicate in 3D, because the mechanic is spatial and a flat rendering of it requires the viewer to translate.
The third is configuration. Change a finish, a colour or a component and see it on the object immediately. That is a mechanic in its own right, it maps neatly to a real purchase decision, and it works for products that have no game to show at all.
What it costs, in the numbers that matter
The renderer itself is a fixed cost, and a larger one than people expect. Three.js is roughly 590 KB minified — about 155 KB once gzipped — before a single loader or any of your content. On a single-file network the uncompressed figure is what counts against the cap, so under Meta's 2 MB HTML budget the renderer alone can be a quarter of everything you have.
Geometry is usually the smaller half of the remainder. A well-decimated model of a single product is a few thousand triangles and compresses well; the trouble is that source models from a product pipeline routinely arrive at hundreds of thousands of triangles, and nobody decimates them because they look fine in the viewer on a workstation.
Textures are where budgets actually go. A single 2048×2048 albedo map is 16 MB in GPU memory regardless of how well it compresses on disk, and a full physically-based material set multiplies that by the number of maps. This is the constraint that most often turns an ambitious 3D playable into a stuttering one.
The budget that usually works
One hero object, one 1024×1024 texture set, no more than a handful of thousand triangles, baked lighting rather than real-time, and no post-processing. That fits comfortably inside a 5 MB cap and runs on hardware several years old. Everything beyond it should be justified individually.
Lighting: bake it
Real-time lighting is the single most avoidable cost in a 3D playable. Baking the lighting into the texture gives you the look at a fraction of the per-frame expense, and for an object that is being rotated rather than moved through a scene the visual difference is small. Shadow maps, multiple dynamic lights and reflection probes are all things a phone can technically do and should not be asked to do inside a ten-second ad.
The exception is when the interaction itself is about light — a product where the finish changes appearance with angle, for instance. Even then, an environment map is usually enough and costs a fraction of a real-time setup.
The frame rate problem is a device problem
3D magnifies the gap between the phone in a marketer's pocket and the phone the audience is using. A scene that runs at a comfortable frame rate on a current flagship can be visibly choppy on a three-year-old mid-range Android, and in an ad a stutter during the interaction is indistinguishable from the ad being broken.
Testing on at least one mid-range Android is not optional for 3D work. It is the single test that most reliably changes what gets built, because it converts abstract performance advice into an obvious problem you can see.
When 2D is the better answer
Most casual game mechanics. Match-3, merge, sorting, word games, bubble shooters and puzzle mechanics are all fundamentally 2D, and rendering them in 3D adds cost without adding information. A well-made 2D creative at 400 KB that runs at a solid frame rate on every device beats a 3D one at 3 MB that stutters, and it will beat it in delivery as well as in experience.
The honest test: does the viewer need to understand the object in space to understand the offer? If the answer is no, 3D is decoration, and decoration that costs frames is a bad trade in a format measured in seconds.
Where 3D and orientation collide
A 3D scene has a camera, and a camera framed for portrait crops badly in landscape unless the field of view and distance adapt. This is the same problem as 2D layout adapting to orientation, but with an extra dimension to get wrong, and it is worth deciding at storyboard stage how the camera behaves in each aspect rather than discovering it in review.
Preparing a model that fits
Source models are almost never ad-ready, and the preparation is mechanical: decimate the mesh to the silhouette the viewer will actually see, delete geometry that is never visible — interior faces, hidden fasteners, the underside of an object that cannot be orbited that far — and merge materials so the object draws in as few passes as possible.
Then bake. Combine the material set into a single texture at the resolution the object occupies on screen rather than the resolution it was authored at, and bake the lighting into it. A product filling half a phone screen rarely needs more than 1024 pixels across, and the gap between that and a 2048 source is a factor of four in memory for a difference most viewers cannot see at arm's length.
Finally, use a compressed geometry format rather than a raw one. The saving on an already-decimated model is modest next to textures, but it is free, and under a 2 MB Meta budget every free saving is worth taking.
Create playable end cards in minutes—no code required.
Open Playable Ads Maker