Details of Compute Terrain, Tex Coords from XYZ, etc. and their render time impact

Started by Tangled-Universe, August 27, 2019, 05:21:58 AM

Previous topic - Next topic

Tangled-Universe

Moderator: This topic has been split to focus useful discussion in its own thread. Further discussion of the path tracing render time on Rich's scene can be continued in the source topic.

Quote from: Dune on August 26, 2019, 11:06:15 AMI get the impression that an XYZ shader doesn't cost much, certainly not as much as compute nodes. I use them quite a lot too. I wonder, btw, if patch sizes differ much in cost.

You might be right, but I think it's valuable to test it so we can verify it for this setup and indeed as a bonus clarification on the rendercost of XYZ nodes.

Patch size does not differ that much I believe, since the shader needs to evaluate all normals to actually generate the patches.
The patch size is the scale at which normals are allowed to change rapidly. A rough surface with a large patch size compute node below it will allow for more predictable addition of subsequent displacement than a rough surface with small patch sizes. Since small patch sizes allow for more rapid changes in surface normals relative to its position.
To calculate such a patch the shader needs to evaluate each normal. See it as a way of averaging. There's no way of averaging a set of values without knowing those values.

Some random thoughts following this...I see the patch size as an "output" therefore.
I can imagine though that when using multiple compute nodes at small patch size that it somehow could become more expensive, since the potential amount of fractal detail also increases. It may therefore also depend on your micropolydetail setting. Sorry if these are confusing thoughts.

Dune

I'll do some tests if time permits, see what XYZ shader does to render time and patch size too. I'm not technically into TG as much as you are, but I grasp your way of thinking.

Hetzen

From my experience, Tex Coords from XYZ isn't that expensive, it does add a bit but not too much. Patch size on the other hand does make a difference in the Compute Normal/Terrain render cost, it's the resolution the underlying mesh is calculated.

TG starts with the planet surface as its base mapped shape, a sphere. Once it's displaced it still has the same mapping as the sphere. The Compute node re-maps the displacement in a series of triangles, the Patch size determines the size of those triangles. Think of it like the preview window (it's not the same, just an illustrative). It starts off with large triangles (large patch size) which incrementally decrease in size and take longer to process because there's more of them. 

I think you've got it the wrong way round Martin, I could be wrong. You need to work out the patch sized triangles for mapping first before you can average them. The end surface can have a higher detail than the mapping patch size because what the Compute nodes do is change the base sphere shape to what ever you've formed with displacement, on which the finer detail from PFs etc are added at render time.

Tangled-Universe

Yes you might be right Jon, I'm not sure.
I follow your reasoning and apply a similar vision on how TG parses the network (from bottom up, actually)
The way you explain it sounds to me like the compute terrain potentially limits the maximum amount of surface detail allowed, but with standard 20m we can easily have smaller scale details.
Normally, without any patch size computations, if you would apply displacement to such smaller scale terrain details then displacement direction would follow the normals exactly everywhere, causing many many spikes/needles/artefacts.
To avoid this we would need to average the normals over a given area, the patch size, to make sure that the normals of small scale details are weighed less.
To calculate that average, you'd need to parse over all those normals.
Otherwise I don't see how we can have small scale displacement details, smaller than the 20 meter default patch size.
There must be some sort of interaction with the micropoly renderer as well, because with higher surface detail you also create more triangles and more normals to be evaluated by the compute node.
In overall the lower octaves are dominant I guess, because they cause the biggest displacement amplitude and therefore are the biggest contributor of surface normal change.

Oshyan

Hey guys, I split this discussion into its own thread as it was getting a little in-depth for Rich's thread. There's a link back there in T-U's first post above.

I also want to point out that a lot of these details about Compute Terrain are discussed in the docs: http://planetside.co.uk/wiki/index.php?title=Compute_Terrain
Including a bit on compute/render time impact.

In answer to some speculation here, according to Matt, it doesn't need to calculate normals of all micropolys, and smaller patch size doesn't require more computation. He may update with more info here soon.

- Oshyan

Tangled-Universe

Great to hear we're both wrong on some aspects. Learning something along the way.