Basic instancing microcode command?

[lmcd]

I'd like to render some triangles from the contents of the vertex buffer various times on different parts of the screen.

It would be nice to fill the vertex buffer, then push various matrices onto the stack (e.g. 5), and issue a render triangles command with an instance count that just loops through N positions on the stack and renders them all against each given matrix at once.

[lmcd]

After checking out the microcode, I don't think this would work as it seems the lighting data is being calculated during vertex load, and 'instanced' models are in different places relative to the lights.

Another idea in this case could be a separate load verts command where baked lighting information is supplied as part of the vertex data. My particular use case has various repeats of the same model, but with known lighting in each case. Each model is split into 3 parts, and repeated 6-7 times, so you have 21 full lighting passes per frame that can potentially be skipped altogether.

[HailToDodongo]

The exact reasons are a bit more complex, and it's ultimately a tradeoff, but the ucode as is can't have multiple matrices loaded.
Mainly for memory and also performance reasons during processing.
The instancing case would also require keeping original vertices loaded to bring benefits, which would further complicate things.

As for lighting, you can already pre-compute lighting and store it in the vertex color.
If you only use an ambient light there is effectively zero cost as the lighting loop is skipped.

[lmcd]

The exact reasons are a bit more complex, and it's ultimately a tradeoff, but the ucode as is can't have multiple matrices loaded. Mainly for memory and also performance reasons during processing. The instancing case would also require keeping original vertices loaded to bring benefits, which would further complicate things.

Got it, thanks for the explanation.

As for lighting, you can already pre-compute lighting and store it in the vertex color. If you only use an ambient light there is effectively zero cost as the lighting loop is skipped.

That didn't occur to me 😮 Very useful.
A tool to pre-compute vertex colours using a given scene/pointlight setup is an interesting idea - I might look at this if I can make sense of rspl

I don't know how possible this is, but would be interesting to have flexibility (perhaps via Makefile) to turn on/off different types of vertex structure depending on needs. Like different variants of T3DVertPacked with accompanying microcode and functions. Like you could almost double vertices per load if you didn't need UVs or normals. Just a thought.

Thanks also for your work on tiny3d - it's really great 👍

[HailToDodongo]

The easiest way is to to just bake lighting in blender to vertex color, that's already a builtin feature.
Otherwise you ofc hand paint vertex color too.
(That's pretty much how a lot of commercial games did things too).

Using vertex color doesn't require any ucode changes as it's already a feature that is always available if you meant that.

I did briefly test differently sized vertex structures, but there are issues wrt alignment in the ucode then.
As well as a really small benefit in terms of time savings.
Specialized ucode also means more ucode switches which drive up memory bandwidth.
If your entire game never uses any lighting you may benefit from a specialized version, but i would carefully measure that part.