Hey folks!
I will not copy/paste here my wall of text from the repo but if you are interested in what we are cooking for the next big update, you can chime in here:
Introduction of CoreScene by deltakosh · Pull Request #15620 · BabylonJS/Babylon.js (github.com)
Please voice your support or concerns before it is too late 
My experience is not high enough to suggest that all (maybe any, really) of these concerns must be addressed. But here is what comes to mind.
I don’t see the rationale behind “…user will also have to listen to scene.onDisposeObservable to dispose all entities.” Are there really use cases where a user would not want to dispose all entities?
The example is mostly the same as boilerplate playground code and only show an alternative render step is possible. Isn’t there an alternative render step available in Scene?
I thought there was a parallel effort to reduce interdependencies and modularize imports so that the framework only loads what is needed or used.
One concern I have is that every implementation using CoreScene would now have duplicate yet custom and possibly incompatible code that essentially implements the same thing. The creativity of other developers would then become less compatible and essentially accessible.
CoreScene will not be able to auto dispose as it is not tracking the list of entities. It is something done by Scene itself.
Rendering in the Scene is static: you cannot remove the evaluateActiveMesh or the rendering groups and so on. This adds a lot of code when you do not want it. We cannot remove more without breaking backwards compatibility quite massively. And this Scene is a fat baby we cannot split anymore.
The CoreScene is the answer to that problem: you can decide how you want to do your rendering phase. The point is specifically to allow all users to have their own version. I see no problem with that.
I also do not get your incompatible code point: this remains pure Babylon API. If you decide to call a.render() before b.render() in your render loop , where is the issue?
Oh and this is purely optional: CoreScene will NOT replace Scene. If you like what we have now, stick with Scene, it is here to stay.
Is it really good to target master branch? Seems master branch is used for rolling releases now. Since the Babylon X is not planned for recent versions, should there be a “Babylon X branch” for features like this?
Incompatible code reasoning goes like this:
Edit:
If that is the major difference between Scene and CoreScene, my argument falls apart at step 2.
Although perfectly valid concerns, they seem more related to the previously discussed rationale for breaking changes in Babylon X, rather than anything specific to Scene?
Good point! As this is a step toward Babylon X, it makes a lot of sense. Is CoreScene intended to replace Scene over time?
Would it be possible or prudent to write a class on top of CoreScene that is compatible with Scene similar to how PhysicsAggregate is (somewhat) compatible with PhysicsImposter?
CoreScene sounds like a useful option for those who want finer control over rendering and higher performance. Since Scene will still be available, this satisfies backward compatibility.
I’m excited to see how CoreScene develops and how others use it!
Yes please!!!
This looks really promising to have more control on the render pipeline and more perf at the same time. Also I am really curious to see render graphs in action in the future.
I also like the idea of importing additional features to get a more personalized feature set. However I am concerned this will make the Playground useless as we don’t control the imports there. People using the CoreScene won’t be able to repro their bugs unless the Playground also receives an update to support es6 imports.
I don’t know if that would fit, but if we control the render loop, I would love also to be able to do something like
mesh1.render()
postProcess1.render()
mesh2.render()
postProcess2.render()
bjsUI.render()
That would simplify a lot of the burden of having 2 cameras (or 2 scenes) when just wanting to display a UI without post-processing on top of it. It would also help ordering post-processes dynamically which can be very useful when rendering volumes with raymarching in post-processing.
This is how we are rolling all our changes. Babylon’s is just a code name to encapsulate the major breaking changes
I think there is major misunderstanding here. Both CoreScene and Scene will cohabit. There no two pools. The same way today we have several materials like StandardMaterial and PBRMaterial for instance
CoreScene is the root class of Scene. Scene extends CoreScene
Playground will be able to render everything Babylon. Why do you think it will not be able to use CoreScene?
Edit: from the import standpoint, I agree with you. As the Playground imports everything it will not be able to replicate missing imports issue. But this is not new, we are already facing the problem with some users for other classes.
@CrashMaster With the render graph, you could do something like this (under development, so subject to change):
Rendering:
In the PG, I put the sphere in the ObjectList1 list and the plane in ObjectList2, which means that bloom is only applied to the sphere, and B&W to both meshes.
Totally makes sense. Count me in 
Was a major misunderstanding on my part. You’ve cleared it up and addressed all of my concerns. I am in agreement with you and am excited to try it out!
lol i honestly prefer that outcome:) I can always miss things out and then I would have to come with a different solution:)
I’m glad it was not the case this time 
I won’t lie: this is one of the most exciting feature we had in a long time (at least for me :))
