In my previous I already mentioned my preference of using blocks and octrees for static scenes and I wondered whether I can combine it with my ASCII raytracer. It was of rather poor performance, but even with some improvements the main problem of passing through the same tiles over and over again didn't make it faster. Thus, I was thinking about using an octree for it, too, but quickly noticed how problematic this concept becomes when using destructable terrain. For rendering, it's probably a good to use an octree with opaque and transparent walls, so that the CPU only needs to pass the stuff that's potentially displayable. But with more destructed terrain, the bigger and complex the octree becomes. So it's suitable for my raytracer, BUT (and that's the point where it's actual scene assembling), you can precalculate stuff for single blocks/scenes and reuse it later. Scenes made up of smaller scenes seem to be less common in modern video games. Well, there are equal techniques for producing assisted hidden surface detection or arbitrary polygon sets, so it's no wonder why artists prefer to just sculpture stuff. However, I like the approach of assembling maps with premade blocks. In the particular case of orthogonal ASCII raytracing, it could be used to precalculate single blocks in different angles and then just quantize the ray angles. This way, you only need to take data from pre-rendered content and no rendering would occur. Well, this won't work for dynamic colors but only for static data. Well, it might be possible to find a way of dynamically generating those precalculated chunks. But I don't think that the required work to archieve this is worth it - in the end, you'll probably end up doing more management than good for the performance.
All in all I'm wondering how I could speed of my own renderer with this. In whatever way I turn it, it simply doesn't fit and I never get much out of it. Seems that raytracing and destructible terrain is a combination no way near to speed-ups.