-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Extend GroundPrimitive shadow volume based on screen space error #4751
Conversation
Let's octencode this. See AttributeCompression.js. |
This should come from the terrain provider, but we can hard code it to the right min for Earth for now. @bagnell do you have it handy from STK? |
Update CHANGES.md. |
Perhaps there is a winding order issue: Click "Create large polygons" |
Related idea: at one point, I just tried to normalize the WGS84 position, to avoid storing an extra attribute, and it was very noticeably wrong at places like Mount Saint Helens. However, perhaps there is another way to compute a better approximation, but still not perfect. |
@hpinkos did you try using |
* @alias czm_geometricToleranceOverDistance | ||
* @glslUniform | ||
*/ | ||
czm_geometricToleranceOverDistance : new AutomaticUniform({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Distance
-> Meter
|
||
var fov = camera.frustum.fov; | ||
var viewport = this._viewport; | ||
if (viewport.width > viewport.height * camera.frustum.aspectRatio) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this check work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was just a straight port. Did I misinterpreted something? Here's the original source:
if ((double)mainViewport[3] > ((double)mainViewport[2] * p3dScene->pixelAspect))
{
pixelSizePerDistance = tan(0.5 * p3dScene->view.m_pCamera->FieldOfView()) * 2.0 / (double)mainViewport[3];
}
else
{
pixelSizePerDistance = tan(0.5 * p3dScene->view.m_pCamera->FieldOfView()) * 2.0 / (double)mainViewport[2];
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure mainViewport[3]
is width
? In Cesium, the array would be [x, y, width, height]
.
Are you sure pixelAspect
ratio is width / height
like aspectRatio
?
Perhaps ask Greg to double check these.
Right now, I think the if
statements reads like "if (width > (height * (width / height))", which is "if (width > width)"
float delta = min(u_globeMinimumAltitude, czm_geometricToleranceOverDistance * length(position.xyz)); | ||
|
||
//extrudeDirection is zero for the top layer | ||
position = position + vec4(extrudeDirection.xyz * delta, 0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use 0.0
, mixing integers and floats didn't use to compile on some WebGL implementations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
extrudeDirection
is a vec3
so we can remove the .xyz
.
What do you think about cleaning up the geometry types by adding adding a temporary @bagnell what do you think about this for vector tiles? Seems like we don't need to store the extruded direction in the payload. We could even separate out the bottom cap vertices so the I feel like we should do some fill rate tests before getting into all this. This should make a huge difference for horizon and 45 degree views depending on how well early-z does (even with early-z the rasterization load is very high). |
Just those comments for now. @hpinkos this will be a much appreciated fix! |
updates from review
@pjcozzi I believe I addressed your comments and fixed the problems you found with some of the geometries. I haven't done the octencodeing yet because I'm waiting to see if we want to change the |
Added in 2d50df1. This restriction was removed:
But the polygon is no longer drawn when the volume is drawn. |
Let's just move forward so we don't stall this. We can optimize later if we come up with a good idea. |
size: 1, | ||
datatype: WebGLConstants.FLOAT, | ||
getValue: function(uniformState) { | ||
return uniformState.pixelSizePerMeter * uniformState.maximumScreenSpaceError; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is constant per frame, right? Precompute and store in UniformState
.
* @type {Number} | ||
* @default 2 | ||
*/ | ||
maximumScreenSpaceError: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These two getters may not be needed after the about change.
Just those comments. |
@pjcozzi this is ready for another look. I fix the issues you pointed out and I added octencode for the new attribute. And I updated |
Oct-encoding is fine for lighting because the error isn't noticeable but it may be noticeable for geometry extruded with these normals. Have you seen this at all? |
I didn't see any noticeable errors, but I'll look more closely to make sure |
How many bits are we using? It should be OK if we use enough....more than lighting. For example, normals for rotation of instances in i3dm use 32: https://github.com/AnalyticalGraphicsInc/3d-tiles/tree/master/TileFormats/Instanced3DModel#oct-encoded-normal-vectors The paper has exact error bounds. |
Bump:
|
It uses |
* @param {float} range The maximum value of the SNORM range. The encoded vector is stored in log2(rangeMax+1) bits. | ||
* @returns {vec3} The decoded and normalized vector | ||
*/ | ||
vec3 czm_octDecode(vec2 encoded, float range) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll be pleasantly surprised if JSDoc handles function overloads, but it's not an issue now.
@pjcozzi no I don't see that on my machine. That's happening after the 32P update? |
I don't get this on Windows. Will test Mac/Intel now, hopefully the artifact is in master. |
Good news, it is in master. See #4820 |
OK, this is good! Please reply to all the forum threads. People will be thrilled! |
Fixes #4326
Fixes #4161
This extends the bottom of the shadow volume below the terrain based on the screen space error. The shadow volume is updated in the ShadowVolume vertex shader.
extrudeDirection
attribute. TheextudeDirection
is a normalized vector pointing in the direction in which the position should be moved in the vertex shader.extrudeDirection === Cartesian3.ZERO
because only the bottom positions need to be movedczm_geometricToleranceOverDistance
toAutomaticUniforms
pixelSizePerMeter
andmaximumScreenSpaceError
toUniformState
scene.globe.maximumScreenSpaceError
get piped through toUniformState
via theframeState
. Not sure if that's the best way to do this.u_globeMinimumAltitude
toGroundPrimitive.uniforms
.33000.0
, which is a magic number I found with testing. I'm not sure what this value should actually be.abs
it later when i find themin
between this value and the value computed using the screen space error.TODO
extrudeDirection
attribute