## Vector Displacement Shader : The offsets

Started by fleetwood, June 05, 2013, 11:52:15 am

#### fleetwood

##### June 05, 2013, 11:52:15 amLast Edit: June 05, 2013, 07:16:11 pm by fleetwood
I was under the impression from what Matt said that the vector offset parameters in the shader could alter the zero point of the vectors,
and compensate when you want gray to be considered zero instead of black.

I am testing using Y projection onto the planet surface.
Changing Any of the x,y,or z vectors offsets seems to move the entire displacement across the planet surface.

I would particularly expect a Y offset would either lower or raise the displacement but changing the Y value only
causes the whole displacement to give the appearance of moving sideways , not up or down .

What I have noticed is that really the Y offset causes the altitude of the planet's surface to shift up or down by an
amount equal to the Y offset times the vector displacement final multiplier value.

For example if my displacement is Y projected in size 100 by 100 at point 0x0 and have the
final multiplier set to 100, then setting an offset of Y -10 causes the altitude of the planets entire surface to
drop from 0 to an altitude of -1000.

I will post some renders of this with a reference grid when I am able.

What am I doing wrong ?

#### Dune

##### June 05, 2013, 01:17:38 pm #1
Is that so? Never noticed it actually. Let's test...

#### fleetwood

##### June 05, 2013, 07:03:51 pm #2
Some tests.
Colored marker spheres are at 150, 100, and 50 meters altitude over point 0,0.
Reference grid is Y projected 1000x1000 at point 0,0,0.
Image for the vector displacement is Y projected 100x100 at point 0,0.
Vector displacement has its XYZ functions all set to 1 with final multiplier set to 100.

When a Y Offset  of positive 1 is used the planet's surface raises by 100 meters as readout in the preview window
and shown by the position of the marker spheres.
Conversely when a Y Offset  of negative 1 is used the planet's surface lowers by 100 meters.

Camera position is the same in all renders.

#### jo

##### June 05, 2013, 07:25:08 pm #3
Hi fleetwood,

You are correct that the offset value is multiplied by the final multiplier. This is mentioned in the docs BTW:

However, this should be easily overcome. Use the XYZ multiplier parameters to scale the incoming displacements and leave the Final multiplier value at 1. This will mean that the offset will be the value you put in the field and not multiplied.

Typically other displacement shaders add the offset after the displacement has been multiplied. The Vector displacement node still does this, but it also has the additional Final multiplier value which scales the whole lot.

I have to say I'm not quite sure what's going on in the first part of the first message you posted. The second part of that message and the followup with the tests make sense to me though :-).

Regards,

Jo

#### fleetwood

##### June 05, 2013, 08:34:25 pm #4

However changing the final multiplier to 1 and the XYZ functions to 100 makes NO
apparent difference in the rendering of the vector displacement.

The problem is still exactly the same, which is to say that
Y Offsets appear to lift or lower the entire visible planet surface.
They do not move the displacement relative to the surface which was what I expected.
The displacement still sits above the new surface instead of  level with it.

It is entirely likely that I misunderstood, but I thought that one purpose of the offset was to negate that obvious  "block"  that the vector displacement generates and bring it down level with the surrounding surface.

Here is a new render with Y Offset set to -100.
The only effect of this appears to be to cause the entire planet surface to be lowered by -100 meters.

#### jo

##### June 05, 2013, 09:14:51 pm #5
Hi fleetwood,

Ah, I see what you mean now. Sorry for misunderstanding you. You're right that the offsets will shift the entire planet surface. I'll ask what the story is with that.

Regards,

Jo

#### fleetwood

##### June 05, 2013, 09:58:18 pm #6
Thanks Jo,

For what it's worth, a quick test shows that projecting the vector displacement onto a plane object acts the same.
Specifying a Y offset resulted in the plane object lifting or lowering.

#### Hetzen

##### June 06, 2013, 10:34:53 am #7 Last Edit: June 06, 2013, 10:36:45 am by Hetzen
I would have thought you would need a colour adjust shader to offset your grey value to black. Offset usually just adds/subtracts rather than stretch the 0 point in a vector.

Or, if your mid point is 50%grey in your map, you could multiply vector by 2 and subtract a vector of 1 (constant scaler can be used, as the same value will be used across x,y,z).

#### fleetwood

##### June 06, 2013, 05:19:07 pm #8
Thanks for the good ideas Hetzen.

I tried out both your methods, and either one successfully changes the gray to black.

Unfortunately the resulting renders don't come out any different.
The planet surface simply lifts or lowers depending on the new Y values produced by
the colour adjust or by the Multiply by 2 and subtract 1.

The big block below the desired displacement still exists, as the planet surface moves instead of the 100x100 displacement.

#### Hetzen

##### June 06, 2013, 06:38:35 pm #9 Last Edit: June 06, 2013, 06:40:25 pm by Hetzen
Pleasure Fleetwood.

Ok. It maybe that you need to isolate your vector displacement to the size of your map, ie you'll need to mask it from the rest of the planet. Difficult to be sure without seeing the network.

#### fleetwood

##### June 07, 2013, 05:14:50 pm #10 Last Edit: June 07, 2013, 05:19:17 pm by fleetwood
I finally had a bit of success at least in the matter in getting this vector displacement to sit level with the ground *.
I should say that this exr displacement map I'm using is nothing fancy, just a crude one I made in the sculpting features of C4D using the RGB (xyz object) option.

