Author Topic: [DLL] Rendering Optimization Experiments  (Read 1880 times)

Hello, I'm releasing the rendering optimization DLL I've been working on the last several weeks. It includes a few fixes to improve rendering performance and a *disabled* complete custom brick renderer.

Some exciting screenshots to start us off:





Check out that FPS boost!

So, to briefly outline the fixes, let's discuss the issues. The first issue is Blockland does not frustum cull objects during the shadow map generation pass(es). This means the entire scene will be rendered up to four times even if the shadow cascades are small! This is where the primary FPS increase comes from. The second issue is Blockland uses a bad heuristic to compute the orthographic projection (object to light space) matrix size when doing shadow maps, which greatly overestimates the size they need to be, causing more brick batches to needlessly be rendered even if they're culled against the frustum. Finally, Blockland uses an old frustum culling algorithm which is only mostly correct. Since it culls large objects (octree nodes), it falls victim to the issues discussed on this website: https://www.iquilezles.org/www/articles/frustumcorrect/frustumcorrect.htm. These issues are all fixed with this DLL! Warning: shadow cascade overlaps are forced to be ten percent of the z distance of the previous cascade because of these fixes. Some custom shaders will break unless fixed themselves.

B-But what about that custom brick renderer??!

Unfortunately for Blockland, its rendering pipeline is far too old to take advantage of more modern techniques like batching by location instead of texture in order to utilize technology like hardware occlusion queries. The sad truth is that we will never see effective use of occlusion queries in Blockland just because it's too old. As for why this happens, I'm not even sure myself (much hair has been pulled over this). I included the code for it anyways so people can experiment, but it is disabled by default.

Update: I'm going to briefly revisit this part of the DLL. See below.

Happy rendering!

Source
« Last Edit: July 13, 2019, 12:03:09 AM by CompMix »


i suggested this on a whim and val actually loving carries through

this is crazy stuff

you are a goddamned wizard

i dont understand a godamn part of it but it looks cool

i dont understand a godamn part of it but it looks cool
basically the rendering pipeline does math for every pixel on the screen per frame. the more math to be done per pixel, the longer each frame takes to process ie bad fps. this dll makes it so that there's less math done per pixel and therefore every pixel gets rendered faster

the specific change is that in the normal rendering pipeline, the math is done on objects that are outside your view which is useless. this makes it so that any objects outside your view are ignored (mostly) so you don't have to spend time calculating all the math on objects you can't see. also i guess a lot of their math equations were just inefficient and wasted extra time so he fixed that too
« Last Edit: July 10, 2019, 12:04:10 AM by PhantOS »

also i want to ask as someone who understands rendering but doesn't understand c++, how can the brick batcher be accessed? is there some static location that the global brick batcher can be read from? does it require separate c++ code or can it be accessed from glsl? and finally is it even worth using or is it too slow at this point due to the the limitations of the engine

i see brickbatcher has its own render method for opaque and transparent. does this just provide the logic that opengl can use?
« Last Edit: July 10, 2019, 12:41:55 AM by PhantOS »

also i want to ask as someone who understands rendering but doesn't understand c++, how can the brick batcher be accessed? is there some static location that the global brick batcher can be read from? does it require separate c++ code or can it be accessed from glsl? and finally is it even worth using or is it too slow at this point due to the the limitations of the engine

i see brickbatcher has its own render method for opaque and transparent. does this just provide the logic that opengl can use?

The BrickBatcher class and its friends are disabled because the performance of a batch by location first renderer is poor. You can enable it by uncommenting the CreateCustomBrickRenderer() line in Main. A BrickBatch represents a chunk of bricks and their vertex data renderable by OpenGL. I use a special hack to make the engine tell us whenever the chunks need updating, more about that if you look at the patches. None of this is accessable through glsl (I'm not sure what you mean) but the shaders still apply and everything.

ah ok. thats insightful, thanks



You will have to build it from source. However, as always, anyone can DM me on my discord for a build if they want, or instructions.



I believe I made a mistake estimating how poorly large batches of geometry would impact game performance. For any visual update for a brick, the entire batch mesh needs an update and obviously this makes a big difference if say, players are building or a mod uses different brick datablocks to symbolize something visual (like the treasure chest). I'm going to briefly revisit the custom renderer since I poured so much time into it anyways to see if occlusion queries actually can be used here. My bad for berating the older pipeline without much reasoning to back it.