But that screenshot above is with logarithmic depth disabled. When it’s enabled, the fragment shader writes depth, overriding the effect of the polygonOffset, and we’re back at the first screenshot above.
Looking at other parts of the Cesium code that use polygonOffset, it seems like the Vector3DTilePolygons will have the same problem. Perhaps it was written before Cesium used logarithmic depth?
In any case, I was wondering if you guys have already thought about how to combine polygonOffset with logarithmic depth. Presumably the fragment shader needs to apply the depth offset manually, but the code to mimic the fixed-function behavior isn’t at all obvious to me, and the internet is surprisingly unhelpful.
If I get this working reasonably well, my plan is to define a glTF extension for outline rendering in my fork. Happy to PR it upstream if it’s something others might be interested in.
But that screenshot above is with logarithmic depth disabled. When it’s enabled, the fragment shader writes depth, overriding the effect of the polygonOffset, and we’re back at the first screenshot above.
Looking at other parts of the Cesium code that use polygonOffset, it seems like the Vector3DTilePolygons will have the same problem. Perhaps it was written before Cesium used logarithmic depth?
In any case, I was wondering if you guys have already thought about how to combine polygonOffset with logarithmic depth. Presumably the fragment shader needs to apply the depth offset manually, but the code to mimic the fixed-function behavior isn’t at all obvious to me, and the internet is surprisingly unhelpful.
If I get this working reasonably well, my plan is to define a glTF extension for outline rendering in my fork. Happy to PR it upstream if it’s something others might be interested in.
It basically just subtracts a fixed amount of the depth value. It works well when the polygons are facing the camera, but it’s not great when the polygons are at an angle to the camera because it doesn’t scale the depth adjustment with the Z slope the way polygonOffset does.
Sorry Chris, I haven’t run into that as I’m not using pickPosition for much of anything. I suspect that will be a difficult problem to solve completely. Perhaps choosing the value to subtract more carefully would help, but if you’re adjusting depth at all then certainly a position computed from depth will be affected.
I just realized I overlooked a simple solution when I responded before. We just need to disable the depth adjustment during the pick rendering pass. Unfortunately the pass isn’t a parameter to the function where the adjustment is added, but it should be possible to weave it down through.
