Heightfield generate, alpine fractal issues

Started by djwhitehart, September 02, 2017, 04:14:17 AM

Previous topic - Next topic

djwhitehart

After a great deal of searching through forum posts, trial, and error, I've been unable to save a heightmap of a specific area of my current project. I've tried following the conventional wisdom of attaching my Heightfield Generate node to the end of my terrain network, as well as setting the heightmap's coordinates as precisely as I can, but I always end up with a completely flat .ter file. I'm at my wits' end, so I've decided to turn to the brilliant minds here for help. My project is too large to be attached to this post, so I've added it to my Dropbox here, sans several extraneous (and large) resources.

In all my efforts, I've also noticed that some of my alpine fractal's settings are getting reset every time I reopen the project. The "Terrain alt fractal detail" node is supposed to have five lead-in octaves and a smallest scale of 10 meters, but I've had to reset them to those values each time I open the file. I assume this is unintended behavior? (I'm running TG 4.1.11 on Win10 Pro x64.)

Thanks in advance for your help, folks!

Tangled-Universe

Weird, why is this scene so utterly damn slow in TG? I only see half a dozen of relevant nodes which make up the scene, but it is impossible to navigate and the preview takes eons to finish.

At this stage I can't tell if things aren't configured incorrectly or not, I'm not going to wait half an hour to get a preview finished, but my two cents would be to have the compute terrain go into the heightfield generate node.


Tangled-Universe

Aha...
So I started with a default scene and loaded the image, set it to spherical projection and set displacement to 100000 (yes 100km).
The area around the origin (coordinates 0,0,0, where your heightfield is configured to be) is completely flat.

If I rebuild your scene from scratch it is blazing fast, so I would really like to urge you to do that as well.
It's probably because you have been tinkering with the planet's position and radius and what not why your scene is so hogging.
I wonder why on earth someone wants to play with those values, but anyway, the fix is easy.

djwhitehart

#3
Quote from: Tangled-Universe on September 02, 2017, 04:58:48 AM
Aha...
So I started with a default scene and loaded the image, set it to spherical projection and set displacement to 100000 (yes 100km).
The area around the origin (coordinates 0,0,0, where your heightfield is configured to be) is completely flat.
That's why I had rotated the planet to put my area of interest exactly at the origin. My attempts to position the heightfield using converted spherical coordinates and copy/pasting the coordinates of a specific point (while keeping the planet in its default orientation) never seemed to work; I could never see the bounding box. The one time that generating the heghtfield did anything, it took an absurdly long time to generate just 60% of the heightfield (at which point I aborted the process), and the portion of the heightfield it did generate looked nothing like it should have.

EDIT: After trying this method again with a lower-resolution heightfield, I found that it was, in fact, my area of interest. However, the generated heightfield looked like it had been "squashed" north-south, as if it were in equirectangular projection instead of a less-distorted one. That's easy to correct in another program, however, so it doesn't bother me too much.

Quote from: Tangled-Universe on September 02, 2017, 04:58:48 AM
If I rebuild your scene from scratch it is blazing fast, so I would really like to urge you to do that as well.
It's probably because you have been tinkering with the planet's position and radius and what not why your scene is so hogging.
I wonder why on earth someone wants to play with those values, but anyway, the fix is easy.
I changed the default radius and position of the planet to match the radius of the planet it represents (which I calculated elsewhere), while keeping the North Pole at the origin.
I don't see why changing the planet's size/position would have such a drastic effect on speed, but I'll try rebuilding the scene from scratch, just to see what happens.

Tangled-Universe

Oh yes I definitely agree why changing those settings should affect performance!
I meant why one would want to change those, even if you want to 'match' a described radius.
Unless you need *real* scale it would make sense, but I haven't heard before so far that someone really needed to have the scale accurate for this type of shots.

Anyway, it's a bit unclear to me now if it is working for you now, or not?

If the exported area is very large you may have the planet's curvature being at play as well.
If you load the heightfield into the shader you can change this behaviour using the "flattten first" options, but right now I can't tell you which does what exactly, but it's quick to check and find out.

djwhitehart

Quote from: Tangled-Universe on September 03, 2017, 04:55:49 PM
Oh yes I definitely agree why changing those settings should affect performance!
I meant why one would want to change those, even if you want to 'match' a described radius.
Unless you need *real* scale it would make sense, but I haven't heard before so far that someone really needed to have the scale accurate for this type of shots.

It may not be clear from my post, but I was actually disagreeing about planet size/position affecting performance. That argument doesn't make sense to me. I'm more inclined to believe it was my use of two alpine fractals, one of which applies to most of the planet's land area, that was slowing performance down so much. Even deleting the fractal I didn't need for this heightfield had no noticeable effect on performance, so I may try masking the remaining one with a SSS to restrict it to my area of interest and environs.

Quote from: Tangled-Universe on September 03, 2017, 04:55:49 PM
Anyway, it's a bit unclear to me now if it is working for you now, or not?

I've just gotten it to work. The squashing effect I mentioned in my last post confused me until I remembered that heightfields are sampled on a plane at y=0, so any area that's d degrees from the apex will be squashed by cos(d) - easy enough to fix in Photoshop or any other program. The main issues I faced were the aforementioned sluggishness of the HF generation and the lack of a visible bounding box, which forced me to generate a larger HF than I needed after blindly copy/pasting coordinates for the HF center. I could see the bounding box when I was looking at the planet's apex, so I imagine it was staying on the HF evaluation plane.

Anyway, thanks for your help!

digitalguru

#6
This is another example where you can use this method to generate your height field:

http://www.planetside.co.uk/forums/index.php/topic,21311.0.html

The advantage here is that you can set up an orthographic camera anywhere you like to sample the environment. This was written for the generation of a vector displacement map which can represent all axes of displacement, but with modification of the map can be used to generate height fields as well. 

The logical thing to do would be to replace the displacement to vector shader with a displacement to scalar shader as you only need a single value (the Y or vertical displacement), but I think there's a bug in Terragen (version 3) which renders incorrectly, so the workaround would be to render the vector version then copy the green channel to red and blue in an external paint program. (There might even be some combination of nodes in Terragen to do this internally).

Then, depending on your intended use of the height field, you can convert to map produced by this method into a height field . I use World Machine to convert a .tif file into a .ter file for Terragen. The freebie program TerraConv could also be used.

If you intend to bring the height field back into Terragen (for instance to "bake" out a processor intensive Alpine terrain) then the displacement map can just be brought back into Terrain to create a displaced terrain.

p.s This method tests the displacement against the planet node, so planet curvature is taken into consideration.