how to build a massive scene renderer using this library

[pixeljetstream]

from another issue @mzwaal asked

A feature I would like is geometry simplification on model level, that would make a big wall for example cheaper to render. My use case is is rendering the maximum amount of models in real time. I don't use the chamfer feature for that reason. Also full support for all the official parts would be great. Also for non transparent parts, there is a lot of stuff inside bricks that should be culled when bricks are stacked. There are more things I can think of. What would be the best way for you to receive feedback/feature request that are not issues per se?

While this library is more of a data provider, here is some thoughts about its design features:

• shapes were intended so one can override studs/other frequent detail bits, by something like a dedicated rendering system tuned for such low complexity meshes (think particles). This could influence the roundness etc.
• the chamfer effect uses a separate index buffer still using the regular vertices, so it can be used for level-of-detail
• in a deferred renderer the bevel highlights could be done in post by rasterizing the hard edge lines for closer objects and perturbating the normals (imo some level of bevel edges is important to get the highlights of plastic, makes it look nicer)

As for generally going about it and solving the obstruction/waste

• using raytracing the studs (as shapes) could detect if they are occluded (shoot hemispherical and detect if you can escape), and then be removed from the shape list. I could imagine doing something in vulka raytracing for this. Moving the ldrawloader_viewer to vulkan, some "bake" type operations could be done there. If the models are known ahead of time, or if such baking is okay at load-time. One could do this detection for individual triangles but that will need a healthy amount of rays to be accurate enough.

• reduced number of parts at distance? you could rasterize/raytrace the model from a few angles at lower resolutions. That could give you a list of parts that are more "important" then others. So if the model is afar you render less parts (this isn't free of visual error but could work good enough).

• collapsing walls to larger triangles imo isn't needed, hardware is pretty good at how much triangles can be pushed (although depends on your target). It's more important to occlusion cull.

• brute-forcing occlusion culling is pretty good on todays hardware (using HiZ depth textures etc.). Especially with lego you can build nice proxy shapes using the bboxes and evaluate a bit hierarchical. Test the bbox of the model first, then the various part instances within. Then the "special" shapes like studs... Depending on distance you might straight skip them. (I originally wrote this library in preparation of showcasing some of this using mesh-shaders, though didn't find the time yet). But https://github.com/nvpro-samples/gl_occlusion_culling might be inspiring

[mzwaal]

Nice, a dedicated thread for ideas! In my case I actually have a renderer that for various reasons I do not want to modify. It already supports LOD, rich materials etc so I do not want to implement anything on that level. What I want out of a loader are the triangles, normals and materials, which your library supplies. This information is then imported into an internal format.

About reducing triangles, another strategy I have seen is the create parts that are less detailed. So bricks that are boxes without inner structure or studs. That might be done with the shapes feature and can be automated for entire categories of elements like bricks and plates. It is easy to figure out the dimensions of a 2x4 brick replacement box.

My own wip loader has a somewhat different strategy btw in that it renders all triangles and optimizes normals when possible by averaging based on a best effort. That way any valid ldraw file can be rendered. So it does not reject anything that is has a questionable shape. Even free floating triangles get rendered because the ldraw format does not forbid it.

So in order to switch to completely to this loader I need it to be more permissive in the rendering. Any valid ldraw file should render as the standard does not say anything about geometric correctness. Perhaps it could have a strict geometry mode that gives the part builders some hints on how to improve the geometry. That way parts can become more correct in the future just like with the BFC effort and make them easier to render.

[pixeljetstream]

Okay. As I attempt to process all parts at the moment I also realized how the mesh fixing required for the render normals fails quite a few times. So I second the need for an alternative render part mode mode that is more robust.

With some crude voxelization I could imagine those lowest lod bricks could be generated automatically. Like sample on the aligned Lego grid and then figure out percentages of how "filled" a cell is.