When Optimisations Work, But for the Wrong Reasons

Patrons can now vote for the next video! Thank you for your support. Also, some additional links from the video: ❤Patreon: www.patreon.com/simondevyt 😍Courses: simondev.io/ WolfFire Games Article: blog.wolfire.com/2010/10/Imposters

This is the stuff about gamedev that almost nobody talks about, and if they do, it's way too indepth. I love channels like this. You're doing a lot for making people understand how complex and smart Game Engines and Render Tech actually are.

thank you so much for saying "impostor" at least a dozen times while not making a single among us reference, im proud of you

I like that Epic's approach to finding out that subpixel polygons kill render times isn't to tell artists to avoid intricate geometric detail and to make more LoDs, it's to double down and make a system that lets the artist go absolutely wild with detail and not need to even think about LoDs.

This also really helps explain how 4k gaming is possible on these GPUs. In terms of GPU usage efficiency, smaller pixels is effectively the same as having larger triangles. So while 4k screens have 4x as many pixels, you're also throwing away far less work that the GPU is doing, which helps regain some of the performance loss

One LOD technique I like a lot especially in the mobile world where nanite-like LOD engines currently aren't feasible is Progressively Ordered Primitives/POP buffers. The core idea is to cluster vertices through quantization at different levels of precision and sort them such that lower-precision vertices are first in the vertex list and higher-precision ones are last. The end-result is you can change the LOD of a model just by changing the quantization level and how many vertices you choose to draw without storing any more data than original mesh used. The benefit is four-fold: - Artists only need to make one model with any arbitrary attributes - Cracks/seams can be handled perfectly - Can have dynamically adjustable LOD levels without popping from mesh swaps - Can stream in the extra vertices as they're needed or upload the whole vertex buffer once and instance multiple LOD levels in one draw call. The latter is useful as draw calls are still disproportionately expensive on mobile. Since you're sorting the vertex list anyway (which can be done in O(n) time) and vertex order within quantization clusters doesn't matter much, you can also sort them on a secondary level to maximize vertex fetch efficiency which is important for mobile because of binning (more-so than overdraw since tile-based deferred renderers often have near-perfect hidden surface removal). The neat thing is you can scale the quantization level according to how large quantized grid would make triangles appear on screen to help maximize quad occupancy while maintaining enough detail for it to look good. It does have some drawbacks, notably that it doesn't play well with vertex skinning and lower LOD levels tend to have a bit more triangles than hand-made LODs, but it's great in a mobile environment or for procedural mesh LODs. As a side note, optimizing for mobile tile-based deferred-rendering is a lot of fun and it feels so much more rewarding to make a mobile engine run fast. Most mobile developers just port PC games or graphics techniques to mobile as-is and call it a day while limiting gameplay to negate poor performance; however, with careful optimization you can achieve between Xbox 360 and Xbox One levels of performance on most modern (>5 year old) mobile hardware. I'm definitely biased though as I've found my niche in mobile optimization.

14:30 the "maximum area" triangulation improving performance so much is news to me! I usually create slices since it looks "nicer", but I should probably think more about the final result.

My takeaway. Please let me know if I'm wrong: small triangles are less efficient with their quads and thus are inherently more inefficient but the main reason they are inefficient is that the triangle assembly is a linear process that assums you will have less triangles than pixels and gets bogged down when it can't keep up with the assembly load. So the bottleneck is the assembly.

Ill confess, even up until about 10 minites in I has assumed, naively, that I did actually understand why billboards were so kuch better for performance, with thoughts along the line of "reading a precalculated viewing angle from a file/ram is MUCH cheaper than doing the matrix multiplication to calculate the physics perspective appearance of even a very low poly 3D mode". When you went through how the physically arcitexture of the GPU differently handles triangles with a size close to the pixel size, it was so mind-blowing. I haven't realised I was so starkly wrong about something in a while, such a great feeling!

Now send this to Mortal Kombat

Really enjoyed this! As an artist you get told what things to avoid - e.g. long thin triangles and extremely small triangles, but it's rare to get a good explainer on *why*.

I am an absolute novice at game dev whos been toying around in Unity and now Godot for about two years, and I have to say each one of your videos feels like I should be paying you for this kind of info. The fact that this is your FREE content is insane, and I'm excited to see what your paid content looks like. You have a knack for beginning small, simple, and approachable, and then expanding to the point that I'm pausing and writing things down and yet still not feeling overwhelmed. I've read through documentation and white papers before for plenty of other coding subjects, but nothing has ever made me WANT to like your videos do.

"Mommy, Daddy, where do pixels come from?" SimonDev: "Sit down son"

One iconic example of billboards is the infamous 1000 Heartless fight in Kingdom Hearts 2. Back then, it would've been impossible to have 1000 entities individually moving and acting all at the same time. Square Enix's work around to this was to have only have a handful of active enemies actually nearby. Meanwhile, the rest of the Heartless would be represented by these 'billboards'. While in combat, it's hard to notice this detail at first, but it's extremely obvious on repeat playthroughs. This work around is also present when there's a swarm of Rapid Thrusters, except it's a lot less noticeable since the enemies are flying above you and often spawn offscreen rather than right in front of the player.

I don’t think I’ve seen anything that talk about this stuff in this much detail, much respect for your career choice, I am truly amazed at the information dump and how accessible you’ve made it, thank you.

Wow, this really explains why Nanite was such a breakthrough, of course it doesn't dig into the difficulty of implementation, but it does show how it eliminates the excessive tiny triangle issue.

this channel is insanely underrated. The amount of knowledge you offer with each video is absolutely great. Pleas keep this up.

“I’ve always been interested in optimizations” man I wish this was a requirement to work for any big game company 😭

This is a very nice video! I have heard avoiding micro triangles is a big thing but now I finally know why

In intro to 3D modelling we were told very sternly, "keep the triangle count to a minimum, and remove as many unnecessary triangles as possible. So this is nothing new to my ears... but it is fun to listen to anyways.