While playing with Jon's (hetzen) Cubed noise I came across something
that was new to me.Found it pretty cool and hope some of you will like
it also.
It's all about the use of the Compute normal node.
For the following example the displacement is applied to a basic shape
- which is of course also displacement -located after the Compute terrain.
It is color based displacement applied via a Power fractal connected to the
displacement input of a Surface layer.
Noise flavour is Perlin ridges with mildly extreme settings for a better
visualization.
The first image shows the basic shape that is to be displaced.
It's done with a Simple shape shader.
[attach=1]
The second image shows the applied Perlin ridges noise in the top half
and in the bottom half you see the same with an added Compute normal.
It's inserted directly before the Surface layer with the displacement.
The reason why it's inserted there and not before or directly after the
compute terrain is that we want to displace along the normal of the
basic shape so it has to be placed after that shape.
[attach=2]
The third image shows the same as image 2 just with the addition of
a Transform input shader set to use World space.
[attach=3]
Some amazing differences,methinks.
If the basic shape is located before the Compute terrain the results
can be less dramatic.Will show that in the next post.
Now the basic shape is located before the Compute terrain.
The images show the differences between a setup where
the Compute normal is located before the Compute terrain
and one where it's located after the Compute terrain.
With and without Transform shader set to World space.
First is without World space.
[attach=1]
Second with World space enabled.
[attach=2]
Not that dramatic,but still noticeable.
It will give you different results with non color based displacement.
Also depending on where it takes place,before or after the Compute
terrain.I encourage you to do your own experiments with that,though.
Feel free to contribute to this thread.
Indeed, this is exactly why we recommend doing major displacement before the Compute Terrain where possible.
- Oshyan
Most excellent tut, J! Words go sooooo much further when accompanied by images.
But you wouldn't need a compute normal before compute terrain, as it's also computed in the CT. If you don't need the angles and heights at all, you can even do without a compute terrain. But I guess you have a CN first, then the displacement and then the CT for the rest of the line?
And setting the CT to small patch size also helps getting the normals calculated on a smaller patch, so more precise (which is quite logical).
Here's a quite epic post from Matt:
http://www.planetside.co.uk/forums/index.php/topic,1249.msg12539.html#msg12539
Quote from: Dune on November 13, 2014, 02:47:20 AM
... But I guess you have a CN first, then the displacement and then the CT for the rest of the line? ...
Nope,it was more like displacement first,then the CN then the CT.
Used the way you suggested only once some years ago iirc,then I
forgot about the CN.
Our recent discussion in the Rectangular Noise thread made me
think again.And since I like to work after the CT or without it this
comes in very handy.
T-U - Thanks,would not have remembered where to find that one.
Quote from: Tangled-Universe on November 13, 2014, 03:00:07 AM
Here's a quite epic post from Matt:
http://www.planetside.co.uk/forums/index.php/topic,1249.msg12539.html#msg12539
Thx for this link :D
If you perform a CN after a CT and then displace then the surface before displacement uses 2 different patch sizes for normals and UV's and I think that's where your differences are coming from.
A CN has a default patch size of 2, while a CT has 20.
So the CT evaluates the surface in patches of 20 meters and returns the updated normals and texture position (UVW-like I suppose).
If you then perform a CN you only update the normals of the terrain with a smaller patch size of 2 meters.
This allows the surface normals to change more rapidly over the surface, resulting in different displacement.
Since you're using colour based displacement you are working with different states in the network which I think lead to these results.
What happens if you use PF's as displacement with colour disabled?
On a side note, there's no need to do a CT for the flat surface of the terrain, then add simple shape shader and do CT again.
You can leave out the first CT in this situation.
Martin - As for the first part of your post that's beyond me to say anything
in regard to these aspects.
If you use PFs with color disabled other results show up as I mentioned
before.I could have shown some of those results,but decided to leave
that to you guys,because I think it's better to see that differences and
playing with the various methods for yourself instead of me teaching
the community things I don't understand myself.It's pretty complex.
At last everyone has to get it into their own heads.
But at least I can say it gets harder to displace laterally (still along normal)
when using color disabled PFs before the CT.And the CN makes sense again.
Try it and maybe you can teach us. ;)
Matt's post is really informative and there's no way I can describe it any better.
Otherwise just read it thoroughly, a few times.
I always read these technical posts with great interest, though not always with great understanding. It's been my hope thru some osmosis effect to awaken one morning to find I out I really do get it. :) Alas, not so far... J. Meyer, TU , Dune: thank you guys for carrying on these discussions in public! TU that's a great link, whenever Matt steps in to explain some aspect (a fundamental one here) of TG, I almost think I'm close to understanding, and just need a little more focus to grasp it. Yet, that link is 7 years old and so many of us are still struggling to apply that information. Normals, okay an easily understood concept. Patch size, again not that mysterious. Node linkage hierarchy, well that's where things break down (at least for me). There seems to be dozens of threads in this forum discussing how the hierarchical placement of nodes affects this or that, but not always with agreement of consistent logic or application. I realize TG is a very open ended creation machine, still the underlying processes are surely able to be 'mapped' out, a series of flow chart guides for basic operations of node networks. I have countless tgd's of node set-ups, some seemingly contradict each other while achieving equally successful results (fake stone set-ups come immediately to mind). Not to digress any further, just a spectator to the information flow, and appreciating the information shared.
J_Meyer, the guys are right. Those differences are coming from different patch sizes. What may seem logical on first glance, is to assume nothing should change. But your initial shape is being triangulated by the patch sizes when you use a compute node, so triangulating different patch sizes on top of each other will yield different reference points depending on which order they are set. Drawing a triangle on top of another triangle so to speak.
I tend not to like using the displacement tab in a PF, I find it difficult to track masks when displacement happens on displacement. So I tend to stick in the -1..0..1 scaler range to build a pattern, then multiply that output by the amount of meters I want to move something.
Try this, turn the colour roughness in the "Fractal terrain 01" PF in a default scene down to 1. Make sure Apply high and low colour is switched on and displacement switched off, then multiply that output with blue nodes by a value that is equivalent to displacement amplitude in the PF with a Constant Scaler, in this case 2000. Then plug the result into a Displacement node, you should have more or less the same terrain as if you had created it with the displacement tab in a PF. The advantage here is that you have full control over how you want to mix or temper your fractals, noises, or SSSs.. at an early stage that can be read downstream later on. Its also a really good way of building terrain around a scene focus, like a road.
Now take the input of the previous Displacement node and plug that into the y of a Build Vector node. Plug that into the function input of a Vector to Displacement node, then plumb that into your Base colours node attached to the planet. You should still have the same terrain as before. But now you have access to shifting x and z through y with another pattern via the Build Vector node x and z inputs.
Try multiplying another PF scaler (black and white) output with displacement turned off, apply colour on, roughness back to 1, and some tasteful scales, via blue nodes to a sensible size in meters and plug that into x of the Build Vector. Your terrain should now have shifted laterally in the x y plane, by the PF multiplied by meters. Notice that you haven't needed to use a Compute node to shift laterally. Cool huh?
This can all be done by displacement too, with a redirect shader as Matt suggested in the squared rock thread. Its essentially doing the same thing.
Zaxxon, TG gives you tools to do what you like how you like. Most shaders use "overloaded functions" which means, I can add one thing to another without defining what form that thing is in the first place. It means I can plug almost anything into anything, nothing will break, but something may not always happen. :)
T-U - I forgot to reply to your last point yesterday,sorry was a bit
tired.
There was only one Ct in all my setups,so we must have misunderstood
each other somewhere.
hetzen - thanks Jon,I'll have to read your post a few more times and then
I'll play with your suggestions.
And maybe then I can understand this better.
Thanks again for your input,I've learned a lot dissecting your
files.Specially your parallel warp file was really revealing to me.
Generally my thinking was still orbiting around how to displace something
kind of radial from a user defined point out- and inwards.That lead me to
the CN.
That might be too simplistic,but it seemed to work.
And my own experiments showed -unless I mixed things up- that there is
a difference in the results between a small patch size in the CT and when
you use a CN.Haven't shown the pics this refers to so far.Will check this
again,though and if it holds up I'll post the results here.
These discussions are really inspiring! :)
Ok,you guys were absolute right.It was definitely my fault.
It was a missing Transform shader that caused the difference
in the other file.As soon as that was added it was indeed the
same result as with the CT with a patch size of 1.
Still interesting enough to me.
My apologies to anyone thinking I've wasted their time.
In the meantime I read your post with TG open Jon and now
I can say that what you suggested is pretty similar to what
I like to do.Only that I connect the PF directly to the displ
shader and control the height with that.Of course I would have
to use a Displacement to scalar,if I'm not mistaken, to use it
with a Build vector.
The Build vector thing is indeed a cool variation I didn't think
of myself before.
Your suggestion is a good example for the differences between
color based displacement and the built in displ of a PF.
This difference is what I don't understand and one of the reasons
I decided to work with color based displ rather.
Again thanks for your input,I do appreciate.
Well,errh,I had another idea in regard to the use of a Compute normal,
which I wanted to test.And so I did.
I wanted to find out,if it would be possible to apply that method to just
a part of a terrain.So that there would be the main portion of the terrain
with the CT (default patch size) only and a small area with the CN to get
a better resolution or whatever you call that.
I made a separate node chain for the SSS-block,the CN and the surface
layer for the displ and connected it to another surface layers child input.
The main node chain has an identical SSS-block that is connected as
usual.
And it seems to work, only the SSS-block of the child chain is getting
the "higher resolution" displacement.
[attach=1]
Then I wanted to apply what I just learned and replaced the CN with
a CT with the patch size set to 1. I did nothing else,at least nothing
I'm aware of.
This is the result.
[attach=2]
Thereafter I tried it with World space disabled,same result.
Any ideas as to what may cause the difference here?
Edit: forgot to say the SSS-block with the CN/CT is on the right hand side.
It would help a lot if you can accompany both images with their respective node-network screenshots :)
When you're right you're right. ;D
One should be sufficent in this case,though.
Here it is.
[attach=1]
I used that method of a localised small patch CT/CN for making walls. The only problem is that if you have a lot of displacement in the line before and add that as child, it will 'double' the whole terrain displacement, so you have to be careful.
The difference between CT and CN is not visible in your examples, which is quite logical, you only effectively use the normal calculation. Only if you'd apply color, you would need the XYZ information, hence an added XYZ shader, or a replacing small patch CT.
Thanks Ulco,I get the first paragraph of your post,but for the second
I'm not sure that I understand what you're saying,'cause to me the
difference is clearly visible in the images.
And the xyz will be needed for terrain/displ matching colors,did I get
that right?
You mean the difference between upper and lower image (left-left/right-right)? I don't see them next to eachother, but at first glance there's not a huge difference. And yes, XYZ is for texture location.
If you want horizontal strata colors for instance a default compute terrain will often warp the strata, so if you add a XYZ shader, the strata will be absolutely straight (if stretched XZ).
Ah ok then I think I know what you're refering to with that xyz.
Yes the difference is not that huge,it's just on some parts.
They don't get displaced as much as with the CN.
Quote from: j meyer on November 14, 2014, 11:13:41 AM
....
There was only one Ct in all my setups,so we must have misunderstood
each other somewhere.
....
Hey j meyer excuse me please,but this is hilarious man.
The most shocking display of mathematical insufficiency
ever.Obviously you can't even count to 2.
C'mon now,really...of course there are 2 CTs in some of
the files.
Thanks for pointing that out J!
Indeed a mathematical record performance.
Will be hard to top that one! ;D
Martin,I apologize for being that dense,unbelieveable.
Of course the first CT wasn't there to compute the flat terrain.
While experimenting I put the noise over the whole of the
default scene,even without the default SSS.As you can see
in the version posted to the Rectangular noise thread btw..
One setup to test more than one possibility.
Hope that makes it somewhat clearer.
Didn't think of posting an animated gif either.
Would have been better,too.
[attach=1]
It's like a pumping heart... fascinating.