Add a terrain TEXTURE or mesh painter for making nicer terrains . .

[jasperbrooks79]

Describe the project you are working on: A Tomb Raider game . . Exploration, puzzle, lore . .

Describe the problem or limitation you are having in your project: I can make nice terrain in Blender, atm . . But, I find it difficult to make really nice terrain, bec. I don't have a tool, for painting the terrain, with for instance rock, grass, stone, forest, so on . . Since Godot won't get a full terrain editor right away, maybe for Godot 4 we could get a ' splat-map ', or so terrain painter, that allows to paint stuff made in Blender, in an efficient way, ie. texture blending, tiling, over-lap, etc etc . . This would not be a full feature terrain editor, but a nice step towards making nicer 3D environments, in Godot . . Imo, this could also be a first step, towards the full terrain editor, that seems to be intended, some-where down the line, it would really help tie 3D game makers over, until we can have the full-blast voxel-based terrain editor, that we deserve . . . ;) ;) <3 . . lol

Describe the feature / enhancement and how it helps to overcome the problem or limitation: Basically, like Zylann's terrain editor, that supports painting with 4 different textures, on a mesh surface . . the terrain can be shaped in Blender, but painting them, is not an option . . Hope we can get that in Godot 4, since we won't be getting a terrain editor, this would be a nice ' upgrade ', to an already amazing looking Godot 4 line-up, of features, awesome, and more . . Yes, I've seen the cool shit we're getting, I'm impressed, for real . . .

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams: Like Zylann's terrain painter, not to sculpt terrain, but to have some different textures one can use for painting rocks in some places, grass in other, a road, etc etc . . It would really help, to break up terrain, and give amazing results, on terrain made, in Blender . . Also, support for transparent stuff, so one can paint debris, stone and, wood pieces, as well . . Combined with the new Decal node, one could easily make amazing looking, realistic 3D worlds, with nice roads, etc . . And, it could be the first step, towards making a full terrain editor, while keeping it managable, for those making it, ie. smaller scope, but would give a MASSIVE boost, in 3D environment quality, almost immediately <3

If this enhancement will not be used often, can it be worked around with a few lines of script?: I can't do this stuff, atm . . I think it is called splat-maps, or some sort of, blending shader, I don't know how to make this, in an optimized way, maybe there's a ' best ' solution, one can use, maybe GPU shader, or so . . It would hopefully allow for HQ-blending, ie. not be so simple, one can't make impressive terrain, but also fast, efficient . .

Is there a reason why this should be core and not an add-on in the asset library?: Bec., it would take Godot from basic 3D environments, to REALLY nice environments, and just be over-all awesome, I hope it might support 4 different textures, and 4 different decal layers, one can blend, or so . . Optimally, blending of 8 textures, or some other cool method, of terrain texture PAINTING, not sculpting . . .

Thanks . .

ps. I know one can use vertex painting, to get some of this effect, maybe there's a way to use that stuff, to also blend textures, on a surface, it's probably pretty fast, if done that way . . Combining vertex painting, and texture layering, or blending, would be an amazing thing, since we won't get the FULL terrain editor yet, to tie us over, and make Godot 4 such, a well - rounded, epic release, thanks . . .

Something close to this, in quality, would be amazing, or so . . <3

[jasperbrooks79]

It would also be a small, first step, towards a FULL terrain editor, that runs really well, and would make all the terrain editor questions at least, be toned down, until we can get the full package . .

<3 . . .

It makes sense, as a first step, since it would be amazingly powerful, and using the most modern shader-GPU-vertex paint-what not techniques, it could probably run fast, and, be fun . . And, take 3D worlds in Godot to a really high level, for all users, going forward, and development would be limited, compared to full terrain editor, I hope we can get this, as I really, really miss it, for my games, atm . . . Thanks <3

If it could support painting, on static .obj meshes, exported from Blender, it would be wonder-fully powerful, and useful, and really help make terrains, that ' pop ', or so . . Hopefully, it's not too much work, for the Godot masters, not sure . . .

