Sorry, I haven't had a look at this thread for a while due to work and stuff.
I think the basic issue is that it doesn't really matter if you implement sub-scenes, some sort of soft occlusion culling tech or whatever; you're still having to test every object in the currently active scene against the frustum. If there's no trivial rejection before you're determining if something can be seen by the camera, that's a lot of work and a lot of memory to plough through, even on a moderately complex scene.
I suppose it depends who you think the "customer" for T6 is going to be. Is it going to be people who make games only for high-end desktop hardware? It going to be people who want to use mobile (console, phone, tablet) as well as desktop?
I would consider at least think of adding some sort of basic scene type interface in there. Rather than having the renderer just iterate through all of the objects, have it loop through some sort of list of objects provided by the scene interface. The default implementation could just function "as is" and build a list of everything, but it gives people scope to add their own trivial rejection scene, (kd-tree, sphere tree, oct tree etc) in its place.
It might be worth point out that my reason behind asking this, is that I work for one of the large console manufacturers, supporting developers in technical issues and focusing on performance. I'm a pretty low-level guy, but I fid the best optimisations are the high-level ones that require the least amount of work
One of my biggest bug bears is helping with performance opt on Unity. Unity is pretty ubiquitous these days, it's on everything. One of the big issues facing Unity is that you can't make a graphically complex game on anything but desktop, because it just checks EVERYTHING against the frustum or it uses Umbra which isn't optimised for some platforms (mobile, some consoles). It does't perform any sort of trivial rejection. So you end up with an operation (frustum cull) that SHOULD take around 3 milliseconds for a complex scene, taking anything between 32 and 64 milliseconds (that's 2 and four frames at 60 fps) in Unity.
So I'd like to see at least some basic support for trivial rejection in there - even if it's "here's the interface, implement your own as a plug-in".
Of course, that makes it sound like a lot less work than it actually is. The scene manager would need an interfaces that;
* Allows objects to be marked as dirty when they are added to the scene, moved or have their bounds changed ( The objects would mark themselves as being dirty, notifying the scene that they should be added to a dirty list)
* Update the dirty objects, sorting them into the correct partitions (this should happen before frustum culling)
* Tell the partitioning scheme to build a list of visible objects
If I have the time, I'll take a look at the render submission code and prototype my own interfaces as an example. Assuming I can get it to build on Mac