Import control maps from other tools

[TokisanGames]

Import the texturing control map from other tools. This will require understanding and writing code for each proprietary format then convert it to our own. And the importer tool needs to map channels.

• WorldMachine
• Unity
• UE
• hterrain
• Gaea
• World Creator

At the very least we should be able to import splatmaps and convert them to a control map.

Maybe also import a texture atlas and convert it to separate textures? idk.

[nanodeath]

This seems like it could be a big feature for Terrain3D, because...if I'm not mistaken, the only alternative is to manually paint the terrain inside Godot, correct? Which...kind of works, but seems a bit fussy, and things like World Machine already have all that data anyway, just not in a format Terrain3D can currently understand.

What's the task breakdown look like? Probably there's some baseline splatmap conversion infrastructure, with adapters for each engine? Though, I'm using World Machine at the moment, and I think it lets you export basically whatever you want -- packs stuff into an RGBA image that you can export as PNGs, for example. If the others are like that too, maybe we don't need engine-specific adapters, but an adapter per format? Or we just say "you must export in this format"?

For context/fun, here's the outputs outputs from the "Basic Splatmap Example" example in World Machine Basic:

Visualizer View:

Splat View:

Height Output:

Splatmap Output:

And...here's the actual splatmap, which doesn't look like much, but if you decompose the channels in GIMP, it's all there (sand+rock+vegetation+erosion):

[TokisanGames]

The first step is to get the exact format definitions of each tool so we don't have to guess. E. G. Height should be grayscale, not green/brown. We have ours documented.

Then a conversion script can be written and a UI created to handle assigning textures to slots.

Also, Terrain3D doesn't use splatmaps. It uses an index map. So the conversion from a splatmap system won't be pixel perfect.

[nanodeath]

Sorry for the confusion, this is the actual height map generated. The previous screenshot was a visualization.

I don't quite get the Control Map Format yet, but I'll keep staring at it. The code refers to the control map as cmap usually, yes?

[TokisanGames]

Height maps can already be read. The point was we need the format definitions. So, the next step is finding the documented format of each tool's texturing maps.

In the code the control maps are storage._control_maps, written to in Editor, read from in the shader. There are converters in Util.

Our document should be self explanatory to those familiar with C/C++ and arcane to those who aren't.

[TheLegend368]

Adding to this since it's the main feature I was hoping to see added to Terrain3D.

I mainly use Gaea (a little bit of World Creator) but it's the same exporting for all the terrain generation tools listed in the original post, only the terrain creation/generation workflow is different between them. They don't have any proprietary formats, they all just output greyscale images (8bit,16bit, and 32bit) exported to different image formats: RAW, Tiff, EXR, PNG, etc.

I've used Gaea with Unity, Blender, and Unreal, so I can also speak on what those import and export. Unity- Height in RAW format (16bit) and splatmaps in any other image format (usually PNG 8bit and full-size textures +1).
Blender- Height in any 16bit texture format blender supports and splat maps in any image format (usually PNG 8bit & full-size textures). Unreal- Height in RAW or PNG format (16bit) and splat maps in any other image format (usually PNG 8bit at weird resolutions).

HTerrain- It seems it's using the same formats as everything else, RAW or PNG for height and regular texture formats for splats with resolutions the same as unity. HTerrain Height Import HTerrain Height Import

Unreal and Unity can export their textures to widely used formats.

The height maps are usually exported at 16bit to get the best results but you can also change that. Splat maps are just different greyscale masks packed into each channel of a texture.

Example - Splat 01

• R - Grass
• G - Rocks
• B - Dirt
• A - Peak (Snow)

The layer/channel order matters mainly for Unity since that's how the default shader is made. Each channel layers/masks on top of the other from R-A and supports 2 Splat maps. If you can reorder layers with their masks in Terrain3D then this might not be an issue.

There's also exporting the generated base texture for the terrain that is sometimes used as the base layer to draw in the distance, and your layered material closer to the camera that blends into it. This may or may not be useful info.

Scaling- Each program uses 1m² per texel so a 1024 texture would be 1024m² terrain if you are making it 1-1 (but most times people don't). You could export a larger height map and get more details on the same size terrain. 4096 height map on the 1024m² (4-1) terrain would now be 4x 0.5m² mapped to a 1m² area. Most people don't know or worry about this, but it could be important.

If helpful, I can make a video showing the workflow/process setting up and exporting maps from Gaea or supply height and splat maps for testing.

[TokisanGames]

We will take texture control map specifications for all tools. I don't think export tutorial videos will help. We don't need instructions. We need format definitions. e.g. Names like raw doesn't mean anything except that it's just a data dump. What is the data? Is it 16-bit integers? 32-bit floats? We need a definition of the format used of various tools. Preferably a link published by the developers.

Height specifications are not needed. We already import heights in r16, exr, or res in raw values. Normalized heights can be scaled on import. We can read already HTerrain's height res natively.

We only need the export control map data format. That is how they define how textures are applied to the terrain. Some tools provide multiple export options for how control maps are defined. At least one per tool is useful, but we'll document all of them.

In terms of priority, the first thing before anything can be done is to identify the formats. Then they can be implemented, which will typically happen when a contributor needs it. I personally may get to it, but it's a much lower priority compared to collision, memory, instancing and other features.

They don't have any proprietary formats

Proprietary could mean a unique image format, but no one uses that. We mean a unique process, quality, or usage. Our control map is just a 32-bit float image that can be stored as an EXR. The file format is not proprietary. How we use the data is. How they use their data is also. We don't need the file format specification for EXR. We need the usage definition for what the pixels on the image mean.

they all just output greyscale images

This is not enough detail. We need the definition of what those gray scale images are used for. Are they splat maps? Are they albedo rgb channels? Are there other options available that will break textures down into some sort of indexed map? Most users will not want to import albedo maps. We could import and render them on the colormap. But that's only useful for GIS applications, or unless you're doing all texture work in the other tool. This workflow won't convert the map into a usable texture layout data that can be modified in Terrain3D.

[Radivarig]

@nanodeath can you please edit the original comment to use the corrected heightmap?