Hello!
I’m trying the 3DGS to see if it’s usable for our business. I’m getting a pretty good result in PostShot:
But then when I import the PLY in SuperSplat, the rendering is a lot weirder. The colors are off. It’s not as opaque. And there’s not really any settings to play with. Is there a PostShot to SuperSplat tutorial somewhere? Am I missing settings?
Have you tried reimporting your exported PLY back into Postshot? If so, does it match the original scene?
Are you able to share your Postshot file?
Hello!
Re-import the PLY file does match the original. Here’s the PostShot file:
So does the re-imported PLY in Postshot match how it looks in PlayCanvas? If so, it does sounce kinda like it’s a bug in Postshot.
When I re-import the PLY in PostShot, it looks exactly like it was before I exported it. I don’t see the issues I see in SuperSplat.
Ah right, yeah, confirmed on my end.
For the record:
You can certainly see quite a difference. I’ll be really interested to get @slimbuck’s thoughts.
Thanks Will!
No rush on this. We’re just evaluating the tech.
Hi, sorry I missed this thread somehow!
This looks to me like the “render target precision” issue we have seen before. When the scene is made up of a large number of semitransparent overlapping gaussians, then the render target precision must be float32 to correctly accumulate all the layers of gaussians.
We render and accumulate to a RGBA8 buffer by default. For the vast majority of scenes this is fine. However, we have 3 or 4 scenes which display the precision issue you’re seeing here.
We have discussed whether it’s worth defaulting the backbuffer in SuperSplat to float32 (meaning all users take a performance and memory hit, but it always just works correctly) or whether to provide a user option to toggle the precision.
Note that this model will likely never run very well in realtime. The fill rate required is generally just too great as soon as the camera approaches one of the surfaces.
I am interested to know what causes scenes like this to be generated. Whether it’s training parameters or source images or something else. If you load the model into SuperSplat you will see that double-clicking on the model doesn’t work because there are no solid gaussians at all. Very strange.
You can also see on the SPLAT DATA panel, opacity is all very low. Not a single gaussian in the scene has opacity larger than 0.3. Why? So strange!
Thanks! Is there anything I can do on my end? Techs like this really live and die because of the quality of authoring tools and documentation. The PlayCanvas viewer/editor is fantastic as usual but getting there is weird. It’s a lot of trial and error without a clear understanding of what’s really happening.
I don’t understand how people got something that clean and sharp:
Both of those splats were not generated from regular photogrammetry. Instead, they’re generated from 100s of rendered images from Blender. I believe using this tool:
Thanks! This is super helpful. We were using 3DS Max/Octane to render our frames.
That is really cool. The video he did of his plugin, shows a nice example.
I came to the forum to ask pretty much the same question - why does it look so good in postshot but worse when uploaded in supersplat. Initally thought there was something with Spherical harmonics but since support for that was added, i’m thinking if I see the same issue as ou describe here - with a lot of transparent gaussians. I too created my dataset using Olli’s camera array tool in blender.
Postshot:
Supersplat:
See how it looks like the surfaces are almost scratched with something:
Here is my opacity data:
Really curious on how this can be remedied or worked around.
Regards
We might just have to bite the bullet and switch to a f32 frame buffer. I’ll ask @slimbuck to revisit this when he’s back from holiday on Monday.
Fortunately we can very easily update supersplat to render float32, but what about runtime? If users want to use these models at runtime also, then that would require float32 target there too.
Yes, good questions.
Would you say this level of opacity data is unusual? is there something in the synthetic render process that pushes the opacity data to be this way?
This is the question. I have no idea. Important to find out.
