Skip to content

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

Merged
merged 3 commits into from
May 21, 2018
Merged

Fix 3d stroke #2657

merged 3 commits into from
May 21, 2018

Conversation

Spongman
Copy link
Contributor

@Spongman Spongman commented Feb 20, 2018

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).

pi

@@ -23,7 +23,7 @@ uniform mat4 uProjectionMatrix;
uniform float uStrokeWeight;

uniform vec4 uViewport;
vec3 scale = vec3(1.0);
vec3 scale = vec3(0.9995);
Copy link
Member

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
Copy link
Member

@kjhollen kjhollen left a 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?

@Spongman
Copy link
Contributor Author

Spongman commented Mar 2, 2018

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.

FWIW: processing 3.3.6 also shows this behavior:
image

@kjhollen
Copy link
Member

kjhollen commented Mar 6, 2018

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.

@Spongman
Copy link
Contributor Author

Spongman commented Mar 8, 2018

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.

@stalgiag
Copy link
Contributor

stalgiag commented May 21, 2018

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?

@kjhollen kjhollen merged commit 964ca1a into processing:master May 21, 2018
@Spongman Spongman deleted the fix-3d-stroke branch May 21, 2018 22:08
@kjhollen
Copy link
Member

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!

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

Successfully merging this pull request may close these issues.

4 participants