RenderState and Custom Volumes

I’m seeing some undesirable lighting and blending behavior on my custom volume in 3D mode. I don’t know how to describe it other than each plane’s luminosity seems to change too drastically as I navigate around the scene. I’ve also noticed that my z-depth doesn’t seem to be correct when translucency is enabled. I captured both in this video: Lighting/Blending Video. In the first part of the video my PerInstanceColorAppearance has translucent : false, **faceForward **: *true *and everything else set to default. In the second part of the video I set translucent to true.

I’ve ensured my normals are all pointing away from the interior of the volume. If I set faceForward : false, I get this: No Face Forward Video
The outside of the volume looks correct when I enable translucency and back face culling (closed : true), but when I look into the volume from the end, everything disappears. I guess it considers every face a back face in that case, and since the volume isn’t truly closed on top, there’s nothing to show.

Are these expected behaviors? I’ve been banging my head against the wall with RenderState trying to improve this, but I’m not sure what all of the options are and how to use them.

Thanks,

Eric

Hi Eric,

For your first video, the artifact at 0:03 looks like the bounding sphere is too small. Have you tried to visualize it with debugShowBoundingVolume?

For the light intensity changing, it is because only diffuse light is being used by this appearance. You could hack the fragment shader to include ambient light (something we’ll add eventually) or create the appearance with flat : true.

For the z-value, when an object is translucent is reads, but does not, write z. Cesium doesn’t yet sort these back-to-front (which will also hurt performance), but even when it does, your case is hard because the geometries intersect each other, and need to be split for proper sorting. When the geometries are opaque, you won’t see artifacts because they both read and write z.

When closed : true, the behavior you get is expected. Only use this when the volume is completely closed like a box.

If you are interested in these graphics topics, check out this free short course: https://www.udacity.com/course/cs291

Also, for your videos, can you please use youtube? Among other issues, we do not have access to photobucket on our main network.

Patrick

Thanks for the tip Patrick, I will try and upload my videos to Youtube from now on. I’ll take a look at the fragment shader.

The bounding sphere looks correct, I use BoundingSphere.fromPoints() to compute it. I doubled it and visually verified it just to make extra sure, but I still see the same behavior. When I turn translucency on and look closely, I can see that the top planes don’t actually disappear, they just get really dark with one slight camera move, rather than gradually darkening. The bottom planes do disappear completely when looking directly into the volume, but as I pan underneath the volume they gradually become lighter.

Well, I’ve tried more troubleshooting with no luck. I’m not sure what’s causing the artifacts at :03. I’ll look into it later, but if anyone has any ideas, I’d appreciate them!

A large part of what I’m doing is visualizing ellipsoids around satellites as they intersect other geometries. I’ll be zooming in, out, and around the walls of these geometries, watching the ellipsoid as it intersects and travels into the volume. I’m doing this all through CZML (I’ve extended the CZML spec for my custom geometries.) So far it’s been a little disorienting to see these intersections since the ellipsoids and the volumes don’t render correctly due to the z-depth issue: Ellipsoid and Geometry Intersection Video.

Anyone have any thoughts on how to improve this sort of interaction given the limitations of the z-depth issue? I think if I wait until the Geometries and Appearances make their way to CZML, I may be able to use opaque volumes and ellipsoids to at least bypass the z-depth issue. I can also fix the camera at the point of intersection, which I plan to do anyway. But neither are ideal or complete solutions. I’d really like to show intersections like you guys do with cones and the earth, but it sounds like that likely won’t be possible. Do you think it will ever be possible for Cesium to determine the z-depth of these objects correctly?

Hi Eric,

Dan and I are starting to do some renderer changes, as part of our work on 3D models and to remove some other artifacts, that may help here. Specifically, we will be sorting translucent geometries back-to-front with the following limitations:

  • No sorting within a batch, i.e., geometry instances inside a primitive will not be sorted; the primitives themselves will be. Later, we may relax this at a performance cost.

  • Intersecting geometry will not be split. For example, if a plane interests a sphere, we will not split the sphere into two separate geometries for more precise sorting.

  • Large bounding volumes can cause imprecise sorting. For example, a large plane may be behind a small sphere but given a back-to-front sort of their bounding volumes, the plane may be determined in front.

If you can provide a sample CZML or code snippet, we’ll consider your use cases.

Patrick

Thanks Patrick, I’ll see what I can get you. My scenarios essentially amount to an ellipsoid intersecting an Extruded Extent, a CustomSensorCone, and a simple 4-point defined plane. All of these “volumes” will be huge, likely originating near the earth and extending out to the geo belt, so I would think #3 below will cause me problems. And if I understand #2 to mean that the sphere cannot straddle a volume that it’s intersecting and will instead be either completely visible or completely hidden behind the plane, that will cause me problems as well.
Thanks,

Eric

Eric,

Dan made some improvements in #1340.

This will land in master soon and will be part of b24 in January. It comes with the caveats I previously mentioned but is an improvement.

Regards,

Patrick

I just wanted to update this post because in b27 I still see the same issue with abrupt changes in lighting when setting faceForward : true. My artifact at :03 in the original video I posted here is apparently something the faceForward attribute is prone to produce. I recreated the issue with an extruded extent in Sandcastle, and I assume it could be reproduced with any of the geometries.

Here’s a repost of the original video, this time on Youtube

Here’s the same issue with an Extruded Extent

For now I’m planning on setting faceForward : false on my geometries and allowing the user to change it to true when needed, because there are definitely cases where it’s very helpful.

Eric