Imported heightmap has different shape from original object

[Moonwards]

We thought this might be an issue with how we created the heightmap from the Blender file we want to copy, but after trying it three different ways and talking it over, I wonder if the add-on has interpreted the heightmap in some way that changes the shape produced. There are a bunch of differences between the mesh produced in Godot and the original object in Blender.

This is the heightmap being used

And now i've used that with a displacement modifier on a subdivided plane in Blender 2.8 to check that the heightmap is accurate. There, it will accurately recreate the original object.

[Zylann]

Can you better explain which difference there is? The screenshots obviously show some differences if taken litterally, but I don't understand what is the nature of that difference.

The plugin doesn't interpret image pixels in any way. It takes the values as they are. If the image is 8-bit, values can be remapped, but that mapping remains linear.

My only guess so far is that Blender ran this in a different color space, like sRGB. In fact, I had the opposite problem: I once exported an EXR from Godot using the plugin so I could do a Cycles render of it from Blender. But in Blender, the result ended up different, very likely due to some color space transformation that had NOTHING to do here. So what I did was to make sure that NO color space information gets in the way (in my case I think it got embedded by Gimp, which I had to use for some intermediary processing), because color management is completely useless for terrain data.

You can check if that's the case by modeling a perfectly straight slope in Blender, export it as a heightmap image, and look at a slice of the values from within an image editor. Make sure to look at the REAL values in the image file, without any color space transformation. If pixel values show a straight curve, you're good. If you see a curved slope, Blender screwed up.

[Moonwards]

This is the node setup used in blender to create that heightmap. I keep looking at it, and it really seems like it should create 309 shades of grey between black and white with that setup. I'm doing what you suggest now but wanted to show the nodes.

[Zylann]

Yeah, it's likely that color space transformation was applied if you output your values to a surface port, which is supposed to be a color.

[Moonwards]

Pretty much what you predicted. The histogram on the right is of the render from the file on the left in GIMP.

I'm talking to someone and i'm about to ask about it on Blender.SE. Maybe they have an idea of how to correct for it. I don't know how i'm going to export it without using a material output node, so the algorithm seems like it will need to be compensated for or undone.

[Zylann]

Maybe fiddling with options here could help?

[Moonwards]

Here is a file from TheDuriel that has that adjusted for this sort of situation (Standard in the View Transform field instead of Filmic, ) and a node setup for the heightmap generation that adjusts the grayscale. It is an improvement but there are still problems.

Duriel_Heightmap_Nodes.zip

[Zylann]

What do I need to check? This is just a Blender file.

[Moonwards]

This needs a solution from the Blender side and this is our best shot at it. Anyone else who has created a landscape in Blender and wants to use that with this addon is going to run into this, so it seemed worth posting. Even if it doesn't really solve it. This needs more input from people who know Blender.

[Zylann]

The Cycles material editor was built from the ground up to generate colors and displacement to be rendered on screen, not surprising that this problem rises when generating something else. Either Blender needs to be configured to avoid any kind of color management, or you need to add a node to undo the color space.

My plugin expects correct heightmaps, but maybe a workaround could be done to perform this "undo" in the import function, but I don't know which kind of operation to run here. sRGB conversions usually work within the 0..1 range, heightmaps go way beyond that. Godot has srgb_to_linear but it doesn't work with HDR images.

Did you actually try to put the camera under the terrain in Blender, make it orthographic covering the exact size of the terrain, output height in displacement instead of surface and somehow export the resulting depth as EXR from the compositor instead?

[Zylann]

Is this still an issue? Is there a feature request to consider? At the moment the plugin just reads the image as it comes without any particular conversion, so I don't think the problem is on that side.

[Moonwards]

Sorry to get back to you late. I thought your answer before was sufficient, and didn't think it called for a reply. I got guidance about setting up the nodes correctly in Blender, in a question on blender.se - here https://blender.stackexchange.com/a/154900/7548 if that might be useful to you.

It does seem like it would tend to come up for people who are trying to import something from Blender. Having an option to switch the mode by which the heightmap is interpreted seems like it would be useful. What the conversion should be, I don't know, but it's probably a simple formula.

[MJacred]

What @Moonwards said still only generates a png file, which does not sound usable for the this plugin (unless I misunderstood sth.).

so I tried what @Zylann mentioned

Did you actually try to put the camera under the terrain in Blender, make it orthographic covering the exact size of the terrain, output height in displacement instead of surface and somehow export the resulting depth as EXR from the compositor instead?

I don't know about how to use the result if you put the height info in displacement port, but I tried sth. similar: still output into surface, but in compositor, read the z-depth of the camera…

But, I still have trouble getting a landscape from Blender to Godot:

blender test file: terrain-baker.blend.zip

I tried exporting an EXR file using the compositor in blender (select Viewer node, go to Item in the Node tab and click Save This Image as .exr file). Imported into Godot (Godot 3.3.4; addon is version 1.5.2), I get the following issues:

ripped corners

I can get rid of the ripped corners, if I place the camera above instead and compensate for the camera position by modifiying the z-depth values, but then the corners stretch really high (which can be fixed using "flatten" in the addon)

I don't have the stair-cased issue, but it's also not so smooth:

The compositor relies on the render to get the depth buffer, but I don't think color management is important here. Though I tested all kinds of combinations (and the sequencer was always set to linear)

• sRGB + Standard
• sRGB + Raw
• None

I also tried what @RonanZe mentioned in his comment here by importing the exr file into krita and saving as R32, but then on import in Godot, it said that the heightmap is not square (maybe this is because of the ripped/missing corners? I didn't test the exr file where the corners where upwards stretched once imported into Godot).

Any help would be greatly appreciated!
Maybe @RonanZe can elaborate more on the workflow they succeeded with!?