-
-
Notifications
You must be signed in to change notification settings - Fork 160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question/Discussion: Best practice to import Terrain generated in Blender (and similar) #327
Comments
At the moment I have no more info on how best to proceed. I was always thinking that if you can get an image out of Blender with sufficient depth precision and not altered by color management, importing into Godot should be fine. |
Hm… it's possible there is a precision loss in the Blender shader or compositor… There is one more approach that should be possible in vanilla Blender: first render to a 16-bit greyscale image file (without color mgmt) and then import the file in Blender and remap using the compositor as seen here: https://www.youtube.com/watch?v=UPwoG_8KGa4 I'll try it this weekend. EDIT: If the above does not work out, I'll try this approach first to create a .raw file: https://github.com/Mezaka/UnityHeightmapBaker If that also does not work, I'll try writing a Blender addon which directly reads the vertex positions Vector3.UP and creates a RAW (unsigned integer 16-bit) file. (While looking at the terrain in Blender from above) I take I would have to read the vertex positions from left to right, bottom to top? if my math skills did not fail me, then I guess I need this formula
|
Well, don't know if this can help, but I solved my import problems converting png 16-bit to raw 16-bit shorts unsigned with one line of code with imagemagick:
|
Thanks, I'll try it this weekend. |
Ok, I finally did some testing with Note: found issue:
And using the command above definitely improves the results (thanks @Naurk ): But the wireframe is uneven on slope tops -> cannot be fixed with hterrain brushes:
see blender vs godot (same mesh resolution -> see 1x1x1 cube on top): |
Still Weirdnesswith new commit 778907a, there's now more control, but there is still some weirdness there hterrain (used a script in Blender to get highest and lowest vertex.z position for accuracy) Proposal: recalculate Heightmap from lower LOD to fix imported mapone way to allow fixing issues with imported maps would be to recalculate higher LODs
LOD LOD Comparison: Godot <> Blender (using magick process)i lined up the vertical lines: blender (orange) <> hterrain (blue) @Naurk: As you got so good results using the |
I also tried https://github.com/Mezaka/UnityHeightmapBaker, and had to
But the result was quite chunky His import looked smoother, but that might be due to his scaling? As it was rendered at 1025x1025, the height is 0.0-512.5. But dividing map size by 2 (to get this scaling on import) did not improve the spikes… |
@Zylann: I wrote a Blender addon bmesh-to-raw to correctly export a mesh to raw (provided it's clean) some screenshots: https://github.com/cubiest/bmesh-to-raw/tree/main/docs As this issue is more or less stale and one sound solution (not counting imagemagick) has been found, I'll be closing this issue. |
For anyone stumbling over this issue: I wrote a Blender addon bmesh-to-raw to correctly export a mesh to raw file
The Problem
Currently, this plugin allows (out-of-the-box) to create terrains by
a) importing a file with height info
b) using a dialog with some adjustable parameters
c) sculpting by hand using OpenEXR brushes
d) procedurally by code (I think)
b) is not that useful if you desire a bigger map with more variation and c) takes just really long.
For a) there are a lot of terrain generators like world machine, world creator, gaia, gaea, etc. But from what I could see, there is a lack of control over the finer details regarding size and shape (or maybe they just didn't showcase that).
Either way, it's also possible to create heightmap terrains in general purpose 3D modeling software like Blender which allow a great deal of freedom on how to create and edit them quickly. Though there is the issue of getting it into Godot properly.
From time to time there are issues popping up regarding transferring a terrain; currently open are
The Goal
This plugin can import file formats such as PNG, OpenEXR (16-bit (half-precision float mode) greyscale), XYZ and Radiance HDR - and well… RAW (unsigned integer 16-bit), where all except PNG expect real height information and not floating point values between 0-1.
Exporting from Blender to PNG is doable using a node shader (#90 (comment)), but Godot can only import PNG as 8-bit, which creates stepping artifacts.
Blender also supports these formats afaik, though, I could only get
OpenEXR
to work even remotely. And it still has issues.Export to OpenEXR in Blender
so I tried what @Zylann mentioned
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 OpenEXR file using the compositor in blender (select Viewer node, go to
Item
in the Node tab and clickSave This Image
as .exr file).Current issues with export to OpenEXR
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 modifying the z-depth values, but then the corners stretch really high (which can be fixed using "flatten" in the addon)
Overall, using either of the 2 approaches, I don't have the stair-cased issue, but the results are never 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
)I also tried what @RonanZe mentioned in his comment here by importing the OpenEXR 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 OpenEXR 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!?
The text was updated successfully, but these errors were encountered: