Hope so. There is now just a single scene graph update per frame render (plus some extra one-shot updates if light cameras are auto-added to scene graph).
Actually, this would break cameras added as childs of objects, reverting.
So there is no clear and simple way to handling multiple scenes unfortunatelly.
Encouraging `scene.add( camera )` seems like the right thing to do then, less problems.
Actually, I think this can be handled magically instead of requiring understanding of the concept that the camera is part of the scenegraph.
While I was at it, I fixed it so you can use a camera for rendering different scenes (the renderer will add it and remove from each scene graph) .
Removed LOD text example. I think LOD example is good enough.
Ubiquity test working again.
Tweaked README to show the new pattern (Scene first thing created).
I had to resurrect parts of old code (keeping track of scene graph changes).
Good news: performance is great, new scene graph gains compound with buffers optimizations and non-array materials refactoring. Together we gained about 15% for rotating cubes performance test (pushing max to 2650 cubes at 60 fps).
Still broken with new scene graph: lod, skinning, collisions, AnaglyphWebGLRenderer, ParallaxBarrierWebGLRenderer, multi-canvas circle example.
Before lighting was messed up in dynamically generated cube maps.
Dynamic cube maps need to have flip uniforms (flipEnvMap / tFlip) set to 1, static cube maps to -1 (default).
For standard materials this is handled automatically, it's just something to be aware of when using cube maps in custom ShaderMaterials (dynamic and static cube maps have different cube face orientations, dynamic ones are correct, static ones need flipped x-axis in lookup vector).
There is still mystery of disappearing last cube face (negative-Z) and weirdly clipped objects in cars demo (works ok in simpler test).
Mr.doob
alteredq