Inspector v2 foundation + some partial impl + stubs

[ryantrem]

This PR includes:

• Foundational work for inspector v2 (modularity/extensibility, Fluent)
• A partial implementation of scene explorer and the properties pane
• Various stubs for other inspector features, such as the debug and status panes, etc.)

Here is what it looks like when testing in the Viewer test app:

Review this PR in this order:

1. readme.md (which contains an overview of the foundation)
2. modularity/serviceDefinition.ts
3. modularity/serviceCatalog.ts
4. services/panes/properties/propertiesService.tsx (for a concreate example of a simple "service" that consumes another service (dependency) and produces a service (dependents)).
5. extensibility/extensionFeed.ts
6. extensibility/builtInsExtensionFeed.ts
7. extensibility/extensionManager.ts
8. services/shellService.tsx (or at least the contracts/interfaces)
9. modularTool.tsx
10. inspector.tsx
11. services/**
12. Everything else in whatever order

[bjsplat]

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.

[bjsplat]

Reviewer - this PR has made changes to one or more package.json files.

[ryantrem]

These are temp changes to make testing inspector v2 easy. They won't be merged.

[bjsplat]

Snapshot stored with reference name:
refs/pull/16636/merge

Test environment:
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/16636/merge/index.html

To test a playground add it to the URL, for example:

https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/16636/merge/index.html#WGZLGJ#4600

Links to test babylon tools with this snapshot:

https://playground.babylonjs.com/?snapshot=refs/pull/16636/merge
https://sandbox.babylonjs.com/?snapshot=refs/pull/16636/merge
https://gui.babylonjs.com/?snapshot=refs/pull/16636/merge
https://nme.babylonjs.com/?snapshot=refs/pull/16636/merge

To test the snapshot in the playground with a playground ID add it after the snapshot query string:

https://playground.babylonjs.com/?snapshot=refs/pull/16636/merge#BCU1XR#0

[ryantrem]

This is an additional dependency that we can discuss. I'm mostly using the local storage hook, which does useful things like watching for local storage changes and updating the state accordingly. I'm also using a theme related hook. This came over with the pivot from the predecessor project this code was part of. If we really don't want this dependency, we could implement our own, but this is a common package and I don't think there is much risk in taking a dependency on it.

[bjsplat]

Visualization tests for WebGPU

https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/16636/merge/testResults/webgpuplaywright/index.html

[bjsplat]

WebGL2 visualization test reporter:

https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/16636/merge/testResults/webgl2playwright/index.html

[deltakosh]

Looks solid to me!

[kzhsw]

1. Will the perf be better? Like having a scene with ~10k nodes, will there be some perf improvement with something like virtual scrolling tree
2. Which set of feature requests on forum about inspector be considered in this version
3. Will it be default from scene.debugLayer

[ryantrem]

Hey @kzhsw, thanks for sharing some feedback here!

1. Will the perf be better? Like having a scene with ~10k nodes, will there be some perf improvement with something like virtual scrolling tree

Yes, in fact the new scene explorer already supports virtualization, and I've tested with a model with ~16k nodes. Expanding the tree is basically instantaneous, and scrolling is very low lag. This is one of the types of improvements that is motivating moving to a modern, well-resourced React UI framework.

2. Which set of feature requests on forum about inspector be considered in this version

A few thoughts on this one:

• Some of the issues discussed on the forum will be inherently addressed by moving to a modern, well-resourced React UI framework (like virtualization mentioned above, but also robust UI components/interactions).
• Modern ESM support for the new package will also address some asks.
• Extensibility will help with a class of issues as well. First, it will be much easier to hook into the new inspector to interact with existing features (like getting the selected entity), and second it will support runtime extensibility and ideally a community governed extension feed. There are many scenario specific asks for inspector, but it is a lot of work to support every single one and would likely be overwhelming to have them all enabled by default in the inspector. Our hope is that with runtime extensibility and a community extension feed, it will create an opportunity where the community can introduce new scenario-specific features that inspector users can opt into (by installing extensions).

This inspector v2 work won't automatically address every forum ask for the inspector, but it should address a subset and lead to a lot more flexibility for customizing the inspector to meet a wide variety of needs.

3. Will it be default from scene.debugLayer

Yes, the plan is to make it the default once it reaches parity with the current inspector and we have sufficient time for community feedback.

[georginahalpern]

for the initial PR i wonder if we should just go ahead and create the new shared tools package to hold the pieces that will be used by both of our workstreams (this would include the components, the hooks, the themes, some of the misc folder that are not specific to inspector )

And then what remains in the InspectorV2 package could be separated into 'truly just used for inspector v2' and a 'sharedTools' folder which holds the things that are meant to eventually move to shared package once/if we embark on adapting our other tools to use the modularTool framework? the main benefit of keeping them in inspectorv2 instead of moving directly to new shared tooling package being that old tools v1 will immediately start using the shared tooling package with my workstream, but won't be usign the modularTool concepts for a while, so we can keep that distinction more clear to open source folks who dont have full context on our future plans

[deltakosh]

Can you explain what is the gain of a addPropertiesProvider inside a PropertiesServiceDefinition?

Before we simply folded line of properties inside a LineContainer.

Now I feel it is overly complex so what are we gaining for the increase complexity of having addPropertiesProvider?

[digisomni]

Maybe this is redundant to ask but, I firmly believe the inspector should grow into a full editor for BJS, it just makes sense, every game engine has one, and having it integrated allows for real-time creation / updating.

One major feature of that would be the ability to easily "extend" the editor with game specific features, addons, etc. because every game and toolset might have more advanced needs and features, and being able to add windows / controls / modify existing would go a long way I think.

These kinds of composable controls are popular with frameworks like Docusaurus, Vite, etc. with the ability to override and extend internal features simply by hooking in.

All in all, this is 100% a step in the right direction and we salute you!

[ryantrem]

Maybe this is redundant to ask but, I firmly believe the inspector should grow into a full editor for BJS, it just makes sense, every game engine has one, and having it integrated allows for real-time creation / updating.

One major feature of that would be the ability to easily "extend" the editor with game specific features, addons, etc. because every game and toolset might have more advanced needs and features, and being able to add windows / controls / modify existing would go a long way I think.

These kinds of composable controls are popular with frameworks like Docusaurus, Vite, etc. with the ability to override and extend internal features simply by hooking in.

All in all, this is 100% a step in the right direction and we salute you!

Thanks for the feedback @digisomni! For sure our aim with Inspector v2 is for the most common use cases to be covered by default, optional/opt-in extensions/plugins for more specific use cases, and full extensibility for app-specific use cases. We'll try to get to a point where the community can try it out as fast as possible and give more feedback, and when we are at that point we'll definitely post about it on the forum!