Cesium crashes when we enable attenuation for point clouds.
This seems to be about Camera.main access here.
Camera.main is null for us. We use CesiumCameraManager.additionalCameras functionality to define the camera to be used by Cesium.
As a quick test, I used the following function for camera access, and it seems to work:
private Camera GetCamera()
{
CesiumCameraManager camManager = GetComponentInParent<CesiumCameraManager>();
if (camManager == null || camManager.useMainCamera)
return Camera.main;
return camManager.additionalCameras[0];
}
Right now we work with attenuation off. We can’t enable it because of that bug.
We have other point cloud problems (reproduced with attenuation off):
On Windows we get points of 1px size rendered. This is ok.
On Mac, our points have huge size. Something around 400-500 px.
On WebGL, we get a crash once we enable point clouds:
Invoking error handler due to TypeError: Cannot read properties of undefined (reading ‘explicitUniformLocations’), at WebGL.framework.js.gz
It is mentioned in that blog post that point clouds are not supported for WebGL. However, I think it should not crash even if it does not render anything.
I was hoping that enabling attenuation affects these bugs in a positive way, but I don’t know.
Hi @myavuzselim,
I’m sorry that point clouds are you giving you trouble in Unity. We’re going to open GitHub issues to track these bugs.
For the crash when Camera.main is null, we’ll have to think through what a reasonable fallback would be. Does additionalCameras[0] always apply in your use case, or are there other times where there may not be a known camera in the level?
Also, trying to get a sense of what’s pressing in balance with our estimated level-of-effort to fix: what is more blocking or urgent between Mac and WebGL? Or are they both unequally unusuable for your use case?
Hi @janine,
In our case, Camera.main is always null, while additionalCameras[0] is consistently non-null and the only entry in the list. It can be replaced with a new camera instance when another application model is loaded.
I think the most pressing issue right now is the crash on WebGL. While it would be nice to support viewing Cesium point clouds on macOS or WebGL, stability should come first.
As a next step, macOS point clouds might be the easier to fix. They do render. They just have excessively large point sizes.
WebGL rendering, on the other hand could be more challenging due to missing features like StructuredBuffer support (and geometry shaders, though those are largely obsolete). For what it’s worth, in a similar case where we rely on StructuredBuffer on other platforms, we’ve successfully used textures to store vertex data on WebGL. This might be a viable workaround here too.