Use Z for altitude

Started by feeder1803, March 29, 2011, 03:33:20 AM

Previous topic - Next topic

feeder1803

Hi, I'm new in Terragen 2 and I am having a little bit of trouble when applying a shader. In my project I have imported a .ter file that I got from the web. The landscape is basically a mountain (the K2). My problem is that the real altitude is in z axis but I can't find the way to apply a snow shader for it because it uses the Y axis.

How can I solve it?

freelancah

#1
I'm assuming you're using a surface layer to mask your snow. Do you have "Use Y for altitude checked?" You should disable it if you do

edit: and the same thing for slope depending on what you want..

feeder1803

Hi, checking or unchecking the Y altitude checkbox doesn't work. I attach my project with the .ter and .tgd files. It is very simple...if you could figute out what's the problem I'll be grateful!

freelancah

Quote from: feeder1803 on March 29, 2011, 09:14:17 AM
Hi, checking or unchecking the Y altitude checkbox doesn't work. I attach my project with the .ter and .tgd files. It is very simple...if you could figute out what's the problem I'll be grateful!

I cant open any terragen files atm but I'l try to remember once I get home..

feeder1803


choronr

A few years ago, I got this tip from 'Oshyan' regarding the issue; hope this helps:

"TG to TG2 CAMERA POV SETTINGS (from TG 0.09)
There are a number of possible explanations for this. Due to some UI issues TG2 and differences between it and TG 0.9, there are some easy to make mistakes that would definitely result in major differences.

First, the use of coordinates in TG2 and TG 0.9 is a bit different, and to add to the confusion in TG2 the coordinates are sometimes not labeled, as in the Camera node. In TG 0.9 Z is "up" (perpendicular to the terrain). In TG2 Y is "up". So you basically just have to switch the Z and Y values when copying between the two. The order they're listed in is the same, X, Y, Z (even though they're not labeled), so just put the Z value into the Y slot. This is the most likely source of your problem.

The scale is another thing that could get confused. If TG 0.9 is set to work in meters, as it is by default, then the scales should match as TG2 respects the scale definitions in .ter files. However if TG 0.9 was set to measure in Terrain Units, then it won't match up. There are radio buttons in the Rendering Control dialog to the right of the "camera" title which control the measurement mode. You can also tell what mode it's in by looking at the numbers for the camera placement - if they end in "m" (e.g. 3900.m) then it's in meters mode (as it needs to be to accurately translate position). Switch to Meters mode if it's in Terrain Units.

Last and least likely is that TG 0.9 wasn't operating on a full globe, it was just a finite, rectangular terrain, so depending on how you're positioning your loaded heightfield (at default 0.0 with left position, or at center position, etc.) the positioning might be offset. What you want is Left Position and 0.0 in the Heightfield Shader.

Also note that the camera in TG2 has no Target, so you'll need to use the Rotation settings. The "Head" coordinate (first on the left in TG 0.9) corresponds to the 2nd Rotation coordinate in TG2. "Pitch" corresponds to the 1st coordinate and so Bank of course corresponds to the last one.

I think one of those should explain and help you resolve your problem."

feeder1803

Thanks for the reply, though I think it won't work with my problem because I am not switching or copying files from TG to TG2. I will explain what I have done step by step:

1. I have to make a Terragen 2 render that resembles a photograph of the K2 mountain.
2. I found a website were I got a .hgt file that represents the terrain.
3. I opened the .hgt file with 3DEM and I exported the piece of the terrain that I wanted to a .ter Terragen file.
4. I opened TG2 and I used the .ter file from the previous step to get the terrain.
5. Later I downloaded a snow shader from the web.
6. When I tried to apply the shader I found out that the real height of the terrain was using the Z axis instead of Y so if I try to apply the shader with altitude contraints instead of taking into account the real height it uses the Y coordenate of the image and I get a uniform line of snow...

So I don't know where to switch the X and Y coordinates...I attach the .rar file again for anybody that wants to try and solve it. I would really appreciate it.

Thank you for your help!

Matt

Quote from: feeder1803 on March 29, 2011, 02:23:23 PM
6. When I tried to apply the shader I found out that the real height of the terrain was using the Z axis instead of Y so if I try to apply the shader with altitude contraints instead of taking into account the real height it uses the Y coordenate of the image and I get a uniform line of snow...

I am not sure what you mean when you say that the real height of the terrain was using the Z axis. Can you explain it in a different way? Is it because the heightfield is located on a different part of the planet, away from the usual 0, 0, 0 position?

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

Hetzen

I had a look at your tgd file, and found nothing wrong with it. TG coordinates work in x left right, z forward backwards and y for up down. It doesn't matter how your heightfield was generated. Y is always up down when you work in TG at near to 0,0,0 on a sphere (the planet).

Try setting your lower limit in your surface node to say 4000. You'll see snow only appear above 4000m. Also to note, there is a slope dependency in that surface layer node, which only applies snow to a maximum angle on your mountain. If you turn that off, you'll see snow all over your mountain.

feeder1803

I don't think you understand the problem. Here is a photo of my render with a minimum altitude limit of 3000 for the snow:



The point coordinates:

red:   x: 7841
   y: 3002
   z: 5131
   
blue: x: 6129
   y: 3001
   z: 3186

As you can see by the z coordinate, the real height of the two points is different as it should be but Y axis is the same and that's why the shader appears to have a straight line limit. What I want is to make a shader that looks like this photograph:




Thanks!

Hetzen

#10
Z is not the height here. Y is. Altitude is the distance above the surface of your planet.

Z here is forward and backwards. Not up down.

If you want to modulate the y/altitude limit in a surface layer, then use the surface layer to output black and white only, then feed that into a powerfractal to modulate that black and white mask with a warper, then use that to blend another surface layer with your snow texture.

I've attached a clip file (file/insert clip file) that will load a replacement for your Thick Snow_1 node.

The thing to do with this is to play around with the PF scales and the displacement amplitude.

freelancah

I checked the file too. This K2 is not georeferenced. If you zoom out you notice your mountain is in the pole of the planet. Also there's a bunch of nodes that dont do anything because they arent connected. Since the thing is in the pole your Y value represents the height most accurately here..

Hetzen

I've attached a tgc file to my last post for you to look at.

Hetzen

I've re-done this and taken out the intersect underlying so that it's clear what's happening here.

The thick "snow_1 replacment" replaces your node of similar name.
"PF - Scale - Disp Amp" is a power fractal (PF) that you use to warp the colour space that is coming out of "SL - Altitude Base Line", which is where you set your altitude snow line.
This creates a mask that we plug into the blending input of the "Thick Snow..." node, switch the "blend by shader" on and off to see what's happening.

If you go to the PF in this clip and turn the Displacement amplitude down to 0, you'll see a flat line at 3500m (which is the limit I've set up in the SL). By playing with the scale in the PF, you'll be able to play around with how you distort the snow line. You can also add more PFs that link into each other to add more variation if you wanted.

Dune

Interesting technique, Jon, haven't thought of that before. Might be useful. Thanks.