Planetside Software Forums

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

---

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

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 :(

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

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...

---

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

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.

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.

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 ??

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

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.

---

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

---

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.

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 ?

---

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....

Not sure if that it is the same problem in the images in your last post.
It could be the water shader node(?) causing that problem.
I had mostly problems with it in the past.
If i remember right when i used only 1 CPU core i got rid of that black squares.

Neon try to render one problematic image without that shader (if you really use it of course ).

Quote from: Kadri on August 12, 2013, 11:36:53 AM
Not sure if that it is the same problem in the images in your last post.
It could be the water shader node(?) causing that problem.
I had mostly problems with it in the past.
If i remember right when i used only 1 CPU core i got rid of that black squares.

Neon try to render one problematic image without that shader (if you really use it of course ).

Sure - here you can see a similiar result without the water.
visible at Q=0.3, bad at 0.4. Scene entirely black at 0.5
Of course this scene is extreme in the nature of its displacement so is very much a test case.
But it does show the relationship between quality and this error.

I also checked it with 1 core instead of 16. interestingly similar but unexpectedly different. weird.

---

Thanks for testing Neon.
Interesting.

You could try some workarounds maybe...
Use a different Planet node with high displacement tolerance settings over the other one with masking for example to lower render times.
But i actually lower my displacement settings mostly and change the scene if possible, when i encounter such problems.

Just curious how a much bigger ( 4 times or more) render with low quality render settings and different bucket settings etc. might look , Neon?

Quote from: Kadri on August 12, 2013, 05:19:17 PM
Just curious how a much bigger ( 4 times or more) render with low quality render settings and different bucket settings etc. might look , Neon?

Hmm its weirdly frustrating. Here it is 4k wide but entire image renders black if Q gets over 0.1
But if I render it cropped, I can get Q=0.4
Highly non-linear... I guess I could tile it using tgd_Batch and render it large that way. Just as well I don't need to :-)

---

Interesting. Thanks for testing Neon .

After much experimentation I have come to the following conclusions:

If you have missing geometry from extreme displacements in your scene you should try the following, in this order:

• Increase the Max Bucket size in Render/Advanced/Bucket Controls. Default 256. Increase to 512 or higher.
• Try switching off "Allow auto reduction" in same Render Bucket control.
• Increase Displacement Tolerance in the Planet node. Default is 1. Try 2 or larger and reduce, until problem reappears.

• values over 3 indicate you have more serious problems.
• values over 4 will make your renders too slow to be useable. Find another solution.

In some special cases - you can get a good solution by just rendering a cropped region around the failure point, and by lowering Render Quality. But these last two will only help in weirdly catastrophic situations involving unusual node connections such as multiple compute terrains. Generally these last two will not help you but they do indicate where the problem lies.

Following steps 1-3 and trying them one at a time will result (if successful) in keeping your render times as low as possible.
You will need more memory as the Bucket size increases - so this may place a limitiation on you.
Increasing the Displacement Tolerance will directly affect render times by a large factor. Try it last.

It is noticeable that the effect is amplified if the displacement projects into the camera viewport. So looking down on a mountain might render well, but looking up at the mountain will exacerbate the error and parts of it might disappear...