rendering ter file with mountain - holes in terrain

Started by neon22, August 02, 2013, 05:33:59 AM

Previous topic - Next topic

neon22

In 2.5.
I have a ter file which is an island with mountain (Yay GC2).
When rendering the mountain loking down on it - always get a good render but as camera drops and start to look up at mountain - it increasingly disappears from render. see images.
Any ideas ?
Rendering stock settings with Quality 0.9 AA 5

Dune

On the planet node increase displacement tolerance. Start with 1.5 or so. Much bigger will increase render time.

neon22

#2
Excellent - thanks - no idea how I missed that :-)
FWIW - default is 1. My problems disappeared between 4 and 5. But the render time has gone form 1 minute to 1 hour I stopped it at 9 hours - incomplete :(

Dune

I was afraid of that, but the displacement is quite much, that's the problem.

neon22

#4
Yes - but interestingly if I look down on mountain then no problem at all...
Its how much the dispacement projects into the visible frustum.

Also interesting is that GI prepass can clearly see all of mountain - at any angle...

Oh but what's to become of my island paradise - unrealised, ephemeral, lost...

neon22

Matt - maybe you can use the GI prepass to help locally determine if the displacement has been sampled enough ?

Matt

Hi Neon,

Interesting idea. Theoretically the GI pass can have the same problems, but apparently not in this case. I will think about it.

Thanks.
Just because milk is white doesn't mean that clouds are made of milk.

Mr_Lamppost

Quote from: Matt on August 02, 2013, 07:09:30 PM
Hi Neon,

Interesting idea. Theoretically the GI pass can have the same problems, but apparently not in this case. I will think about it.

Thanks.

I'd noticed this a s well but had never thought of pointing it out.  I often work with abstract / fantasy landscapes which feature extreme displacements which often suffer cut offs when rendered.  I know what I am doing is not the main focus of Terragen so not complaining. However I have noticed that the GI prepass clearly sees the areas that are clipped in the render.
Smoke me a kipper I'll be back for breakfast.

neon22

I'd also suggest that even the x40 or x80 visual in the interactive viewer also does not suffer from this problem. So maybe even a pass with that could indicate where displacements need to be extended ?
Maybe not all shaders would need to be evaluated to discover this, so maybe its cheaper ??

Oshyan

It comes down to the render bucket size I believe - large displacement that crosses multiple render buckets is problematic. This is why the 3D preview doesn't have the same issues, but it also renders to far lower detail so doesn't need to use buckets. You could try increasing the size of the render buckets (and uncheck auto-reduction), but this will increase memory use I believe.


The solution for now is to increase Displacement Tolerance.

- Oshyan

neon22

Quote from: Oshyan on August 11, 2013, 01:31:21 PM
It comes down to the render bucket size I believe - large displacement that crosses multiple render buckets is problematic. This is why the 3D preview doesn't have the same issues, but it also renders to far lower detail so doesn't need to use buckets. You could try increasing the size of the render buckets (and uncheck auto-reduction), but this will increase memory use I believe.
This is very interesting to me. So I tried some variations.
I usually use 64 size buckets. I do this because when rendering animation I don't like the idea of 15 cores sitting idle while the last tile renders. Of course I pay somewhat for this as there is more overhead to setup and tear down each tile render. Finding the right bucket size is also highly dependent on the view and so a low number is not always ideal. (For this image execution time varied from 4:50 to 6:20)

Below are several images showing:
- the base render with tile 256 - looks OK but parts are missing at tile boundaries.
- an image showing the missing parts for 64, 128, 256, 512 sized buckets.
- a casual overlay of some of those tile boundaries relating errors to boundary alignment.

From this I am able to determine that increasing the tile size is very beneficial to getting better coverage but does not solve the problem on its own. I suspect we need Displacement tolerance as well. I will continue to experiment with that and the larger tile sizes.

Quote from: Oshyan on August 11, 2013, 01:31:21 PM
The solution for now is to increase Displacement Tolerance.
- Oshyan
Alas going from 1 minute to render a frame (default Displacement Tolerance=1) to stopping it at 9 hours (Displacement Tolerance=5)  - well its a solution but its not a useable one. I hope to find a lower number using this new information.
More data soon.

Oh yes - when unchecking auto-reduction - I noticed my render never actually finished when using 512 as bucket size on a 1920x1032 image. I had to recover image from cache directory. Could be a small bug here with process never ending but have not tried with animation - stills only.

neon22

#11
Alas I have found an example where the GI calc does indeed not see the extended Displacement :-(
This was a 64 pixel sized bucket.

Dune

Conclusion; it's best to refrain from extreme displacements for the time being, and use objects if needed. For such a pinnacle you could use a distorted sphere, by the way.

neon22

Whoops there's an additional wrinkle.
I tried another older file I had (almost since beginning) its a crater...
As you increase the Quality - the bucket size has less effect and the Displacement Tolerance becomes supercritical...
Here you can see some effects.
Q = quality
DT= Displacement Tolerance
final numer in filename is render time...

The outstanding question to me is:
As quality goes up - actually get less accuracy in sampling displacements. Maybe there is a clue here ?

neon22

Quote from: Dune on August 12, 2013, 02:59:28 AM
Conclusion; it's best to refrain from extreme displacements for the time being, and use objects if needed. For such a pinnacle you could use a distorted sphere, by the way.
well maybe... but I've used GC2 because of its great erosion filters. - so it could be hard to generate what I need manually when the terrain generation program has done such a great job...

In any case - I'm just trying to gather info to, hopefully, either help Matt to fix it, or give some pointers to future experimenters....