Offset .Ter created from Procedural terrain

Started by VisMod, October 21, 2013, 10:18:56 PM

Previous topic - Next topic

VisMod

So ...

What I'm *really* after is a .exr file of any area I wish to nominate on a (procedurally displaced) terrain
- accepted solution: plug it in to a Heightfield Gen node, click Generate, right-click on Gen node -> save file as (either .ter or .exr)

However, the further away from 0,0,0 the Heightfield Gen node is placed, the greater the differences between the procedural terrain and what gets generated.
- e.g. #1 - default TG2 scene:
         - add default power fractal, then in nodes panel plug it in to default Heightfield Gen node ("Shader") and click Generate
         - add camera at 5000, 10000, 5000 pointing straight down, set to ortho @ 10,000x10,000, add Micro Exporter and render
            to generate terrainFromHtf.lwo
         - now plug power fractal terrain straight in to "Computer Terrain", change Micro Exporter save filename and render
            to generate terrainFromProc.lwo
         - a comparison of terrainFromHtf.lwo with terrainFromProc.lwo show that the further away from 0,0,0 the geometry
            gets, the greater the discrepancy ...
- e.g. #2 - greater distance offset:
         - set up a similar project to above, but make the heightfield box smaller @ 1000x1000m, again 1000x1000 points
         - set the heightfield shader position to 20,000x20,000
         - set the heightfield Generate position (Use Shader Tab) also to 20,000x20,000
         - once more create a Camera setup in the center of this to export geometry via Micro Exporter
         - now render & save exports to different filenames as per first example
         - open resulting files and compare ... huge differences

What I suspect is that the heightfield is generating in flat earth coordinates, whereas the procedural terrain is spherically generated.

However, THE output I am ultimately after is a .exr file accurate to TG2 procedural terrain (read NO differences), to be used as a displacement map in another 3D app to aid scene correlation.

Is this a can do via some other means?

Cheers & thanks in advance





























Matt

#1
The values baked into the heightfield are altitude (displacement from the planet sphere), not worldspace Y, so if your goal is to apply this to some geometry in another 3D application you'll need that geometry to be a curved surface.

When you exported your first LWO from the heightfield, I take it that you used a Heightfield Shader. On the Heightfield Shader there's a checkbox called "Flatten surface first". This prevents the heightfield from following the curvature of the Earth. If you uncheck this, the procedural terrain and the heightfield should be similar.

Matt
Just because milk is white doesn't mean that clouds are made of milk.

VisMod

Hi Matt

Thanks for following this up.

The end result, even with the "Flatten Surface First" set to off is the same - the further away from position 0,0 the greater the generated mesh differences.

I have done some more digging since my first post, and I believe others have run into this issue in various ways as well. What we're looking for is not some means for dragging assets out of TG to render elsewhere ... there's no point, as TG does what it does so well.

What I am looking for specifically is a means of telling my vehicle *exactly* where terrain is via an EXR displacement map taken straight out of TG, and one which matches *exactly* TG's terrain ... allowing me to do the whole front projection thing with renders out of TG, and knowing my 3D is going to match TG perfectly. Yes I could do this via collision detection over Micro Exporter geometry - it just takes years to calc, even on a powerhouse machine, which makes it suck for speedy development.

What I could really use is an upgraded "Micro Exporter" that wrote out exactly the same camera-view-dependant data as it does right now except in .EXR format. All the coding for the exporter exists, it just needs the EXR writer code plugged in ...

Cheers and thanks again.

PS If this is "the" Matt of TG fame, then it has been many years since we have exchanged any correspondence - I even recall flicking some details your way about Animatek World Builder :-) , but that must have been 100 years ago!








Matt

#3
Hi,

Quote from: VisMod on October 22, 2013, 04:30:07 AM
The end result, even with the "Flatten Surface First" set to off is the same - the further away from position 0,0 the greater the generated mesh differences.

I have done some more digging since my first post, and I believe others have run into this issue in various ways as well. What we're looking for is not some means for dragging assets out of TG to render elsewhere ... there's no point, as TG does what it does so well.

What I am looking for specifically is a means of telling my vehicle *exactly* where terrain is via an EXR displacement map taken straight out of TG, and one which matches *exactly* TG's terrain ... allowing me to do the whole front projection thing with renders out of TG, and knowing my 3D is going to match TG perfectly.

I've tested it again and found the same thing you did. The heightfield is generated by sampling the procedural terrain on a plane, which has 3D texture coordinates that are different from the curved planet. I can I see two ways you could work around this problem.

A) Replace the planet with a plane. On the original planet, disable "render surface" so that you can still render the atmosphere, but connect your terrain shaders to the plane to render the terrain. A Terragen plane with a procedural displacement should render similarly to a plane displaced with the exported EXR. Just make sure the Y coordinate of the plane is 0.

or

B) Generate the EXR displacement map the old fashioned way by rendering an orthographic view of the terrain with a black-to-white gradient mapped to the Y coordinate of the surface. To do this in Terragen, put a Default Shader as the very last shader on your planet, set its diffuse colour to 0, luminosity to 1, and assign a "Get Position" node to the luminosity function. The Y value of the surface will be rendered into the green channel. To make it greyscale, insert a "Y to Scalar" node after the "Get Position" node.

Try this:


<terragen_clip>
<y_to_scalar
name = "Y to scalar 01"
gui_use_node_pos = "1"
gui_node_pos = "2840 -1260 0"
gui_group = ""
enable = "1"
input_node = "/Get position 02"
gui_use_preview_patch_size = "0"
gui_preview_patch_size = "1000 1000"
>
</y_to_scalar>
<get_position
name = "Get position 02"
gui_use_node_pos = "1"
gui_node_pos = "2840 -1200 0"
gui_group = ""
enable = "1"
input_node = ""
gui_use_preview_patch_size = "0"
gui_preview_patch_size = "1000 1000"
>
</get_position>
<default_shader
name = "Default shader 05"
gui_use_node_pos = "1"
gui_node_pos = "2700 -1340 0"
gui_group = ""
enable = "1"
input_node = ""
gui_use_preview_patch_size = "0"
gui_preview_patch_size = "1000 1000"
diffuse_colour = "0 0 0"
colour_image = ""
colour_function = ""
translucency = "0 0 0"
translucency_image = ""
translucency_function = ""
luminosity = "1 1 1"
luminosity_image = ""
luminosity_function = "Y to scalar 01"
reflectivity = "0 0 0"
reflectivity_image = ""
reflectivity_function = ""
reflection_tint = "1 1 1"
index_of_refraction = "1.5"
specular_roughness = "0.2"
specular_roughness_image = ""
invert_specular_roughness_image = "0"
specular_roughness_function = ""
displacement_direction = "1"
displacement_multiplier = "0.01"
displacement_image = ""
displacement_function = ""
displacement_offset = "0"
opacity = "1 1 1"
opacity_image = ""
use_alpha_channel = "0"
invert_opacity_image = "0"
opacity_function = ""
alpha_from_colour = "0"
alpha_key = "0 0 0"
key_tolerance = "0.1"
image_projection = "4"
projection_camera = ""
unpremultiply_colour = "1"
unpremultiply_translucency = "0"
unpremultiply_luminosity = "0"
unpremultiply_reflectivity = "0"
unpremultiply_specular_roughness = "0"
>
</default_shader>
</terragen_clip>


And turn off all lights to make it render faster.

Most of the pixels will appear brighter than white in the Render View because the values are in metres, but the data should still be there to work as a displacement map in another app. You should be able to see the data if you expose it down a few stops in Photoshop or Nuke.

Quote
What I could really use is an upgraded "Micro Exporter" that wrote out exactly the same camera-view-dependant data as it does right now except in .EXR format. All the coding for the exporter exists, it just needs the EXR writer code plugged in ...

The Micro Exporter exports geometry. If it were to export the displacement as an EXR then I think you need to have some geometry with UVs to map that EXR onto. But since it's view-dependent, I'm not sure what the exported geometry should be. Because it's view-dependent it's not going to be some simple geometry like a quad. Or are you talking about encoding the XYZ into each pixel of the EXR? You could get that by writing out the SurfPos render element, and I guess it could be useful to export this directly from the Micro Exporter node. But wouldn't you still need to generate geometry from that in your external app?

Quote
PS If this is "the" Matt of TG fame, then it has been many years since we have exchanged any correspondence - I even recall flicking some details your way about Animatek World Builder :-) , but that must have been 100 years ago!

Yes, I suppose that must be me :)

Matt
Just because milk is white doesn't mean that clouds are made of milk.