Tag
Development posts tagged three-js. Tags cut across the categories, so this pulls together work on the same subject from different parts of the game.
11 posts
All 21,864 models in this game shipped with a flag nobody chose, drawing their own hidden interiors into every frame and every shadow. A default that arrives with an asset was never a decision.
Five stack choices and what each one charged: a physics engine never allowed near the simulation, a renderer whose failure mode is a blank white map, and 1,266 files with no upstream maintainer.
Zoom out on an eight player map and the game asked the graphics card to draw every unit separately. Grouping them took 1,392 requests down to 96.
A month of planned work was aimed at reducing triangles. Fifty five captures with real graphics card timers said the frame was going somewhere else.
Every level of detail is a real mesh now. Switch points come from how many pixels a thing covers, and a zoomed-out jungle went from 113M triangles a frame to 7M.
An MIT-licensed three.js casting sandbox became the spell renderer, after a Z-up remap, an ink-banding pass, and a rule about which number decides a spell's size.
The map used to be a flat plane with rock painted where you could not walk. Now the ground rises, cliffs block, ramps are the doors, and high ground sees.
Grass now bleeds into dirt along a warped contour instead of a grid of transition tiles, and the 2D and 3D views of a map finally draw the same world.
When four hundred units meet, deciding what they do and drawing them take turns. This is what had to be true before those two jobs could stop competing.
Four hundred animated units is the worst thing you can ask a renderer to do. Storing the animation as an image instead removes the skeleton entirely.
In April the camera stopped looking straight down. What a player got when a canvas RTS was rebuilt on three.js, and what the simulation never noticed.
