.spz file makes Studio AR experience crash

I’ve been working on a portal project that involves gaussian splats ei .spz file format. The experience seems to work fine when the splats are less than 35MB or so but when they go above 60MB it crashes without any errors visible in the console. Is this to be expected?

Hmm, 60 MB for a web asset seems really high in general, so I think it’s a bit expected. However, I can certainly make the engineering team aware of this.

Can you share the .spz file with me, so we can take a look?

I’ve kept cropping it more and more. The latest run was output_V20 with 30MB and still crashing.

OneDrive Folder Splats

The previous splat was 24MB and worked. So it’s odd to me.

It also renders fine within Studio on Desktop:

I am getting all these warnings though I’m not sure its related?

I’ve even cropped down the splat to 25.8MB. Less than 2MB more than the splat I did on my phone and still having the loading issue. is there an internal cap that is preventing this maybe?

Those warnings shouldn’t be affecting it. Can you send me a download link, for the uncropped 60 mb Splat, that doesn’t require logging in?

1 Like

This should not require sign in to download but let me know? I can find another way.

output_V20.spz

Got it. Taking a look.

1 Like

I think it must be something in the files itself that is causing some sort of error with how 8th wall studio handles .spz files. Because I trimmed this spz down to 17MB and it’s still making the phone experience crash while it renders fine in the viewport on desktop.

And the version I did on my phone with scaniverse works fine at 24MB but looks pretty bad.

@GeorgeButler could it not be because of WebGL: non-portable extension enabled: WEBGL_polygon_mode ?

It looks like relying on this extension could lead to inconsistent rendering on various devices, specifically mobile.

Has there been an update recently that causes spz files to not render consistently?

I spoke with the engineering team, and the issue is related to the number of Gaussians and the fact that they’re not opaque, so they can’t occlude each other. This leads to excessive overdraw, which can crash the browser.

I recommend cropping the Splat into two or three smaller Splats and assembling them in Studio. This should help reduce overdraw and improve performance.

But what is strange is that I went back to using a basic scaniverse splat and some people that tested the experience get an error saying “A problem repeatedly occurred..” on black screen or the experience does a white flash and refreshes entirely.

A problem repeatedly occurred..

Is what you see from the Browser when the tab has crashed. I would expect this from the heavy Splat.

Ok I’ll try to trim but 24MB doesn’t feel heavy and this one is coming from scaniverse so I’m assuming it does have the opaque Gaussians.

And it’s not possible at this time to crop .spz directly right? I have to convert to .ply → crop → convert back to .spz?

All gaussians are not opaque, that’s how Gaussian Splatting works.

Can you try scaling the Splat up in Studio by about 10x? I would guess that would help with performance as it will reduce the overdraw on the screen at any given point.

Oh ok haha!

Yes I could try scaling it up by a lot to try to space the blobs out. I will also have to scale up my portal opening proportionally. Let’s see what happens. Thank you for hour help George!

1 Like

@GeorgeButler I also tried to split the splat into 3 different files but then there some strange rendering that happens where the piece that is behind is rendered in front . Do you knwo of any tips to deal with this?