Rectangular Noise

[Dune]

I will try some more later, but have little time right now. But it's challenging, so....

[TheBadger]

But it's challenging, so....

Which? your project, or these noises?

[Dune]

Both!

[mogn]

mogn - I use color nodes,because I like to work in color space.
           As far as I know the displacement shader uses color space
           also.(before the compute terrain it can be very handy because
           of that,if I'm not mistaken)
           As for the trick you suggested I didn't understand what you
           suggest,sorry.
           Maybe the node network can be reduced,I didn't bother with
           that or any fine tuning or whatever,busy with other stuff,
           this was just a quickie.
           Moreover I don't have any mathematical understanding,so
           please excuse my "barbaric" approaches.
         

I Wonder why you prefer to Work in a 6 dimensional Space (x,y,z,r,g,b) instead
of a 3 dimensional state (x,y,z).
In your current Work, which I found very nice, you only Work in B&W colours, i-e r=g=b, so all your nodes
could be replaced by scalar nodes.
Your colour node input to the the displacement node I think is converted to the luminicence of the colour node,
which in the case r=g=b is r.

Since I am not artistical minded, I don't understand the colour adjust node, But in this case it could
be replaced by Colour multiplied by constant(35.34).

Another thing that I don't understand is that the functions you apply to x,y,z are not symmetrical in x,y and z.

[j meyer]

"I Wonder why you prefer to Work in a 6 dimensional Space (x,y,z,r,g,b) instead
of a 3 dimensional state (x,y,z)..."

I wasn't aware doing so.To me it was black and white in three dimensions.

"..., you only Work in B&W colours, i-e r=g=b, so all your nodes
could be replaced by scalar nodes..."

That's right and occasionally I use scalar nodes instead,but this file started
from my pavement file and for some reason I don't remember (too long ago)
that had the color nodes in it and I just went with it.So no special reason or
consideration.

"...Your colour node input to the the displacement node I think is converted to the luminicence of the colour node,
which in the case r=g=b is r..."

According to the wiki the displacement shader takes all sorts of input and
converts it to scalars.
As long as it does what I want it to do I don't really care about those aspects.

"...Since I am not artistical minded, I don't understand the colour adjust node,
But in this case it could be replaced by Colour multiplied by constant(35.34)..."

To me it's just a bit more versatile and fits better my habit of testing things
as I go.That's also a reason why I set up the nodes the way I did.It's kind of
modular and allows easy and quick changes,even if I have a few more nodes
with that approach.
When you open the clamp node in a new preview and have a look and then
open the colour adjust node in a new preview also and compare you can see
what it does for me here.(colour adjust has more advantages since it has
some features in one node that would require lots of other functions in
some cases,so it's really handy while experimenting)
I like to work with these node previews as they give me a visual feedback,
which helps me to see what's going on.Another reason why I like to work
with the black and white part of the color space.


"...Another thing that I don't understand is that the functions you apply to x,y,z are not symmetrical in x,y and z."

That's most likely due to the fact that I don't know how to do that,I guess.
I'm not even sure that I know what you mean.

[TheBadger]

@mogn
If you have energy and time for it, it would be cool if you could get J's file to have your randomness (where some squares are raised and some lowered), but maintain the ease of use J has. That is, his way of connecting the noise to a node tree is very clear and simple.  And in general any simplification and reduction of nodes in number is desirable.

I still find it interesting that although all of these noises are basically the same thing, they all give rather different results. As things are in TG, it seams smart to collect as many variations as possible in lieu of a built in noise function that solves the issues discussed here, and creates variety. While you guys still have interest in the problem.

[Dune]

I think square rocks have to be implemented in a totally different way, inside of TG3: use a rectangular 3D noise as a basis to fill the displacement to the max, so to speak. So if on a certain slope there's a white block 'crossing the slope' the value/displacement of the slope is maxed out until it reaches the 'end' of the white block. Kind of the same way the strata shader works... or the way I think it works.

[Tangled-Universe]

I think square rocks have to be implemented in a totally different way, inside of TG3: use a rectangular 3D noise as a basis to fill the displacement to the max, so to speak. So if on a certain slope there's a white block 'crossing the slope' the value/displacement of the slope is maxed out until it reaches the 'end' of the white block. Kind of the same way the strata shader works... or the way I think it works.

I think I see what you mean Ulco and I'm definitely with you.
However, what we both want is not how TG works unfortunately.
Even 3D noises like perlin/voronoi (blue node) isn't true 3D if you'd ask me.

Say you have a 45 degree slope and that intersects with the 3D voronoi noise in true 3D space.
Now, what we want is that TG "grows" the surface to the point where the voronoi noise "stops" in 3D space.
What I think TG is doing, actually, is reading the noise value ON the existing surface along that cross section and then just displaces it along the normal.

The reason I'm thinking this is is first of all because of this lengthy discussion where many seem to have issues to get the noise functions appear "volumetric" for the lack of better words.
We create interesting looking patterns, often on the default "flat" planet and then try to apply it to more complex terrain. Then it becomes very apparent that the noise is "mapped" in a 2D fashion over the surface, instead of a true 3D interpretation.
Secondly, if it would work the way we wanted then 1 noise function could create overhanging features already, but we all know that that isn't happening/possible.

[Dune]

Yes, that's it exactly. But the strata shader does 'max out or min off' the slope values, so I think something should be possible. But it probably needs a new shader (that Matt should make  )

[mhaze]

Yes please.

[Tangled-Universe]

Btw, this doesn't necessarily mean we need 'isosurfaces' as I have the feeling this is what we're going to hear about this, if.
(With isosurfaces you "convert" the 3d volumetric fractal into a surface. This can give quite awesome results, but is even more challenging to control.)

If you sculpt nice rock shapes in mudbox from a standard plane, including overhanging features and cracks etc, then you can write that out into 1 single vector displacement map.
Then you apply this map to your planet/plane in TG and you'll have the same result from just 1 input.

Yet somehow TG's noise functions aren't interpreted in the same way as the vector displacement map is interpreted in the example above.
Just to try to explain it in yet another way what we want.

[Hetzen]

"Yet somehow TG's noise functions aren't interpreted in the same way as the vector displacement map is interpreted in the example above."

I'm not sure that's strictly true. You just need to make a noise with that vector information in it.

[Tangled-Universe]

"Yet somehow TG's noise functions aren't interpreted in the same way as the vector displacement map is interpreted in the example above."

I'm not sure that's strictly true. You just need to make a noise with that vector information in it.

Yes I guess you're right and I have been thinking about it as well before saying it...I just don't see how (yet).

A big "however/but" is that what I said still applies to PF's not being able to create the overhanging features I referred to in my previous post.
So a PF also does this differently than how a vector displacement map is interpreted.

[Dune]

I've been messing around with repeated vdisp maps, but from a slope it's still hard/quite impossible (for me) to make nice square blocks. And a vdisp map goes one way (so on the other side of a bump, the noise is 'inward'), displacement goes along normals to all sides.

[Tangled-Universe]

That makes much sense since a vdisp map tell exactly in which direction each pixel needs to be displaced in 3D space. Consequently it only works correctly if it is on a surface same/similar to the surface the vdisp was calculated from.