One of the big new features of the upcoming 4.0 release will be the scene inspector (also known as the debug layer).
The overall goal of the scene inspector is to help developers and artists set up or debug a scene. They can, for instance, drag and drop a glTF file onto the sandbox and then open the scene inspector by clicking on the edit button in the footer bar to get a sense of how the scene is built.
We plan to add as many tools as we can to the scene inspector so users will find all the weapons they need to kill a bug in their scene.
We also plan for the scene inspector to help artists set up their scene to be able to test textures, materials, lighting, environments, and post process effects. This should help them determine the final look of their scene and give them a quick and easy tool to test and validate their assets.
For example, here is the PBR property panel used to configure all aspects of our powerful physically-based material:
You can try this PBR materials scene to get a sense of how much control the scene inspector gives you to quickly try out material variations.
Regarding the features we want to add to help artists, we recently faced an interesting dilemma: Do we want to let artists add new elements to the scene instead of just configuring the ones that already present? That lead us to reformulating that question to: Where is the line between an editor and an inspector?
That question is important because designing an editor is a completely different task than creating a debugging tool. For an editor, you have to provide a creation user interface for nearly every single feature of the engine (and believe us, we have a lot of them!). So it is important to draw a clear line and set expectations so that users will not be disappointed.
In my mind that line between these extremes was that an inspector allows you view and tweak the parameters of elements that already exists in a scene, where an editor (like the great Babylon.js editor which is a community driven editor for Babylon.js) allows you to add new elements to your scene.
But, as always, it is not that simple. After discussing this at length with the team, and mainly with Patrick (our creative director), I ended up changing my mind for some specific features that could help an artist test their assets.
This is why the inspector will soon be shipped with support for adding a default rendering pipeline to a scene that did not have one initially included. You add one by right-clicking on the rendering pipelines node on the Scene Explorer and choosing Add new DefaultRenderingPipeline:
Then by using the property panel, you can control all available features of the rendering pipeline and set up your scene accordingly:
Feel free to try that demo here.
The inspector is a living entity that will keep evolving with Babylon.js. For instance we recently added support for highlighting elements of the user interface in order to draw attention to new features. Go ahead, try out our new clear coat system. But I know that we will always have to carefully balance between creating a scene completely from scratch and tweaking the parameters of an existing scene with this tool. We want to give our users enough functionality to unblock them for debugging and validating, but going too far will result in the tool having to withstand comparison with fully-featured editors which was not the purpose of the scene inspector.
This is also a place where our community can definitely help by providing feedback on what they want for the scene inspector and what would be too much.