Final position v. Position in terrain/texture

[sboerner]

OK, time for a basic question.

What's the difference between "Final position" and "Position in terrain/texture," and how can I know which is best to use? And what effect does "Use Y" have?

So far I've been faking it by trying all of the options for various situations, then using what seems to work best. But it would be nice to know what I'm doing.


I've searched the forums for references to "Altitude key" but the postings I found concern very specific situations. In the wiki the definitions are all "TBC". It would be great to have a complete explanation in one place, which is why I'm asking.

Thanks in advance . . .

[Tangled-Universe]

I don't have time to go into a lot of depth detail, but this reply from Matt offers most of the explanations:
https://planetside.co.uk/forums/index.php?msg=71067

See if this helps and otherwise I can comment further tomorrow or the day after.

[WAS]

I believe Final Position is a position in the 3D space of Terragen relative to the planet

Where Position in Texture/Terrain is as it says, and the 3D texture or geometry space present.

For example, take a Cloud Fractal for clouds, and apply a surface layer. The surface layers altitudes are relative to the cloud fractals noise space, and doesn't relate to the planets atmosphere altitudes. If you use Final Position, the altitudes align up with the cloud altitudes relative to the planet.

Use Y means it is using Y in XYZ instead of curving along the planet axis. So you could do things like polar ice caps to a planet for example with Use Y and surface layers.

[sboerner]

Thanks, TU and Waz, your comments (and the link to Matt's post) really help.

For starters, it sounds like "Use Y" should be unticked unless you are working with a very large (i.e. planetary) scale, as you usually want constraints to follow the curvature of the planet. Yes? No?

And, just a simple example to help me get my head around this: Let's say you have a surface layer with a displacement offset of 100 meters. You connect the output of this layer to the main input of a second surface layer. Now, does this mean that a terrain/texture value of 0 for the second layer equals a final value of 100? And does this same relationship hold if the second layer is a child of the first?

I'm running into problems in deciding which setting to use for altitude constraints and fuzzy zones for overlapping layers. The scene I'm working on now uses several, and my initial thought was that I should set all of them to "Final position," so they use the same baseline and can be more easily coordinated. But the results haven't always been predictable. So now I'm wondering if I should use "texture/terrain" as the default, or use a mixture of both. But I'm not sure what to base the decisions on.

[Dune]

I always think of final altitude/slope as the one computed in the layer used, with all tiny displacements calculated. Position in terrain uses the last calculated altitudes/slopes/normal from compute terrain. So if you have only a high displacement after a compute terrain, you won't get much done in altitude restriction without using final.
And Y is indeed usually ticked off, unless for (what WAS says) global altitude restrictions. But for altitudes in objects I usually set it, as it's then somehow needed. Don't ask me why.

[sboerner]

Position in terrain uses the last calculated altitudes/slopes/normal from compute terrain.

Thanks, Ulco. This seems to be a key point and makes sense.


Sounds like I may want to to set up a simple scene and test various settings and compute terrain node placements against some standard altitude restrictions.

[WAS]

I always think of final altitude/slope as the one computed in the layer used, with all tiny displacements calculated

If it's computed. Doesn't need to be. Which is why I say it's relative to the planet. You could be up against the background sphere's radius and the altitudes will still correspond to the planet. Which is why it also takes into account every displacement, etc, because it's looking at the planets final setup (unless that's what you mean by computed).

[Matt]

"Final position" uses the most recent known displacement of the surface, but has some limitations when used to mask displacements. When used in the context of displacement, "Final position" depends on where the node is connected with respect to other displacement shaders. It only knows about upstream shaders. However, when used to colour the surface or used as a mask from any other kind of non-displacement shader, it gives you the final displacement of the surface including downstream shaders. This is because in Terragen the displacement pipeline is calculated first for all shaders, then the non-displacement shading pipeline is calculated on the final displacement.

This can cause misaligment between masks applied to displacements and non-displacements. To try to solve this, there is the "Position in terrain/texture" option.

"Position in terrain/texture" uses the texture coordinates which were generated for the surface. On terrains these coordinates are initially set to the position on the flat planet from which the terrain was displaced, but may be updated by Compute Terrain or Tex Coords From XYZ nodes to provide fully 3D texture coordinates. The documentation for the "Get Position in Texture" node elaborates on this: https://planetside.co.uk/wiki/index.php/Get_Position_in_Texture

