Hi everyone,
I’ve been testing the integration of Gaussian Splatting (GS) with the pc.CameraFrame constructor, and I’ve encountered some specific rendering discrepancies that occur as soon as the frame is instantiated.
While it might look like a subtle “washed out” effect at first glance, the issue is more nuanced. When CameraFrame forces the pipeline into HDR/Linear (Gamma 2.2), we see:
Hue and Saturation Shifts: There is a noticeable shift in color fidelity. For instance, neutral or dark areas (like hair) suddenly exhibit a reddish/magenta tint that isn’t present in the original render.
Alpha “Thinning”: Some parts of the Gaussian cloud become slightly more transparent. This affects the perceived volume and “weight” of the object, making it more ghostly.
I’m aware that a potential fix would be to re-train the GS model specifically for a Linear/HDR color space. However re-training is often not viable due to time constraints or they are just downloaded assets. Also most GS tools are currently standardized for SDR/Gamma outputs, so the user cannot do that on its own.
It seems that the way GS shaders accumulate and blend splats in PlayCanvas doesn’t currently account for the shift in the color buffer’s gamma when CameraFrame is active. Since alpha blending and color SH are so tightly coupled in GS, a change in the rendering pass’s math directly impacts the final transparency and hue.
I’m sharing this because I’m a big fan of PlayCanvas and I believe it is the best option for Gaussian Splatting on the web. However, for applications that require CameraFrame for post-processing effects, these subtle shifts in color and density are a significant hurdle.
Is there a plan to allow the GS shader to “detect” the CameraFrame state and apply a compensation mask or a gamma correction toggle internally?
Thank you in advance, and thank you for your impressive work!