Matching 3ds max camera/terrain to Terragen 4

Started by wubba, July 28, 2018, 05:31:59 AM

Previous topic - Next topic

Kadri

#30
Quote from: wubba on July 30, 2018, 10:23:02 AM
...
Not exactly sure on the metres... Could it be the 'Terrain Real Width'?
[attachimg=1]

Just curious.
If this is for Unity and game oriented you might get a resolution depending image that takes the camera position in account too. I use neither programs so i am not sure.

There is a "Detail Distance" parameter there in your image for example.
It is 100 so maybe already at  full percent (still place to go on the right side of the slider) but just in case.

digitalguru

got it :-)

in the Raw options in Photoshop set channel to 1 and the other options like this:
[attachimg=1]

and the image imports correctly:
[attachimg=2]

change mode to RGB color and export to OpenEXR

attached a Terragen project file - import the full rez open exr and check it out.


KlausK

Thanks, digitalguru. Gonna have to try this.

Btw. your scene file crashes my TG 4.1.25 installation immediately.
On startup I see the Network window with the Notes then before the gui is build completely it crashes.
Could it be that 4.2.x.x files not backward compatible?
CHeers, Klaus
/ ASUS WS Mainboard / Dual XEON E5-2640v3 / 64GB RAM / NVIDIA GeForce GTX 1070 TI / Win7 Ultimate . . . still (||-:-||)

digitalguru

QuoteCould it be that 4.2.x.x files not backward compatible?

probably doesn't help, but it seems that when Terragen can't find the heightfield exr it crashes - made a 4.1 scene file also

I've uploaded the exr file to Dropbox, just put it in the same folder you launch the scene from.
https://www.dropbox.com/s/i8mz9euc4o03ha0/heightmap4k%20unity_32bit_pshop.exr?dl=0

Alternatively, you can edit the project file in a text editor and insert the name of your file there

search for:
name = "Heightfield load 01"

then insert the name of the file in the quotes next to file name i.e:

   <heightfield_load
      name = "Heightfield load 01"
      gui_use_node_pos = "1"
      gui_node_pos = "-920 1140 0"
      gui_group = "Terrain"
      input_node = ""
      read_from_file = "1"
      filename = "heightmap4k unity_32bit_exrio.exr"



KlausK

Thank you very much.
You are right , it is because I did not have the *.exr and the scene file in the same location.
Now the 4_2 file opens fine (complaining about some new features missing, of course) with all the files together in place.
I would have thought it would simply complain about the missing file.
On the other hand deleting the Fractal Terrain node set from a default scene also crashes TG.
Perhaps the Compute Terrain node suddenly has nothing to compute anymore.

Anyways, gonna take a look at your notes now.
CHeers, Klaus

/ ASUS WS Mainboard / Dual XEON E5-2640v3 / 64GB RAM / NVIDIA GeForce GTX 1070 TI / Win7 Ultimate . . . still (||-:-||)

digitalguru

#35
There's a Terragen 4.1 project file attached to the previous post :-)

The heightfield file load has a recent addition of a file refresh option, probably a new bug.

QuoteOn the other hand deleting the Fractal Terrain node set from a default scene also crashes TG.

Yes, that happens to me sometimes


wubba

#36
Quote from: Kadri on July 30, 2018, 11:16:33 AM
There is a "Detail Distance" parameter there in your image for example.
It is 100 so maybe already at  full percent (still place to go on the right side of the slider) but just in case.
Good morning! :D .... Yes I will give that a shot and see what difference that makes..

Quote from: digitalguru on July 30, 2018, 12:48:45 PM
got it :-)

in the Raw options in Photoshop set channel to 1 and the other options like this and the image imports correctly:
change mode to RGB color and export to OpenEXR

attached a Terragen project file - import the full rez open exr and check it out.
Ahh!..don't think I changed the channel setting, Will try that! ... Thank you for your efforts digitalguru!!!.. I'm not at the computer to test this but dare I ask.. does importing the 4k openexr into Terragen improve/remove the stair artefacts??

As importing the 4k tiff16 from Lightroom didn't make any difference compared to 2k tiff16 I downsized (other than scale)
What don't kill you only makes you stranger.


wubba

Quote from: digitalguru on July 30, 2018, 07:25:16 PM
Yes it does :)
Sweet!  ;D Look forward to testing it out!! Just want to move on & complete this scene!!!
What don't kill you only makes you stranger.

wubba

#39
Man this is wrecking my head! :S ... I got the .exr exported so thanks for that digitalguru but concerning the last 2 .tgd files you uploaded.. They open fine (except the 2nd one which seems to load fine but gives errors), though the minute I attempt replicate your stack in Terragen, it displays the .exr heightmap correctly in the 'Heightfield load' sub-level (small Preview window) but displays like a flat bed in the render/camera preview!?
I swear I've copied the settings note for note so is it just me or a version issue?..I also loaded your .exr into my replicated stack and did the same!?...

What don't kill you only makes you stranger.

wubba

I got it working! :D (Nevermind;).. Ooh Yeah!! converting to .exr REALLY makes the difference!!!

Thanks again digitalguru  :)

[attachimg=1]
What don't kill you only makes you stranger.

digitalguru

Nice. Glad it worked out  :)

QuoteThey open fine (except the 2nd one which seems to load fine but gives errors)

The second .tgd was created in Terragen 4.2 08 (Frontier build) so the errors are probably just the differences in versions

Quotedisplays like a flatbed in the render/camera preview!

I'm guessing the vertical scale wasn't set up in that example. I like the way Terragen uses Open Exr in that it stores the height value properly and you don't have to work out a multiplier for the height. Hopefully, OpenExr will become a standard for all these types of programs soon.

wubba

#42
Quote from: digitalguru on July 31, 2018, 04:11:29 AM
I like the way Terragen uses Open Exr in that it stores the height value properly and you don't have to work out a multiplier for the height.

Still have issues with the height value whether it be the height map or camera...  This time in Max I imported a 2049x2049 (full resolution) .obj from UnityWC2 (500mb!.. autosave takes forever!!).. UWC2, units are set to 'metres'
[attach=1]
Inside Max, the units are also set to 'metres'
[attach=2]
When I import the .obj, It is set it to convert to metres as 'current' is greyed out & set to centimetres for default!?  ???
Once the .obj is imported into Max, these are its 'Object Properties'
[attach=3]
And the 'Absolute World' position..
[attach=4]

So to give you an idea of where the camera path begins relative to the landscape mesh in Max
[attachimg=5]

& inside Terragen, imported .exr heightmap & .fbx camera animation from Max with 'correct' settings applied?..
[attachimg=6]

I have added a second 'Heightfield Adjust Vertical' into the stack, increasing the Z position (NOT the heightmap peaks) but I have no idea what to set it to now!?
(Max's Absolute World Z: 124.379 goes way under heightmap!?)..

I need it to be exactly equal to Max otherwise my palms wont sync!?...
[attachimg=7]


***In UWC2, the 'Real Terrain Height' is set to 300, but doesn't get equally translated to the .obj export!? inside Max's Object Properties (X:2048 Y:2048 Z:248.773)!??
What don't kill you only makes you stranger.

wubba

#43
.
What don't kill you only makes you stranger.

digitalguru

#44
it's a bit of a minefield isn't it?

I don't have World creator or use 3ds max - so I'm just guessing here,

Quote***In UWC2, the 'Real Terrain Height' is set to 300, but doesn't get equally translated to the .obj export!? inside Max's Object Properties (X:2048 Y:2048 Z:248.773)!??

I would say the Real Terrain Height is a kind of end stop in WC2, and the actual max height as defined by the fractal generator is actually 248.773

So this could be the yardstick by which you figure out the correct scaling for your heightmaps.

For example, if I'd generated a similar terrain in World Machine (x 2048 by Y 2048 with a height of 248.773) and I'd exported a .ter file then I'd expect the brightest pixel to be 248.773 (and it is)

If the raw map is normalized ( darkest pixel is 0 and the brightest pixel is 1), the conversion is simple, since you know the actual height is 248.773 then use that as a height multiplier in Terragen.

Things get a bit murkier with the raw files out of your WC2. In the file you posted the brightest pixel was 0.722329 ( not 1.00) so you would:

248.773 divided by 0.722329 = 344.4040042695226 (to be exact  :) )

This is what I had to do when I rendered a raw32 map out of World Machine. This might be a similar situation in World Creator.

I used a tool in Nuke (curve tool) to figure out the brightest pixel in the raw file, if you don't have Nuke that might be tricker - I haven't seen any other program that does that.

If the file you posted is the file you're using, then 344.4040042695226 is the multiplier to use.

You would then use that value in Terragen.
Load the heightfield.
Insert a Heightfield resize - check Re-size in meters and set the x y size of your terrain in meters - 2048*2048
Insert a Heightfield adjust vertical - check Multiply height by  - and enter  344.4040042695226

If you're using a different map - you'll have to figure out the brightest pixel manually - or if you're in a jam, send me the file and I'll give you the value.

This worked for me - but bear in mind I'm using a different program to generate the raw file, it might work for you.