Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable improved depth testing for all billboards #6802

Closed
wants to merge 8 commits into from

Conversation

hpinkos
Copy link
Contributor

@hpinkos hpinkos commented Jul 13, 2018

Fixes #6762

Now that we can do the billboard depth texture lookups in the vertex shader, I think it's safe to enable this option for all billboards instead of only when they're clamped to ground.

I did some performance testing using some of our sandcastle examples like the KML, BillboardClampToGround and Billboards Instancing Sandcastle examples and saw no differences in performance.

@bagnell can you review?

TODO

@cesium-concierge
Copy link

Thanks for the pull request @hpinkos!

  • ✔️ Signed CLA found.
  • CHANGES.md was not updated.
    • If this change updates the public API in any way, please add a bullet point to CHANGES.md.

Reviewers, don't forget to make sure that:

  • Cesium Viewer works.
  • Works in 2D/CV.
  • Works (or fails gracefully) in IE11.

I am a bot who helps you make Cesium awesome! Contributions to my configuration are welcome.

🌍 🌎 🌏

@hpinkos
Copy link
Contributor Author

hpinkos commented Jul 13, 2018

I also bumped up the default depth testing range from 2000 to 4000. I found 2000 to be a little too close in practice.

@hpinkos
Copy link
Contributor Author

hpinkos commented Jul 13, 2018

Well, now that I increased the range I do see a bit of a performance hit for a lot of billboards in a small area.

Sandcastle

I think I'll put this behind a flag instead. I'm thinking it should default to true and people can disable it if they're seeing a performance impact and they don't need the feature.

@hpinkos
Copy link
Contributor Author

hpinkos commented Jul 13, 2018

Actually, I'm not sure if it's a performance issue. There's something weird with zooming in and out though when you're at this angle:

image

The FPS doesn't drop and panning around still works fine, but zooming in and out kind of stops working.
@bagnell do you have any idea why that would be?

@bagnell
Copy link
Contributor

bagnell commented Jul 16, 2018

Looks like the zooming problem is the camera picking the depth buffer for the collision detection and it's picking the billboards. The problem is that billboards are pushed to the near plane when within the disabled depth test distance. I'm not sure how we fix this. There is a fallback for picking the terrain using ray-triangle intersections but we rely on picking the depth buffer so the camera doesn't go through 3D Tiles.

@hpinkos
Copy link
Contributor Author

hpinkos commented Jul 17, 2018

@bagnell okay, so this is an existing issue with disableDepthTestDistance

@pjcozzi what do you recommend we do here?

@pjcozzi
Copy link
Contributor

pjcozzi commented Jul 18, 2018

The problem is that billboards are pushed to the near plane...

What are the other options:

  • Separate depth buffer for collision detection / environment - doesn't need to be a separate render pass could just GPU-to-GPU copy the depth buffer - this is also needed for polylines on 3D Tiles, CC @ggetz
  • Maybe a gl.clear at the right time with a separate render pass for billboards/labels/points. I dunno.
  • Bump by a fudge factor instead of all the way to the near plane? Could be hard in practice.

We should also ask if we ever want collisions with billboards/labels/points, I suspect not.

Perhaps also chat with @lilleyse if he has bandwidth and ping me if you run out of ideas.

@bagnell
Copy link
Contributor

bagnell commented Jul 18, 2018

Separate depth buffer for collision detection / environment - doesn't need to be a separate render pass could just GPU-to-GPU copy the depth buffer - this is also needed for polylines on 3D Tiles, CC @ggetz

There are no GPU-to-GPU copies for depth buffers.

Maybe a gl.clear at the right time with a separate render pass for billboards/labels/points. I dunno.

We can't clear the depth since we determine whether to depth test in the vertex shader. Some billboards may need to be depth tested while others are moved to the near plane so they are not.

Bump by a fudge factor instead of all the way to the near plane? Could be hard in practice.

This could work, but I also think it could be hard in practice.

Other options:

  • Have two depth buffers and use the previous depth to render the billboards and the current depth for collision detection.
  • Render billboards last and have them enable the depth test but disable depth writes.

With both of these options, pickPosition wouldn't work on billboards.

@bagnell
Copy link
Contributor

