Terrain and shadows changing during animation

[Tangled-Universe]

Hmmm I don't know Oshyan. Look at the bottom right part of the fake stone example. Some parts are directly lit and are smoother compared to the example with lowest RDM setting.

Puzzling

[Oshyan]

They all appear to be errant shadows to me. The actual edges (against the base terrain of a different color) appear equally smooth as far as I can see. Which supports my theory. Hopefully Matt can answer definitively.

- Oshyan

[Matt]

I said I'd noted this happening on fake stones as well.
Here's two tests, a simple and entirely default fake stones shader, no surface shaders or other modifications added. Both tests at final render detail=1 for consistency. Both with the default micropolygon renderer.

Firstly, an RDM setting of default=0.25 with fully adaptive enabled;
[attachimg=#]

Lastly, the very same with RDM=1;
[attachimg=#]

The difference is plain to see.

I'm out.

Yes, there is a difference, but the difference is caused by shadows (which are ray traced). When you cast shadows from a lower detail version of the geometry, problems like these can occur. They look more pronounced than I expected, and I can look into that to see if I can improve it.

[dandelO]

**EDIT FOR CLARITY IN MY ABBREVIATIONS; 'RDM'='ray detail multiplier' and 'DRTS'='do ray traced shadows'.**

OK. Here's a quick test I just ran that is pretty conclusive. All at render detail=1, fully adaptive=1, force all edges=1.

It seems that a low RDM *only appears to affect geometry* when 'do ray traced shadows' is checked.

Notice the undefined edge in the first image, I zoomed in very close to the bottom edge of the shape(the single image beneath), where I expected to see the apparent geometry discrepancies magnified. But it didn't turn out that way. The discrepancy is still there but it's shrunk in size, telling me that it is, after all, just stupidly calculated shadows.

The last 3 images in the tall stack picture have identical geometry, I viewed them in sequence and there is no real difference between them at all.

[attachimg=#]

First image viewed close;
[attachimg=#]

[dandelO]

Matt, you posted before I did, confirming what I just found out the long way!

Thanks for the confirmation!

[Tangled-Universe]

Thanks Matt and Martin. Makes more sense now!

Cheers

[dandelO]

The way to improve it in the meantime, for anyone reading here, is(when not using RTE) set the ray detail multiplier to '1' for correct shadows. Remember, this will multiply render time, especially so in scenes containing transparent water and GI.(and ray traced objects/atmosphere, as well, I'd imagine?).

[Matt]

The way to improve it in the meantime, for anyone reading here, is(when not using RTE) set the ray detail multiplier to '1' for correct shadows. Remember, this will multiply render time, especially so in scenes containing transparent water and GI.(and ray traced objects/atmosphere, as well, I'd imagine?).

With shadows, it only affects the shadows of terrain or other displaceable primitives (sphere, lake, plane), but those shadows may be cast onto other things like objects, so it will increase render times all round. Also, ray detail multiplier affects the time taken to render the GI prepass because that pass is entirely ray traced.

Matt

[Tangled-Universe]

Thanks Matt,

While you're here, can you also tell us about the "force all edges" and "fully adaptive" and in which situations disabling or enabling any of these two might be beneficial?
Thanks

Cheers,
Martin

[Matt]

Thanks Matt,

While you're here, can you also tell us about the "force all edges" and "fully adaptive" and in which situations disabling or enabling any of these two might be beneficial?
Thanks

Cheers,
Martin

I hadn't documented these settings because they are 'unsupported' settings that may change in future versions. They are supposed to be temporary features that will be replaced by automatic settings in future. The only reason they work in the public release is so that if you are rendering an animation and you have micropolygon popping issues you can follow my recommendations, which are as follows:

For animations:

In the Render Subdiv Settings node:

Fully adaptive OFF, but there may be side effects. OFF may reduce detail unsatisfactorily in some places or put needless detail in others, but if you need absolutely pop-free animation it might need to be OFF in current versions.
Force all edges ON
Jitter shading points OFF
Stabilise ray detail in motion ON (if you have v2.4 alpha)

On the 'Extra' tab of the render node:

Detail blending 1. This is the most important setting for blending between levels of detail as the distance between camera and surface changes. Values other than 1 can be used, but I would not recommend lower than 0.5. Higher blending values increase render time, unfortunately.
Displacement filter 1 (default). Allows displacements to blend between levels of detail. The effect also depends on detail blending.
Microvertex jitter OFF or ON. OFF seems to produce a more stable animation because I think there is an error somewhere, but ON reduces render times by a small amount.
Detail jitter OFF. There is an error that cause this to change from one frame to the next, so you should switch it OFF for animations.

For still images:

Either delete the Subdiv Settings Node altogether, or reset it to default settings, which are:

Fully adaptive ON (default)
Force all edges OFF (default)
Jitter shading points ON (default)
Stabilise ray detail in motion OFF (default)

Still image quality is generally higher and often with shorter render times if you have the following settings on the 'Extra' tab:

Detail blending 0 (default). Higher blending values increase render time, and are not as useful with still images, so I suggest setting to 0. Blending also softens the appearance of surfaces, but its main purpose is to blend between levels of detail in animations.
Displacement filter between 0 and 1. I always leave this at 1 (default) for still and animations.
Microvertex jitter ON (default)
Detail jitter ON (default)

Briefly, this is what the Render Subdiv Settings do:

Fully adaptive causes micropolygons to be more heavily subdivided when the surface is stretched by displacements, but reduces the amount of subdivision where the surface is compressed in screen space due to the angle of view or due to displacements. For stills this is usually a good idea, but it can lead to sudden changes between frames in an animation (and may also produce gaps in stills, although I am not sure about this). Turning this off means that the amount of subdivision is quite regular according to the undisplaced surface, and therefore stable in animations, but doesn't give the best image quality when studying each frame separately. Big displacements will look quite faceted when this is turned off.

Force all edges fixes one of the problems that causes gaps between micropolygons. If two neighbouring micropolygons A and B are subdivided to different levels along a shared edge, this can cause gaps. Force all edges causes the shared edges to be subdivided to the same level. This helps in both animations and stills. The default is OFF because this feature hasn't been in use for very long and it does slightly increase render time. For animations, though, it's probably worth the cost to remove artefacts.

Jitter shading points chooses a random point on each micropolygon as the point where lighting and shaders are calculated. The results of those calculations are used to colour the whole micropolygon. Jittering provides a more natural image, but because of an error in current versions the jitter is different on each frame so it is a source of unwanted noise in animations.

Stabilise ray detail in motion. This feature is even more recent than the others, and needs some further work, but its purpose is to blend between levels of detail when calculating shadows and reflections. If it's working correctly, it should have two benefits. It should minimise the crawling of shadows across surfaces as the distance from camera changes. The crawling motion is instead replaced by a gradual blend between different shadow positions. (Unfortunately it's impossible to completely stop the shadows from changing shape, because the terrain that casts the shadows needs to change levels of detail as the camera moves.) Second, because the shadow positions are now blended instead of moving from frame to frame, popping that occurs when shadow-casting micropolygons very close to the point receiving the shadow change their shape should no longer happen. Unfortunately, stabilise ray detail in motion produces artefacts of its own - sometime a kind of cross-hatching pattern is visible. This is something I still need to improve.

I really don't like having all these options. The goal is hide these behind a couple of simple options which should optimise Terragen for animations or stills.

Matt

[dandelO]

Thanks very much for those explanations, Matt!

[MKE]

Hi Matt,

thanks a lot for this explanation. This helps very much to understand what's happening and that's way more satisfying than when we just try to turn some knobs, to see what's happening and then interpret what Terragen is doing.

It's also good to know that there are still some bugs in Terragen (and it's not always because I'm to stupid... ;-).

Kind regards,
Martin

[Tangled-Universe]

Thanks for the extensive explanation Matt.

In the animation section of explanations you didn't really mention the detail blending parameter and displacement filter setting as being important to animation.
Did you forget it or is it on purpose because the "new" parameters overrule the detail blending/displacement filter technically, or by importance?

What about those anyway? I suppose the detail blending parameter blends geometry in between frames to avoid popping geometry, but little clue about the displacement filter?

At the moment I'm working with Jon West (Hetzen) on animating a scene (with vegetation) and are experiencing some issues like popping shadows and especially vegetation flicker.
(the latter I think has little to do with detail blending).

Sorry Martin (MKE) for deviating a bit, but I hope you find this interesting too.

Cheers,
Martin

[MKE]

Sorry Martin (MKE) for deviating a bit, but I hope you find this interesting too.

Sure, still learning a lot from you all... :-)

Martin

[Matt]

Ah, yes Martin, that was an oversight. I'll edit my post to add those. Thanks.