There's a longer discussion here:

Discussion in forum: https://planetside.co.uk/forums/index.php?msg=12539
Wiki copy of forum post: https://planetside.co.uk/wiki/index.php/Compute_Terrain

[WAS]

"Final position" uses the most recent known displacement of the surface, but has some limitations when used to mask displacements. When used in the context of displacement, "Final position" depends on where the node is connected with respect to other displacement shaders. It only knows about upstream shaders. However, when used to colour the surface or used as a mask from any other kind of non-displacement shader, it gives you the final displacement of the surface including downstream shaders. This is because in Terragen the displacement pipeline is calculated first for all shaders, then the non-displacement shading pipeline is calculated on the final displacement.

This can cause misaligment between masks applied to displacements and non-displacements. To try to solve this, there is the "Position in terrain/texture" option.

"Position in terrain/texture" uses the texture coordinates which were generated for the surface. On terrains these coordinates are initially set to the position on the flat planet from which the terrain was displaced, but may be updated by Compute Terrain or Tex Coords From XYZ nodes to provide fully 3D texture coordinates. The documentation for the "Get Position in Texture" node elaborates on this: https://planetside.co.uk/wiki/index.php/Get_Position_in_Texture

There's a longer discussion here:

Discussion in forum: https://planetside.co.uk/forums/index.php?msg=12539
Wiki copy of forum post: https://planetside.co.uk/wiki/index.php/Compute_Terrain

What about 3D Space? Such as cloud fractals? There is no displacement, just the texture maps, but a great degree of variation between the two?

[Matt]

Oops, sorry I edited your post. I meant to edit my own but I edited your quote instead.

[Matt]

What about 3D Space? Such as cloud fractals? There is no displacement, just the texture maps, but a great degree of variation between the two?

In a cloud, "Position in terrain/texture" depends on whether the cloud layer has "Move textures with cloud" enabled. If it does, the texture space is relative to the localisation centre, otherwise it's simply world space and gives the same result as "Final position". Cloud Layer V3 and Easy Cloud have the localisation centre at the base of the cloud, and Cloud Layer V2 puts it midway between the top and bottom.

[WAS]

What about 3D Space? Such as cloud fractals? There is no displacement, just the texture maps, but a great degree of variation between the two?

In a cloud, "Position in terrain/texture" depends on whether the cloud layer has "Move textures with cloud" enabled. If it does, the texture space is relative to the localisation centre, otherwise it's simply world space and gives the same result as "Final position". Cloud Layer V3 and Easy Cloud have the localisation centre at the base of the cloud, and Cloud Layer V2 puts it midway between the top and bottom.

That doesn't seem to be the case (with v2). It doesn't have Move textures with clouds enabled by default, and when, for example, setting up the Auroras and Coronas setup for a help topic, Final Position was needed, otherwise the altitudes were out of whack and required extremes that made no sense.

Similarly when I did a solar system model, and had the camera against the background sphere, Final Position was needed to be accurate to scale. V2 again.

[Matt]

That doesn't seem to be the case (with v2). It doesn't have Move textures with clouds enabled by default, and when, for example, setting up the Auroras and Coronas setup for a help topic, Final Position was needed, otherwise the altitudes were out of whack and required extremes that made no sense.

Similarly when I did a solar system model, and had the camera against the background sphere, Final Position was needed to be accurate to scale. V2 again.

Ah yes, Cloud Layer V2 does work a bit differently because it's a much earlier design. I'd forgotten about that. The various state variables are set up in a way that can lead to confusing results with the Distribution Shader and other altitude-based functions. I looked at it when improving things for Cloud Layer V3 and Easy Cloud and came to the conclusion that it needed to stay that way in V2 and fixed it in V3.

[WAS]

I think even for v3 this applies, I remember with the multi-layer clouds, which are v3 I had trouble with this cause I needed to use final position for accurate altitudes but than that means I couldn't redirect for altitude variations.

https://planetside.co.uk/forums/index.php/topic,24581.msg250167.html#msg250167
And
https://planetside.co.uk/forums/index.php/topic,25903.msg257079.html#msg257079

[Matt]

I downloaded your file "Multi-Layered Sample by WASasquatch.tgd" and was able to convert all 4 surface layers to use altitude constraints that are relative to the cloud height of 2500. I changed them to use "Position in terrain/texture" and subtracted 2500 from all of your altitude constraints and it worked.