Thanks . . Can't wait, for ' 4 ' . . <3

It would also gives us ' something ', until we get the FULL terrain editor, please, please . . :O :O . . . .

Waiting, for ' the 4 ' . . <3 . . . lol, Thanks . .

[jasperbrooks79]

Ideally, one could have 1 - 4 textures, where one can paint per pixel layering, ie. if one wants a rock, to go to a certain pixel, one can paint it, and then have some more ' blending ' based textures, where one creates a rough line, or so, and down to vertex paint level blending, where it's really rough . . That way, combined with the new decal node, one can make any terrain, really fast . . as it gets more powerful, one could go from 2 really detailed blending textures, down to painting pixels, to 4, if it can be optimized . . .

So, one can plug in HQ blending textures, MQ blending textures, and LQ blending textures, as one needs, or so . .

So, along with having ability to paint REALLY accurate per-pixel almost blending, there's also more ' vertex paint ' looking options, to get LQ results, but that would work, for many games . . a feature-rich terrain texture painter, that works on .obj meshes, exported for static terrain, from Blender, or so <3

Thanks, hope you can make it, soon <3

Even if we only got a really LQ vertex painting like effect, it would REALLY help, make nicer games, or so . .

[jasperbrooks79]

One could also make a setting, so when doing per-pixel layering, one could paint 1x1 pixel, 2x2 pixel, 4x4 pixel, 8x8 pixel, 16x16 pixel, as a setting, and save performance, and size of terrain painting info, if needed . . .

[jasperbrooks79]

The next step, would be a vegetation painter, tree, rocks, etc etc . .

It would be important steps, towards making a FULL terrain editor, and most of the requests for terrain full editor, would be answered by this feature, and I think the shader gods, I see on the forums, could make some-thing nice, really fast, little work . . And, the massive amount of data, that full terrains require, it could start moving in that direction, ie. make the stuff that takes the least storage, maybe vertex painting texture blending, or so . . The better it gets, the fewer requests, for the terrain editor <3

A kick - ass, next - gen terrain texture painter, to tie us over, for Godot 4 . .

For starters, a painter, where one can have 4 textures, and can paint them, like vertex painting, with 4 levels, of blending, ie. 25 % alpha, 50 % alpha, 75 % alpha, so one can blend them, it would be a fairly low-size file, to get started, on a terrain editor, and could be improved, as needed . . the seams, or so, could be hidden with grass planes, rocks, etc, and something that simple, might be enough, and keep the size of the data, very low, or so . . <3

If we got a rock, vegetation painter, it would basically be enough, for most games, the rest could be made custom, in Blender, or so . . maybe the Godot engine gods could make a super-powerful, performant version, that runs well, on most machines, low data-size, efficiency, power . . . <3 Thanks . .

And, people would stop asking for a terrain editor, 90 % . . <3

[jasperbrooks79]

The last thing we could hope for, would be a river painter, or, a road painter, something that makes painting those things very easy, or maybe a cave painter, where one can make some rock assets, and then paint a cave, or so, where one just ' adds ' rocks, as needed, to form a simple cave, a sort of 3D vegetation painter, but with rocks, that gets placed, naturally, some algorhitm . . .

It would basically just place rock assets, not as 2D paint, but as 3D paint, and quickly make a rock cave, or so, with collision shapes so, on, and it would technically just be meshinstance nodes, that are placed, and rotated, ie. a bunch nodes, with individual rotation, maybe scale . . Like a vegetation painter, but that works, in 3D, to give 100 % cave formations . . . :O :O . .

It would be quite simple, and not take more space, than placing them manually, or so . . each one can be selected after-wards, and rotated, for a custom look, ie. they're really just individual meshes, but could be stored, in one ' common ' node, or so . . a MeshComposite3D node, or so, one would just need a 3D painter, boom, one can make anything . .

