fix(grid3d): Color fighting with clamp color is fixed. #1998
Conversation
| @@ -26,7 +26,7 @@ vec4 getContinuousPropertyColor (float propertyValue) { | |||
|
|
|||
| vec4 color = vec4(1.0, 1.0, 1.0, 1.0); | |||
| float x = (propertyValue - colorMapRangeMin) / (colorMapRangeMax - colorMapRangeMin); | |||
| if (x < 0.0 || x > 1.0) { | |||
| if (x < 0.0 - 1e-6 || x > 1.0 + 1e-6) { | |||
There was a problem hiding this comment.
Is there a story where we can see this impact ?
There was a problem hiding this comment.
There was a temporary story for testing the impact but I don't realize what a permanent story is supposed to demonstrate.
There was a problem hiding this comment.
Stories are tested automatically. Thus the storybook also acts as tests for webviz.
There was a problem hiding this comment.
Agree with @t0oF-azpn, it would be good with a story that demonstrates the issue that this fix solves.
There was a problem hiding this comment.
Added a story which can reproduce the issue if tolerance is not used in the fragment shader.
The functions are refactored. The story shows the correct image for the case when there are cells with property values exactly equal to colorMapRange min or max. Without the fix in the fragment shader this image is corrupted with visual artefacts. I have no idea how to trigger the artefacts in the storybook except exposing a special layer prop. But... do we really want a prop of the sort in the public API? |
## [0.22.1](https://github.com/equinor/webviz-subsurface-components/compare/[email protected]@0.22.1) (2024-04-04) ### Bug Fixes * **grid3d:** Color fighting with clamp color is fixed. ([#1998](#1998)) ([4b83d1a](4b83d1a))
|
🎉 This issue has been resolved in version [email protected] 🎉 The release is available on GitHub release |
Tiny tolerance value is now used to define when clamp color is to be used in the fragment shader.