-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
Fix 3d stroke #2657
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
Fix 3d stroke #2657
Conversation
src/webgl/shaders/line.vert
Outdated
@@ -23,7 +23,7 @@ uniform mat4 uProjectionMatrix; | |||
uniform float uStrokeWeight; | |||
|
|||
uniform vec4 uViewport; | |||
vec3 scale = vec3(1.0); | |||
vec3 scale = vec3(0.9995); |
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.
great! worth a comment here about what this is doing (moving closer to camera), but otherwise this looks good to me.
Add comment
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.
Hmm, something's not right here with test/manual-test-examples/webgl/immediateMode/mixTextureAndFill/
The outlines for all of the rectangles always show, regardless of render order (this is not currently true in master, where they layer / get occluded as expected). Is there another way to solve this without breaking layering?
ah, yes, well spotted! this was actually the previous behavior (in 0.5.16, demo here: https://codepen.io/Spongman/pen/YYEJjy?editors=0010). this was reported in #2105 & #2510, and 'fixed' in #2511 and #2515. i don't think there's any way (without huge architectural changes, scene graphs, etc...) to fix both problems at the same time. i think fixing the edge popping issue is probably preferrable here since it occurs in almost all cases and there's no workaround, whereas the edge z-fighting issue only occurs in the co-planar case and the workaround is pretty simple. |
just a note to say I'm thinking about this one! I'm not sure which mode to preference, here—need just a little more time to figure out what to prioritize, so we don't end up pushing bugs back and forth. |
merging this would still fix the stroke popping bug. i believe the fix in #2510 was actually in error, since the processing shader actually also exhibits the overlapping stroke issue. the main reason for using it is that it fixes the stroke issue in #2488. i think reverting to the behavior that existed since 0.5.15 is fine. |
I agree with @Spongman that it makes sense to prioritize the stroke-popping. It is pretty common to have coplanar z-fighting issues with any 3D graphics framework and learning how to quickly remedy it is maybe a useful part of learning how to work with 3D graphics. I agree that pushing the bugs back and forth isn't ideal but hopefully this thread could help deter that from happening in the future? |
thanks! fwiw, I encountered this issue in Processing for a project earlier this month and it was confusing. It doesn't really feel like a lesson in stacking and ordering objects in 3D graphics because it subverts the expectations of an end user. The fill ordering follows expectations (draw order) but the lines behave differently. It forces the end user to know that the lines are drawn in a separate render pass, at a different depth, and work around that. I think it's probably worth tracking this in another issue, in case someone has an idea for another render method that might fix it in the future! |
this fixes the webgl stroke popping & disappearing issues seen here:
https://codepen.io/Spongman/pen/JpLdao?editors=0010
it moves the strokes a tiny distance toward the camera, and halves the default stroke width (since previously half the stroke was usually hidden behind the face).