0
$\begingroup$

I have made this Capsule.

Now I've made it like this and set the color ramps blue color to 0.499 and it works fine here: enter image description here enter image description here

But when I set the color ramp to 0.5 now the "Material preview" and "Render Preview" don't match.

enter image description here enter image description here

Could someone please help me to understand why this is happening?

I tried setting the texture coordinates in the shading editor too but still it does the same thing there is no difference.

Solution :

I plugged the position node into the value socket of "Store named attribute" and now it works better than before. Now I can set the value of both colors to 0.5 and have the same image in render and material viewport. also now when i try to adjust the gradient node using mapping node its less sensitive and jumpy in the middle and its actually very smooth transition.

enter image description here

enter image description here

But still I don't know how this works. why using position made it much smoother and not jumpy at all while adjusting it using mapping node?

$\endgroup$
3
  • 1
    $\begingroup$ Using Blender 3.6.5, I fail to reproduce what you show when changing the Color Ramp position from 0.499 to 0.5. The view in Shading Editor and 3D Viewport are always coherent. However, the transition between blue and red shifts a lot between 0.499 and 0.5. I notice that you capture in GN the UV Map before moving the top cap. So UV map in the "equatorial" region is strongly stretched (to view that, replace the Gradient Texture+Color Ramp nodes by a single Checker Texture node). My guess is that you are experiencing round-off errors because of this stretching. $\endgroup$ Jan 22 at 21:33
  • $\begingroup$ Thanks @StefLAncien ❤️👍 I tried EVEE and it looks fine there its in the cycles that gets distorted. also i tried Checker texture I divided the uv maps V component (same as Y axis) using vector map and got it precisely centered then I deleted Checker texture and add color ramp and gradient texture back but it still didn't work. its nothing serious. I was curious why this is happening. $\endgroup$ Jan 23 at 7:59
  • 1
    $\begingroup$ Eventually, I succeed to reproduce what you show by switching between Eevee and Cycles Render Engine. May I recommend that you change in your title "Material Preview" by "Eevee" and "Render Preview" by "Cycles" ? $\endgroup$ Jan 23 at 20:56

1 Answer 1

1
$\begingroup$

(Using Blender 3.6.5)

The issue about rendering with Eevee or Cycles yielding different shading seems related to sensitivity to numerical round-off. To illustrate this point of view, two approaches to distribute a Color Ramp along the Z axis are compared using both render engines.

Results with both render engines

1. The sub-figure labelled Mesh shows wire edges. The geometry is made of a UV Sphere with upper vertices shifted by 2 times its diameter along Z direction. Before this deformation, the original UV Map is stored in an Attribute named UVCAP. As a consequence, this UVCAP field is highly stretched in Z direction in the region at mid-height of the original UV Sphere.
2. The Shader Editor shows the Color Ramp tailored for the demonstration. Symmetric colour variations are restricted around mid-range. Blue starts at 0.0 ; Green starts at 0.45 ; Magenta starts at 0.49 ; Yellow starts at 0.5 ; Cyan starts at 0.51 ; Red starts at 0.55.

3. The original shading approach, which nodes are labelled (1) in the Shader Editor view, is based on the gradient, after rotation, of the stored attribute UVCAP.
3.1. The sub-figure labelled Eevee (1) shows the colours distribution using Eevee render engine. It is noticeable that the colour strips width is not symmetric, whereas the Color Ramp is symmetric. Green and Cyan strips width should be equal; it is the same for Magenta and Yellow strips. The limit between Magenta and Yellow, at position 0.5 in the Color Ramp, should be at mid-height.
3.2. The sub-figure labelled Cycles (1) shows the colours distribution using Cycles render engine. It is not symmetric neither. Furthermore, the transition between adjacent colours is at different Z position comparing both render engines.
3.3. As a conclusion, this shading approach seems unreliable as the conversion from the UVCAP field to the Color Ramp factor is sensitive, because a small variation of this factor spans a large variation of Z. A slight numerical truncation might lead to a significant shift of colours.

4. An alternative shading approach, which nodes are labelled (2) in the Shader Editor view, is based on Z coordinate. The Texture Coordinate node delivers positions normalized between 0 and 1, through its Generated socket. Only the Z value is considered and it is subtracted to 1 to keep the same slope as the Gradient Texture node (i.e. Red at bottom and Blue at top positions).
4.1. The sub-figure labelled Eevee (2) shows the colours distribution using Eevee render engine. Colour strips width is symmetric and the Magenta-Yellow transition is at mid-heigth.
4.2. The sub-figure labelled Cycles (2) shows the colours distribution using Cycles render engine. The colours strips width and position are almost similar comparing both render engines. But it is to notice that these are not identical, suggesting that computations are different, as well as numerical truncation.
4.3. As a conclusion, this shading approach is more robust.

Resources:

$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .