These are definitely all good ideas. Up until now we haven’t had the need to do loading based on view frustum or level of detail, because of the fact that the particles always came from within a 3d application, and were likely to fit in memory. However, we have done in-house benchmarks for out-of-core datasets that have been quite successful. Tools for handling very large data is something we will be adding in the future. You are right when you say that it would be very useful to use an adaptive loading strategy in the renderer when dealing with large data.
The reason “stream_bound”, and “detail” aren’t included in the stream object is because of the nature of streams. It is true that this information is often available if loading from a file (as file meta data), but Krakatoa typically has no idea of the final bounds of the stream until it has been fully retrieved (for example, if someone has modified the stream with Magma, etc.). So, in our own plugins, to get the stream bounds we would have to scan through all the particles prior to actually loading them. That may be necessary for very large data sets, but the option isn’t provided currently.
The way that the “particle_stream_interface” class works is that it allows the programmer to provide raw particles one-by-one to the renderer. It is used in cases where you would want to provide particles directly from a Houdini particle system without a file intermediate, etc. The upside to using that class is that the particles don’t have to be all in memory. So, you can do your own bounds clipping within the code, or do your own frustum clipping, or LOD loading. The downside is that it is a low-level interface, so if you’re loading particles from disk, you’d have to write your own file I/O.
One wishlist item that I’d like to add is a programmable particle stream “modifier” object. It would allow you to provide a custom function for each particle in a particle_stream object before going to the render (Kind of like what Magma is for artists). That way you could cull on-the-fly, etc. It would just be a convenience function, since all this can be done with the “particle_stream_interface” directly. Is that something you’d fine useful?
It might help me if I had an idea of what you are doing with Krakatoa. If you don’t mind mentioning it that is.