1. A concise explanation of the problem you’re experiencing.
The problem is that when there are many small points on the globe and a couple polygons. The globe crashes. I would estimate the number of objects on the screen would be 20,000-40,000. When I run the scenario I am running more objects keep getting added. I am only running on a Quad core cpu and nothing I am drawing is using the GPU.
3. Context. Why do you need to do this? We might know a better way to accomplish your goal.
I need to be able to support large scenarios where there would be multiple objects flying on the screen. Its kinda like a stress test and to prove that the system can handle a heavy load. So do you guys know how to optimize cesium for these large scenarios I need to support?
When it crashes, what kind of error do you get? Can you post the error text here or a screenshot of it?
Generally tiling your data so it’s not all displayed at once or at the highest resolution is the solution to having massive amounts of data like that. 3D Tiles can do this for a lot of 3D formats and point clouds. For example, this LiDAR dataset of Montreal is about 10 billion points:
In this case, they’re static, but some people have used 3D Tiles for time dynamic data, like visualizing the data an autonomous vehicle records as it moves:
Supporting time dynamic data with 3D Tiles is something we’re still working on, as well as being able to tile shapes like polygons (which would require vector tiling). I talked a bit about that in this forum thread that asked a similar question here: https://groups.google.com/d/msg/cesium-dev/G_0tzm6dvwA/Vi3OnyQNDQAJ
So I’ll have to check when it happens again. When it happened the first time the screen just froze and nothing happened. Another time the page went white . I did not have a debugger up to see if there was any error logged out.
Here is the error I get when cesium crashes
<— Last few GCs —>
[16392:0x106b880] 422584 ms: Mark-sweep 1404.4 (1494.4) -> 1404.4 (1493.4) MB, 1247.3 / 1.1 ms (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 1248 ms) last resort [16392:0x106b880] 423812 ms: Mark-sweep 1404.4 (1493.4) -> 1404.4 (1493.4) MB, 1228.1 / 1.0 ms last resort <— JS stacktrace —>
==== JS stack trace =========================================
Security context: 0x2e3b277e3019 <String: http://localhost:8080>
1: add [http://localhost:8080/Build/Cesium/Cesium.js:~476] [pc=0x6581b94aacc](this=0x203871c28c39 <a h with map 0x11f2ad288b31>,e=0x15e4f7916b69 <an Object with map 0x3de7a6002201>)
Received signal 4 ILL_ILLOPN 7fbe26020dd5
r8: 000000000000016e r9: 00007fbe08000868 r10: 0000000000000000 r11: 0000000000000170
r12: 00007fbe285812bb r13: 00007fbe285812bb r14: 000000000106b8a0 r15: 0000012e81480000
di: 00000000010710d0 si: 00007fbe253d0c30 bp: 000000000106b880 bx: 0000000000000001
dx: 0000000001000000 ax: 000000000000063d cx: 0000000000000000 sp: 00007f fc8906afd0
ip: 00007fbe26020dd5 efl: 0000000000010202 cgf: ffff000000000033 erf: 0000000000000000
trp: 0000000000000006 msk: 0000000000000000 cr2: 0000000000000000
I’m not entirely sure what this could beOn Wednesday, September 11, 2019 at 3:21:50 PM UTC-5, Omar Shehata wrote: