Optimizing EXR’s High Fidelity NFT’s for the Bonus Browser Based Game — The Grind & Journey.
Quality or performance? EXR has some of the highest quality NFTs in the market, but that’s a blessing and a curse for a browser based game…
TLDR; the EXR bonus training game is just about ready to go (we’ve been surprise streaming with mods in Discord ;)— all that remains is the in-game asset optimization & QA. Our NFT quality “is too damn high” for browser based gaming — so we’ve created multiple solutions to bring our bonus in game assets down from GIGABYTES in size to under just 50mbs per race to get us a smooth browser experience.
Cracking on…
GM EXR gang — happy year. Welcome to another one of our technical breakdown posts. We run these types of longer form pieces every so often to help the community understand more about “how the sausage is made.” In this post we will be talking about the challenges of creating a smooth browser based gaming experience using some of the highest quality NFT assets out there. The Bonus 24 Hour Training Race format has been ready to go for a couple weeks now, all that remains is the game asset optimization and QA.
The Goal: Create Beautiful, High Fidelity NFTs.
When EXR first launched we had one thing on our mind — to bring it back to the art. To achieve this we took on the challenge of creating some of the highest quality 3D NFTs that the market has seen, from a small team. Once we had the high fidelity EXR NFTs designed, we wanted to then put them nicely into the EXR Bonus browser based game, built with WebGL. There’s a lot to unpack here.
The Challenge: “woah, NFTs those are incredible, but ser — they’re massive, and there’s sooo many...”
Creating 3K of some of the highest quality 3D NFTs means you face some interesting challenges down the road when developing game assets. This is for a number of reasons;
1. Game asset file size requirements — the curse of the polygon count
The size of the 3D models we created our NFTs off of were so big, our teams could barely download and work on them when trying to optimize for bonus game assets — there were hundreds of thousands of Polygons excluding textures and materials, and the file size of a single racecraft was easily over 100Mb, way too large for a browser based game. We need that to be a maximum of 5MB per Racecraft — that’s a 20x improvement requirement…
2. Browser File Size Limitations — the quality & quantity hurts the experience
The goal of making the EXR bonus game browser based, is one we are passionate about because of how accessible it makes the experience. But browsers have major limitations when it comes to gaming. For browsers to run smoothly and load quickly we had to challenge ourselves to keep the download size of an entire game session well under 100 Mb. When we first started working on the assets, a single racer NFT asset averaged 30 Mb… Pretty big gap when we need 10 Racecrafts per race, a planetary system, stylized gates, background etc.
3. Quality Checking & Assurance — the time needed is wild
With files that massive, and with that many assets — the work and workarounds to allow us to do quality checking on the optimized assets was incredibly painstaking and requires notable tools and tech to get the time down — especially with a small team.
Ultimately the quality of the EXR NFTs “are too damn high.”
The Solutions: relentless optimization techniques — smaller, lighter, faster.
We have a team of big brains that love a challenge — and watching the team solve for the above has been incredible to watch. Here’s some of the solutions we built to help drastically decrease the file sizes, improve the browser load times, and streamline QA for the team.
1. Cutting the Poly counts. ~500K triangles to 50k
In order to optimize the rendering speed and reduce load times, the number of polygons had to be lowered without changing the look of the NFTs — not as easy as it sounds. This process is manual and it requires attention to detail to create simplified versions of the NFTs while still preserving high quality game asset visuals. This work can’t be automated (sadge), only 3d artists will know which shapes can be simplified and which curves can be merged while retaining the look and feel of the model.
To get smooth frame rates, the vertex (this is what makes up 3D assets) count had to be reduced from ~MILLIONS of vertices per NFT to a maximum of just 50k per model — this is no joke. We went from half a million triangles to approximately 50 thousand - — from requiring a render farm and not being able to render a single ship on phones to rendering a full race at 60fps on phones. This was an incredible accomplishment.
While these results were great — we weren’t done yet. Downloading ten Racecrafts per race still exceeded our file size goals by several times — so we went back to work. Lowering polygon count further was not an option so — instead, we found ways to reduce file size without making the NFTs less complex.
2. Decreasing download size by a Cool ~6x times — *ooooof gif*
Making things more efficient usually creates time sucking activities within workflows — so we had to fix that too. The team built custom tooling to convert all assets to files optimized for the web, since decompressing data is much faster than downloading large files. All textures, materials and properties are bundled and compressed into a single file per model, reducing file sizes 6x, while also reducing the number of files a browser has to pull down.
On top of that, material properties and opacity data are read from many sources and packed into a single image. We want to use every color on every pixel to store something that adds to the experience. Details like occlusion and light sources are baked onto these compressed textures so we don’t have to calculate those in real time, this means the game doesn’t load anything that’s not used.
3. Squeezing assets as far as they go, ~10MBs down to ~1MBs — the last leg.
NFTs are viewed from a distance in the browser game; a single racer takes up only a few percent of screen space in many cases. The ship viewer allows the user to inspect tiny details on the same NFT, showing much more than the game ever will. To squeeze out a few MBs more, we built two versions of every asset using our tooling: one high res version for close ups, and a super optimized version to show during races.
By stripping all details that are unnoticeable at a distance and lowering vertex coordinate precision for the low res models, we managed to slash download size per asset again from SEVERAL megabytes to just ~1 megabyte, finally reaching the per-game download size goal we set for ourselves. Since we now have two models per NFT, we never need to compromise on quality, we just load up the high res models for close ups. LEGOOO.
4. Running Quality Assurance at scale — cutting time from hours to seconds
All those optimizations sometimes do a number on our NFTs, so we had to take QA into account. Loading up thousands of models one by one and inspecting them after each optimization was not doable, so we built another tool that allows us to scroll through game assets quickly. Only when a model is messed up in any way, we mark it as broken so the team can work on a fix.
QA for thousands of assets — absolute pain, absolutely no way around it.
The Next Steps: Thoon™
We are so close now with these bonus game assets, its just a manual grind that we simply can’t get around. The bonus training game is live and being played by our mods and it pains us that we cant simply launch training to everyone right now — but we want these assets looking acceptable. Thank you all for your patience, we are a small team but a passionate one and we are extremely excited for what’s to come with EXR.
