Something for the weekend, sir?

Super Attack Programmer Dan was working feverishly away on the model rendering code in Voxoid over the weekend. He appears to be mostly nocturnal. Let's have a peek at his incoherent ramblings, muttered into the void of Discord as he worked...

18:58pm

Dan: I think the bare minimum to get something rendered in the spanking new model handler is done. I've got Voxel model support added, but no shader made yet. I still have to fix Voxoid so it does the threading right and manages the new model handler correctly. The new model handler depends on a number of soon-to-be shared resources that need to be managed by Voxoid. I also have to fix up the data structure etc to handle the new model instances.

I'm taking a break now, but I should get to the point of testing tonight, and if the stars align the thousands of lines of code that I've written without being able to test anything yet will even actually render something

02:33am

Dan: I got something rendered... kinda. Not really.

(don't mind the terrain being broken for unknown reasons)

03:31am

Dan: Working external stuff:

• sproxel animation (had to mess everything up since it's no longer an index but an actual model object that needs to be "animated")
• all model data stored in a single huge buffer.
• alignment support in the memory allocator (extra fast for power of two alignments)
• automatic per-frame tracked GPU memory uploads using persistently mapped buffers that are auto-cleared when the GPU is finished using them (with correct, non-blocking GPU synchronization!), with dynamic allocation of new buffers as needed.
• fast per-frame mapped data is used for instance data, camera visibility lists, per-model data and draw call data. The model renderer does not need to allocate any buffer objects itself.

Dan: Working model renderer stuff:

• model "types" (previously "ModelDataFormat" but it was expanded to "types" for implementation and clarity purposes)
• model types can have any number of custom shaders added to them at load time
• shader.createMaterial() gives you a material from that shader that you can put on a model instance
• model loading allocates bin indices for the model and uploads GPU info. Model type can fully customize the stored metadata.
• custom vertex format and index format support, can be specified per model. Batching occurs when both vertex and index format matches.
• multi-draw-indirect batching generally means 1 draw call per vertex format. Above image rendered with one indirect multi-draw call, drawing instances of 17 different models.
• batching can be broken up if per-model metadata is too big to fit in one uniform buffer. For voxel models, this is once every 4096 models (actual different MODELS, not instances)
• customizable per-model data system, can be used to upload voxel model projection offsets, arbitrary model texture pointers, etc
• customizable material data (instance data). shader defines exactly what info it needs to upload and size can be varied per material, technically per INSTANCE. You don't even need to upload the matrix if you don't want to
• frustum culling works as before, binning of visible objects into visibility lists, with cached bin indices to reduce cache misses as much as possible. Should be about as fast as before.
• instance data uploaded to fast mapped memory to eliminate 2 copy operations
• multi-draw indirect data uploaded to fast mapped memory to eliminate lots of OGL buffer updates and extra OGL buffer objects
• full threading support of course. everything that can be threaded is threaded.
• Improved meshifier. It can now be easily made to retry until it creates an optimal model, has no duplicated tris and has the vertex cache optimizations.

Dan: Batching:

for each scene

    for each camera

        for each shader

            for each vertex format

              for each model

                  for each visible instance

                      render();

 batched

04:08am

Dan: committed