Deleted Comment
The other was breaks. I didn't do this all in one stretch and instead did it in small chunks over time. I wasn't trying to ship a final game or finish as quickly as possible so the time scale was very relaxed.
Then the last was to make sure the process stayed as enjoyable as possible. If I was getting stuck on a problem or if a particular path really didn't seem to be working, I preferred to either take a break from the problem and come back later or find new sources that helped me see if in a different way (or both).
Looking forward to seeing improved versions.
I'm tipping you've got a pretty bright future!
"Even if that’s the case, is there a huge amount of work to integrate existing models/scenes into your engine?"
It uses the Assimp library which allows it to support things like .obj, .fbx and .gltf. Usually what I do is export from Blender to gltf and ask it to export the textures separately rather than pack them into the binary. Most assets that were designed with metallic-roughness in mind either work immediately or with minimal changes. In my own testing the most frequent things I had to change were if normal maps were inverted (fix by flipping the green channel in photoshop) or if the model exporter set all the metallic values to maximum due to missing data (fix by loading the metallic or metallic-roughness maps in photoshop and flipping metallic channel from max to 0).
> Each of the four cascades are given the scene at different levels of details. The first cascade uses the highest level of detail while the last cascade uses the lowest available level of detail.
I would expect the shadow renders would want to use the same LOD as the primary view to keep the shadow casting geometry consistent with the shadow receiving geometry. Otherwise, you might have incorrect self-shadowing.
In the future I'll probably do something similar to what you mentioned and have the cascades use the LODs selected for the main view.