localize /mask out cloud

Started by Dune, June 12, 2011, 02:59:05 AM

Previous topic - Next topic

Tangled-Universe

#15
Quote from: jo on June 16, 2011, 07:11:20 AM
BTW, I will now insert my customary recommendation of "Texturing and Modelling: A Procedural Approach" :-). I'm sure you would get something out of it.

Yes I have seen this recommendation pass by a few times before and I have the PDF for at least a year or two now.
It's either me being dump (not impossible lol) or it's meant for people familiar with software- and/or 3D-background or above average feeling for math, because I can't seem to get something useful out of it so far?
Also I can't always manage to link it to TG2 as there's little information regarding TG2's internals (for understandable reasons).

Here's why I think that: I know virtually every button and slider of TG2 and what it does and why/how (mostly), but when the node-colour changes from red to blue it just STOPS. There's just something with these blue nodes which makes it completely beyond my mental capabilities.

I often have discussions with Jon (Hetzen) about this when he tries to explain again (for the tenth time or so) how some of his blue node networks work and what the logic is behind it.
It's just completely illogical to me. Why do I sometimes need to subtract a value from the other to "compare" it or as a base and wht do I need the other time a division or multiplication? All that kind of stuff which just doesn't get to me.

I think I'm not entirely alone in this?

Jo, perhaps it is a nice idea to make a handful of clipfiles/little projects which show useful ways of blue-node networks? For instance something like in this topic.

Dune

#16
Thanks, Jo. I'll have another go at a soft cone.
Ah, TU, you posted same time as I did. Where is this pdf? I'm not a mathgician either, but I'd like to have a try.

Dune

Hey guys, help me out please. I've got this, but I can't find a way to really make the cone soft at the sides (preferably starting from an adjustable height).

DutchDimension

Quote from: jo on June 16, 2011, 07:11:20 AM
BTW, I will now insert my customary recommendation of "Texturing and Modelling: A Procedural Approach" :-). I'm sure you would get something out of it.

Ah.. I know this book. It's the staple of many of my more math oriented colleagues. Now that you recommended it for Terragen I'll have to check it out for certain.

Matt

Quote from: Dune on June 16, 2011, 11:22:33 AM
Hey guys, help me out please. I've got this, but I can't find a way to really make the cone soft at the sides (preferably starting from an adjustable height).

softconetest.tgd

You're on the right track. A couple of things:

Anyone using v2.3 who loads this file will not see the same thing as you. v2.4.5.0 (alpha) was the first build that allowed Smooth Step Scalar's step start to have a larger value than step end. To make it compatible with 2.3 you should should swap your step start and step end connections, and then use a Complement Scalar to invert the output. Apart from that, you're on the right track with the Smooth Step Scalar.

The main thing you need to do to get a softer edge (and more consistent softness) is to plug your functions into the final density modulator of the cloud layer, not the main density shader input. Edge sharpness won't have an effect then, so you need to increase cloud density to compensate. I've set edge sharpness to 1 and cloud density to 0.6. That gets you part way.

The cloud is quite dense, and that's fighting with your attempts to soften the edge. But you want the density so that it has strong self shadowing. The way to get a softer edge is to reduce the density at the outer edge without reducing the density on the inside. You can do this with a power function, e.g. Power Scalar. Your Smooth Step Scalar gives you a value between 0 and 1, so if you raise that to a power you change the curve between 0 and 1 while keeping 0 and 1 the same. A power greater than 1 reduces all the values (a power less than 1 would increase all the values). Try the following: Power Scalar at the very end (after the Complement Scalar), and give input 2 a Constant Scalar with a value of something like 4. It shrinks the column a bit, but you can easily fix that. There is still some density right up to the original edge, it's just very low density. Now increasing your column base width to 300 gives a really soft edge (originally was 150). Multiplying that with some other fractal might look quite good.

I've attached my modified version.

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

Matt

Another thing you can try is putting the Power Scalar before the Complement Scalar, as it gives a different curve that changes more rapidly near 1 and less rapidly near 0. In this setup you'd use a power value smaller than 1 instead of larger.
Just because milk is white doesn't mean that clouds are made of milk.

Dune

Thanks a lot, Matt. This is perfect! I had an interesting time trying out all sorts of blue node combinations (without very much in-depth knowledge), and found some weird clouds, but this is what I need. Now for the perfect volcano...

mogn

Quote from: jo on June 16, 2011, 05:20:34 AM
Or just keep the conditional if it makes more sense to you :-).

It's not bad to have conditionals to choose between two things, mogn just doesn't like them. You can often avoid using conditionals if you feel you must but it does sometimes make logic harder to follow.

One of the problems with conditional is that you have to go inside the node to see what it does.
The conditional has 4 inputs to consider, the hard step has only two.

Tangled-Universe

That might be true, but you can use naming conventions to "solve" that.
Give the node itself the name of the operator you've chosen like "greater than" and set the node names of the output values to the value it has.

jo

Hi Martin,

