Final position vs. Position in texture/terrain: A visual aid

[sboerner]

After years of struggling to comprehend the precise difference between these two altitude key settings, I decided to draw a picture. So this is for TG newbies and others (like me) who are visual learners. Please let me know if you see any errors here; I'll correct and repost.

[WAS]

I think the only thing that isn't correct (but I am not even sure) is the colour/texture. If you use a Compute Terrain, these two will follow the undulation of the compute terrain, and not displacement. Which is where you can get fuzzier PFs with large patch sizes, and more noisey detailed PFs with smaller patch size (same PF settings).

This is especially crucial when exporting geometry with the Compute Terrain. Where lower patch sizes give you larger resolution (better detail) UVs, and larger sizes gives you more muddled, blurry small UVs expanded to the object.

[sboerner]

I think that's implied -- a shader following the compute terrain will use its smooth texture coordinates provided its altitude key is set to Position in texture/terrain. Shaders set to Final position won't. Correct?

I just realized that I mistyped the name of this thread. It should be "Final position vs. Position in texture/terrain." Is it possible to rename a thread?

[WAS]

You can rename the topic in the full edit, provided it hasn't been too long.

And I think I just misinterpreted it.

[gao_jian11]

thank! Very important summary, this is the problem I have always wanted to find out, and I have never had a precise definition.

In addition, I don't know much about the difference between "altitude and position", and I hope to make an accurate decision.

[sboerner]

You can rename the topic in the full edit, provided it hasn't been too long.

Perfect! That did it. Thanks, Jordan.

thank! Very important summary, this is the problem I have always wanted to find out, and I have never had a precise definition.

You're welcome. I'm hoping that the diagram accurately describes how it works. 

As for the other "get" nodes, have you looked at the wiki?

[Dune]

Great summary. This should be put in the wiki, I guess.

[WAS]

I figured out what stumped me 🤔

There is no texture space in this diagram, which would be what would follow the computed space from a compute terrain, or a tex coordinates over a compute normal.

[sboerner]

Great summary. This should be put in the wiki, I guess.

Thanks, Ulco. You've said you try to avoid compute terrain nodes in your scenes, to save render time. How do you prevent mismatches between displacement and color? Or do you just not worry about it?

There is no texture space in this diagram, which would be what would follow the computed space from a compute terrain, or a tex coordinates over a compute normal.

Jordan, isn't texture space the same thing as "Position in texture/terrain"? So, unless it's updated with a compute terrain, texture space is simply the planet's undisplaced surface?

Edit: Having said this, perhaps there is an error in the diagram. In the panel titled "After first displacement," maybe Final position (color) should = Position in texture/terrain (which also = undisplaced surface). Maybe there is no need for Final position (color) at all, with the understanding that Final position is used only by displacement.
 
I tried to pare down the diagram to the bare essentials, but the choice of altitude key has many implications. Smoothness, effect on transform and warp, etc., etc. Still figuring this all out. In my imaginary book for Terragen users, this would constitute an entire chapter.

[WAS]

Final position can change a PF too I believe. You can lock in textures for example.

But what I mean is when a compute terrain is used colour space / texture space (following the compute terrain) will be following the patched compute terrain, not the base displacement. For example what was strictly Y noise may now be warped a bit and what was just a Y noise is no warped on Y and Z or Y and X tilting its texture space directions much like you show woth the computed normals.

[sboerner]

I think we are saying the same thing here. The way I think of it is what you're calling texture space = position in texture/terrain, whether or not its been updated with a compute terrain.

Hoping that someone from Planetside will weigh in at some time to point out any errors and/or refinements.

[WAS]

I'm just looking at it wrong I guess. It just doesn't make sense to me.

So only the texture space is effected by a compute terrain? Because that doesn't seem to be the case in TG. Colour and displacement will follow the compute terrain won't it? For example, smaller patch sizes allow smaller tighter displacement form PFs applied to that computed terrain. Greatest example if doing lateral displacement and having it correctly follow the computed terrain. Higher patch sizes and it looks more approximated in application.

[sboerner]

Compute terrain also updates normals, so that would account for some of the things you mention (like lateral displacement). But the discussions I've found here and on the wiki seem a little ambiguous about whether displacements after a compute terrain use the smoothed coordinates. As far as I can tell, they don't -- unless you are using intersect underlying. But I could be wrong.

[WAS]

Fairly certain it does.

You can see this by creating as terrain with same PF before, and after a compute terrain. Disable the compute terrain and PF it's computing, to allow only the duplicate PF (no computation). Then highlight them all and use D to switch between them. Apply a Fake Stones surface, and a PF with super high noise variation on billows (to easily distinguish it's displacement) and you'll see the results provided by a computed PF, and a non-computed PF are entirely different (with colour/disp applied over it).

It seems to either change the noise space (to what I don't know. Obviously not final) for all functions of the shaders, or is conforming to the displacement differently.

[WAS]

Here is a quick test. Something is clearly very different between the two scenarios.

It just seems something else is happening and modulating the spaces after a compute terrain, cause boy if you are used to working with a computed terrain, and don't, all your logic starts getting funny and things start going wonky.