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 ?
Is that so? Never noticed it actually. Let's test...
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.
Hi fleetwood,
You are correct that the offset value is multiplied by the final multiplier. This is mentioned in the docs BTW:
http://www.planetside.co.uk/wiki/index.php?title=Vector_Displacement_Shader
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
Thanks for the reply Jo, I tried your suggestion.
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.
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
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.
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).
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.
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.
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)
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
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
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
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.
I am trying your suggestion of one Add Vector of -0.25,-0.25,-0.25.
I have placed it directly between the Image Shader and the Vector Displacement.
It is producing the same "block" effect I want to get rid of.
Quote from: fleetwood on June 07, 2013, 08:00:15 PM
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.
I am trying your suggestion of one Add Vector of -0.25,-0.25,-0.25.
I have placed it directly between the Image Shader and the Vector Displacement.
It is producing the same "block" effect I want to get rid of.
Then I don't understand how you got rid of the block effect in your other image :o Your nodes would still have that effect because they operate on everything, they're not restricted to just the image projection. What am I missing?
Matt
Right this second I've just added some offset parameters to the Image Map Shader which should be useful in a future version.
Does C4D have any offset options on the displacement map export?
In the mean time, you could try multiplying your offset vectors by a mask (a white image with the same projection settings).
Matt
I don't see any offset options on the C4D side.
My hunch is that the nodes I came up with work because they cause offsets to balance in the middle.
I think that is the reason that the value 0.25 works instead of the more logical 0.5.
It seems that the vectors from the image are lowered by 0.25 while the planet is lifted by 0.25 (verified that Alt is 2.5m in the flat in the preview window, plus it can be seen in the render by the position of the Blue sphere located at 2.5 meters altitude).
I do know that my method only works with the individual X,Y,and Z vectors fed into the Build Vector.
I wonder if what happens inside the Build Vector when it is fed vectors is key.
Attached is the TGD with the EXR file I'm using if anyone would like to fool with it.
Is this the answer to your problem? In the experiments I did with VDisp by image map I had a black background, not gray.
Yes that's it !
Thanks Dune :D
Using the Vector Displacement as the child of a surface shader and blending back in a single Add Vector using blend as coverage allowed eliminating all of the extra nodes and keeps the planet at 0 altitude.
Just need one Add Vector now as Matt said. ( I have the Add Vector is set -0.46,-0.46,-0.46, which seems a little strange but that is
the exact amount needed to bring the displacement level. At least it is far closer to the expected -0.5)
A Plus is that the displacement has fewer distortions from what was modeled .
Quote from: fleetwood on June 07, 2013, 09:04:38 PM
I don't see any offset options on the C4D side.
My hunch is that the nodes I came up with work because they cause offsets to balance in the middle.
I think that is the reason that the value 0.25 works instead of the more logical 0.5.
It seems that the vectors from the image are lowered by 0.25 while the planet is lifted by 0.25 (verified that Alt is 2.5m in the flat in the preview window, plus it can be seen in the render by the position of the Blue sphere located at 2.5 meters altitude).
I do know that my method only works with the individual X,Y,and Z vectors fed into the Build Vector.
I wonder if what happens inside the Build Vector when it is fed vectors is key.
Attached is the TGD with the EXR file I'm using if anyone would like to fool with it.
Ah, I see what's happening now. Your vectors are being converted into scalars automatically when you plug them into the Build Vector. Now, because you subtracted 0.25 from them, this produces some negative values, but when these negative vectors are converted into a scalar they become positive again. This is similar to taking the absolute value (where negative values are reflected to become positive). It's a very unexpected way of solving the problem but it works in this case! :) However, you have to be careful with this method. If any of the values in the displacement map are below 0.25 then they will get clamped and reflected back in the other direction.
Matt
Quote from: fleetwood on June 08, 2013, 01:08:32 PM
Yes that's it !
Thanks Dune :D
Using the Vector Displacement as the child of a surface shader and blending back in a single Add Vector using blend as coverage allowed eliminating all of the extra nodes and keeps the planet at 0 altitude.
This isn't right. You need to mask it with a value of 1 wherever the image is. That's why I suggested masking/blending with a second image map shader with a white image. If you mask by the original vector, you're distorting the values.
Matt
Thanks Matt for looking into this.
Using a pure white image mask as a blender is working perfectly to show all the displacement including the lowest portions
and the amount subtracted from the original vector is the now the anticipated -0.5, -0.5, -0.5.
Thanks again for all the information and help.
Great :)
A simple shape shader of 10x10 will as well as a blender.
Quote from: Dune on June 09, 2013, 03:14:10 AM
A simple shape shader of 10x10 will as well as a blender.
Only if you can guarantee that the border blending will be the same ;)
Yes. In this case it was, and when I made it a circle of 10x10 it also worked as that was obviously slightly smaller than the max map size (apparently).
Hello. I am studying with a very wonderful Tpic.
When connecting to the Surface layer, problems will occur in shadows.
Am I doing something wrong?
>> That's why I suggested masking/blending with a second image map shader with a white image.
The mask image is a blank image map.
You are masking by an image map. It's not included, so it's hard to see what's going on, but I guess it cuts off the displacement. Better check its location and settings, or include it in a zip.