[Feature]: Support external `SparkRenderer`

[pmi-gbs]

Problem or use case

I've seen that a lot of code is just there to sync the camera changes with the internal SparkRenderer, including complex and brittle code (accessing internals of either the 3DTilesRenderJs and Spark) just to handle instances of the SparkRenderer relative to the camera, while the recommendation of spark is to have it parented at the camera.
This also includes cloning of the camera which has unwanted side-effects (like cloning children parented to it) (I've actually started a branch to avoid this here: https://github.com/GEOBILITY-SYSTEMS/3D-Tiles-RendererJS-3DGS-Plugin/tree/avoid-camera-cloning).
But I think usually it's better to just handle this externally entirely so that the user has more control over spark and that it's really just one instance of the SparkRenderer in the whole scene.

We're currently driving a fork of this (https://github.com/GEOBILITY-SYSTEMS/3D-Tiles-RendererJS-3DGS-Plugin/tree/fork), that allows initialization of the plugin with an external SparkRenderer that is parented to the main camera instead.

Proposed solution

So I would propose to add an option to avoid the whole internal management of the SparkRenderer and instead be able to just pass the renderer to the plugin (as in the fork, which is well... a little bit more radical)

Alternatives considered

No response

Integration context

No response

Additional context

No response

[WilliamLiu-1997]

I've seen that a lot of code is just there to sync the camera changes with the internal SparkRenderer, including complex and brittle code (accessing internals of either the 3DTilesRenderJs and Spark) just to handle instances of the SparkRenderer relative to the camera, while the recommendation of spark is to have it parented at the camera.

Spark has a serious precision issue in world coordinates, so my cameraRelativeSparkRenderer cannot be removed until they resolve that problem. And spark's recommendation cannot fix this issue.

[WilliamLiu-1997]

Problem or use case

I've seen that a lot of code is just there to sync the camera changes with the internal SparkRenderer, including complex and brittle code (accessing internals of either the 3DTilesRenderJs and Spark) just to handle instances of the SparkRenderer relative to the camera, while the recommendation of spark is to have it parented at the camera.
This also includes cloning of the camera which has unwanted side-effects (like cloning children parented to it) (I've actually started a branch to avoid this here: https://github.com/GEOBILITY-SYSTEMS/3D-Tiles-RendererJS-3DGS-Plugin/tree/avoid-camera-cloning).
But I think usually it's better to just handle this externally entirely so that the user has more control over spark and that it's really just one instance of the SparkRenderer in the whole scene.

We're currently driving a fork of this (https://github.com/GEOBILITY-SYSTEMS/3D-Tiles-RendererJS-3DGS-Plugin/tree/fork), that allows initialization of the plugin with an external SparkRenderer that is parented to the main camera instead.

Proposed solution

So I would propose to add an option to avoid the whole internal management of the SparkRenderer and instead be able to just pass the renderer to the plugin (as in the fork, which is well... a little bit more radical)

Alternatives considered

No response

Integration context

No response

Additional context

No response

I plan to refactor the sparkRendererManager in next version, probably will export the relativeCameraSparkRenderer，and let user to control it themselves

[pmi-gbs]

Spark has a serious precision issue in world coordinates, so my cameraRelativeSparkRenderer cannot be removed until they resolve that problem.

Yes I'm aware of that problem, we had it ourselves some time ago with spark, which is why we have fixed it, like this:

camera.add(sparkRenderer);

and when the camera changes, just reparent it to the new camera, this was enough for us.

This could also be a way to significantly simplify the code in this repo (i.e. no extra sync, just directly parent it to the camera that is used for rendering).

And spark's recommendation cannot fix this issue.

Well the fork branch works for us with an externally provided SparkRenderer (that is parented to the viewing camera)

[WilliamLiu-1997]

fork branch

This is what I get from your fork branch. The splats are in the wrong direction or order. Do you have any commits that have not been pushed yet? If there is really an elegant way to fix the precision issue, I would be happy to receive a PR from you.❤️

[pmi-gbs]

Ah right, the changes in the fork branch are vibecoded, I have never tested the example there, just a quick evaluation if that works with our application (where the camera-parenting happens). I've noticed that we have a locally referenced scene (i.e. the global coordinates were small, although relative to the camera we still had issues after a few kilometers (f16?)). I just read that this isn't an issue anymore in spark 2.0, although I could reproduce your image above even when the renderer was relative to the camera.

Anyway, I think this should just be fixed in spark, so that we don't even have to care about all of this, which is why I have done here, let's hope it gets merged (soon): sparkjsdev/spark#356