Quote from: Tangled-Universe on June 16, 2011, 08:46:06 AM
Yes I have seen this recommendation pass by a few times before and I have the PDF for at least a year or two now.
It's either me being dump (not impossible lol) or it's meant for people familiar with software- and/or 3D-background or above average feeling for math, because I can't seem to get something useful out of it so far?
...snip...

Fair enough if you can't figure the function nodes out at all then you might not get so much out of the book. I saw Dune starting to find his way with them and asking questions of the sort where he could find it useful so I recommended it. We can't really teach people how to use these things but there are resources out there to help people learn. It's the way I learned.

I will admit that there is some stuff which is clearer in the book if you are familiar with a programming language, but it doesn't take a lot. A little Javascript or PHP would be enough I think. It also helps to know a little bit of maths for sure, but that's kind of necessary to use function nodes anyway.

However most of what I got out of the book came from the text and diagrams rather than the code I would say.

You do need to be able to make the jump between how things are represented in code and how you would do in in the node network but a lot of the time that's pretty straightforward.

At some point it would be good to have some examples so people can get started. If we were to go much beyond that we'd probably just end up writing a book like "Texturing & Modeling" anyway :-).

I should also add that it's a definite goal that people shouldn't need to use function nodes to make nice scenes. The function nodes are there for people who want to go a bit further beyond what TG2 provides normally and do things we might not have thought of, for example. The function nodes are basically a visual programming language that allows you to extend what TG2 can do. Not everyone will be able to get their head around it and that's fine.

Regards,

Jo

Dune

Perhaps some community finds in blue nodes can eventually be put into a complete shader (by you of course  ;)) with sliders and such.

DutchDimension

I think one of the things that can help demystify function nodes is to know what type of data they expect and what type they output.
Is it Vector data, scalar, colour... or is the node polymorphic? It's implied by the name of some of the nodes, but certainly not by all. Consequently, a Terragen user with but a rudimentary understanding of maths will easily be lost at this early stage, thus immediately stumbling before he or she even got to connect a few nodes together.
Some of you maybe familiar with SoftImage and it's ICE system. It's very similar to TG's node graph in that it allows very extensive and low level access to many parts of the application. The cool thing about the ICE tree (think Node Graph viewer) is that each node's in/output ports are colour coded. Each colour represents an individual type of data, allowing you to very quickly see what nodes are compatible with each other and thus can be connected immediately or which ones might need a conversion node here or there. ICE is even clever enough that it can insert the correct conversion nodes on the user's behalf, so you don't have to. :)

Personally I'd love to get some more clarity on the data types of some (if not all) of the more "obscure" function nodes. Be that added to the documentation or in similar fashion as SI ICE does it.


bobbystahr

Quote from: Dune on June 20, 2011, 03:19:40 AM
Perhaps some community finds in blue nodes can eventually be put into a complete shader (by you of course  ;)) with sliders and such.

Hear hear...well said.. ...
something borrowed,
something Blue.
Ring out the Old.
Bring in the New
Bobby Stahr, Paracosmologist

Tangled-Universe

Quote from: jo on June 20, 2011, 03:10:33 AM
Hi Martin,

Quote from: Tangled-Universe on June 16, 2011, 08:46:06 AM
Yes I have seen this recommendation pass by a few times before and I have the PDF for at least a year or two now.
It's either me being dump (not impossible lol) or it's meant for people familiar with software- and/or 3D-background or above average feeling for math, because I can't seem to get something useful out of it so far?
...snip...

Fair enough if you can't figure the function nodes out at all then you might not get so much out of the book. I saw Dune starting to find his way with them and asking questions of the sort where he could find it useful so I recommended it. We can't really teach people how to use these things but there are resources out there to help people learn. It's the way I learned.

I will admit that there is some stuff which is clearer in the book if you are familiar with a programming language, but it doesn't take a lot. A little Javascript or PHP would be enough I think. It also helps to know a little bit of maths for sure, but that's kind of necessary to use function nodes anyway.

However most of what I got out of the book came from the text and diagrams rather than the code I would say.

You do need to be able to make the jump between how things are represented in code and how you would do in in the node network but a lot of the time that's pretty straightforward.

At some point it would be good to have some examples so people can get started. If we were to go much beyond that we'd probably just end up writing a book like "Texturing & Modeling" anyway :-).

I should also add that it's a definite goal that people shouldn't need to use function nodes to make nice scenes. The function nodes are there for people who want to go a bit further beyond what TG2 provides normally and do things we might not have thought of, for example. The function nodes are basically a visual programming language that allows you to extend what TG2 can do. Not everyone will be able to get their head around it and that's fine.

Regards,

Jo

Thanks Jo.

I think that TG2 certainly meets the definite goal of getting nice images without using function networks and that's really well done by you guys :)

It's no problem for me to confess my math simply sucks, as well as the way my brain copes with logic at sometimes.
Maybe some day the pieces of the puzzle will suddenly fit for me. I've learned TG2 with a lot of patience, maybe blue nodes take even more patience.

Cheers,
Martin

Tangled-Universe

Btw, I think DutchDimension made a very valid point about some coding for type of data-stream, especially for the nodes which do not provide information via its name.
Could be a case for documentation as well maybe, if you prefer not to clutter the UI too much with graphical fancyness.