Author Topic: Aligment lines on large scaled terrains  (Read 2281 times)

Danilo Nishimura

  • Sr. Member
  • ****
  • Posts: 66
  • Senior Technical Artist at Massive Entertainment
Image: https://i.imgur.com/FcpR3Lt.png

STR:
#1: Create a Ridged or Billowy noise node
#2: On the Node Properties tab, increase the scale to the max (artifacts noticeable from 1500 onwards)
#3: Observe the alignment lines
« Last Edit: December 29, 2019, 07:49:14 AM by dnishimura »

Alexis Vaisse

  • Administrator
  • *****
  • Posts: 189
These lines come from the fact that a computer doesn’t have infinite precision numbers.
On the GPU we use single-precision numbers which have approximately 7 significant digits.
When you set a value of 3000 for scale, we end up with very big values when computing the noise and these lines appear because of the limited precision on numbers.

We could use double-precision numbers, but it would take more time to compute.

You usually don’t have to set too high values for scale.
If you have a very large terrain, a possible workaround is to generate a noise on a smaller terrain then use a “change terrain size” node to increase the size of the terrain, and then add detail.

If this is really an issue, we can try to use double-precision numbers and see the impact on performance.

Thanks a lot for your feedback.

Danilo Nishimura

  • Sr. Member
  • ****
  • Posts: 66
  • Senior Technical Artist at Massive Entertainment
Quote
You usually don’t have to set too high values for scale.
The idea is to use a terrain to simulate how big the world through an ants perspective. It's just a prototype, not really a game. And not that I need that scale, just wanted to see how it would look if I modified the scale to that extent.

Quote
a possible workaround is to generate a noise on a smaller terrain then use a “change terrain size” node to increase the size of the terrain, and then add detail
I'll give it a try. Thanks!

Quote
If this is really an issue, we can try to use double-precision numbers and see the impact on performance
Well, I think that as long as we're talking about a baked solution, taking more time to get a better quality is very acceptable. We're used to this kind of thinking from an artistic point of view. If it takes 4 times longer to generate the maps, but deliver high quality results, I really don't mind the time it'll take. We can prototype using the low precision, and use the high precision for production.

Quote
these lines appear because of the limited precision
A lot of work would be necessary to change the codebase to allow multiple precisions. Using System.Numerics.BigInteger, or even custom fixed-point precision could potentially decrease the performance for single precision calculation due to bigger code complexity. But as I said before, from an artistic standpoint, quality is usually the priority. It's a complicated tradeoff.
(also see: https://www.researchgate.net/publication/325663757_Parallel_Multiplication_of_Big_Integer_on_GPU)