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. :P
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 . . .
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.
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.
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.
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.
QuotePosition 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.
Quote from: Dune on January 16, 2020, 01:56:41 AMI 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).
"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
Quote from: Matt on January 16, 2020, 05:03:34 PM"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?
Oops, sorry I edited your post. I meant to edit my own but I edited your quote instead.
Quote from: WAS on January 16, 2020, 05:11:18 PMWhat 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.
Quote from: Matt on January 16, 2020, 05:19:28 PMQuote from: WAS on January 16, 2020, 05:11:18 PMWhat 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.
Quote from: WAS on January 16, 2020, 05:27:15 PMThat 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.
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
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.
Sooo, it's not the same as Final Position, is what I'm saying...
Good to know the exact offset though.
Yes, in a cloud layer Final Position is different from Position in Terrain/Texture if the cloud layer has "move textures with terrain" enabled. This is by design. It doesn't work properly in cloud v2 but it does in cloud v3 and easy cloud. It sounded like you thought it wasn't working this way and gave an example where you thought you needed to use Final Position, but I tested your example with Position in Terrain/Texture and it works the way I described here. So I guess I misunderstood what you were saying.
In a cloud you can use Position in Terrain/Texture but you have to be aware that it's different from Final Position because it's meant to be different. It's meant to be relative to the cloud space, not world space (unless you uncheck "move textures with cloud", and then they are the same). This is useful because you can create layers like you did in your example and then you can move the cloud to any height and your layers will continue to work.
Quote from: Matt on January 16, 2020, 05:19:28 PMIn 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"
Sorry I was just trying to get clarification on that. You indicated they are the same as Final Position without "Move textures with cloud". I can see the difference of localization with v3 though.
Quote from: WAS on January 16, 2020, 09:55:28 PMSorry I was just trying to get clarification on that. You indicated they are the same as Final Position without "Move textures with cloud". I can see the difference of localization with v3 though.
Yeah, they should be the same if "move textures with cloud" is turned off, so I don't know what this difference is. Unless you are warping or transforming. That only works with position in texture. But there wasn't any of that in your file.
Quote from: Matt on January 16, 2020, 10:41:05 PMQuote from: WAS on January 16, 2020, 09:55:28 PMSorry I was just trying to get clarification on that. You indicated they are the same as Final Position without "Move textures with cloud". I can see the difference of localization with v3 though.
Yeah, they should be the same if "move textures with cloud" is turned off, so I don't know what this difference is. Unless you are warping or transforming. That only works with position in texture. But there wasn't any of that in your file.
Nope, especially the Corona and Aurora's share in the bigben post, that's just basic surface layers and fuzzy zones in soft fractals.
Does the octave warp of the fractals themselves change this space maybe?
I don't know what you're referring to, but it sounds like a separate issue.
https://planetside.co.uk/forums/index.php?msg=273163
v2 clouds don't have move textures enabled by default, and final position and position in terrain/texture are different, contrary to your comment.
Unless I'm misunderstanding.
But they are v2 clouds. We already established they work differently. So there is nothing contrary to my statements above which were about v3.
Quote from: Matt on January 16, 2020, 05:19:28 PMIn 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.
Here's the whole quote. My question was regarding both cloud types (cloud space). The only difference you mention is the localization of the centre at the base. And we already established there's a difference now in both v3 and v2... In both circumstances, move with textures or not there are offsets.
That was the first thing I said about clouds, yeah. But that's before you reminded me that v2 wasn't working like that. So we established that v2 was broken, I thought you understood that. Then after that we had a whole conversation about v3. You thought that v3 also had that problem. I told you I loaded your file with v3 clouds and it worked how I claimed it should. But now you are going back to talking about v2 and using v2 examples to try to convince me that there's an issue in v3?
Quote from: Matt on January 17, 2020, 12:20:01 AMThat was the first thing I said about clouds, yeah. But that's before you reminded me that v2 wasn't working like that. So we established that v2 was broken, I thought you understood that. Then after that we had a whole conversation about v3. You thought that v3 also had that problem. I told you I loaded your file with v3 clouds and it worked how I claimed it should. But now you are going back to talking about v2 and using v2 examples to try to convince me that there's an issue in v3?
Well, I think you're putting words in my mouth now. We're done here. I asked if I was misunderstanding.
I'm trying to understand the exact offset between keying and surface layers between clouds types, you know, to work around them with knowledge rather than guessing. You found it was -2500 for v3.
Quote from: WAS on January 17, 2020, 12:59:58 AMQuote from: Matt on January 17, 2020, 12:20:01 AMThat was the first thing I said about clouds, yeah. But that's before you reminded me that v2 wasn't working like that. So we established that v2 was broken, I thought you understood that. Then after that we had a whole conversation about v3. You thought that v3 also had that problem. I told you I loaded your file with v3 clouds and it worked how I claimed it should. But now you are going back to talking about v2 and using v2 examples to try to convince me that there's an issue in v3?
Well, I think you're putting words in my mouth now. We're done here. I asked if I was misunderstanding.
Sorry, I didn't mean to. I thought you knew I was talking about v3 this whole time.
QuoteI'm trying to understand the exact offset between keying and surface layers between clouds types, you know, to work around them with knowledge rather than guessing. You found it was -2500 for v3.
-2500 was the offset for your cloud because your cloud had an altitude of 2500m, but for a different cloud it would be different. This is how to convert from world space to texture space if you were working in world space before, but it depends on your cloud position. If you have a cloud whose base is 2.5km altitude and you want to set a mask that starts at the base, that's simply 0 in the cloud's texture space.
Quote from: Matt on January 17, 2020, 01:38:40 AMQuote from: WAS on January 17, 2020, 12:59:58 AMQuote from: Matt on January 17, 2020, 12:20:01 AMThat was the first thing I said about clouds, yeah. But that's before you reminded me that v2 wasn't working like that. So we established that v2 was broken, I thought you understood that. Then after that we had a whole conversation about v3. You thought that v3 also had that problem. I told you I loaded your file with v3 clouds and it worked how I claimed it should. But now you are going back to talking about v2 and using v2 examples to try to convince me that there's an issue in v3?
Well, I think you're putting words in my mouth now. We're done here. I asked if I was misunderstanding.
Sorry, I didn't mean to. I thought you knew I was talking about v3 this whole time.
Quote from: undefinedI'm trying to understand the exact offset between keying and surface layers between clouds types, you know, to work around them with knowledge rather than guessing. You found it was -2500 for v3.
-2500 was the offset for your cloud because your cloud had an altitude of 2500m, but for a different cloud it would be different. This is how to convert from world space to texture space if you were working in world space before, but it depends on your cloud position. If you have a cloud whose base is 2.5km altitude and you want to set a mask that starts at the base, that's simply 0 in the cloud's texture space.
That's the formula I think was getting stumped on, thanks.