This is the stuff I DREAM about, for Godot 4 <3

[jasperbrooks79]

After that, it is a FULL terrain painter, but these simple tools, would really go a long way, and be faster, to program . . <3

Thanks, waiting . . <3

Add: the rock formation painter would just have to be able, to detect the normals, of the already placed rock meshes, and sort of add to them, in a ' natural ' way, that works, is performant . . then, we'd have 99 % a full terrain editor, with a really low data size, bec. technically, it's just a bunch of meshes, that have been rotated, from a set . . .

Like this, but with different sizes, ie. 25 cm diameter rocks, 50 cm diameter, 1 m diameter, so on . . <3

Then, we have a ' cheap ' 3D terrain painter, or so . .

also, having a limited set, of ' tile ' rocks, might be able to be optimized, ie. it's the same meshes, to lower memory usage, draw-calls, so on . . it would have to be able to detect the 3D ' collision shapes ' already there, and place more rocks, semi - intelligently . . It avoids massive terrain data files, at least, if the algorhitm was done well, one would have to do very little tweaking, or so, ie. naturally caves, made quickly, and performant, little data - storage . . <3

Like this, but for painting caves, from rock assets, in 3D . . .

[jasperbrooks79]

Would be a cheap way, to avoid the massive cost, of terrain data, and create caves, etc etc . . <3 <3 <3

Add : The algorhitm would have to be able to avoid holes, in the meshes, ie. be pretty complex, then no more need, for a terrain editor <3 . . also, settings for a defined rotation range, to avoid caves looking weird, and a scale range, to preserve texture size, relatively . . . ie. lock rotation of placed rocks, around x + z axis, so certain rock stripes, would look pre-served . . .

That way, erosion lines would be preserved, or so, and scale wouldn't be a problem, since making such a cave would require placing them manually, anyway, the data size, should be about the same, and they could be stored in a multi-meshinstance, or some efficient format, graphically . . . <3

It basically could just store all the placed rocks, in a sub-scene, and could have a feature, to generate an efficient collision shape, ie. more performant, from code, algorhitms . . .

for instance, if it could generate a static trimesh collision shape, that followed the out-side surface, of all the rocks, to save space, would be so nice, Thanks . . .

Also, after one has painted a cave system, one could click a button, fill holes in meshinstances, so there are no gaps, or ' holes ' . . <3 <3

if the rocks were placed, in a sub-scene, one could open, one could always replace individual rocks, by hand, then hit ' calculate combined trimesh collision body ', and have a nice semi - voxel terrain editor, for caves, so on . . . <3

The algorhitm could be improved, in later versions, or so, for better performance, placement and, style . .

One could also lock placement, to say, the y axis, so one could place the lower height, of the rocks, ie. the lowest level, like the tile editor, then when one has a nice rock, the lower level, one can start painting on top, of those, or so . . start with the lowest rocks, make some corridors, or so . . then, paint on top of them, to make the roof or, such . . Thanks . . . <3

and, the sum-total data size, would be the same, for placing them, individually, any-way . . <3 lol . .

[jasperbrooks79]

Procedural cave painter, or so . . That way, we wouldn't need a full terrain editor, for a LONG time <3

These things would have to be added eventually, anyway, since they're smaller, more easy to code tools, it makes sense to start there, since there's so much work for Godot 4, and we won't get a terrain painter soon, I think <3

it Might also be possible to store the data, in such a way it can be compressed, or so . . also, after the cave has been painted, have an algorhitm to remove needless rocks or, assets, or so, to further optimize . . <3

Maybe there are some Godot dev masters, Zylann knows a TON, about this, that could start building this, from the most basic angle, ie. start with the simplest features, having in mind, it should eventually integrate, with a full terrain editor <3

Add: Eventually it should be so ' competent ', it could even paint pretty good rock-walls, or some-thing like simple rock house, even . .

Then, it'd be pretty epic <3

end - goal, simple rock ' architecture ', procedurally placed, or so . .

or, simpler rock bridges, more simple, than this . .

<3 . . all done, procedurally, so it doesn't make Godot that much larger, in size . . . <3

up to, simpler castle-walls, for ' simple ' architecture . .

That's, ideal, for such a tool, or such <3 a bit more random, than the examples, above, but close . . . :O :O <3 . .

[Zireael07]

As you yourself noted, we have Zylann's terrain addon. Because this addon exists, I don't think Godot needs a competing core terrain system - and I don't recall core devs saying they want the addon merged, because it's only useful for 3D and it's a lot of code to maintain while a LOT of people use Godot for 2D only.

So, the vast majority of your ideas in this issue are probably better suited for the aforementioned addon.

[Xrayez]

I recall reduz suggested that eventually the terrain tools may be integrated into Godot at some point in one of the live Q&A videos, but that's more to cater to the wishful thinking of people. If that happens, I think this could be done for Godot 5.0, and likely as a GDNative solution, if GDNative gets a usability treatment. 😄

But there's a reason why Zylann (including myself) prefer to use C++ modules, because it more closely integrates with the engine, be it for performance or low-level access to the engine internals, which cannot be done with GDNative, AFAIK.

[jasperbrooks79]

Well, I had an idea, suppose one had a 3d terrain mesh, made in Blender . . And, one stored the splat-maps, per 1 m square, in a 64x64 pixel image, where red channel equals one texture, green another, blue a third, and alpha a fourth . . That way, one could have the information, about where each part of the surface should be rendered, in a 64x64 size image, which are very small, in size . . this would effectively give a sub-division into 64x64, for the surface, which is a LOT, of like squares, to paint . . .

There, one can actually make a 16x16 pixel image have a nice resolution, of texture blending, for a 1x1 m square . . if there was a shader, that blended, or layered it better, it could look nice . .

So, for a 10x10 m surface, one would need a 160x160 pixel image, to store information, about where to have a certain textured as ' primary ', or so . . and, for a 100x100 m, it'd be a 1600x1600 size image . .

to get 32x32 sub-divisions, for 1 m^2, it's a 3200x3200 texture, which could even be saved, as a .jpg, to get better compression . . or, 4 1600x1600 textures, would be enough, to paint a 200x200 meter surface, ie. know which texture was supposed to be where . . If one made so, that the textures were only in memory, when a player was within a certain AABB of a terrain piece, compared to total texture size, prob. 20 - 40 mega-byte, it'd be quite low . . :O :O . . .

One could get really nice blending, especially if one placed plants, rocks, etc etc, on the surface, or so, and used an algorhitm, for blending the transitions . . one could even make an 8x8 size texture, pixels, and get okayish result, for a 1x1 m square, or so, if it had blending, like vertex painting . . Not sure, if this would work, but be nice, to have such a feature, imo . . And, since we won't get a full voxel-based terrain painter, this could be a nice first step, that could be implemented first, and make a lot of terrain editor fans happy, for Godot 4 . . <3

the above planes are 2x2 m, forgot to scale them, but a 8x8 pixel texture, could store the information, what texture to paint, and if they were subdivided, so each different terrain tile only had the texture loaded, when it was visible, it'd be almost on performance, other than the shader, maybe GPU accelerated <3 . .

[jasperbrooks79]

even a 8x8 pixel texture, for each 1 m ^2 surface, gives a nice result, in vertex painting, or so . . .

And, if there was an AABB function, so it only loaded the parts of the texture location point texture ( 8x8 pixels ), it could run pretty fast, if optimized, or so . . <3 <3 or, the combined 800x800 pixel texture, with the information, was loaded, partially, or so, each time, or it was divided into 4 400x400 pixel textures, that loaded when needed ..

[jasperbrooks79]

One last thing, if one made it so, that the values for any given pixel coordinate, on the surface, was auto-normalized, when painting, so one could have a smooth brush, or so . . Then it could work, like weight painting in Blender, which makes a really nice painting experience . .

So, if red channel is TEXTURE1grass, and one paints it, on the surface, the red value goes up, and the green, blue, and alpha channel go down, so the other textures ' fade ' out . . it could be nice, the ' painting ' tool-set, was a bit ' cool ', or well - working, or so . .

So, if at first, red = 25 %, blue = 25 %, green = 25 %, and alpha = 25 %, for a given vertex coordinate, in the pixel ' memory ' maps, for the terrain, and one painted red more intense, ie. the texture more dominant or, so . . so red = 40 %, adding 15 %, then it lowers blue to 20 %, green to 20 %, and alpha to 20 %, that controls blending amount, for the other three textures, then one might have, a really nice painting experience, and one could have a setting, to use an 8x8 pixel ' terrain map ' for a 1 m surface, or 16x16, 32x32, etc, to get more detailed terrain painting, but at the expense, of performance, storage . . . <3

It's a bit complicated, but I think this is something, a good shader artist could make, pretty fast, from what I see, they can do, if it was a GPU shader, that did it, it might be really fast, or some other way, or so . . Thanks . . . <3 <3

may-be, this is called splat-map tech, or so, of course we want an optimized, really cool tool, some-thing fast, efficient, cool . . . <3 last, if the textures also could load a normal map, metallic, roughness, it'd be super - nice <3

[jasperbrooks79]

Last, one could instead of having people select 8x8, 16x16, as a setting, simply call it LQ, MQ, HQ, SHQ, low quality = 8x8 pixel per 1m square surface, medium quality = 16x16, or simply make a setting called ' Quality ', and click that up, or down . . It could be stored in small .png, or even .jpg, to save memory, and final size, or so . .

It'd REALLY make use terrain editor hungering fans, feel tied over, until we can get the full, planned terrain editor, and help make AMAZING levels . .

Last, if possible, one could add four more textures, that contain decals, for instance twigs, small stones, etc . . it would require ANOTHER 800x800 pixel texture, to store that, so one can paint decails, on Blender terrain, or so . .

for instance, Quixel twig decals, with normal map, etc . .

If we got this in Godot 4, I could make all my games, right away, no need for a full terrain editor, for a LONG time <3 . .

[jasperbrooks79]

first, one paints the basic textures, THEN one can paint, an optional second layer, of details, or decals on top, of that . . then, we could easily make these terrains, fast . .

Nice, cool . . . .

I guess I'm asking for a terrain painter, instead, of a terrain sculpter, editor, or so . . .

[jasperbrooks79]

it would also mean, instead of having maybe 40 different textures, to make a fully detailed terrain, with each surface being unique, one would need to have 4 textures, in memory, and just paint them, in various ways, lowering amount of texture usage, if done well, sure the Godot engine gods can make something, that's almost next-gen, Godot 4 is looking near AAA <3

[jasperbrooks79]

Alternatively, one could simply make it vertex paint based, and store a value, for each texture blending, or 'layering', in each vertex, in a similar file or, format . . .

That way, Godot would have a working terrain editor, when working with Blender, that's really fast . . . <3 <3 then, it would only have to be a vertex painting tool, that also runs, as a shader, that blends textures, or so <3

but, storing it in textures, could mean one could have a certain vertex count, and more detail, in the paint maps, ie. one could have 4x4 lines, per 1m surface, but a 16x16 pixel map, for texture blending or, layering, thanks . . .

it would minimize size, of terrain texture paint data, to something like 3K texture, for a 100x100 m terrain, or even 2K, depending on quality, and not ' bloat ' engine, it would be a shader, not more, or perhaps some other, not sure . . . <3 Thanks . . .

[mojoyup]

I think this kind of implementation is over the top personally. I like to do the hard work :P But if this gets pushed and works, I will be in awe!

[Calinou]

Closing in favor of https://github.com/godotengine/godot-proposals/issues/445.