what is a fractal terrain?

Started by calyxa, January 03, 2007, 06:24:51 PM

Previous topic - Next topic

calyxa

what is a fractal terrain, or more precisely, what type of data does a fractal terrain node output?

is it a scalar?  a vector?  a "length"?

a "fractal terrain 01" node seems to be a "power fractal shader v3" set up with both the 'apply max color' and 'apply min color' boxes unchecked, and with the scale set large, etc.

what I want to do is run some simple mathematical operations on the output of a "power fractal shader v3" node before it goes into the "compute terrain" node -- for example, to square the output, or at least multiply it by itself (same difference, I know, but one would be done with some sort of 'power' node while the other would be done with some sort of 'multiply' node).

I've read with great interest - and worked through a few times - the user-contributed tutorial on building terrains from functions, but what it does not address is how to modify a "power fractal shader v3" by running it through a function and then turning it back into whatever a "terrain" is.

a tangental question is - what is that input attachment anyway?  does it add?  average?  some other blending method?

efflux

These are the sorts of things I want to know as well.

If I had some more time I would just keep experimenting but it will have to wait.

calyxa

thanks for the "support" efflux, however, I think the timing of your reply knocked my question "out of order" when Oshyan and Matt were going through the forum in their most recent round of answers.

either that, or they perhaps thought it was some sort of rhetorical question?

when I posted it, I believe I'd already ruled out scalar, vector and "length" by trying to use the various conversion nodes to convert my data before operating on it, and then running it through a displacement node as is shown in the 'building terrains from functions' tutorial.  either it's truly not scalar or vector or "length" - or I just don't know what I'm doing (perhaps too biased by what I think I know from MojoWorld..?)

my next tests will try forcing the power fractal shader to output only color (which is turned off when the node is created as 'terrain'), but that seems backwards / wrong - why should I have to force the 'terrain' node to be something its not (a color) in order to operate on the data?

Oshyan?  Matt?  do you have any light to shed on what should be a couple of relatively simple questions here?  i.e., what data type is output by the default 'fractal terrain 01' node? (scalar?  vector?  something else?) and what is the blending operation of chaning two fractal terrain nodes together via one node's 'input' attach point? (add?  average?  something else?)

Matt

#3
Hi Calyxa,

It's a very good question, that's why it's taken a while to come up with an answer ;)

The important thing to realise here is that many of the shaders in Terragen are designed to modify the input surface. They are not simply functions that generate data. Any shaders that perform displacement, such as the Power Fractal, will modify the existing surface. They do not "generate" displacement data as such, but they modify the existing surface. In most cases, displacement is an additive process, but not all (the heightfield shader with its default settings will mix in the new altitude, for example). Displacement shaders usually apply to whichever surface normal was most recently computed, but some displacement shaders choose which direction they want to displace in so that they can do more interesting things.

Any colour data from shaders, on the other hand, is usable as a function much more generally throughout TG. Usually shaders that generate colour data also modify any colour data from input shaders (ie. the Surface Layer allows some of the input colour to show through while replacing other parts with its own colour), but if there is no input you can think of them as simple colour generators.

The decision to treat shaders as surface modifiers rather than simple functions was made very early on in TG2's design. This was done so that shaders can be thought of as layers, which is a familiar concept from 2D paint programs (and also the surface mapping system in the old TG v0.9). Allowing a shader to do many things at once (not just generate a single colour value) also has many benefits, such as applying new layers with different characteristics for specular, luminosity etc. For some people this integration of colour channels at the shader level causes problems, but there are many advantages if you can treat shaders as layers of material applied to underlying materials.

As you know, there are situations where you want to be able to manipulate the displacement data as a function. That's why Function nodes were introduced into TG2 more recently in its design. Function nodes are coloured in dark blue, in contrast to shaders which are red. If you want to perform the kinds of functional manipulation of displacements that you are talking about, in the current version you will probably need to use Functions.

So that it is easier to use any existing colour shaders within the Functions network, and also allow Functions to do anything that was previously expected of colour shaders, Functions and colour shaders are interchangeable (Functions are actually a special type of shader that just generate colour data).

There is a glaring omission from the Function nodes available in TG2 currently, and that is a "Displacement to Function" node of some kind. This would allow you to take some displaced surface (such as one generated by the Power Fractal), manipulate the displacement value by a network of functions, and then replace the original surface with the new functional surface.

There may be some workarounds though. There is a "Get Altitude" Function. It takes no inputs, however, for consistency with all of the other "Get" Functions. It looks at the current render state or shading state (ie. the displaced surface) and retrieves the altitude. You can use a Merge Shader and Displacement Shader as follows:

"Mix to A" = 1
Connect the procedural terrain into the "Input node" plug
Connect the Displacement Shader into the "Shader A" plug
Create a function network and plug it into the Displacement Shader

The Function network can now start with a "Get Altitude" Function and you can manipulate it however you want. It just needs to end with a Displacement Shader, plugged into the second input of the Merge Shader.

It's not ideal, but it is a result of the design decisions I took very early on in development. We might be able to make it easier in future by packaging up the whole Merge Shader / Displacement Shader mallarky into an easy to use "Modify Displacement" setup or something like that.

Before the Function nodes were implemented, I had planned to make a bunch of shaders that would allow common manipulations of terrain data, but since the Function network allows all of that and more it may be better to concentrate our efforts there and make it easier to integrate with the displacement shaders.

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

calyxa

thanks for trying to answer the question.

it hasn't helped yet, though.  the way I read it, a "fractal terrain 01" outputs a data type "displacement" and as of now, there's no way to convert that to anything which can be operated on by the other functions, for example, 'conditional scalar'

I think a "convert displacement to scalar" node is what I'm looking for.

I'm having no luck at all trying to follow the suggestion involving the 'Get Altitude' (which I'd been trying to use before I even asked the question here), nor do I understand how the Merge Shader fits into the whole thing, since the "end with a Displacment Shader" bit sounds almost exactly like the aforementioned user-contributed tutorial on "building terrains from functions" -- all of which assumes that one start with a noise (which outputs a scalar), and not with a "fractal terrain".

somehow, some way, it seems quite logical that a "Get Altitude" would extract some sort of scalar value from the terrain-in-progress, but I haven't figured out how.

if you have a .tgd file illustrating your example, that would probably help.

thanks again.

rcallicotte

Thanks, Matt.  This has been very helpful.
So this is Disney World.  Can we live here?