Essentially in Terragen I have subtracted 0.25 from the X,Y,Z vectors. But it did not work until I first broke them separately, while keeping them as vectors.
I found the amount 0.25 by trial and error.

I piped the Image Shader  to a Multiply Vector 0,1,0 to eliminate the green and blue and isolate the Y green part of the vector.
Then used a Subtract Vector of  0,0.25,0.

I did a similar process on each of the X and Z vectors isolating each one separately and then subtracting 0.25.
The three portions needed to be sent to the inputs of a Build Vector and then on to the Vector Displacement Shader.

Kind of messy but, haven't been able to further combine or simplify without spoiling the displacement.

( * overall planet surface altitude is still modified by this method)

#### Matt

##### June 07, 2013, 06:17:53 pm #11 Last Edit: June 07, 2013, 06:39:52 pm by Matt
Quote from: fleetwood on June 05, 2013, 08:34:25 pm

The problem is still exactly the same, which is to say that
Y Offsets appear to lift or lower the entire visible planet surface.
They do not move the displacement relative to the surface which was what I expected.
The displacement still sits above the new surface instead of  level with it.

It is entirely likely that I misunderstood, but I thought that one purpose of the offset was to negate that obvious  "block"  that the vector displacement generates and bring it down level with the surrounding surface.

Here is a new render with Y Offset set to -100.
The only effect of this appears to be to cause the entire planet surface to be lowered by -100 meters.

This is exactly how it should work. The vector offset is added to the input vector. Even if there is no input, the vector offset is still applied (so it can be used on its own as a constant displacement). The surface is displaced by these vectors (either the input, or the vector offset, or both). So if you add 100 in Y, you displace the surface upwards by 100 metres.

It can't restrict the offset to only the region where the image is, because it doesn't know where the image is. It just sees a vector (converted from a colour) which is sent by the Image Map Shader, which is 0 (black) outside the bounds of the image.

If you are working with an image that is projected over a limited area and you need to adjust for a different zero point in the image (which may be the case if you have a low-dynamic-range image such as an 8 or 16 bit image where values are restricted to the 0..1 range), then you will need to edit the image externally to offset all their values so that your zero-displacement is black. If your app exports an EXR displacement map, it should make sure that black means 0 displacement and negative displacements have negative pixels. If not, that's quite annoying!

Matt
Just because milk is white doesn't mean that clouds are made of milk.

#### Matt

##### June 07, 2013, 06:26:41 pm #12 Last Edit: June 07, 2013, 06:31:00 pm by Matt
Quote from: fleetwood on June 07, 2013, 05:14:50 pm
I finally had a bit of success at least in the matter in getting this vector displacement to sit level with the ground *.
I should say that this exr displacement map I'm using is nothing fancy, just a crude one I made in the sculpting features of C4D using the RGB (xyz object) option.

Essentially in Terragen I have subtracted 0.25 from the X,Y,Z vectors. But it did not work until I first broke them separately, while keeping them as vectors.
I found the amount 0.25 by trial and error.

I piped the Image Shader  to a Multiply Vector 0,1,0 to eliminate the green and blue and isolate the Y green part of the vector.
Then used a Subtract Vector of  0,0.25,0.

I did a similar process on each of the X and Z vectors isolating each one separately and then subtracting 0.25.
The three portions needed to be sent to the inputs of a Build Vector and then on to the Vector Displacement Shader.

Kind of messy but, haven't been able to further combine or simplify without spoiling the displacement.

( * overall planet surface altitude is still modified by this method)

I don't know why you'd need to offset by 0.25, but I can guess. What colour is the background plane (where you didn't sculpt) when you load the EXR into an image viewer? If it is grey, then it's probably 0.5 and you will need an offset of -0.5. If 0.25 worked better then it could mean the pixels are not being loaded as linear data. For this, see the Colour tab of the Image Map Shader. For EXRs, make sure that you check "data is linear" on the Colour tab. EXRs should be linear, but the Image Map Shader defaults to assume that they need to be converted with a gamma of 2.2 because that's usually the case with low-dynamic-range images (8 bit or 16 bit). For EXRs you don't want it to do this conversion. Not only would it change the offset, it would make the vectors incorrect.

Matt
Just because milk is white doesn't mean that clouds are made of milk.

#### Matt

##### June 07, 2013, 06:33:50 pm #13 Last Edit: June 07, 2013, 06:36:52 pm by Matt
Quote from: fleetwood on June 07, 2013, 05:14:50 pm
I did a similar process on each of the X and Z vectors isolating each one separately and then subtracting 0.25.
The three portions needed to be sent to the inputs of a Build Vector and then on to the Vector Displacement Shader.

You don't need to separate the components. A single "Add Vector" with the values (-0.25, -0.25, -0.25) would do the same thing. But see my above post about whether the value -0.25 is correct.

Not only that, all of these nodes do exactly the same thing as using an offsect vector of (-0.25, -0.25, -0.25) in the Vector Displacement Shader. The entire thing can be done with just an Image Map Shader and a Vector Displacement Shader. You don't need any of the other nodes to get the same result.

Matt
Just because milk is white doesn't mean that clouds are made of milk.

#### fleetwood

##### June 07, 2013, 08:00:15 pm #14
Thanks, Matt for the insights

I am using an EXR format map which is built on a plane object in C4D.
The background of the EXR is gray in a viewer.
I have been using the colour setting  Data is Linear in every render.
I did try the most straight forward connections first  Just can't find one that works.