Things arrived in the mail today! With luck, I'll have the server for the bot set up this weekend :D

winders is upturdating!

a hitch in my plan: opening a complicated model on a windows 11 vm running on half a CPU core on a potato takes a hot minute to compile a few hundred shaders 🙃

another hitch in my plan is my RSI is flaring up tonight :|

this is the problem model in the first image. each color is a different shader that had to be generated by tangerine to render the voxel, and the average complexity of the generated shaders is also high.

the second image is the generated part for one of the these shaders. its basically the object structure w/ all the params pulled out.

it's basically half way to being an interpreter, i'd just need to also pull the call structure out into a parameter buffer, and replace the function with an interpreter loop. it would be slower than rendering with all of the compiled shaders, but it only needs to produce one frame for the bot

incidentally this happens to also be my plan for how to deal with shader compiler hitches in general, i've just been procrastinating on it because opengl doesn't believe in async shader compiling

here's some very entertaining reading about the same problem in a completely different project https://dolphin-emu.org/blog/2017/07/30/ubershaders/

update: I hacked together an interpreted mode and it works great for this :D
https://github.com/Aeva/tangerine/commit/19aa738799e3531f69dc0c7de3ebb14d8cf615d1

here's the wheel loading in normally on my main machine. the shaders are cached by the driver, so the pop in is a lot faster than it would be on a cold start.

and here's the same model running with the new interpreter. once the octree stuff is done processing, the model renders with no pop in. The time to image is much lower, but a given frame is much longer.

@aeva whoa, this is cool! Do you have different sdfs at different levels of the octtree?

@jonbro yes :D the root of the tree contains the entire model, which would be too slow to render compiled or otherwise. the octree splits to eliminate dead space, and as it does so each node removes the parts of the CSG tree that can't effect it resulting in a simpler SDF

@aeva are you building the octree cpu side?

@jonbro yes. here's the implementation if you're interested https://github.com/Aeva/tangerine/blob/excelsior/tangerine/sdfs.cpp#L1156

@aeva oh neat! storing aabbs for the sdf ops is clever.