bagnell commented Jul 18, 2018

For testing, search for depthMask in BillboardCollection.js and set them to false.

Is there anything we can to for top-down views? The billboards blink in and out when zooming.
billboard_clamp_depth_test

@pjcozzi
Copy link
Contributor

pjcozzi commented Jul 19, 2018

With both of these options, pickPosition wouldn't work on billboards.

In general, we might need to embrace multiple depth buffers / masks - this is for collision, this is for picking, this is for rendering, etc.

If we resort to multi-pass, don't forget MRT...

If possible, would like to limit the amount of major re-architecture we need to do now.

@hpinkos
Copy link
Contributor Author

hpinkos commented Jul 19, 2018

Is there anything we can to for top-down views? The billboards blink in and out when zooming.

@bagnell I added a value to the depth check. It seems to fix the flickering without causing the billboards to show through the terrain when they shouldn't.

@bagnell
Copy link
Contributor

bagnell commented Jul 19, 2018

Top-down views look much better for the linked Sandcastle example.

@@ -328,16 +328,18 @@ if (lengthSq < disableDepthTestDistance) {
vec4 pEC1 = addScreenSpaceOffset(positionEC, dimensions, scale, vec2(0.0), origin, labelTranslate, pixelOffset, alignedAxis, validAlignedAxis, rotation, sizeInMeters, rotationMatrix, mpp);
float globeDepth1 = getGlobeDepth(pEC1);

if (globeDepth1 != 0.0 && pEC1.z < globeDepth1)
float depthsilon = 10.0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where did you come up with 10.0? Have you tested other areas of terrain?

Great variable name.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I tested on both flat areas and mountainy areas. 10 was the lowest value that mostly got rid of the flickering. Other values I tested like 5 and 7 still had a lot of flickering when the terrain had more drastic slopes

@bagnell
Copy link
Contributor

bagnell commented Jul 20, 2018

I'm seeing 10 test failures for billboards and labels.

@hpinkos
Copy link
Contributor Author

hpinkos commented Jul 23, 2018

@bagnell fixed the test failures. I changed billboard.disableDepthTestDistance to default to undefined instead of 0. That way the end user can explicitly set it to 0. Otherwise it defaults to 5000 for the depth test thing.

Let me know when you're free to chat about the camera collision thing

@@ -682,14 +684,16 @@ defineSuite([
it('adds and renders a billboard', function() {
billboards.add({
position : Cartesian3.ZERO,
image : greenImage
image : greenImage,
disableDepthTestDistance : 0.0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you have to explicitly set disableDepthTestDistance for this to pass?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't think we have to, but when they're both set to the default 5000 the wrong one renders in front. Should I open an issue? I'll see if I can reproduce it for a normal case. Would it be weird for this since there's no globe and it's at 0,0,0?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bagnell yeah it looks like it's a bug with disableDepthTestDistance. I can reproduce it pretty easily, I'll open a new issue

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's because the disableDepthTestDistance is greater than the distance from the camera to the billboard

@hpinkos
Copy link
Contributor Author

hpinkos commented Jul 25, 2018

After a discussion with @mramato, I don't want to merge this in until #6840 (and ideally #6838) are fixed. I ran the KML example in sandcastle and you can run into the bad mouse behavior pretty easily. I don't think it makes sense to put this behind a flag because then we're more-or-less pushing through a feature that is fundamentally broken for no good reason other than to get it in. It's currently enabled for billboards that are clamped to ground which I think covers the most common use case for this anyway. We'll just leave it at that for now.

@hpinkos
Copy link
Contributor Author

hpinkos commented Jul 25, 2018

I had a few minor fixes in this PR, I'll open up a new PR for them

@cesium-concierge
Copy link

Thanks again for your contribution @hpinkos!

No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?

I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.


I am a bot who helps you make Cesium awesome! Contributions to my configuration are welcome.

🌍 🌎 🌏

@hpinkos
Copy link
Contributor Author

hpinkos commented Dec 12, 2018

@cesium-concierge stop

@hpinkos
Copy link
Contributor Author

hpinkos commented Feb 21, 2019

Closing this since we probably won't be able to merge this in the near term

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants