Displacement from image issues

Started by ajcgi, March 23, 2011, 10:21:08 AM

Previous topic - Next topic

ajcgi

Hey all,

I have 2 issues today.

1) Having an issue with an sgi file I'm using to create much of the displacement in my scene. It's a 16-bit sgi file, 4096x4096.
The scene loads, and comes up with an error that says 'ReadImage: Unable to load image: *image location*' This goes away if I go into my image map shader, select the path, alter the name of the file then change it back again. Then the sgi loads and weee! Realistic terrain ahoy.
Small problem is that this isn't a solution once it goes onto our render farm as the nodes pick the file up, open it up, happily ignore the sgi file and render the frames minus displacement.
Is there a work around for this issue? I need it to be 16-bit I was getting stepping on 8. It needs to be this large in pixels as it's a 40km wide shot and lower resolutions weren't introducing the detail needed. Any other formats are requesting to be converted to sgi and a cursory look around the forum suggests this is a normal thing.

2) When exporting my camera data, and indeed any objects out of softimage into terragen, they come in at the correct location, move the correct way and so on, but the terrain is lower than my terrain in softimage. I've checked this using stills of my soft scene and tg2 scene with test objects in place. The objects line up... the landscape doesn't. I've tried many times today exporting the terrain out of TG2 and seeing if it magically lowers itself in Softimage, but to no avail.
I'm thinking this might be to do with the terrain generate node I'm using to get the terrain out of TG2. I'm saving it out as a .ter file, then importing that into Softimage using the import elevation dataset plugin.
All my displacement occurs before the heightfield generate node, but somehow it comes into Softimage slightly taller than I'd like.
If there's no solution to this, I may have to fake it by scaling the object down, but I'd prefer it to be accurate. I don't want a hint of floating between softimage and the tg2 content.

I've attached the tgd, even though it refers to multiple images here that are way too large to upload.
Anybody got any clues how i can resolve my loading issue or heightfield issue?

dandelO

#1
Hi. I notice that the .sgi image map shader seems to be the only one without the 'textures/' location prefix in the filename.
Is it still in the same location as the .tgd, like I assume it was when the project was saved(otherwise the entire filepath would be visible from the .tgd location onwards)?
I just tested with an image map shader here and, as with an object, image maps only seem to require the filename as long as they are in the same directory as the .tgd. Perhaps you've moved the image to a new location and it's not in the same directory as the project file anymore? Just a thought.

*I didn't use an .sgi image to test the IMS', maybe there's a problem with that type of file? The rest of yours appear to be .tif, have you tried converting the .sgi to another format? Otherwise, sorry, that's all I can think of at the moment.

ajcgi

I moved the sgi out of the textures folder as it was the only problem child. Was just testing if the farm machines preferred it that way or something.
SGI is the only 16-bit format that TG2 will let me use for displacement. Otherwise it brings up the error mentioned in my post.

ajcgi

Turns out the .ter is exported as though the landscape is flat, whereas I had my TG2 heightfield set as though curving over the planet. Damn. Have fixed to flatten surface first.
Temporarily using a 8-bit SGI for now. Must've got something wrong before as no longer getting stepping in my displacement now.
So now stuff lines up a heck of a lot better AND loads on the render farm. Just got a detail issue in my mesh. Will resolve it Monday.
Happy beer everybody!

Matt

#4
The Image Map Shader and the Heightfield Load can also read EXR files (I think both 16 and 32-bit), and 16-bit TIFF files.
Just because milk is white doesn't mean that clouds are made of milk.

D.A. Bentley (SuddenPlanet)

#5
Quote from: Matt on March 26, 2011, 01:58:44 AM
The Image Map Shader and the Heightfield Load can also read EXR files (I think both 16 and 32-bit), and 16-bit TIFF files.

I'm having issues trying to load 32-bit Terrains in EXR and TIFF format.  Both formats load in and display the heighmap in the Shader Preview, but the displacement doesn't happen in the 3D Window (I just get a flat Square).  If I crunch the image down to 16-bit, save as Tiff in Photoshop and load it then it does work.  I can't save 16-bit EXRs from PS so can't test that.

Mainly I would like to use the 32-bit EXR exports from Gaea as heightfields in Terragen without reducing them down to 16-bit.

Any ideas?

Derek

D.A. Bentley (SuddenPlanet)

OK I figured out a work around.  For some reason for 32-bit EXR files to work you have to increase the displacement Height Multiplier to a whopping 1000.  :)


Oshyan

The Displacement of EXR (and any incoming file without georef/height information) is assumed to be 0-1, in meters.

- Oshyan

Matt

Quote from: Oshyan on April 13, 2018, 08:52:09 PM
The Displacement of EXR (and any incoming file without georef/height information) is assumed to be 0-1, in meters.

- Oshyan

Actually it simply reads the pixel value in the EXR and that is the height in meters. The range you get will depend on what the exporting software writes into the image. Terragen's choices might be different from those of Gaea. I would encourage Dax to consider using the same mapping that Terragen does (pixel value = height in meters), because it eliminates the need to manually enter a scaling factor on a case by case basis.

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

Oshyan

Oh right, my bad. And yes, there is an argument to be made for the scaling to work the way Terragen assumes it to, since EXR otherwise has no scaling info in it.

- Oshyan

WAS

Curious what the manual information of this is. What is the contrast scale of a pixel to meter ratio, in general for Terragen in the event of other formatted image maps.

Oshyan

Not sure I understand your meaning, but in EXR you can literally encode numeric values, like 1000 (which Terragen would interpret as 1000 meters, I believe). So when TG exports an EXR, it will record values into it that correspond to the height of the exported terrain in meters. When it imports, it interprets incoming data in the same way.

- Oshyan

WAS

#12
Oh I see. That's handy. What I mean is you can supply other image formats, where TG interprets colour contrast as displacement, but the multiplier must usually be upped. Wondering what the actual scale is for a pixel with no information based on it's black to white contrast.

For example using the same style color picker in PS I can clamp a images contrast per pixel.

digitalguru

#13
Quotewhere TG interprets colour contrast as displacement, but the multiplier must usually be upped.

I think I see what you mean (but correct me if I'm wrong  :))

It sounds like you're looking at a map that may be normalised - that is, all the values are between 0 and 1 and it's only the contrast between those values that give you a sense of the displacement from the original terrain. You then need to add a multiplier to "expand" those values so the displaced terrain matches the original.  This is very arbitrary though, and prone to errors.

This is why OpenExr is the way to go when using images for displacement and height-fields - the pixel value corresponds directly to height of displacement - a pixel value of 150.675 will displace to 150.675 metres in Terragen. Though  a common mistake is to not match the area covered by the displacement image - that is. if your displacement map is generated from a terrain 1000 metres square, then it must be mapped to the same size area in Terragen (or whatever software) for the ratio of height to width to be correct.

Another reason why OpenExr is a good idea to use is that, in the main, it is saved as linear data - most software (can't speak for Softimage, though I would hope it would) would read and write an OpenExr and not apply any gamma correction to it - if it did, your height data will change - it must be interpreted linearly.

WAS

Quote from: digitalguru on April 17, 2018, 07:41:23 AM
Quotewhere TG interprets colour contrast as displacement, but the multiplier must usually be upped.

I think I see what you mean (but correct me if I'm wrong  :))

It sounds like you're looking at a map that may be normalised - that is, all the values are between 0 and 1 and it's only the contrast between those values that give you a sense of the displacement from the original terrain. You then need to add a multiplier to "expand" those values so the displaced terrain matches the original.  This is very arbitrary though, and prone to errors.

This is why OpenExr is the way to go when using images for displacement and height-fields - the pixel value corresponds directly to height of displacement - a pixel value of 150.675 will displace to 150.675 metres in Terragen. Though  a common mistake is to not match the area covered by the displacement image - that is. if your displacement map is generated from a terrain 1000 metres square, then it must be mapped to the same size area in Terragen (or whatever software) for the ratio of height to width to be correct.

Another reason why OpenExr is a good idea to use is that, in the main, it is saved as linear data - most software (can't speak for Softimage, though I would hope it would) would read and write an OpenExr and not apply any gamma correction to it - if it did, your height data will change - it must be interpreted linearly.

Photoshop can't read EXR data appropriately without a plugin, that's for sure, though I did find this that can both read, and write OpenEXR format all in PS.

https://www.exr-io.com/