How to debug cesium viewer freezing when rendering 3d tiles

CesiumJS
1

1. A concise explanation of the problem you're experiencing.

Hi everyone. I have a problem which I can't comfortably debug, hope you can help me advance.

CONTEXT
· I am experiencing this problem on Chrome 72.0.3626.12.
· I am using Cesium 1.52.
· I have uploaded a KMZ to my Ion account. Textured, about 3Mb.
· I want to display in an already existing application I'm developing.
· I am loading the Ion asset with the following code.

scene.primitives.add(
            new Cesium.Cesium3DTileset({
                url: Cesium.IonResource.fromAssetId(theAssetId)
            })
        );

· The asset loads succesfully (check with the Cesium.Cesium3DTileset readyPromise).

PROBLEM
When the camera gets into a position where the asset would be rendered, the viewer freezes.
It doesn't crash, throw any WebGL error or console error.
The viewer does not respond to any UI input, doesn't finish the rendering of imagery or tiles if any was ongoing, doesn't actually load the problematic asset.
Commands can be introduced at the Chrome Dev tools console without any problem. For instance, I can do a viewer.flyTo() to the asset and it runs fine in the console, but still nothing happens in the actual viewer.

MORE CONTEXT
Loading the same asset in a simple Cesium Sandcastle works fine.
The application where the problem is happening is loading other 3D Tiles without problems.

What troubles me the most is I know my description sounds kind of stupid taking into account it works on a Cesium Sandcastle, and thus the problem must be in my code. But I was wondering if you could help me find out how to debug this. Since it throws no errors, I'm kind of clueless.

Thanks a lot for your help.

Pablo

2. A minimal code example. If you've found a bug, this helps us reproduce and repair it.

3. Context. Why do you need to do this? We might know a better way to accomplish your goal.

4. The Cesium version you're using, your operating system and browser.

2

This does indeed seem strange that it happens in your app but not in Sandcastle.

You said it works in just a simple Sandcastle that loads the asset, but what happens if you start adding a bit more code from your application to Sandcastle? Are you able to recreate the freezing in Sandcastle at all? If so, I’d be happy to take a look at it.

How long have you waited when it was frozen? Have you checked the Task manager to see if it’s processing anything?

The other option would be to try and comment out parts of your application, to further try to isolate the issue.

You might also try using the performance tab in the Chrome debugger when it’s frozen to see what’s going on. It might give you some more information:

Let me know if you figure this out.

3

Hi Omar, thank you for your time.

Unfortunately, I can't disclose the code I'm running. About testing by parts on Sandcastle, it's quite hard to do since its a complex application with many JS files.

Actually, I removed all troublesome assets (and the code that loads them) and simply added it through Chrome Dev tools console code. It runs fine until I add the asset through the console, using the snippet I posted previously. So, it feels like the only problematic part is that one.

How long have you waited when it was frozen? -> More than a minute, no response.

I used the Performance Tab of Google Dev tools and it showed that absolutely no activity was going on after it froze (see attached picture).

Do you know if there's anyway to check in which line of code is the JS runtime working at? So that I could know where in the code everything stops so I can narrow down the issue?

Capture.PNG
Capture.PNG1892×133 5.62 KB

4

I would put a breakpoint using the Chrome debugger at the

scene.primitives.add

``

line in your application, for the offending asset. Make sure you’re using the unminified version of the CesiumJS source so that the code is readable. Another place to start would be the Cesium3DTileset update function, which is where most of the processing is initiated:

https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Source/Scene/Cesium3DTileset.js#L1974

I’d make sure only the problematic tileset is added to the scene when putting a breakpoint there since all tilesets call this function every frame.

5

Hi Omar, thanks for the tips. I'll try that and let you know what I find out.

6

Omar, I tried to debug scene.primitives.add. I went step by step, going down a few levels on the stack call, and everything looked normal. It seems the resources is loaded correctly (which is aligned with the fact that the ready Promise fires up correctly).

So I guess the problem is not related with the loading of the asset but with the rendering. Any ideas on how to explore that?

7

Did you try putting a breakpoint in the Cesium3DTileset.update method that I linked to in my last post? That happens on every frame before rendering.

8

I just did that. Execution runs constantly through that function without any exceptions. I tried to understand what's going on but I am by no means an expert, so I couldn't really draw conclusions.

Is there any specific part of the function I should focus on?

Also... since controls are not responding, is there any other part of the code related to that where I could also look for problems?

Thanks,

9

Extra info: I did the same debugging process with a working tileset (coming from a CityGML) and noticed that the isRender var (https://github.com/AnalyticalGraphicsInc/cesium/blob/ead9f36a9b155a1d2dada9f8724b531d09195c7a/Source/Scene/Cesium3DTileset.js#L2001) stays as false constantly in the troublesome one, while it is true many times in the one that works fine.

And so, the bad one never gets into the function processTiles (https://github.com/AnalyticalGraphicsInc/cesium/blob/ead9f36a9b155a1d2dada9f8724b531d09195c7a/Source/Scene/Cesium3DTileset.js#L2031).

Is that any help? Should I focus on finding out why isRender comes as false?