Planetside Software Forums

General => User-contributed Tutorials => Topic started by: sboerner on May 25, 2021, 02:10:07 PM

Title: Final position vs. Position in texture/terrain: A visual aid
Post by: sboerner on May 25, 2021, 02:10:07 PM
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.
Title: Re: Compute terrain vs. Position in texture/terrain: A visual aid
Post by: WAS on May 25, 2021, 03:43:09 PM
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.
Title: Re: Compute terrain vs. Position in texture/terrain: A visual aid
Post by: sboerner on May 25, 2021, 07:10:40 PM
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?
Title: Re: Compute terrain vs. Position in texture/terrain: A visual aid
Post by: WAS on May 25, 2021, 11:35:47 PM
You can rename the topic in the full edit, provided it hasn't been too long.

And I think I just misinterpreted it.
Title: Re: Compute terrain vs. Position in texture/terrain: A visual aid
Post by: gao_jian11 on May 25, 2021, 11:53:52 PM
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.
Title: Re: Final position vs. Position in texture/terrain: A visual aid
Post by: sboerner on May 26, 2021, 12:13:19 AM
QuoteYou can rename the topic in the full edit, provided it hasn't been too long.
Perfect! That did it. Thanks, Jordan.



Quotethank! 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?
Title: Re: Final position vs. Position in texture/terrain: A visual aid
Post by: Dune on May 26, 2021, 01:31:42 AM
Great summary. This should be put in the wiki, I guess.
Title: Re: Final position vs. Position in texture/terrain: A visual aid
Post by: WAS on May 26, 2021, 03:01:17 AM
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.
Title: Re: Final position vs. Position in texture/terrain: A visual aid
Post by: sboerner on May 26, 2021, 11:32:59 AM
QuoteGreat 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?


QuoteThere 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.
Title: Re: Final position vs. Position in texture/terrain: A visual aid
Post by: WAS on May 26, 2021, 12:34:26 PM
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.
Title: Re: Final position vs. Position in texture/terrain: A visual aid
Post by: sboerner on May 26, 2021, 12:43:47 PM
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.
Title: Re: Final position vs. Position in texture/terrain: A visual aid
Post by: WAS on May 26, 2021, 12:58:27 PM
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.
Title: Re: Final position vs. Position in texture/terrain: A visual aid
Post by: sboerner on May 26, 2021, 01:12:09 PM
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.
Title: Re: Final position vs. Position in texture/terrain: A visual aid
Post by: WAS on May 26, 2021, 01:40:48 PM
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.
Title: Re: Final position vs. Position in texture/terrain: A visual aid
Post by: WAS on May 26, 2021, 01:44:32 PM
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.
Title: Re: Final position vs. Position in texture/terrain: A visual aid
Post by: Dune on May 27, 2021, 02:48:41 AM
Quote from: sboerner on May 26, 2021, 11:32:59 AMOr do you just not worry about it?
I don't really. Colors in nature are wild and quite unpredictable anyway, and I've never heard anyone complaining about mismatched colors in my scenes. Not even in the latest shorescene, where it also occurs ;)  The main problem I'm having is to color fake stones and get the stone colors onto the stones and not in the soil around it, or soil color over part of the stones. Fiddling with an XYZ usually does the trick to update color space, using a world transform after the stones often doesn't.

And to really match smaller colors and displacements to updated (by compute terrain) geometry, you'd indeed need a small patch size, like Jordan says, especially when working in detail, and not vast mountainous areas, where you can easily delete the compute terrain (not always though).
My 2 cents.
Title: Re: Final position vs. Position in texture/terrain: A visual aid
Post by: WAS on May 27, 2021, 01:11:47 PM
Quote from: Dune on May 27, 2021, 02:48:41 AM
Quote from: sboerner on May 26, 2021, 11:32:59 AMOr do you just not worry about it?
I don't really. Colors in nature are wild and quite unpredictable anyway, and I've never heard anyone complaining about mismatched colors in my scenes. Not even in the latest shorescene, where it also occurs ;)  The main problem I'm having is to color fake stones and get the stone colors onto the stones and not in the soil around it, or soil color over part of the stones. Fiddling with an XYZ usually does the trick to update color space, using a world transform after the stones often doesn't.

And to really match smaller colors and displacements to updated (by compute terrain) geometry, you'd indeed need a small patch size, like Jordan says, especially when working in detail, and not vast mountainous areas, where you can easily delete the compute terrain (not always though).
My 2 cents.

If you do need, like let's say intersections at a distance or something, mixing in two compute terrains by distance works wonders. Get the best of both worlds. Foreground is nicely detailed, and can still have snow favoring depressions on distant mountains, but not favoring tiny patch sizes like your foreground
Title: Re: Final position vs. Position in texture/terrain: A visual aid
Post by: KaseyBear on July 05, 2021, 10:20:01 AM
Quote from: Dune on May 27, 2021, 02:48:41 AM
Quote from: sboerner on May 26, 2021, 11:32:59 AMOr do you just not worry about it?
I don't really. Colors in nature are wild and quite unpredictable anyway, and I've never heard anyone complaining about mismatched colors in my scenes. Not even in the latest shorescene, where it also occurs ;)  The main problem I'm having is to color fake stones and get the stone colors onto the stones and not in the soil around it, or soil color over part of the stones. Fiddling with an XYZ usually does the trick to update color space, using a world transform after the stones often doesn't.

And to really match smaller colors and displacements to updated (by compute terrain) geometry, you'd indeed need a small patch size, like Jordan says, especially when working in detail, and not vast mountainous areas, where you can easily delete the compute terrain (not always though). employee monitoring (https://www.worktime.com/employee-monitoring)
My 2 cents.
User can see Colors and Texture. But 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
Title: Re: Final position vs. Position in texture/terrain: A visual aid
Post by: sboerner on July 05, 2021, 11:06:24 AM
QuoteBut only the texture space is effected by a compute terrain?
Compute terrain updates position in terrain/texture and normals. Normally you place it between terrain and shaders -- displacements and color -- but it depends on the scene. Usually I add very small-scale displacements after the compute terrain.
Title: Re: Final position vs. Position in texture/terrain: A visual aid
Post by: WAS on July 05, 2021, 02:44:51 PM
I think this is a bot. They injected a link into the quote. Ulco would never do that.
Title: Re: Final position vs. Position in texture/terrain: A visual aid
Post by: sboerner on July 05, 2021, 04:08:57 PM
Interesting. Good catch.
Title: Re: Final position vs. Position in texture/terrain: A visual aid
Post by: Dune on July 06, 2021, 01:50:36 AM
I had the vague feeling he was a spammer, suddenly appearing with a few questions and remarks... but he did a 'good' job at it, not just the usual blablabla. But I wonder how stupid these guys are; do they really think anyone would click a link like that? I don't see the point in these spamming actions.