Before I start experimenting, maybe someone knows the answer....
1: if you mask (painted shader) a certain area where one cloud will be, would it decrease render time? My theoretical method would be to add the cloud node as a child to a blended surface shader (no atmosphere needed), which goes into the planet.
And question 2: if you localize a cloud, will the coordinates take the location on the main planet, even though the cloud (where the localizing is done) is based on a second planet?
1) There is a difference between how TG2 deals with the fractal when using "regular" masking or a localized cloud:
If you use a distance shader or painted shader or whatever else then TG2 still calculates the entire texture-space for those fractals and blendshaders.
Rendering itself will be faster since you reduced the amount of volumetric rendering by masking.
However, when using a localized cloud TG2 limits the calculation of the texture space to the localized area only.
Rendering itself will be faster too, but also the calculation of texture space.
2) Yes that's possible. I've attached an example .tgd. Somehow you need to apply the "move cloud with texture" option, but I'm not sure why.
Cheers,
Martin
Thanks, Martin!
You're welcome :) Building metaclouds? ;)
Sure am. What I now need is a (blue) node to bend and widen the cloud according to height exponentially. Exactly, like a windblown volcano smoke column. I was hoping to do that with a distribution shader as a vertical gray scale, square its scalar and use that to displace X-wise, but it doesn't seem to work. Tried it with a camera and distance shader as well... nope. Perhaps a get position, Y to scalar etc... Bending it with a 3D perlin is possible but needs a lot of seeding to get the right curve. I'll find it, but if anyone can tell me, I'd be much obliged.
What I have is this, but it's not good enough. Bending works with a double squared distribution shader entered into a displacement, redirect and warp.
BUT... there must be a way to transform the width (X and/or Z) of a simple shape gradually, based on a gradual height scale. If any one knows, please tell me!
Don't bother, found it.
Quote from: Dune on June 13, 2011, 12:21:28 PM
Don't bother, found it.
Do share now that you've got my/our interest, heh heh heh
Here you go.... speaks for itself. The 'position in texture' is a 'get position in texture', another constant vector can be added to shift the start location.
Thanks for sharing this Dune.
I created something similar, though in a very different way. I think this is more versatile as the data is more flexible because it's made of functions.
To avoid the conditional, replace it with a hardstep and delete constants 0 and 1.
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.
Can you also make it soft edged? Like the simple shape.
Hi Dune,
One good reason not to use conditionals is that they are either one value or another value, which gives hard edges and can show as aliasing/jaggies.
There are various ways to make soft edges with functions. Smoothstep is a classic way to soften an edge. Other ways can be gain, bias, a smooth linear interpolation or anything else that you think could work. The idea is to use one of those methods to smooth the edge over some distance.
Regards,
Jo
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.
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.
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.
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).
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.
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
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.
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...
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.
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.
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
Perhaps some community finds in blue nodes can eventually be put into a complete shader (by you of course ;)) with sliders and such.
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.
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.. ...
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
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.
I have been learning the nodes (slowly) by picking one and trying out things. I now find myself using more and more of them.
Hi,
Quote from: DutchDimension on June 20, 2011, 10:35:02 AM
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.
...snip...
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.
TG2 implicitly converts values from what it gets into what it needs, so basically the data passed is polymorphic or weakly typed. We did actually have documentation up which described how all the conversions worked but it seems to have got lost just at the moment.
If you look at the function nodes (open the Node Palette and choose the Function category) it looks like all of them do a pretty good job of indicating what sort of data they work with. Perhaps you're talking about other types of nodes though?
I think it was a deliberate decision to avoid having type information shown for network connections. You can hook anything to anything and appropriate conversions will take place. Occasionally I've come across situations where I think it would be helpful to indicate the specific data type a connection prefers.
Regards,
Jo
Node Input Type Conversion docs are in the wiki here:
http://www.planetside.co.uk/wiki/index.php/Node_Input_Type_Conversion
This and others need to be added to the documentation index which, following the recent completion (http://forums.planetside.co.uk/index.php?topic=12483.0) of the Node Reference index and conversion, will be taken care of soon.
- Oshyan