Here's a challengs, I've been struggling recently to try and create angular flat rock type textures with PFs and/or Voronoi. The problem I've had, has been creating random levelled steps, without spikes. So I tried a new approach, by creating a new noise type through the functions. I've borrowed Goms' direction shader network to define whether x or z noise is applied depending on which direction the surface normal is facing. (thanks Goms, I think there's a whole lot more exploitation possibilities with that little node gem).
At the moment I have control over Step Size, Angle Between Steps, Noise Scale, and Noise Seed on each of the three axis. It's just a proof of concept for now. The idea will be to modulate these settings, so that each 'square' shape will be more random, and by changing the bias of the steps, the extrusions will be more interesting and unique. Well that's the theory.
Anyone else have any ideas on how to create more rectangular noise?
For a basic square/rectangular noise function I've used extreme stretching of a close-scaled fractal(say scales of 10,10 and 10), duplicate the node and have one stretched, say, X = '100' and the duplicate, X = '-100'. Do this on the Z axis as well with another copy of these nodes and the colour outputs can be merged.
Because they're fractal, though, it's somewhat random. I don't know how to go about repeating an exact pattern this way. ???
http://forums.planetside.co.uk/index.php?topic=6149.msg64869#msg64869
I used displacement in this, too. A colour output on its own could be used as a mask, though.
EDIT: Actually, you've commented there before, sorry. :D
Yeah that was a while back. Interesting little exercise that, although I've tried using clamped stretched noise, and I guess it's still a possibility, but one of the issues I was having, was the 'equalness' of the steps. Ie, if you layer up some stretched noise, say 4, your resulting extrussion will have four steps in it. If you start using difference subtraction, you then start getting a lot of spikes. There maybe a happy medium out there, but I thought it might be interesting doing it in blues. Although saying that, I'm only just managing to stop my brain from ouzing out of my ears from abstract math at the moment.
This is where I'm trying to go with this...
(http://www.lifefamilytraining.com/training/img/rock_climbing_lg.jpg)
(http://www.emma-o.net/Pix/HorneLake_rock3.jpg)
Looking, absorbing and learning ...great stuff you guys.
I know tha dandelO has worked a lot with this problem.
Her is my solution (using a perlin noise):
Hi Jon,
A couple of weeks ago (feb 15th) you sent/showed me a very nice example of this technique when you had this slightly more PF-based rather than function-based.
I don't know if you would like it if I show that image here, but I hope you remember which one I mean: in that image you already had much of the effect you tried to achieve. Sqaured looking fractals, quite like in your reference and also with variation in level steps.
I was just wondering if you lost this setup or deviated too much from it in the meantime? It looked really good!
Martin
@mogn, your approach is actualy quite simillar to mine, but I didn't use the smooth step node, quite simply because I'm not entirely sure what it does. But the main addition I made was sampling whether the previous modulo loop was higher or lower than the current modulo loop, so that I could define an up or down ramp to the next level, rather than have a 90degree cutoff, which kind of messes up any side texturing or displacment.
@TU, I don't mind if you post it at all Martin, I've lost mine in the myriad of temp files. The problem I was reaching, was the regularity of the steps, and breaking that up. But Dandel'o mentioned something earlier about similar sized scale fields, which is something I didn't play around with too much, and since my latest attempt shown below, to modulate these squares, the render time has become close to way excessive for my liking. So I think I may have to go back to the PF approach.
I must say that example you have now looks quite interesting, but I prefer the result shown below here in my post.
It's probably less node heavy and faster and if it's up to me it looks better as well.
I can easily imagine different scales for the fractals there, with other displacement amplitudes as well.
Then use that as a base and add "normal" fractals for details etc. etc.
(the file you sent me then, and shown here below, was called "tgout.0007.jpg" and was from feb 15th....hope you find those files again!)
The last example is very close to random, natural looking noise. I can see very little texture stretching, either. Some smaller scaled perlin would lay across that nicely without any sharp cut-off stretching, I'd imagine.
The example above it still has some stretching on some vertical/horizontal that reduces the realism a bit.
Could the shader array node be fed by these functions to rotate areas off of perfectly vertical/horizontal? Or, maybe just some warp function following the function layout would do?
This is great work, far beyond my paltry brain, though, I'm afraid. It looks like Spider Man has been inside your node network, Hetzen!
Really cool, well done!
Lol Dandel'O, the nodes were compacted and then duplicated per axis, so when it was initially put together, it was a little more spread out and clearer. But that node pic does describe quite well on how close my head came to exploding.
The problem with the PF approach, is controlling the spikes you can see on the right hand side. It's certainly quick to render, and I went through several process of combining the stretched noise, some containing something like 64 PFs!, yet it was still quite renderable. I think I'll roll back a little and see if I can take that further.
The problem with the blue approach, is modulating the modulo's. I was getting some pretty bizzare shapes yesterday, which looked almost like rose petals!! Interesting, but not rock like.....
I suppose it could be used to warp the regularity, simulating tension in the rock where it has been compressed, if the steps weren't too thin..
EDIT - The steps in the Blue approach modulated above, come from using voronoi scaler noise, which has hard cuttoff's unfortunately. To get rid of those, I'd probably have to feed in a new smooth stepped square function with a larger scale.
@hetzen. I like such networks, but I have a personal dislike of conditionals.
You can avoid conditionals and make 3 comparisons in parrallel:
"Subtract vector"("Add vector"([X1,X2,X3],[Z1,Z2,Z3]), "Difference colour"([X1,X2,X3],[Z1,Z2,Z3)) == 2*[min(X1,Z1), min(X2*Z2),min(X3,Z3) ]
You can always use a colour function if the vector function is not implemented.
another minor thing: "Abs scalar" gives a noncontinous second derative (slope of slope) of the noise function.
Thanks Mogn. Conditionals have a logic I can understand. I'm afraid I don't understand....
"Subtract vector"("Add vector"([X1,X2,X3],[Z1,Z2,Z3]), "Difference colour"([X1,X2,X3],[Z1,Z2,Z3)) == 2*[min(X1,Z1), min(X2*Z2),min(X3,Z3) ]
...or how to write that in node form. I would seriously appreciate it if you could explain this to me step by step if you get the time. Something I don't like about the Conditional Function, is the amount of hoops you have to jump through to get a smooth cut-off between your logic argument. ie, if x > 10 then smoothly mix to y over 10 meters.
The Abs Scaler was simply put there to keep things positive (sure, I could +1 then /2), but was also used to get more variation from the Perlin Noise. As I am only sampling one point on the Perlin curve, and comparing that value with a sample point one modulo phase previous, it didn't matter whether there were billows or ridges in the noise. The noise is only there to give a single amplitude value which is used through out one modulo cycle, but I need to know whether the previous step is higher or lower than the current one, to define whether the step smoothing is rising or falling.
Quote from: Hetzen on March 11, 2010, 06:24:29 AM
Thanks Mogn. Conditionals have a logic I can understand. I'm afraid I don't understand....
"Subtract vector"("Add vector"([X1,X2,X3],[Z1,Z2,Z3]), "Difference colour"([X1,X2,X3],[Z1,Z2,Z3)) == 2*[min(X1,Z1), min(X2*Z2),min(X3,Z3) ]
...or how to write that in node form. I would seriously appreciate it if you could explain this to me step by step if you get the time. Something I don't like about the Conditional Function, is the amount of hoops you have to jump through to get a smooth cut-off between your logic argument. ie, if x > 10 then smoothly mix to y over 10 meters.
The notation [X1, X2, X3] means a vector with the values x=X1, y=X2, z= X3
So the top (first level) of the node networks starts with two "Build vector" or "Constant vector"
The second level level contains an "Add vector" where the two inputs are connected to output of the two vectors in the first level.
So the output of this node is [X1+Z1, X2+Z2, X3+Z3]
The second level also contains a "Difference Colour" the inputs in this node is also connected to the outputs of the nodes in the first level.
There is no difference in TG2 between vectors and colours. The output if this node is [max(X1,Z1)-min(X1,Z1), max(X2,Z2)-min(X2,Z2), max(X3,Z3)-min(X3,Z3)]
In the attached picture node the network the example shows the two input vectors with the values [7, 13, 15] and [4,16,12]
the values of the second level are thus [11=7+4, 29=13+16, 27=15+12] and [3=7-4, 3=16-13, 3=15-12]
The third level consist of a "Subtract vector", the left input is connected to the output of the "Add vector" in level 2,
and the right input is connected to the output of the "Difference node" in the second level.
The output of this node is thus [X1+Z1-(max(X1,Z1)-min(X1-Z1)), X2+Z2-(max(X2,Z2)-min(X2-Z2)), X3+Z3-(max(X3,Z3)-min(X3-Z3))]
This shows that the max values are subtracted from the sum, and the minimum valuse are added to the sum, leaving the twice the minimum components.
If and "Add vector" is used instead of a subtract, the minimum values ar subtracted from the sum, and the maximum values added to the sum, thus leaving
the maximum of the components.
Thank you for taking time out to explain this to me. It's making a little sense.
In the node network I posted above, the logic goes:
Convert a Get position statement to give X,
Create a value loop for X of 0 to 100 through a Modulo function,
Subtract the output of the Modulo loop from the true value of X (this will give me one constant value out every 100 steps in X)
Which is then fed into a Perlin function that will give me a new value every 100 of X. Lets call this D (displacement value out of the Perlin)
So far, this is pretty much the same as your function posted earlier to define squares. What I want to do next is to say within that Modulo sequence of 0 to 100, I want to blend between 0 to 10, the difference between D and (D of X-100).
To do this, I need to feed a new Perlin function (with the same seed and scale) the same X but minus one phase of the modulo. This give me the D of the previous square. (D of X-100)
What I now need to do, is find out if (D of X-100) is greater than or less than D.
Because if D is Less Than, then I need to add (the difference of the two Ds divided by 10 multiplied by (10 minus (our modulo only up to 10)).
Otherwise D is Greater Than, and I need to subtract (the difference of the two Ds divided by 10 multiplied by (10 minus (our modulo only up to 10)).
There are 2 conditionals to consider in the above argument. One to work out if the previous step is higher or lower. The other to only count to 10 in our 100 step.
I can sort of see how you may get a 1 or -1 from your vector approach, I can also see how you could get a 0 to 10 from the modulo too with clamping. But does this really save much on processing to put in the extra math over using conditionals?
In other words what you want is generating a smooth pseudo random curve for each 100m, with the value at the zero end of the interval as the end value of the previous interval?
I will think about how to do that without conditionals. (clamp and step function are allowed even it is a form of a conditional)
OK here is my solution, which I think is both faster and avoids any conditionals.
To avoid the conditionals you draws a curve (strait or with zero slopes at the endpoints)
with samples of a simple function, this is done by a "Mix scalar function", thus eliminating the expensive noise functions.
Sampling a non symmetrical cosine function with about 100 degrees difference between the samples do the trick.
1) creating input to the functions:
divide the x-value by the major scale (100)
take the floor value of this generating Xi = ...-1,0.1.2...
subtracting this from the x value gives the controlling value S.
You might apply a "Smoth step" to this value if yoy want.
2) The two samples values is then: (Minor scale = 10)
Left value: 100 + 10*cos(sqrt(3)*Xi+0.25)
Right value: 200 + 10*cos(sqrt(3)*(Xi+1) +0.25)
sqrt(3)*Xi is calculated as Length(Xi) which is the most expensive operation in this scheme.
3) the sample of Xi is fed the the left input of tin Mix scalar
the sample of Xi+1 is fed into the midle input of the Mix scalar
the controlling scalar is fed into the right most input of the of the Mix scalar.
This give you a never repeating and non symmetrical slopes.
That's an interesting approach. Thank you for taking time out to think about this problem. I'll give it a shot tomorrow and let you know how I get on.
I made a nice cake with similar approach.
I was having a play with some voronoi noise and came up with this....
The wobbly parts in the middle arise from the underlying noise in the cliff being stretched too far by the angle not getting enough computed normal triangles.
Looks nice Hetzen :)
This and many other techniques you and the others make should be default options in TG2.
Remembered me of Oshyan's photo :
http://www.facebook.com/photo.php?fbid=2508025954821&set=a.2508003594262.93484.1678235043&type=3
Thanks Kadri. I've been looking at this as a texture you apply to a terrain through a surface layer.
I'm still experimenting, like trying to break up the noise so that the horizontal splits aren't as regular, tweaking the noise scales for the verticle cracks and finding a sweet mix spot in the strata scale variation.
I stuck this on Efflux's tgd he posted in the sharing section, with the above texture, and the bellow pic is was what came up.
Efflux's good idea of using Get Altitude to determine mix events I think, could work here in achieving sharper rocks at the top and smoother water eroded at the bottom.
I've been using a Get Altitude to drive a voronoi cell/dif combination, to get the random spaced horizontal steps. What I would like to do, is be able to increase the lateral displacement as altitude rises through a step, to try and give me flat sides to the outcrops.
My problem is that voronoi gives me no ability to modulo a random step. Can a series of sin functions allow me to create a ramp between irregular steps?
Edit.
Having another look at mogn's ideas above, could be the answer...
Brilliant work!
resurrecting
Does anyone remember if the file Hetzen was using here above was ever posted?
@Badger: Thanks for your PM. Do you want infinity numbers of Squares with random colours (or scalars),
or do you want a transform of a circle to a Square?
Do post it here, if you can, Mogn. Never enough Square noise choice.
Quote from: Dune on September 24, 2014, 03:42:47 AM
Do post it here, if you can, Mogn. Never enough Square noise choice.
Hear Hear!
Hi Mogn And wow, thanks for the choices!
QuoteDo you want infinity numbers of Squares with random colours
Correct me if I am wrong, but squares with random colours made of blue nodes is how you built the quilt network?
And if so, I basically understand what that node file is doing. My problem with it that I don't understand which node in the network does what. Also, I see that the colors are important, I just don't understand how exactly to manipulate them, or what their limitations are.
But to answer your question, Infinity rectangles with random color :) All vertical. I mean all in the same direction length wise. If that makes sense. But I don't know the difference between colors and scalers or how one may be better than the other, Im sorry to say. So I defer to you to decide what would be the most useful for achieving the effect on a terrain.
Quoteor do you want a transform of a circle to a Square
Well this just sounds like an awesome tool! And would be very useful. If you can build something like that I imagine I could really get certain effects into particular areas.
I admit my difficulties are mostly my own fault. I used your previous files in already very complex networks.
I will start again with any new clips you post in a proper way. I will take just those clips and explore them on a simple default planet by them selves, so I do not confuse my self any more than I need to ;D
Thanks Mogn, whatever you feel like creating is welcome.
If you have a circular area and v is the the angle (range 0 2PI) from the center to the current x,z.
You can tranform the circle to a N sided figure in the following way:
q = mod(v , 2PI/N)
w = cos(q - PI/N) / cos(PI/N)
multiply current x,z by w.
The with and heigth in the Quilt are decided by the two Perlins (P) as P*50+100.
The colours are selected from a noise functin in the middle of of these rectangles.
So replace one or both of the two perlins with a constant to limit the size of the rectangles.
:o
Thanks Mogn! I think that I can make the changes to the quilt based on your post, I will play with it today 8) Quite fun!
On the square a circle idea. Its is a little harder to visualize right now.
Have to play with this!
Quote:o
What do you think Ulco?! What do you see?
q/P^ = mod/5(v* , 2$PI/N2) and also; w = acos>=(q - PI/N) /- cos2(#PI/N)+/-/:multiply current x,z/b*acos by what.
Math is not my strongest point.
I use atan2(z,x) and adjust to get into the range 0..2PI, the angle beteen x-axis and the point.
I feel like i am in the wrong forum :D
Seriously i wish i could work in that kind of approach.
Oh man. In way over my head. :-\
Using HSV colouring:
A variation, replace the first "Get position" by a tgc "swirl", which rotates the coordinate system by a random amount
Must be Planetside's secrete partner.
Sorry for asking a question Im probably supposed to know but Why can't I view the noise as it is shown in Mogn's Post in color in a view window? Can't make that work. And that is clearly the best way to view the results of changing Mogn's numbers.
Also, if anyone wants to post a TGD in the simplest way possible, that shows a way to attach the noise above to a terrain and get the results similar to Hetzen's images on Pg 2 that would be swell, because I now can't even explain how I had mogn's quilt working in the Utah thread.
I am obviously forgetting something basic, but cant see what it is.
Very simple. You can use the colors by themselves as well, using the convert colors nodes. The only thing I changed is replacing the get postion in geometry by a get position in texture, or you can't transform (or warp).
Thank you Ulco.
Mogn,
Would you be willing to take one more crack at this?
I think this will fix the issues I am having when using this noise on a terrain. Can you figure a way to give the sides of the displaced noise a slope of some degree?
[attach=1]
Something like this?
I am just guessing that this is possible. I was thinking that this is somehow doable through color or shades of grey? I know that the noises are represented in 2D. But can't color or grey values dictate the way the 2D is translated into 3D within the node network that you shared?
???
Thank you again. Hope you are not bored!
Here are the two scene files from the previous page attached below. They're a bit messy as they were only ever supposed to be doodles. So scales and application may not work for you Badger.
Cheers
@Badger: With centers of the Squares, construct 50*50 pyramids, and then cuts the heights to 1 meter. This creates a 1meter bevel mask.
Multiply the couloured Squares by this mask. Connect a colour (e.g red) and connect to the rightmost input of a display node.
Note that neighbours Squares are garantied different colours.
My solution comming up soon.
@Hetzen
Hey man! Thanks! Glad you saw this :)
@mogn
Thanks again! I'm looking forward to your further instruction.
A side question:
I read in other posts that people can make their own nodes (programers), is it possible to take these noises you guys have made and make them a regular part of the noise options that TG comes with? So somehow get them to appear as an option just as the noises in the power fractals?
I also read in another post that noises can be copy protected and that is why we don't have some well known noises in TG (because someone owns them). But if you create your own as in this tread, even if the result is the same, but because you came to your final by an original means, does that make it new?
Just wondering if the square noises created in this thread could somehow be more integrated into TG as the veroni noise is, for example.
Don't mean to knock you off topic. Just curious about everything.
Below are some images of how this is working.
And it is working, but not quite right. I see that I have everything I need in the nodes to make it perfect (or close enough) But I just can't pull it off.
What do you guys say?
I think it is just about right, but for the roundness of what should be flat tops of the outcrops and the width of the rectangles. I do like the rounded soft sides which takes away stretching. And you can see in some places the flat areas are there and looking good. I cant figure how to control them better though.
goal
[attach=1]
You got it Mikey! Looking super. Now, make your TG image look like this.
I think if you use a setup with stretched (hard, clamped) noise in 2 directions (crossing eachother to form irregular 'squares' in 3D), and a mask derived from the angle in the terrain for directional lateral displacement/redirect/vdisp, you may be able to get those kind of rocks. With some work...
yeah, I did think to stretch but did not think to try an use a clamp, which now seems obvious after you mention it. What did you mean by hard though, hard what?
Its just irritating. I know that I have the nodes I need from the others. Just getting them the right way is frustrating. I would just sculpt the single tower, but that would not help with the hundreds of square miles of the rest of the scene ;D
My pyramids solution failed. But this Works.
The bevel Width depends on the constant 10, greater values gives less Width.
@Mogn
Thank you again, I think that will do it. Just have to clean up my network.
@ Hetzen
The drop in effects from your tree is quite nice. It adds a ton of good results. Its an exceedingly complex thing you did though. I can use it in a couple of different ways depending on how and where I plug it in.
@ Ulco
I like the control group you posted above. It works for me.
only I am not exactly sure how you got the inverted random displacement? Random does not appear to be controlled by the Base color, or the break-up node you used, and I don't see any place else that has a randomize function... So How did you get some of the cubes to invert, and how is that inversion distributed?!
Please be specific. I think that after you tell me that last bit I will be able to rebuild my network in a way that works right.
Thanks again guys!
Quote from: TheBadger on September 29, 2014, 09:24:18 PM
I read in other posts that people can make their own nodes (programers), is it possible to take these noises you guys have made and make them a regular part of the noise options that TG comes with? So somehow get them to appear as an option just as the noises in the power fractals?
The only way to do something like this is with the as-yet-unreleased SDK. So whatever you read was either incorrect, or misinterpreted.
Quote from: TheBadger on September 29, 2014, 09:24:18 PM
I also read in another post that noises can be copy protected and that is why we don't have some well known noises in TG (because someone owns them). But if you create your own as in this tread, even if the result is the same, but because you came to your final by an original means, does that make it new?
Theoretically it's possible that a particular implementation of a noise function could be copyrighted, but not - I think - the actual mathematical process. I may be wrong on this with some recent-ish interpretations of software patent law, which are pretty ugly (IMHO), but in any case such issues - if they exist - have not yet directly affected TG that I know of.
Quote from: TheBadger on September 29, 2014, 09:24:18 PM
Just wondering if the square noises created in this thread could somehow be more integrated into TG as the veroni noise is, for example.
Once the SDK is available someone could do that, if they know how to code.
- Oshyan
Quoteinverted random displacement?
??? You can use a series of surface shaders + PF's (or whatever) mask to get random distribution of displacement masks. Is that what you mean?
No, I mean you already have that in the file you posted. I was asking how you did it.
[attach=1]
This is your file exactly as you made it, except for the hills you had in there. I removed the terrain forms so I could see the Noise better.
As you can see, there are cubes that are Negative in the Y. I did not get this from mogn's file. So I thought you added it.
And I checked all of the nodes with seeds, but changing seeds changed nothing. SO where is the node(s) that have the negative values (that created the depressions)? And which node is deciding what is inverted and what is raised (in the Y)?
See what I mean? OR is it in the functions somehow?
@Oshyan
Thanks for the good answers.
And I did not misunderstand the other thread. I just did not state things fully. That thread was about coding in general, and I just projected on TG. Sorry about that.
But it does not matter, your answer was good anyway. Very excited about what people may do with this SDK, it really sounds like a good thing.
This is not a Reghtangular noise, but some of the tools are used on a Perin noise.
@Michael: there's no negative displacement, just 'not so positive'. All colors displace in their own (greyscale) way.
By the way, mogn, can this bevelling be used in the irregular rectangled noise you posted a while back as well? I'm sure you have it in no time. In the meantime I'll try to combine stuff. For these squarish rocks you really need very irregular, but slightly bevelled rectangles, and all I can do is use merge shaders and transform shaders.
Quote@Michael: there's no negative displacement, just 'not so positive'. All colors displace in their own (greyscale) way
Ahh, ok then! I thought that, but I did not get proper results before you posted your control nodes. I had been plugging the noises in to already too complicated networks which was half of my problem.
Anyway, thank you. Im good on this now.
@Mogn
That last one is nice too. And +1 on dunes request!
Edit*
Mogn,
actually, can you say which function determines the randomness in your builds? So just looking ant any of your images of your networks, which node could be altered to act the way a seed button does in a non blue?
@Badger: The random part in in the Perlin is the fractional part of a multiplum of PI.
if you replaces PI with any PI * constant (non zero) it will Work as a random selector.
On request from Dune:
Hey mogn, thanks a lot!
edit: mogn; did you know a lot (or all) of the nodes are there 2 times?
@Michael: here's mogn's file in tgd shape.
Thanks Ulco.
But can you state that the alterations do only what you intended? I mean can we say that replacing the one node with other only has the effect you wanted and nothing else? I am happy with what I see, I just want to grab as much info as I can while we are on this topic.
Quotemogn; did you know a lot (or all) of the nodes are there 2 times?
I was curious about this too. Is there a simple explanation for it? This build is much more complex then earlier versions. I was not going to dare to ask lest my head start to spin around several times and pop off... but since Ulco did.
Anyway, all of the complex stuff aside. I am very happy with these solutions! And I want to say thank you again. It was very nice of you Mogn to take time and solve some problems. Personally, this topic was one that caused me problems for a long time. But now I have some great working, reusable groups.
And thank you all for helping me make use of the ideas, and Ulco for simplifying how to test.
I will now sing the happy song ;D Which you may not hear lest your ears bleed and fall off.
You mean replacing the get position by the get position in texture? That has side effects, but the get position can't be transformed or warped later.
I simply tore off all duplicate nodes one by one, and ended up with a single setup. But I'm still not happy with what you can do with it, have to do some epxeriments with stretched, rotated and combined PF's as well.
QuoteBut I'm still not happy with what you can do with it, have to do some epxeriments with stretched, rotated and combined PF's as well.
To achieve something like what? And have you had time to try this on fake stones or rock object yet? Any results worth mentioning? Have not tried my self yet, been just working on Utah. But I would love to be able to get a cut stone look out of fake stones or rock object... I have to do a lot of playing yet, too.
Squarish rocks protruding into any angle, that's harder. You'd need to stretch the blocks into the angle they should displace and mask them by that angle, although if you add the tgc as displacer simply to a displaced SSS you get squares allright.
Quote from: mogn on March 24, 2010, 02:29:50 AM
I made a nice cake with similar approach.
Peut-on mettre en pyramide carré dans un sss ?
Can we put in a square pyramid, sss ? ???
That's simple.
Thank you, Ulco. ;)
Here's some rectangular'ish stuff I have been working on and off for the past 6 weeks.
It uses some of the principles described here as well as some of my own approaches.
If there's interest I might be able to disclose something at a later stage, am not sure yet.
It's not that special and not what we're really after I think, but I like the looks of it so far.
Cheers,
Martin
Nice rock, Martin. I found that really square rocks are hard to make. Mogn's noise, though nice, is not 3D but in XZ with infinite Y, so I've added some Y fracturing blue nodes, but I still need to get it to work well.
Well I doubt if any of TG's surface/noise stuff is "real" 3D.
If you'd ask me, anything before a compute node is treated the same, "added up"/combined and then draped over the existing surface.
Just put some extra compute nodes in between your displacing PF's/functions and you'll be amazed how much of a difference it will make if you have your PF/functions can use the updated surface.
It then works much more like you have it in mind. At least, I visualize that an extra layer of PF/noise displaces along the normal created by preceding PF/noise, but it just doesn't work that way.
This only works this exact way if you compute again first. Otherwise, like I said, the whole set of nodes/functions is evaluated into 1 single "result" and then sampled over and applied to the existing surface.
It makes sense actually, but don't ask about rendertimes though :)
Its always a juggling match on where you apply a Compute Normal/Terrain to get these effects to work.
I've realised that you need a solid 2d projection with good masking that you can use after a compute node as a guide to drive these lateral displacements really helpfull. SSSs do that well. Modulating a modulo on that gradient can create nicely uneven strata layers, when you displace them, but maintain that data after a compute node for later surface effects.
Martin is right about putting resolution into a compute to get more info into a near verticle surface.
But you could look at the problem as needing to push a slanted surface horizontaly to become more verticle in steps. It's a tough one. It very much depends on your input terrain on how successful the effect is.
A big underlying issue of getting it to work the way we want is like this example:
Terrain -> compute -> thick strata -> rectangular noise
This gives a very stretched result, since the strata node stretches the terrain strongly in the vertical direction.
As a consequence, the rectangular noise is also stretched accordingly.
No problem if we compute first, right?
Terrain -> thick strata layer -> compute -> rectangular noise (-> compute -> texture)
Well....No.
The result is quite much the same!
What I really really want is to let TG more easily "start over with a clean slate" after a compute node.
If I compute the terrain I'd like to have it to create equal resolution on the vertical sides as well as on the horizontal sides and especially I'd like to have the coordinates behave similarly.
As it behaves now, and has always done, stuff still gets stretched along despite computing terrain in between/before.
Hey guys,
I hope you will continue to work on these problems, preferably out in the open. I am really frustrated on it... So close yet so far >:(
It really sucks that its so hard to get what I think is a basic fundamental form in nature. I mean, rectangular rock faces are just about everywhere.
And aside from that, there is a simple esthetic quality to the shape that can add a lot of compositional structure very easily.
Of course we could use a displaceable object in TG (i think), for a few individual forms. But that will not solve what we are really after here. Although I really want to try that this week.
Perhaps Matt will chime in. Hard to imagine that he has not thought about and even found some ways to make this work a bit better. At this point Im not even too worried about render times. I just want it to look better and perhaps some simplification.
I am really glad you guys are working on it.
@Martin
Nice looking stone!
Dont give up guys. If it is possible, you will find it!
Oh and,
Just for breaking this down a little more. Don't you find that the strata shader has a lot of the power we are after in a single node? And perhaps there is a way for PS to make a single node from the strata node, that will give us what we are after here? I mean I have seen people use the strata node pretty simply out of the box, and it gives the results we want in various places. So could it be striped down and repurposed some how?
Just asking.
The thing is, that I am finding everything I want is already here in some way, I just am not getting the various parts to play well as a whole.
And then there is the discouraging matter of if it is hard for you guys, then how will it ever be simple for the rest of us. And by the rest of us I mostly mean me :P
Please tell me how to toggle the color from mogn's noises on and off for rendering. As it is now I get the colors from the noise patterns in my render. Its good that way to see whats happing of course, but how do I turn it off without losing the displacement?
*added pics so you can see how it nearly works for me. However there are a number of issues yet. And I have to try the beveled in place of the noise that is here now.
Also, the distribution shader is clearly working on the color, but not the displacement, explain that.
some other problems too like where the shapes begin and end, but that just needs tweaking I think.
You should use the colors for displacement only, Michael, not as a child with the colors. And as you see from your sample, even a straight noise isn't straight in the terrain. A small patch szie in compute terrain certainly helps (I needed that in my winding river as well for the strata), and adding more compute terrains, compute normals, and XYZ shaders, also helps, but I'd like to minimize them for the reason Martin wrote; takes more time to render.
QuoteBut you could look at the problem as needing to push a slanted surface horizontaly to become more verticle in steps
That indeed is the hard part!
Here's some of my results at testing...
I think square rocks_1okt14_v1var1-4.jpg is really excellent all around, square noise background cliffs and foreground too.
- Oshyan
Agree with Oshyan, in real life, I have seen these types of rock faces in places in Arizona and Utah ...they are spectacular. Love your images Ulco, especially the first one.
Yes I agree with Oshyan. That image is nearly perfect. I don't think the waving line is natural looking though. But in your last image the hard strata line is really good. There is some nice subtle details in the last image.
On image 1 above on the far left side, the rocks get a little crazy. Whats happing over there?
Nice work ulco! Nearly there!
That rock structure in the first one looks good really.
QuoteOn image 1 above on the far left side, the rocks get a little crazy. Whats happing over there?
That's the problem with the square noise, it works best on one angle. Easy if you have a north facing wall, just stretch the fractals or blues in Z.
Ulco,
What about the image you posted where the snow was only on one side of the hill. Would it be possible to attach the noise to that set up, once for each direction (N,S,E,W so four copies of the noise) and then have the rectangle head in the direction while limiting them by slope. Could that be a fix to the angle problem? Or just new problems?
That's what I did, but it's still not perfect.
Quote from: Dune on October 09, 2014, 02:19:23 AM
That's what I did, but it's still not perfect.
LOL OK, time to re read all of this thread now.
...
"...still not perfect"
Perhaps adding the same in the NE, SE, SW, NW, so eight noises by your method? I am guessing that would be very slow to render even if it worked though?
Its an interesting problem, but I have to say Im still pretty happy how far this has gotten!
I divided into three directions.
This took only 2 PF's (perlin), then some not so complicated tricks with slight warping and conditional blending.
The main trick is, like we're discussing now, how to apply this to a terrain in such a way that it looks nice regardless which direction the steep surface is facing.
This just on flat ground, for example, so getting it work on a vertical wall will probably be quite challenging.
I still have the feeling TG isn't fully 3D in this regard, but rather 2.5D at best.
The stretching and angle-dependent aspects we're discussing wouldn't happen when the noise is interpreted in full volumetric 3D, instead it shows clear resemblence to mapping a flat texture over an irregular surface, causing these issues.
Rightly spoken!
If you keep the white of the pf's clamped you can get flat rectangles and with some additional displacement can get you a long way, but it needs a good 'horizontal way'.
Ulco, the noise was already clamped, but it was a nice idea to clamp them further :)
You should be quite careful though, because the effects can be very strong and quite devastating if you overdo it.
Yes, but if you add another fractal or warp a bit, you can overcome these sharp edges. And some rocks are VERY rectangular and hard edged. Now if you raise the amount of white, you get narrower cracks and more rock. Lots of possibilities, but my main wish would be to displace a (let's say 45º) angled slope (into any direction) into straight vertical blocks...... that would be quite something!
I think I see what you mean.
This setup works best if if I adjust the offset of the PF's as well as a bias function down stream.
Manipulating the white color of the fractal changes the range of values for the whole function and thus I would need to re-adjust the clamping values. I don't like that.
The idea is to have this setup as easy as possible.
With that in mind I would really like to have the option in the transform node to rescale displacement amplitude.
This function uses 10 displacement shaders, each having a different displacement factor which is relative to the scales of the base noise.
It's all inter-linked/tied up to each other.
Now, if I would like to re-adjust the scale of those 2 PF's I'd need to calculate and alter the correct displacement values for those displacement shaders. Oh, and also for the 2 fractal warps.
Why do I need to work so hard to have TG do what I want? I wish we had easier tools for this like extra functions in the transform node, but a macro-approach would be ideal.
Quote from: Dune on October 10, 2014, 10:05:38 AM
...Lots of possibilities, but my main wish would be to displace a (let's say 45º) angled slope (into any direction) into straight vertical blocks...... that would be quite something!
So you mean the issue that this stuff only works on a flat plane which faces exactly X, Y or Z, right?
This issue is HUGE.
TG just isn't 3D in regard of how it handles the noise for the terrain. It's carpet....
Warping your function with the terrain before you displace your function, doesn't work.
Warping the "get position" result with the terrain and using that as input for your noise function, doesn't work.
How on earth can we do this?
If I can make this work I can finish my current freelance job in 2-3 weeks instead of 2-3 months. It would make TG life so much easier.
Agreed, agreed, agreed!
Something I noticed is that at least mogns files miss the 3rd axis
and of course you'd need that to produce rectangular noise on every side.
But even this wouldn't be a solution for the problems caused by the
aforementioned stretching.
Unless we get localized partial subdivision of the mesh (the planet is a
procedural sphere,remember) or another nifty solution we have to use
TGs displaceable objects or cheat somehow,I'm afraid.
Just my 2 cents.
Martin,
Well, you got some pretty nice looking displacements too! 8)
On the problem thats been discussed. I am up to speed now ;D actually I saw this right away when I changed the squares into rectangles and looked at my terrain from high up. Pretty clear now after re reading everything.
So you guys all agree that a tool or feature has to be added to TG to make this work without changing the direction of the noise for different shots?..
There is no possible way to build the noises differently so that they work better with this issue in mind (perhaps not solve it, just work better)?.. Worth asking at least. Perhaps something can be done? Still think there is more exploring that can be done in the building of noises by those who can do that... Just speculating.
Aree with J on the object. Remember John's "Tower Tutorial" I have been meaning to revisit that with these new solutions, and the new objects in TG. At the very least it will be a less complex way of playing with all of this (just one object VS a whole planet, or even a Heightfield). Also there was all of those threads on rock spires, I need to look back at all of those now too. Lots of reading for me to do today.
At one point I had added the third dimension to mogn's beveled rectangles, saved it as clipfile, but when I later opened it, the extra blues were missing. I probably didn't select the all before saving. I have to do the trick again (it's not hard, just copy the stuff that goes into the X and Z and do the same for Y).
So then you have squares in 3D... but then comes the hard part, having the angling surface 'fill' by displacement to the max of the white or grey in the squares. I do have another idea, but have to test that... testing now....
edit: if anybody else is in for testing, why not try masking a strata shader by mogn's beveled squares in all sorts of combi's.
Ulco is right it's really easy to set up.
Here is a simple example.
Didn't bother to fine tune it in any way.
[attach=1]
[attach=2]
Just to illustrate the problem.
Maybe converting to vectors would yield better results,
don't know.Busy with other time consuming stuff.
Forgot to add the tgd.
Which doesn't use mogns set up btw.
Thanks J, just downloaded. Will get into your head today sometime.
Is this not so interesting as I think it is? I just am having a blast seeing the completely different results people are getting. Same basic ideas, but if you look at the images here there are completely different aesthetic and feel to the results. I just think that's fun man!
And really, despite my complaints, and the obvious work I have to do yet, I am really happy with some of the results I got already. On my BW image on the last page, I really like the weathered look I was getting. Got to try and keep that while fixing the other things... And that does get hard when every node seemingly effects every other node, and especially when there are a crap ton of nodes :P
Try this, funny walls can be made with a little experimentation...
TEhhehe ;D
You're not sick; but, you're not well...
Its just that previously to this thread I used hand drawn displacement maps for anything that others would use blue nodes for. ITs much better to use blue nodes.
I just learned a ton about TG in the last week is all. Or rather I can now make more practical, the things I understood in the abstract.
Still really cant construct my own functions yet. I understand the functions and most of the math. A rectangle is not exactly astro physics. But a blue node for each part of an expression just doesn't translate for me now. I would probably do better if I could just write things out in a text editor, but that is also in its self a time consuming learning indevor.
Another hard part of the blues, is that some nodes simply understand and pass on the data of the previous node so that it can be altered by the next node, and that becomes its own language... Then when you start back feeding nodes into nodes, so that several nodes have multiple connections, speaking/writing becomes almost non linear which makes no sense to me.
On the plus side, I am having a blast making small edits to the files posted here, and then mix and matching groups of clips. When I think of the clip files here as one node (where the group serves one purpose) then I make good progress using them to draw with.
Doubt I'll ever be an expert or anything, but I am being productive right now and that makes me feel good.
Quote from: j meyer on October 11, 2014, 12:39:45 PM
Forgot to add the tgd.
Which doesn't use mogns set up btw.
Nice, But why do you use colour nodes, when it all end up in a displacements node which
takes a scalar input. Some trick: replace "add"("sin"(x),"scalar"(1)") by "complement"("sin"(x))
saves one constant and gives a nicer Network.
Now you use 19 blue nodes, I think it could be reduced to less than 15.
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 like J's try here a lot. But if anyone can refine what it is doing even further that would be very cool.
In general (but not always) the fewer nodes the better IMO.
I believe you guys have taken me pretty much where I want to go on my current project as far as this topic go's. But I have many plans for these noises. I have a stack of ideas that I could not do before, so any refinement for ease of use and look, would be great!
Hope you guys continue. I will post some images of how I am using your noises in a while. I am using several. My node tree looks like a crack head made it, but it works, so I don't mind my mess ;D
8)
I will try some more later, but have little time right now. But it's challenging, so....
QuoteBut it's challenging, so....
Which? your project, or these noises?
Both!
Quote from: j meyer on October 13, 2014, 11:15:33 AM
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.
"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.
@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.
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.
Quote from: Dune on October 18, 2014, 04:20:35 AM
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.
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 ;) )
Yes please.
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.
"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.
Quote from: Hetzen on October 18, 2014, 08:25:08 AM
"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.
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.
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.
That's one reason chris suggested to work with an exported part of TG geometry
in the vdisp thread btw.
"...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..."
What about the shrooms and hoodoo stuff generated with PFs then?
Quote from: j meyer on October 18, 2014, 12:08:08 PM
That's one reason chris suggested to work with an exported part of TG geometry
in the vdisp thread btw.
Yes true, but that's not really the discussion here isn't it?
The discussion is how....well....just read it again ok ;) ;D
Quote from: j meyer on October 18, 2014, 12:08:08 PM
"...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..."
What about the shrooms and hoodoo stuff generated with PFs then?
Well, see the bold section in my quote... I didn't want to go through my explanation entirely again on self-repeat so you'll have to scroll up to understand what I really meant.
The shrooms/hoodoos are made of >1 nodes.
So just to clarify once again: if you have a 3D noise and a piece/part of it in the shape of a shroom/hoodoo would intersect with you terrain then TG does NOT displace that part of the terrain in the shroom/hoodoo shape.
Instead, it samples the presence of the noise AT the surface and only "sees" the circular base section of the shroom/hoodoo. The result will be a circular blob.
A true volumetric interpretation of the noise would extend the surface into that shroom/hoodoo.
Ok, last time I have tried to make my point ;) ;D
Thank you sir,thankyou ,thankyou.....and thank you again.
Doing some tests again with vdisp. I made a 32 bit file with PS, using 'render clouds' in the RGB channels, and hardening them, then tiling, then used this to vdisp a terrain. No real rectangles, but interesting patterns can be made..
Quote from: j meyer on October 19, 2014, 10:41:02 AM
Thank you sir,thankyou ,thankyou.....and thank you again.
Haha well I can see how my post may have come accross as derogatory, but surely wasn't meant like that!
I'm struggling with this for weeks and its difficult stuff to explain what's really missing or not to me/our liking.
Also, or may be especially, the lack of attention for this subject by PS made me a bit grumpy.
8 years of TG2 and we're still struggling and nothing changes significantly in the way we can build scenes.
So sorry Jochen if I sounded like a dick, I didn't mean to and your sarcasm was deserved :)
If you use a surface layer as parent for your noise function then that noise function maps a lot nicer on your terrain if you enable smoothing in that surface layer parent.
Be aware...
It will smooth out any displacements you did after that compute terrain, be aware of that.
Also, if you use multiple compute nodes then it will use the info from the very first one only (top compute node in network).
For mapping on overhanging/lateral features you need additional compute nodes, but the smoothing function in the surface layer won't allow you to work with any other compute node than the first/top one.
What will happen is that your overhanging/lateral features will (almost) disappear.
Ideally we should be able to select which compute node to use for smoothing.
^^To tell you the truth, I would not mind a more step by step break down of what you wrote in your last post. I am really nearing the point of giving up. And not just on this one issue, but completely. To say I am frustrated would be a massive understatement.
I wonder if the smoothing also works/helps if you use a vdisp setup, instead of regular PF noise. Will try. I will also try to make a vdisp map of really hard blocks, but it's hard to model real hard blocks in mudbox. At least I haven't figured out how to do that. It would be really cool if you could replace the RGB channels of a 32bit vdisp map (why should it be 32 bit anyway, why not 16bit?) with a procedural noise making blocky outcrops. That is my line of thinking atm.
And another one, after a simple rotation.
T-U - Ok Martin,no problem.
Nice experiments Ulco.
Have you tried image based displacement as a base for
the modeling in mudbox already?
Please let me explain my view and why I think vdisp in TG
might be a solution.I'll try to keep it short.
Is the noise as such 3D or not? I say it is.
Apply a single PF as a density shader to a cloud shader and
what you get is a visual representation of the structure of
the noise.Not the displacement or so,just the pure noise
structure.
[attach=1]
If you examin these structure(s) closely you will see that it's
true (virtual) 3D and not 2D projections on every axis or some-
thing like that.You wouldn't get those arches and caverns with
a 3axes 2D projection.(If you don't believe that,try it,it's posssible
to try that in TG,too).
Then we have our planet,which - from my point of view - is a
procedural sphere or in other words a hollow ball with a sort of
membrane as surface.It's cutting through the noise.
[attach=2]
This membrane is displaced then.And this is where the problems are.
The usual displacement we see in TG is as far as I understand it
not vector displacement,but simple displ that can be compared to
how a heightfield is displaced,not exactly,but in a way at least.
(we have a conversion node displacement to vector,this also
suggests a difference)
Think of vacuumforming with a rather stiff material.
You won't get much undercuts and stuff that way.A more flexible
material is needed - in our case vdisp - to get more detail,namely
undercuts/overhangs and cavities and so on.No holes,though.
Due to the closed surface nature of our membrane we also won't
get holes in TG,but cavities and overhangs are dfinitely possible
with vdisp.
If you think along those lines and examine the images you can get
an idea where some of the distortions come from.(try the cubic noise
on clouds also to see that)
My conclusion is that we need a way to convert a noise into vector
displacement,the nodes needed are there already.
Or better how to specify a special shape and where it's desired to be
located and things like that.Seems to be quite complex,but maybe it
turns out to be rather easy,who knows.
It would be nice to have a working example file to learn from and
personally I hope Matt will give us a hint at least.
All of the above might be wrong of course,at least it's incomplete.
And please excuse may laymenship.
This is exactly what I meant and my beef I'm having with TG during my current job, but also personal wish-list of things to be able to do.
Nice explanation and demonstration!
The fact that you can convert displacement to a vector doesn't necessarily suggest things might be otherwise as you are thinking though?
A vector is just a thing which defines the direction and magnitude a certain point on the surface is pushed to.
The surface itself is displaced into 3D coordinate space and that's where you need vectors to define pre- and post-displacement positions for a given point on the surface.
So even in the situation you described TG is working (which I agree with), the presence of vector operator doesn't suggest something truly 3D is going on.
Question indeed is, how do we get vdisp-like behaviour for our procedural noises???
Given that vdisp can do this means that TG implicitly is capable of performing such displacements and that the key is in how the noises are being sampled which really seems to be NOT volumetric?
Matt???
As you said, vector displacement maps can be imported into Terragen, and that works. So vector displacement can be done. There is absolutely nothing to prevent you from doing a procedural vector displacement, either. This is what the Redirect Shader is for, or more recently the Vector Displacement shader. The renderer is capable of doing so, and the nodes are there. What you're asking for is a specific procedural noise that not only produces a vector (of which there are many existing examples and methods of doing so) but also produced a vector that when added to the current position produces a surface that you like. This is a harder problem ;)
I have some more to write on the subject, and will do so soon.
I may put my foot in my mouth as I lack a lot of knowledge in this area, but the way things in TG work now seems normal and no different than any other displacement-based system. Vector displacement is different thing, which is why it is more capable, but as Matt says simple noises do not (currently? normally?) produce vector values that can be used in this way. Let me try to explain *how I understand it* (which may be wrong).
In traditional displacement (and simple displacement maps), the map is generally a single channel, "grayscale" one might even say, and the lightness value defines the "amount" of displacement. Since it is only defining a single value - lightness, which is interpreted as "strength of effect", just as in a mask - there is no way to get overhangs on a single pass of displacement, just like you cannot have overhangs on heightfields. You can have lateral displacement (applying displacement that is lateral to another surface, relatively speaking), which creates a kind of "overhang", at least relative to the planet surface for example, but from the point of view of the surface the displacement is being applied to there is no non-planar movement that is happening.
Vector displacement is a solution because it encodes a vector for each point in the source map, 3 coordinates rather than 1, sometimes interpreted (or viewed) as R, G, B color values. This allows for the precise placement of the resulting displaced points/vertices, rather than just encoding an "amount of displacement", and thus overhangs or really any continuous-surface 3D shape are possible.
There's a lot of good info and examples on this here: http://renderman.pixar.com/view/vector-displacements
Now, simple noise functions generally create basic lightness values in 3D space so sampling that along a surface and then using it for displacement will only ever create non-overhanging results, at least for single-order displacement. Subsequent displacement can then operate on that already-displaced surface and create additional changes which are still planar, when considering the *current* displacement, but when taken as a whole do create overhangs, etc., i.e. more complex surfaces and shapes. The trick, then, is to come up with a function that outputs vectors instead of single values when sampled, and does so in a coherent way that creates the kind of shapes you want (as Matt said).
So what TG is doing with displacement is quite normal and "correct", you just want a higher or more complex form of displacement (vector displacement). If you think of a 3D noise function that is creating RGB values instead of simple lightness, this is perhaps easy to imagine. Or perhaps you simply use the density of the currently sampled point in the (existing) noise function and define a threshold for the surface, which I guess is kind of like how isosurfaces work. The question is how to create or derive these values in TG and how to then interpret them for a coherent result. Simply sampling RGB values of our theoretical "vector noise" instead of V(alue)/B(rightness) will give you the right *kinds* of values, but will they create coherent output? Remember that displacement is the difference between the flat surface you start with and the position each point should end up at, so Brightness is easy to deal with, you can ensure no overlaps, and the worst problem you run into is roughness I guess. But how do you translate the position of a flat sphere to equal the shape you want to sample from your noise function? Maybe it "just works" (like regular displacement) once you have the necessary source data, I'm really not sure. If it's that easy I'm surprised it hasn't been done (here) yet though. :D
As I mentioned, I think this is where isosurfaces can be interesting as they can essentially create arbitrary volumetric surfaces out of simple 3-dimensional input data (e.g. any current noise function). This is not something that simple displacement can do, but yes *vector* displacement can, so let's figure out how to get vector values out of the noise functions and apply them! :)
Hopefully that is helpful and adds to the discussion rather than just confusing things more. Like I said, I'm no expert at this stuff!
- Oshyan
This is an interesting problem that I keep coming back to. I'm often finding that I need to create rocky cliffs, and it's really difficult to do well.
Simply displacing along the normal has problems. I've seen some procedural examples in this thread that look pretty good when you apply them on a smooth surface, or even a fairly steep surface that points in the same general direction. But there's always the problem of what to do near the top of the cliff where it merges into the flat top of the cliff, and what to do when the cliff face changes direction.
One of the smartest people I know is a guy by the name of Johnny Gibson. In 2001, I was working at Digital Domain. We were working on a film called The Time Machine. Johnny was simulating the erosion of a canyon, a bit like the Grand Canyon, over thousands of years, depicted like a time-lapse sequence. Starting with an elevation map of the Grand Canyon with all its tributaries and fractal valleys, I suggested that we could wind back the clock by adjusting the white point and black point on the elevation map and adjusting the curve, and so on, and then running those adjustments forward through time to gradually widen the canyon at the same time as deepening it. I don't remember if we stuck with that approach, but that was our general starting point for the shape of the canyon eroding over time. That was the easy part.
We needed to add procedural detail to the canyon, of course, and that detail had to change over time. It couldn't be static. Johnny wanted to make it as realistic as possible. He wanted to simulate volumetric rock with hard bits and soft bits that would influence the shape of the surface as it eroded. He was working in Houdini, which at that time was probably the package most suited to this kind of R&D with confidence that it could all be turned into production quality renders when all's said and done. As I recall, one of his ideas was to use Voronoi noise and to project/displace the surface towards the nearest Voronoi cell boundary. As the surface gradually lowered, there would be frames where the surface would instantly pop to a different cell wall. The idea was that this would create a really rocky, craggy looking surface that would collapse in discrete chunks over time as the soft material around the rocks eroded. It sounded like a great idea to me. Unfortunately the client didn't like the frenetic appearance of it due to the extreme time-lapse - even though that might be realistic as far as we were concerned - and we were never able to take it to its full conclusion and make it look really good. But the idea has stuck with me ever since, and I'm reminded of it every time I want to create a surface that should be defined volumetrically to get the best results.
The canyon we ended up with in that film didn't look great - and is pretty poor by today's standards - but I think that's because they were forced to change direction very late in the game and only had a few short weeks to come up with something completely different. Terrain was a difficult thing to make photorealistic in those days, so that kind of U-turn wasn't good. I would have liked to see Johnny's volumetric terrain given the chance to see the light of day. It could have been a much more awesome piece of cinema.
Incidentally, a strange phenomenon would occur when we tried to volumetrically texture (colour) the rock as it was eroding. As the canyon widens, it looks as though the texture is somehow sliding across the surface, and it looks strange even when you understand why it's happening. It's not the kind of thing you want to happen in a movie scene where there's already a lot of crazy stuff happening that most people won't be able to comprehend. So we had to do a lot of cheats, generate UV maps, and slide textures using keyframes. Horrible stuff you would never imagine needing to do, just to make it look OK in the end. Sometimes doing it 100% correctly results in something you really don't want to look at. While the frenetic popping of disappearing boulders had this effect on the client, the sliding volumetric textures made us realise that we weren't immune to such things.
In 2009 I was back at DD and was asked to develop a RenderMan shader for the earth opening up as Santa Monica Airport was being torn apart by whatever ridiculous thing was supposed to be happening in the movie "2012". I really wanted to produce a nice volumetric appearance to the sides of the chasm so I set about using Johnny's idea to do so. I needed to implement a version of Voronoi that returns more information than you get from the textbook/web examples. So I did that. After solving a few other problems along the way, and making some compromises to work around other problems that I couldn't figure out, I got something fairly decent. But it doesn't fully achieve the goal of a volumetric voronoi displacement. The things I wanted to do produced discontinuities that I didn't have time to work out a way to prevent. It was good enough for the specific geometry it would be applied to for the movie, but I ran out of time to really solve the general problem, and once they were happy with the results it was time for me to move on.
I wanted to bring that knowledge back into Terragen, and either write a shader or share a combination of function nodes to do this. I still want to do this. But it's difficult to devote weeks and weeks to a difficult problem that you don't even know for sure will succeed in the end, when users are screaming for more immediate problems to be solved and there are only 2 people to solve them. I have had some minor successes in this area and I keep coming back to this research every now and again. I think that some day I'll be able to show you a working technique or perhaps a shader to accomplish this.
By the way, this whole problem is solved by using an isosurface renderer. Maybe in the future we can give you isosurfaces as an alternative method of building and rendering terrains. While it could be done in a fairly simplistic way and released as part of the product, many of Terragen's existing capabilities would be missing from it. It would essentially be like a separate kind of entity within the scene. I don't know if isosurfaces will render more efficiently than micropolygons. It might take years before it would become a mature, reliable rendering solution in Terragen. So it's no small undertaking. Furthermore, it adds complexity to the application as a whole. But it's something I'm interested in trying out some day.
So the volumetric procedural surface problem is one thing. It's not that vector displacement can't be done, it's that it's difficult to obtain the correct vector that produces the volumetric target that you want. Another idea is to iteratively displace the surface towards the volumetric description, until you approximately converge on it, but that's slow. I tried it once, with a simpler volumetric description, and the speed didn't encourage me to continue that line of research. Isosurface rendering inherently uses an iterative approach, so that can also be slow, but I think the costs are higher when you combine microvertex displacement with an iterative solve. I don't see any evidence that the two approaches are going to hybridize in an efficient way, but I could be wrong.
These days when I need to create a rocky cliff-like surface, I tend to hack away at a few different ideas and combine them together until it works well enough for the job at hand. It doesn't look any better than many of the networks that I've seen posted on this forum, and the setups are usually messy by the end of a VFX production where you never get a chance to really clean things up and understand how and why they're working. Sometimes I'll try to simplify these setups afterwards, and they fail to work in a satisfying way on other scenes that I try to apply them to. But I'll keep trying.
The other problem that was raised in this forum thread is that of extremely stretched vertical surfaces. The way I like to solve this is to start with a surface that is inclined, but not completely vertical, and then displace it outwards so that it becomes vertical. In some situations this can be done quite easily, for example with a Twist and Shear shader. If you have a cliff that faces in the same general direction all along its length, this is fairly straightforward. You could use a Simple Shape Shader for the initial displacement, and then a Twist and Shear to shear it into a vertical wall. It has some unintuitive behaviour though. The entire surface at the top of the cliff is now offset horizontally from where it would have been otherwise. This might cause problems for texturing or applying other shaders. I've also been working on some ideas for built-in shaders that make this a simpler thing to do with only one node (e.g. a Cliff Shader), and I also want to give it some easy ways to add shaders to different parts of the cliff. It suffers from the same problems though. And unfortunately it might give awkward results if the cliff is not just a single face. A mesa which has surfaces facing in all directions requires that the top of the mesa is stretched outwards from some central point. This sets of limit to how small you can make that mesa so that you're not stretching the entire surface from a single point, which is impossible for the renderer to handle. Anyway, one of my goals for Terragen 4 is to provide nodes that make this stuff easier, even with these caveats.
I don't know if it will be possible to produce a "retopologize" node for displaced surfaces, but that's something I've started to think about. The way the renderer subdivides surfaces might make this difficult - I don't know yet.
A future goal of Terragen (and we're thinking about prioritising this for Terragen 4) is to be able to render imported (or otherwise modeled) geometry with the same fidelity as the built-in displaceable primitives. This way you could model your rock face with polygons and then not have any vertical displacements to worry about.
Another aspect to this whole subject is "discontinuity". When displacing a surface, you don't want a displacement that suddenly jumps from one value to another. Terragen will keep on subdividing this discontinuity until it reaches an internal limit, for performance reasons. The discontinuity is never resolved because the function simply does not define any inbetween points that the renderer could ever discover. We know about how this problem pertains to generating vertical cliffs. But it applies more generally than that. Some of the most convincing rocky surfaces are produced by functions that unfortunately have these discontinuities, so you can't get close to them. I'd like to try to implement some soft-edged versions of some useful functions that should allow us to create more useable "rectangular noise" prodedures and other rocky cliff type effects.
I think about these problems and I'll be slowly chipping away (aha) at them from various angles when I get chance.
Matt
How many times did I write "problem" in that last post?!
Matt
QuoteThere is absolutely nothing to prevent you from doing a procedural vector displacement
Ok, but in my limited experience these two things (vector and procederal) are contrary. That is, my experience with a vector is like a heightfield where the vector is limited to one place and form for the most part, like a DEM.
But a procedural is un limited by place or form, since it can go on forever in every direction, and it's form can be altered without limit.
So, if the way forward as things are now is a procedural vector, how is that done?
Again I am thinking of vectors in terms of the mudbox thread. So if I should be visualizing this in another way I need someone to describe it to me.
And it would not hurt is someone could post some files in a very simple way that shows precisely the whole thing
(procedural vector displacement) in the context of rectangular noises.
If everyone gets this but me, well oh well. But somehow I doubt that I'm the only one with a headache right now.
Hi Badger,
Procedural (in the usual Terragen sense) just means that we calculate the value of each point instead of reading the value from a file or user input. Vector displacement - as opposed to scalar displacement - means that we control the direction of the displacement, not just the magnitude. You can do procedural vector displacement just by plugging 3 functions into a Build Vector node and plugging that into a Vector Displacement shader. All this does is provide a function for each of the 3 components of the displacement: X, Y and Z, which together make the vector by which the surface is displaced. But you can think of it as being 3 different displacement shaders in X, Y and Z, combined into one vector displacement.
Matt
Edit: Matt explained this better and more briefly while I was typing, but I'll post this anyway for the fun (and because Matt confirmed I was right, haha!).
There's nothing contrary between vectors and procedurals in this context (or otherwise). They are, if anything, simply not directly related or dependent. You can generate vectors without a "procedural" function, and you can have a procedural function that does not output (or is not interpreted as) vectors (in fact most in TG are this way I believe). I think what you need to get a good handle on is the difference between vector displacement and regular displacement that I described above (and which is nicely illustrated at the link I provided to Pixar's docs). Then make sure you also understand how the procedural noise functions in Terragen (and, I think, most 3D apps) work, the kind of data they normally create. Once you have that understanding it should make more sense why this doesn't "just work". That's not to say it's impossible, but it doesn't work "out of the box" certainly. Terragen is setup to do basic, normal-oriented displacement (or single-axis if desired).
Now here's a thought for you, I have no idea if this will actually work so it might be a bad idea to tell you, it might just confuse you more. But I'm counting on other people to try it or at least correct me if I'm talking crazy. ;) Anyway, the thought is, take a look at the Vector Displacement Maps that people were able to use and *how they are applied in Terragen*. Then, instead of building your vectors out of an exported map from Mudbox or Zbrush, use Power Fractals as input to a Build Vector which goes into the Vector Displacement Shader. I don't see why this wouldn't work, at least in as much as it will *create displacement*. It will probably look terrible though because the vectors are all over the place since there'd be no relationship between the output of 3 different Power Fractals. ;) You could try using 3 copies of the same noise and see what that does, the result ought to be more coherent in some sense at least. But hopefully you get the idea that noise values are not inherently a good thing to derive vector coordinates from for vector displacement.
OK, my curiosity was piqued and now *I'm* playing with this, haha. But please note I have never even done vector displacement from Mudbox or anything, so I really have no idea what I'm doing. So far I have a "result" but no idea what it means, so I won't show it yet. However I did come across something totally unrelated but novel-looking and I couldn't help sharing it with the question: "Why don't people play with clouds-as-terrain/objects more often?". Just look at this little garden of weird cloud shapes! :D
- Oshyan
Ok, this is doing something. I have to get to bed for now, but I will pick this up again tomorrow, unless somebody beats me to it (its super easy to do, the question is how controllable/directable it is). But surprised I've not seen someone doing this already... I kind of think someone probably has and I just didn't know it. :D
- Oshyan
Thanks for your comprehensive post, Matt and Oshyan. I was thinking along the same lines, but can't stop experimenting. As a matter of fact I've experimented before with procedural vdisp setups, like you mention, Oshyan, but you can't help getting weird unnatural crossovers, where the 'membrane' overlaps, so I dropped that. My latest experiment was with a repeated and procedurally multiplied/changed vdsip map, while using several angles for displacement and several angles where what should displace in what direction. But the main problem is indeed that a displacement is relative to a greyscale (PF or vdisp) and it's origin in space; it won't fill the space, or fold the membrane into the end of the '3D space's whiteness'.
If the surface is already vertical or horizontal you can get blocky stuff, but not when you start out of smooth rounded slopes, TG should then displace that with a biased number or something, based on Y, X and Z in some blocky mathematical relation.
This morning I was thinking about using angle and slope based tilt and shear, fed by blocky pf's..... so that'll be next. And make a better vdisp map in mud (I'll try it image based, Jochen, thanks).
Tilt and shear doesn't work.
" I'd like to try to implement some soft-edged versions of some useful functions that should allow us to create more useable "rectangular noise" prodedures and other rocky cliff type effects"
The thing I'd most like is a soft edged voronoi 3d cell scalar. So that I could build softer 3d displacement within voronoi cracks.
I've not had time to play much but I've been following this closely. I have had some minor good results but no better than some of the ones here. I did achieve another goal of mine " flaky rock and then as is the way crashed tg and lost the file. I'll soon have time to play so we'll see.
Thanks Matt for the explanations they have given me some ideas.
Quote from: mhaze on October 21, 2014, 03:14:19 AM
The thing I'd most like is a soft edged voronoi 3d cell scalar. So that I could build softer 3d displacement within voronoi cracks.
Yep, that's the one I want to try first :)
Matt
Great news ;D Meanwhile I've been trying to adapt mogn's bevel quilt cubic noise, sadly though I don't really understand it or have the time to play at the moment.
Thanks a bunch Matt and Oshyan,
It's good to read there is experience with this, regardless succesful or not, and that options for the future are in mind.
Personally I wish a solution or partial improvement could be found soon to aid me in my job for Unity, but I understand very well these things are not possible on such short notice.
But perhaps the following is nice for you to read and think about...
Yesterday I had a chat about this with Jon West (Hetzen) and we knew "vectorizing" the workflow is key.
What we need to take into account is the vector of the terrain, I suppose?
Using a "displacement shader to vector" node converts the terrain displacement to a vector.
From there we think we need to "normalize" the vectors from the rectangular noise values with the vector of the terrain.
Normally (pun), normalizing is a simple division of one over the other, but that gives really messed up results.
Yet I feel we have to work with these 2 together, the vector from the rectangular noise and the vector of the terrain you want to map it on.
After the normalization, or whatever you need to make it work, you feed the resulting final vector back into a vector displacement shader and you will have the terrain + rectangular noise.
How to tell the renderer how to "correct" or normalize is beyond me and even Jon couldn't wrap his brain around it.
Nonetheless I think it's nice to show this file showing the principle I'm talking about.
Matt,
Quote from: Matt on October 20, 2014, 09:03:28 PM
...
These days when I need to create a rocky cliff-like surface, I tend to hack away at a few different ideas and combine them together until it works well enough for the job at hand. It doesn't look any better than many of the networks that I've seen posted on this forum, and the setups are usually messy by the end of a VFX production where you never get a chance to really clean things up and understand how and why they're working. Sometimes I'll try to simplify these setups afterwards, and they fail to work in a satisfying way on other scenes that I try to apply them to. But I'll keep trying.
...
Haha, that's oh so damn recognizable Matt. I can make a NWDA product of all my rock setups or whatever I made, but they all seem to work in very specific situations :)
This is close but note that any Z aligned faces have no displacement.
+1 more thank you Matt and Oshyan from me too.
Seems to be as complex as I was afraid it was,sigh.
Still hoping that some genious might find a simple solution one day.
Heehee,the Simple Solution Shader. ;)
;D
Now rotate it in Z or X direction and apply only to Z or X faces.
One thing at a time, I've just spent the last hour trying to restrict it only to steep slopes with absolutely no luck whatsoever.
UPDATE managed to mask it with the disp to vector shader.
Gosh, thanks Matt. What a compliment. I think I still have the VFL code for that function. I think we called it "Bouldering" at the time. I can track it down and send it to you when I have sec. If I recall correctly I also implemented it as a SOP in Houdini and it looks AWESOME animating. I will see if I can find it but here is the general solution:
Loop over a 3x3x3 cell area centered on the current jittered cell center C, finding the neighboring cell centers Ax = A0...A8. Define each cell's boundary surface to be the surface, Sx, half-way between C and Ax with the normal Nx = normalize(Ax - C). Project the point P, being processed along P - C onto Sx. Call this ray intersection Ix. Remember Ix and dx = distance(Ix, P). The closest boulder face after the loop is the one with the smallest positive dx.
Quote from: Matt on October 20, 2014, 09:03:28 PM
This is an interesting problem that I keep coming back to. I'm often finding that I need to create rocky cliffs, and it's really difficult to do well.
Simply displacing along the normal has problems. I've seen some procedural examples in this thread that look pretty good when you apply them on a smooth surface, or even a fairly steep surface that points in the same general direction. But there's always the problem of what to do near the top of the cliff where it merges into the flat top of the cliff, and what to do when the cliff face changes direction.
One of the smartest people I know is a guy by the name of Johnny Gibson. In 2001, I was working at Digital Domain. We were working on a film called The Time Machine. Johnny was simulating the erosion of a canyon, a bit like the Grand Canyon, over thousands of years, depicted like a time-lapse sequence. Starting with an elevation map of the Grand Canyon with all its tributaries and fractal valleys, I suggested that we could wind back the clock by adjusting the white point and black point on the elevation map and adjusting the curve, and so on, and then running those adjustments forward through time to gradually widen the canyon at the same time as deepening it. I don't remember if we stuck with that approach, but that was our general starting point for the shape of the canyon eroding over time. That was the easy part.
We needed to add procedural detail to the canyon, of course, and that detail had to change over time. It couldn't be static. Johnny wanted to make it as realistic as possible. He wanted to simulate volumetric rock with hard bits and soft bits that would influence the shape of the surface as it eroded. He was working in Houdini, which at that time was probably the package most suited to this kind of R&D with confidence that it could all be turned into production quality renders when all's said and done. As I recall, one of his ideas was to use Voronoi noise and to project/displace the surface towards the nearest Voronoi cell boundary. As the surface gradually lowered, there would be frames where the surface would instantly pop to a different cell wall. The idea was that this would create a really rocky, craggy looking surface that would collapse in discrete chunks over time as the soft material around the rocks eroded. It sounded like a great idea to me. Unfortunately the client didn't like the frenetic appearance of it due to the extreme time-lapse - even though that might be realistic as far as we were concerned - and we were never able to take it to its full conclusion and make it look really good. But the idea has stuck with me ever since, and I'm reminded of it every time I want to create a surface that should be defined volumetrically to get the best results.
The canyon we ended up with in that film didn't look great - and is pretty poor by today's standards - but I think that's because they were forced to change direction very late in the game and only had a few short weeks to come up with something completely different. Terrain was a difficult thing to make photorealistic in those days, so that kind of U-turn wasn't good. I would have liked to see Johnny's volumetric terrain given the chance to see the light of day. It could have been a much more awesome piece of cinema.
Incidentally, a strange phenomenon would occur when we tried to volumetrically texture (colour) the rock as it was eroding. As the canyon widens, it looks as though the texture is somehow sliding across the surface, and it looks strange even when you understand why it's happening. It's not the kind of thing you want to happen in a movie scene where there's already a lot of crazy stuff happening that most people won't be able to comprehend. So we had to do a lot of cheats, generate UV maps, and slide textures using keyframes. Horrible stuff you would never imagine needing to do, just to make it look OK in the end. Sometimes doing it 100% correctly results in something you really don't want to look at. While the frenetic popping of disappearing boulders had this effect on the client, the sliding volumetric textures made us realise that we weren't immune to such things.
In 2009 I was back at DD and was asked to develop a RenderMan shader for the earth opening up as Santa Monica Airport was being torn apart by whatever ridiculous thing was supposed to be happening in the movie "2012". I really wanted to produce a nice volumetric appearance to the sides of the chasm so I set about using Johnny's idea to do so. I needed to implement a version of Voronoi that returns more information than you get from the textbook/web examples. So I did that. After solving a few other problems along the way, and making some compromises to work around other problems that I couldn't figure out, I got something fairly decent. But it doesn't fully achieve the goal of a volumetric voronoi displacement. The things I wanted to do produced discontinuities that I didn't have time to work out a way to prevent. It was good enough for the specific geometry it would be applied to for the movie, but I ran out of time to really solve the general problem, and once they were happy with the results it was time for me to move on.
I wanted to bring that knowledge back into Terragen, and either write a shader or share a combination of function nodes to do this. I still want to do this. But it's difficult to devote weeks and weeks to a difficult problem that you don't even know for sure will succeed in the end, when users are screaming for more immediate problems to be solved and there are only 2 people to solve them. I have had some minor successes in this area and I keep coming back to this research every now and again. I think that some day I'll be able to show you a working technique or perhaps a shader to accomplish this.
By the way, this whole problem is solved by using an isosurface renderer. Maybe in the future we can give you isosurfaces as an alternative method of building and rendering terrains. While it could be done in a fairly simplistic way and released as part of the product, many of Terragen's existing capabilities would be missing from it. It would essentially be like a separate kind of entity within the scene. I don't know if isosurfaces will render more efficiently than micropolygons. It might take years before it would become a mature, reliable rendering solution in Terragen. So it's no small undertaking. Furthermore, it adds complexity to the application as a whole. But it's something I'm interested in trying out some day.
So the volumetric procedural surface problem is one thing. It's not that vector displacement can't be done, it's that it's difficult to obtain the correct vector that produces the volumetric target that you want. Another idea is to iteratively displace the surface towards the volumetric description, until you approximately converge on it, but that's slow. I tried it once, with a simpler volumetric description, and the speed didn't encourage me to continue that line of research. Isosurface rendering inherently uses an iterative approach, so that can also be slow, but I think the costs are higher when you combine microvertex displacement with an iterative solve. I don't see any evidence that the two approaches are going to hybridize in an efficient way, but I could be wrong.
These days when I need to create a rocky cliff-like surface, I tend to hack away at a few different ideas and combine them together until it works well enough for the job at hand. It doesn't look any better than many of the networks that I've seen posted on this forum, and the setups are usually messy by the end of a VFX production where you never get a chance to really clean things up and understand how and why they're working. Sometimes I'll try to simplify these setups afterwards, and they fail to work in a satisfying way on other scenes that I try to apply them to. But I'll keep trying.
The other problem that was raised in this forum thread is that of extremely stretched vertical surfaces. The way I like to solve this is to start with a surface that is inclined, but not completely vertical, and then displace it outwards so that it becomes vertical. In some situations this can be done quite easily, for example with a Twist and Shear shader. If you have a cliff that faces in the same general direction all along its length, this is fairly straightforward. You could use a Simple Shape Shader for the initial displacement, and then a Twist and Shear to shear it into a vertical wall. It has some unintuitive behaviour though. The entire surface at the top of the cliff is now offset horizontally from where it would have been otherwise. This might cause problems for texturing or applying other shaders. I've also been working on some ideas for built-in shaders that make this a simpler thing to do with only one node (e.g. a Cliff Shader), and I also want to give it some easy ways to add shaders to different parts of the cliff. It suffers from the same problems though. And unfortunately it might give awkward results if the cliff is not just a single face. A mesa which has surfaces facing in all directions requires that the top of the mesa is stretched outwards from some central point. This sets of limit to how small you can make that mesa so that you're not stretching the entire surface from a single point, which is impossible for the renderer to handle. Anyway, one of my goals for Terragen 4 is to provide nodes that make this stuff easier, even with these caveats.
I don't know if it will be possible to produce a "retopologize" node for displaced surfaces, but that's something I've started to think about. The way the renderer subdivides surfaces might make this difficult - I don't know yet.
A future goal of Terragen (and we're thinking about prioritising this for Terragen 4) is to be able to render imported (or otherwise modeled) geometry with the same fidelity as the built-in displaceable primitives. This way you could model your rock face with polygons and then not have any vertical displacements to worry about.
Another aspect to this whole subject is "discontinuity". When displacing a surface, you don't want a displacement that suddenly jumps from one value to another. Terragen will keep on subdividing this discontinuity until it reaches an internal limit, for performance reasons. The discontinuity is never resolved because the function simply does not define any inbetween points that the renderer could ever discover. We know about how this problem pertains to generating vertical cliffs. But it applies more generally than that. Some of the most convincing rocky surfaces are produced by functions that unfortunately have these discontinuities, so you can't get close to them. I'd like to try to implement some soft-edged versions of some useful functions that should allow us to create more useable "rectangular noise" prodedures and other rocky cliff type effects.
I think about these problems and I'll be slowly chipping away (aha) at them from various angles when I get chance.
Matt
Quote from: Tangled-Universe on October 21, 2014, 07:13:25 AM
Using a "displacement shader to vector" node converts the terrain displacement to a vector.
From there we think we need to "normalize" the vectors from the rectangular noise values with the vector of the terrain.
Normally (pun), normalizing is a simple division of one over the other, but that gives really messed up results.
Sorry Martin I didn't explain very well last night. What I was explaining is that you can get an RGB vector map of your terrain, that will work in an image viewer, by dividing the output of a "displacement to vector" node by your scenes maximum displacement (which in the default scene is 2000). This scales back the colour/vector information into a float (0..1) value that image viewers tend to use, rather than green values of 2000 plus, etc.
Thanks Johnny. I need to check my code to see if that's what I'm doing, but it sounds familiar. IIRC I was getting discontinuities. I'll take another look. Awesome :)
That's the inherent problem with the voronoi algorithm. Its discontinuous by design at the seams. Mainly because it was designed to generate seams. :) In theory you could super sample the seams with a filter to smooth it to bevel the plane pairs inside the checker loop but I've never tried.
Quote from: Matt on October 21, 2014, 04:20:21 PM
Thanks Johnny. I need to check my code to see if that's what I'm doing, but it sounds familiar. IIRC I was getting discontinuities. I'll take another look. Awesome :)
Quote from: jmgibson on October 21, 2014, 03:59:18 PM
Gosh, thanks Matt. What a compliment. I think I still have the VFL code for that function. I think we called it "Bouldering" at the time. I can track it down and send it to you when I have sec. If I recall correctly I also implemented it as a SOP in Houdini and it looks AWESOME animating. I will see if I can find it but here is the general solution:
Loop over a 3x3x3 cell area centered on the current jittered cell center C, finding the neighboring cell centers Ax = A0...A8. Define each cell's boundary surface to be the surface, Sx, half-way between C and Ax with the normal Nx = normalize(Ax - C). Project the point P, being processed along P - C onto Sx. Call this ray intersection Ix. Remember Ix and dx = distance(Ix, P). The closest boulder face after the loop is the one with the smallest positive dx.
Fascinating. Thank you for posting. Do you have any links or images we could see?
Quote from: jmgibson on October 21, 2014, 03:59:18 PM
Gosh, thanks Matt. What a compliment. I think I still have the VFL code for that function. I think we called it "Bouldering" at the time. I can track it down and send it to you when I have sec. If I recall correctly I also implemented it as a SOP in Houdini and it looks AWESOME animating. I will see if I can find it but here is the general solution:
Loop over a 3x3x3 cell area centered on the current jittered cell center C, finding the neighboring cell centers Ax = A0...A8. Define each cell's boundary surface to be the surface, Sx, half-way between C and Ax with the normal Nx = normalize(Ax - C). Project the point P, being processed along P - C onto Sx. Call this ray intersection Ix. Remember Ix and dx = distance(Ix, P). The closest boulder face after the loop is the one with the smallest positive dx.
Thank you for joining this discussion Johnny.
I'm curious too to see any links or images created with the method you described, just to see what's possible in principle :)
Quote from: jmgibson on October 21, 2014, 04:25:55 PM
That's the inherent problem with the voronoi algorithm. Its discontinuous by design at the seams. Mainly because it was designed to generate seams. :) In theory you could super sample the seams with a filter to smooth it to bevel the plane pairs inside the checker loop but I've never tried.
I imagine there must be some surface that sort of shrink-wraps the voronoi boulders without this discontinuity, and that's what I was trying to find. Supersampling sounds like it will be expensive, but perhaps I'm not thinking of the right way of doing this?
Matt
I don't mind a discontinuous normal, or sharp edges where planes meet, if that's what you mean. I just don't want the surface position to suddenly jump at a cell wall.
Matt
Quote from: Dune on October 21, 2014, 02:50:55 AM
Thanks for your comprehensive post, Matt and Oshyan. I was thinking along the same lines, but can't stop experimenting. As a matter of fact I've experimented before with procedural vdisp setups, like you mention, Oshyan, but you can't help getting weird unnatural crossovers, where the 'membrane' overlaps, so I dropped that. My latest experiment was with a repeated and procedurally multiplied/changed vdsip map, while using several angles for displacement and several angles where what should displace in what direction. But the main problem is indeed that a displacement is relative to a greyscale (PF or vdisp) and it's origin in space; it won't fill the space, or fold the membrane into the end of the '3D space's whiteness'.
If the surface is already vertical or horizontal you can get blocky stuff, but not when you start out of smooth rounded slopes, TG should then displace that with a biased number or something, based on Y, X and Z in some blocky mathematical relation.
This morning I was thinking about using angle and slope based tilt and shear, fed by blocky pf's..... so that'll be next. And make a better vdisp map in mud (I'll try it image based, Jochen, thanks).
Tilt and shear doesn't work.
maybe not Ulco, but that's a damn fine surface.
Here's something neat...just 2 vector displacement nodes and a strata shader :)
That looks extremely nice Martin!
I think any strictly rectangular, volumetric function is going to have issues being used as a displacement source at certain angles. You have the edges of each square in each dimension at some point, and this could end up just looking flat or crappy at some angles, right? If you want something that presents square shapes that are oriented toward the surface they are displacing, regardless of angle, then you need to take the surface normal into account when generating your function, and indeed a volumetric function probably isn't what you want (you're faking the appearance of it I guess, but to actually accomplish it the results need to vary by surface normal I think). Anyway, just some thinking out loud, might not make sense. ;)
Regarding smoother Voronoi, Inigo Quilez has written and shown some interesting info/examples on this:
http://www.iquilezles.org/www/articles/smoothvoronoi/smoothvoronoi.htm
http://www.iquilezles.org/www/articles/voronoise/voronoise.htm
- Oshyan
If you need flat squarish rocks, you should start with a quite straight angle and smooth base, then work the finer displacements in outside/around the blocks.
That one looks realy good TU. :D
;)
That looks pretty cool Ulco :)
Quote from: Dune on October 22, 2014, 02:38:59 AM
If you need flat squarish rocks, you should start with a quite straight angle and smooth base, then work the finer displacements in outside/around the blocks.
I suppose for this render you did the above? ;)
Unfortunately I have no idea what you actually meant here :D
Yes, I did. Well, if you start out with rounded shapes it's harder to get straight edges. I also limited to verticals, and used a get normal to project stretched PF's onto certain angles. Doing something with an image map now, which works much better as you have to softly ending lines from the PF's.
And I prefer displacement versus vecor displacement, because blocks will be square holes on the other end (unless you use 4 angles, instead of 2).
Image map shader...
Thanks for the in depth posting guys.
@Oshyan,
Were you going to continue where you left off?
...
So, where are we exactly then. The vector is the best way forward or not? Ulco thinks no it sounds. Or at least it sounds like there are an abundance of problems with every option. But what is really the best general or specific solution of the options that have been explored so far? I mean, what do you guys think now is the best place to invest effort and time of the the various ways of doing this? Still vector?
I would hope (I do hope), that at least one method of making rectangular faces and addressing the issues of applying the form to a terrain, could be distilled down to a manageable method (for lack of a better way to say it), that everyone can use. Not simply a clip file, but a method.
Of course, if this is still moving along and there is more ideas being worked out then this may not be the right time to ask that.
As for me, I simply want to make specific images. But if you guys inadvertently transfer your powers to me through this thread then thats fine too! Don't hold out hope though that you are making me smarter. Before this thread and even during parts of it I thought I understood a 5 sided rectangle, Now I think I may be brain damaged :-\
That link with the Vorinoise... how hard is it to code and just add the formula to Terragen? Is that not all that is needed here, just a new noise flavour.
Quote from: ChrisC on October 23, 2014, 02:32:28 PM
That link with the Vorinoise... how hard is it to code and just add the formula to Terragen? Is that not all that is needed here, just a new noise flavour.
I'm curious about that too, but didn't want to sound impatient so I waited for someone else to ask first :)
Certainly. :)
I don't think anyone can say TG users are impatient. Sometimes brilliant, sometimes crazy, sometimes passionate. Even sometimes paranoid, maybe. But never impatient ;) Patients feels like the one thing we all share.
Quote from: ChrisC on October 23, 2014, 02:32:28 PM
That link with the Vorinoise... how hard is it to code and just add the formula to Terragen? Is that not all that is needed here, just a new noise flavour.
We'll add Iñigo's Smooth Voronoi to Terragen at some point. But I don't think that's the real breakthrough we need here. It would just make the edges smoother and rounder than what we can already produce with Voronoi.
But a smoothly-interpolated version of the voronoi
cell scalar, which is a separate thing, would open up some new possibilities.
Matt
Quote from: TheBadger on October 17, 2014, 10:47:19 PM
@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.
I am working on it. The Picture below shows a Picture of the x-z plane and annotated x-axis (the inner nodes of a multipy node)
Thank you Mogn. 8)
Not Integrated with the cube yet.
Facinating stuff. I'm learning a lot from your contributions as well as a headaches from trying to understand it!!! :o
Thanks a lot Mogn! Is there any way to make the sides still softer? Square but soft edged. A mix of 2 sizes can do wonders!
Quote from: Dune on November 01, 2014, 12:54:59 PM
Thanks a lot Mogn! Is there any way to make the sides still softer? Square but soft edged. A mix of 2 sizes can do wonders!
That sounds good. Can you do it by your way of working, Mogn?
On pourrai faire une ville avec ça. :)
Every thing is possible in TG. This is a Square mask mulitplied by a Manhattan mask.
Thanks Mogn, more toys to play with.
To place the textures it will be hot. ::)
Nice work Mogn.
To prove there's more than one way to skin a cat I had a go.
Nice noises gentlemen. 8)
Ah, now were's getting somewhere. Looks good, Jon. Did you 'just' displace or use as vdisp?
Quote from: Dune on November 03, 2014, 11:36:15 AM
Ah, now were's getting somewhere. Looks good, Jon. Did you 'just' displace or use as vdisp?
I had a day off, so had a look at what you can do with displacement to vector from the default scene. The strata was formed from the y information, that had the cube pattern (x,z) added on the side slope part of y, mixed with another scale, then plumbed back into a vector to displacement. Didn't need a compute, which is cool.
But should work fine after a compute terrain via a surface layer lateral displacement.
Sugar cubes! Awesome. :D
- Oshyan
I just have to dive into this again...
Quote from: Oshyan on November 03, 2014, 02:09:08 PM
Sugar cubes! Awesome. :D
- Oshyan
The Sugarcubes (Bjork) are from Iceland right? :)
Haha, indeed Jon!
- Oshyan
Cool.
;D
Now that is very cool man! ;)
Et, les ponts ? lol
Playing with hetzen's file I remembered something I did with my file,
but totally forgot about.Since it has a certain effect here also it might
be interesting for some of you.
First pic shows jon's Cubed noise as it is applied to the default scene
and a simpleshapeshader block.Only the size was adjusted to fit the
scene.
[attach=1]
The second pic shows the same,but this time with a transform shader
set to use world space added at the end (after the last blue node).
[attach=3]
Nice and simple,hope you like it,too.
Edit: sorry for the little mess up,something went wrong while posting
Interesting, good for cities...
In the meantime I found that using the blocks in a vdisp setup doesn't work as expected (well, I expected it, so maybe I should say 'as wished for'). Only at one side it works, but on the other side the cubes displace inwards, which is quite logical. So you either have to vdisp per terrain angle, or simply use (lateral) displacement after a tight compute terrain or compute normal. Really nice rock effects are possible though.....
Yeah,that's a problem with vdisp.
Would be nice if we could choose a center to displace from
in both - and + directions on the axes or radial,but that would
lead to other problems -for the programmer at least - I guess.
It's easier to use lateral displacement, though using angles isn't impossible.
Some tests, not done yet....
Rounding a rectangle:
This is done so:
That is really flexible Mogn. I like the alternative shapes you can get with different values of n.
Quote from: Dune on November 07, 2014, 03:23:50 AM
It's easier to use lateral displacement, though using angles isn't impossible.
Some tests, not done yet....
The grass on the top side of the rock you've populated, helps bind that rock pattern making it more natural than at first thought it should be. Really nice work.
Ulco,i like the look of the rock formation.
Looks really good Mogn, just have not had a try with it yet. Thanks in advance!
QuoteThat is really flexible Mogn. I like the alternative shapes you can get with different values of n.
Which node represents n (what is n)? and which node effects the uniformity of the noise?
@ulco,
How are you using the strata node to get "sections" of the noise in the wall, but not getting stepping? If you are using the strata node? OR are you changing the dimensions of the rectangle noice so that the so that it is fat enough to have a "top". Hope that makes sense to you.
^^ or to put it another way, why is the noise flat in ulco's example, and why is it rounded to an edge in J's example?
The n is the constant node with the value of 2.5
Lower value creates rounder corners. 2.5 is the preferred value by Piet Hein.
Preferred by him why? Most perfect math? like the Golden Ratio or something?
With these cubes, we could make a world of minecraft. ^^
Quote from: TheBadger on November 08, 2014, 03:07:25 AM
Preferred by him why? Most perfect math? like the Golden Ratio or something?
Piet Hein was Poet, designer, inventor e.t.c
http://www.google.dk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=7&ved=0CFMQFjAG&url=http%3A%2F%2Fias.au.dk%2Ffileadmin%2Finternationalstaff.au.dk%2FUIC%2FPresentations%2FPiet_Hein_engelsk_redigeret.pdf&ei=CSJeVIGwDcS4OMzNgPgI&usg=AFQjCNH9muIsKpN4gMumoOgeHtFSz0fjiA
And a bit of progress on my side,too.
Still Jon's noise.
[attach=1]
yeah, pretty. :D
Quote from: j meyer on November 08, 2014, 10:28:00 AM
And a bit of progress on my side,too.
Still Jon's noise.
[attach=1]
This is almost exactly the types of rock forms one sees in various parts of Arizona and Nevada. I Googled questions as to what type of geological rock formations these are but could not find the answer.
Thank you Mogn. I will read the bio!
@Bob,
I was trying too! Could not find the geology term. I am absolutely sure that there is a word for everything we want to define. We need a geologist here!
@J
Very nice demonstration! But are the corners "fixed" by the new noise? Or did you make the raised box a cylinder this time?? It appears to be working in every direction?
Yes Michael,the box was a cylinder this time.
SSS set to be circular to be precise.
Have to inspect it some more myself,was the last quick
test before I went to bed yesterday,but,indeed,it should
work in every direction.
Quote from: TheBadger on November 08, 2014, 12:19:22 PM
Thank you Mogn. I will read the bio!
@Bob,
I was trying too! Could not find the geology term. I am absolutely sure that there is a word for everything we want to define. We need a geologist here!
You won't find these formations everywhere. It must have something to do with the weather (rain/snow, freezing/thawing; and, the composition of minerals of the rock). Some of these are younger; i.e., a formation appears a bit more solid with multi-directional cracks that have smooth, rounded edges. The older ones seem to have rounded boulders that have fallen away from the main formation. Yes, a geologist amongst us would be very helpful.
@J
Very nice demonstration! But are the corners "fixed" by the new noise? Or did you make the raised box a cylinder this time?? It appears to be working in every direction?
Quote from: choronr on November 08, 2014, 11:26:58 AM
Quote from: j meyer on November 08, 2014, 10:28:00 AM
And a bit of progress on my side,too.
Still Jon's noise.
[attach=1]
This is almost exactly the types of rock forms one sees in various parts of Arizona and Nevada. I Googled questions as to what type of geological rock formations these are but could not find the answer.
Hoodoos and hoodoo rocks, referred to locally as "goblins", which are formations of mushroom-shaped rock pinnacles, some as high as several meters. The distinct shape of these rocks comes from an erosion-resistant layer of rock atop softer sandstone.
QuoteFor you math-heads, there are several handy new Function Nodes in 3.2 as well. You'll be able to experiment with Max Scalar, Min Scalar, Soft Maximum Scalar, Soft Minimum Scalar, adding several important capabilities to your advanced shader networks.
From the update notes.
Does this help here? Sounds like it does, but Im not a "math head". It sounds like it gives more control. Has anyone had a chance to explore this in the context of the perfect rectangular noise?
@ matt
You sounded like you were on to something a few pages back. Any news?
@Badger, I plan to experiment more in this area for TG4.
Matt
TG4!! This sounds like celestial music... ;)
We all need a dream ;)
Vous pouvez essayer ma technique ?
You can try my technique ? :D
http://www.planetside.co.uk/forums/index.php/topic,17206.0.html