-
-
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
Texture sets #212
Comments
Seems to be a nice workflow improvement. |
@RonanZe if you only want to use albedo textures without normals, without fancy blending, and only 4 textures, then you might find the process a bit redundant compared to assigning textures directly without import step (although Godot still imports from PNGs to STEXs in any case). |
I was in the testing phase when I found the following blockers.
The alternative is to not import, and just generate PNGs, then reverse-engineer
Conclusion:
I wasted two nights on this so I'll make a pause there... I need to figure out what to do from here, because it appears what I wanted to do is impossible, not with extra steps from the user (crazy, right)... I would really like to get the design from my previous post though... the "correct" way Godot is exposing feels very limiting. |
Update: The feature is available to test in the |
This is now in master. |
This is an upcoming feature I'd like to expose before I merge it.
Texture sets would be a new custom resource to setup terrain textures, replacing the old way.
Existing system
So far setting up textures for the ground was up to the user, as explained here: https://github.com/Zylann/godot_heightmap_plugin/blob/master/addons/zylann.hterrain/doc/main.md#texturing
If you used a classic shader, you had to make 4 pairs of textures that are each packed like this:
You had to do this packing yourself in an image editor, or using a separate plugin.
If you used an array-based shader, you had to not only do that, but also assemble all your textures in an atlas, and use the default TextureArray importer of Godot, which is impractical and time consuming (also you better have lots of RAM to spare).
Proposal
HTerrainTextureSet
will be a new resource that can hold a collection of terrain textures. It lets you define source images (albedo, bump, normal, roughness), and allows to import them into the kind of texture the plugin expects. This way, you won't need to use an external tool anymore, and changing one of the source images is a lot simpler in the case of texture arrays.Each
HTerrain
node will start with one of these resources by default, and once you choose the data directory, it will be saved next to thedata.hterrain
resource, as a simple.tres
file. The generated textures will then be saved in the same place, either as.stex
or.texarr
.In this workflow, source images may not be used by the game, so it will be possible to place them in a folder with a
.gdignore
file, so they won't bloat the exported build. This leads to the following folder organization:Note: because it behaves like a regular resource, it is also possible to re-use the same pre-made set of textures for multiple terrains, by assigning it in the inspector.
Interface
There will be a custom interface to configure a
HTerrainTextureSet
, which can be shown either by inspecting the.tres
resource, or with a shortcut from the terrain editor (double-click on any texture slot, or chooseEdit...
).Work-in-progress:
Other options may also include default values for non-filled slots, normalmap strength to allow using DX convention from CC0Textures, and a mode to switch between texture arrays and individual textures, depending on the shader you are using.
The text was updated successfully, but these errors were encountered: