Performance issue with Primitives after upgrading to b27

CesiumJS
1

Hey all,
So, I updated my GIT repository today from b22 to b27 after a couple months of being side-tracked with other tasks. I haven’t kept up with the goings-on here for several months so I’m hoping something very obvious has changed that I missed, but I’m experiencing a big performance hit using Primitives after upgrading to b27. To verify, I went out and tried the Sandcastle demos and I have the same problem with any demo that has Primitives. When those demos load, my entire desktop gets laggy, and the Cesium framerate drops from 60fps to ~10 fps with just one primitive in the scene. Performance picks up as I shrink the browser window.

Have the minimum hardware requirements changed? Have there been significant changes to primitives? I’m assuming this is a problem with my machine, but if I use my same application with the b22 build instead of b27, everything works smoothly, and I’m not sure why. I’ve looked through the last few months of discussions but nothing jumped out at me…

Eric

2

Hi Eric,

Welcome back. You should not see a performance hit like this. If anything, you should see a performance increase with the new-ish geometry and appearances work. Are you using Chrome or Firefox? Are your drivers up to date? Are you getting software rendering? What does your webgl report look like? Can you post the Sandcastle example that is getting poor performance?

Thanks,

Patrick

3

Hey Patrick,
It is good to hear that things should be better and the hardware requirements haven’t changed. This must be something on my end, and I’m really confused by it.

My device drivers are up to date, and we get the same performance issues on all the machines here that we’ve tried it, even though we all have different machines. I also got the same issues whether I deployed a pristine Cesium build to a node.js server or our Weblogic Application Server. We’re all using Chrome, we are unable to try Firefox due to corporate restrictions. I am getting software rendering but when I zoom, rotate, or tilt, or interact with the browser in anyway, the frame rate drops and the display is slow to respond to mouse inputs and the playback gets very choppy. As far as the Sandcastle Demos:

3D Models is particularly unresponsive, and sometimes it doesn’t load successfully for me, I have to refresh the browser to get it to load successfully. I run at about 5-10 fps if the aircraft is in view, and if I zoom out and rotate the globe so the aircraft is no longer in view, the frame rate jumps up to 50-60 fps.

CZML Sensors is very unresponsive when I’m zoomed in, runs at 3-5 fps…when I zoom out I get 12 fps and things run fairly smoothly but still hitch once a second. Sometimes I get errors when loading this demo as well, and I have to refresh the browser to load it successfully.

Cesium Inspector is choppy as well, I get about 12-15 fps when zoomed out and only 5 fps when I zoom in on one of the boxes. If I remove the primitives, those numbers jump to 25-30 fps and 15 fps respectively. Things seem normal at 30fps. If I zoom way out without the boxes, I eventually hit 60fps.

Polylines runs around 10-11 fps no matter how far out I zoom and is pretty unresponsive. Again when I rotate the camera around the earth so the polylines are no longer in view, the fps jump to 40-50 and everything runs well.

Does this help at all? I’ll post my webgl report in a minute.

Eric

4

Hey all,
So, I updated my GIT repository today from b22 to b27 after a couple months of being side-tracked with other tasks. I haven't kept up with the goings-on here for several months so I'm hoping something very obvious has changed that I missed, but I'm experiencing a big performance hit using Primitives after upgrading to b27. To verify, I went out and tried the Sandcastle demos and I have the same problem with any demo that has Primitives. When those demos load, my entire desktop gets laggy, and the Cesium framerate drops from 60fps to ~10 fps with just one primitive in the scene. Performance picks up as I shrink the browser window.

Have the minimum hardware requirements changed? Have there been significant changes to primitives? I'm assuming this is a problem with my machine, but if I use my same application with the b22 build instead of b27, everything works smoothly, and I'm not sure why. I've looked through the last few months of discussions but nothing jumped out at me...

Eric

WebGLReport.jpg
WebGLReport.jpg700×1131 90.5 KB

5

Eric,

The WebGL Report looks fine. Do all the machines have the same GPU and driver?

I suspect something is forcing software rendering. Do you get the slowdown if the scene contains all opaque geometry? We redid the translucency rendering path in b27. Try setting:

scene.fxaaOrderIndependentTranslucency = false;

Patrick

6

Patrick,
Thanks for the reply. Translucency does seem to be the issue, when all the primitives are opaque things run smoothly. Turning off fxaaOrderIndepentTranslucency results in a minor improvement, but the scene is still pretty unusable.

Is this related to my post in a previous thread? If so then I appreciate the work, and I will likely need the changes. I have an ATI Radeon HD4550 installed on the machine I’ve been given to test with, maybe it’s just too under-powered to run the new changes at 2560x1440 resolution. Things do run better at 1920x1080. I’m not sure yet what the specs are for the hardware we will be deploying on but I will try and find out. It makes me a little nervous that our hardware might not be good enough to run translucent primitives now, but hopefully since we’re purchasing new machines they will be sufficient.

Eric

7

Eric,

The new translucency is beyond what I mentioned in that thread. A new paper came out in December that solves the translucency problem for intersecting objects so we implemented it for b27.

That GPU is pretty low-end but it should still be OK. If the driver is up-to-date and you’ve tried the latest version of Chrome and Firefox, I would expect reasonable performance. The WebGL Report shows that Multiple Render Targets are not supported, which means that we have to draw translucent objects twice, but this is not a huge performance hit, especially if there are only a few translucent primitives. It’s possible that the texture formats - which are required - are forcing software rendering.

To use b27, you could hack-up Scene.js to use the old translucency technique, but it won’t fully fix your translucency artifacts. It is already there for old hardware so you’ll just have to change a flag or two.

Patrick

8

Patrick,
Translucency is definitely the difference, I tried the demo at http://bagnell.github.io/cesium/Apps/Sandcastle/gallery/OIT.html and when I switched to alpha-blending instead of OIT with Multiple Passes, performance returned to what I am used to. But yes, I do need those changes. I feel better knowing what the issue is, I’m sure I’ll be able to figure out a way to work with any graphical limitations we have.

Thanks,
Eric