Page 1 of 35

[MOD] Distant Terrain

Posted: Mon Mar 23, 2015 11:00 am
by Nystul
As some of you may already know I have been working on increasing the terrain/view distance in DFTFU

mod download:
Distant Terrain 2.4.2 (only compatible with new dfunity version with new baseline (Unity 2018.1.2f1)):
https://drive.google.com/file/d/1pEhlbv ... sp=sharing

see the (old) screenshot gallery (with Lypyl's Enhanced Sky and Uncanny Valley's RealGrass mod):
http://imgur.com/a/FijMk

Re: Project "Increased Terrain Distance"

Posted: Mon Mar 23, 2015 1:06 pm
by Deepfighter
Just want to say that I really appreciate your work! The screens are looking fabulous! Daggerfall has so much more to offer and your work shows what we can expect. Love to see improvments on this "frontline" :)

Re: Project "Increased Terrain Distance"

Posted: Mon Mar 23, 2015 1:43 pm
by Nystul
I am glad you like it! ;)

Re: Project "Increased Terrain Distance"

Posted: Mon Mar 23, 2015 5:04 pm
by LypyL
I'm glad to see you're still working on this! I was flying around last night with this on and it was really fun, though the pop-ins become a little distracting when you're up high looking down and moving fast :D

Re: Project "Increased Terrain Distance"

Posted: Mon Mar 23, 2015 9:17 pm
by Interkarma
This is great work. I can't wait to see even more enhancements to the terrain system.

Re: Project "Increased Terrain Distance"

Posted: Mon Mar 23, 2015 9:23 pm
by Nystul
I would like to write a bit about what I am currently up to:
You might have already seen that I played around a bit with the WOODS.WLD file and reimported it into Vanilla Daggerfall.
See this post on reddit-dftfu: http://www.reddit.com/r/dftfu/comments/ ... _woodswld/

While my original intend was to find out if and how nature flat information is stored in it (I failed in both a devastating as well as hilarious manner) I managed to get some interesting insights into vanilla daggerfall's handling of height data:
First it seems to use all of the 5x5 pixels of the noise map in a straight forward way (and only the noise map and it seems to ignore the altitude map completely).
Second it applies heights in this noisemap with an exponential scale (the exact computation formula is still unknown, but one can get sample world height values for certain height map values)
See this screenshot of Vanilla Daggerfall interpreting a 5x5 grid with values of [10,10,10,10,10; 10,65,65,65,10; 10,65,120,65,10; 10,65,65,65,10; 10,10,10,10,10]:

Image

and the table of sample height map values and corresponding world height values in-game (there might be an offset for player head to ground distance):
000 > 40
010 > 160
020 > 280
030 > 440
040 > 600
050 > 800
060 > 1024
070 > 1280
080 > 1600
090 > 1960
100 > 2440
110 > 3160
120 > 4440

So if somebody is able to derive a computation formula, I would be glad (with integer arithmetics, heavy shifting operations as vanilla daggerfall would compute it...)
The closest formula I came up with was after using excel's powerful curve fitting functionality: +0,0041841491841491100000x3 -0,4277522477522950000000x2 + +27,0437229437239000000000*x - 40,1978021977266000000000

What I want to try out in DFTFU is now:
*) use all of the 5x5 noise map values instead of the inner 3x3 values as it is done now (this includes transforming the grid like structure in some kind of random structure)
*) use similar exponential scaling of heights as vanilla daggerfall but with a much stronger attenuation

I started investigating the second point:
One problem is quite obvious when one tries to scale the height map values without special handling... the highest regions in the height map are not the dragontail mountains and wrothgarian mountains, but the spots/regions indicated in this screenshot:

Image

problem regions marked with yellow color are the single spot errors which could easily be corrected
problem regions marked with orange color are menevia cliffs (the highest map values except the single spot values, which is kind of too high in my opinion) and the right border of the map (which could be just solved by setting it to much lower values
problem region marked with red color is the sentinel plateau - and here my headache starts. It was obiously intended by the original designers to have elevation here but it is so high compared to some other mountains it just doesn't fill right... since it is next to sea level, it is really critical (anyone who set TerrainScale in DFTFU to higher values than the standard value, knows how unnatural things become...)

so what is the solution. manually correct the height map? - I don't like this idea very much... (especially since you could lose intended relations)
when thinking about the problem regions it becomes evident that especially near water one should not exaggerate height values anymore - especially not with exponential scaling
So what I want to try out now is this: I only want to exaggerate height values of map pixels that are far enough away from water, see this screenshot of the 2D distance transform of the height map pixels and the water level:

Image

I will try to use this distance map as weighting function for the height exaggeration. I hope to make the height map more interesting but still maintain a general plausibility. There are a lot of open questions though especially when it comes to implementation details.
I hope to be able to show some progress soon!

Re: Project "Increased Terrain Distance"

Posted: Mon Mar 23, 2015 9:30 pm
by Interkarma
Clever stuff, I like where this is heading.

Re: Project "Increased Terrain Distance"

Posted: Tue Mar 24, 2015 12:24 am
by Lazaroth
Nystul wrote: So if somebody is able to derive a computation formula, I would be glad (with integer arithmetics, heavy shifting operations as vanilla daggerfall would compute it...)
I tried using the Eureqa software, but having it run for 30 mins on 8 cores only gives crazy formulas. Maybe it can find something usable if run overnight with properly tweaked settings. I know too little of how Daggerfall works to know what those settings would be though. I wouldn't be surprised if an important variable is missing however.

The alternative I suppose is decompilation.

Re: Project "Increased Terrain Distance"

Posted: Tue Mar 24, 2015 8:54 am
by Nystul
since curve fitting software fails to compute meaningful (easy enough) formulas, I think this is a sign that either there was integer division or right shifting with truncation involved or piece-wise functions were used...

Re: Project "Increased Terrain Distance"

Posted: Fri Mar 27, 2015 6:10 pm
by Al-Khwarizmi
The closest I get is this, using some transformations and a bit of intuition:

f(x) = 40*ceil((x/10)^(5/3))

With this, we get the following values:

000 > 40
010 > 160
020 > 280
030 > 440
040 > 600
050 > 800
060 > 1040*
070 > 1280
080 > 1560*
090 > 1880*
100 > 2200*
110 > 2520*
120 > 2880*

So at least the first few are OK... could it be the first part of a piecewise function?

I'm very puzzled by the f(60)=1024 because it's the only value that is not a multiple of 40. Strange. Are you sure there's no typo there?

Also many values ring a bell from screen resolutions.