Speed up this module implementation

[AndreaCatania]

Hi @Zylann I'm writing you here because I want help you in order to speed up the process of implementing this new feature.

Please let me know what you have to do to complete it so I can help you.

[Zylann]

Hi, thanks for your proposal :) There are currently 3 areas to look for development:

• Issues raised so far on this repo, mostly features and improvements (half of them require feature design before coding), and bugs as we find them
• Some features of this tracker are needed in the engine: https://github.com/godotengine/godot/issues/9046, as well as potential others not listed yet which are related to shaders, as creating custom terrain materials is currently not ideal
• We need to decide what we want to land in 3.1 while having room for evolution in the future. I asked reduz on the above issue but got no answer yet.

I have some WIP for texture splatting, which is mostly the writing of default shaders, but it's horrible because the engine doesn't have texture arrays.

Ideally, what I generally wanted to have is a heightmap system that can scale quite big without needing to hang the CPU and take full memory on huge sizes (so ability to stream, without requiring the user to fallback on stitching maps manually), enable users to write custom shaders, and scalable physics. More can be worked on (like grass, trees, wind zones etc) but I believe some might not have to be built into it (example: in UE4, you can paint grass on anything, not just heightmaps).

Two reasons why I didnt work on this recently: I have a non-code project going on, and point 3 of the above list^^

[darrylryan]

I think given the fact the playing field is likely to change quite a bit as far as the Godot core goes, it would probably make most sense to aim for a feature-complete static terrain first before getting bogged down in open world issues. To do really big worlds we're going to need a streaming system, not just for the terrain but all the other objects in the scene and we're going to need better mesh LODs, open-world-friendly GI, possibly some coordinate rebasing tricks to avoid float precision issues etc.

With a single heightmap image of 4096x4096 we should still be able to have quite huge terrains like in Torque3d without any chunking or streaming or worrying about seams.

Probably by the time Godot gets to 3.1 or 3.2 there will be stuff in the engine which will make planning/implementing the super-sized terrains a lot easier.

[Zylann]

UPDATE: after a short discussion with Reduz, such a terrain might actually not end up in core. I'm starting a GDNative port, which however could be a good candidate for "official" plugins (like the OpenVR one). Let's see how it goes... so far I see there is already need for more stuff that is currently impractical to translate, like the custom ResourceSaver/Loaders or compressed FileAccess. I think the module's features can be partially replicated but stuff will be missing until GDNative gets updates.

@darrylryan I agree, I'll probably setup on making a first fixed-size version (so, basically the current one^^), then if we need to implement a larger one it may either extend it, or create another node if the inner workings are too different. Engine features are still in need though.

[darrylryan]

@Zylann If GDNative is even more limiting, why not just make the current one usable until the core team get their ducks in a row? At least then those of us that need a terrain will have a viable option. To me it makes more sense to work on stuff like the shaders, tooling, grass trees etc. which will need doing either way and come back to the heightmap system when they've got further in the core. In my game I've done a quick hack-around to snap the characters to the height of the terrain using the get_height function you implemented which works in a pinch to make the terrain usable until we have a proper collider.

[Zylann]

@darrylryan it's a bit of a paradox: if nobody tries for real to use GDNative this way, chance is the features needed won't be considered sooner. To be fair the terrain can work with GDNative with almost the same code (I finished porting HeightMapData, which looks 90% the same as the module version, the 10 remaining % being the part that was using Godot internals), it may just have some temporary hoops (which the module already has btw, did you see that skull? :p). It's been only one day so it's too soon to push GDNative back. If I get really blocked I may go back to the module until it improves.

I can't do much work on shaders until proper features get to the engine anyways, at best it can be placeholder code (like writing a bunch of ifs to emulate texarrays, or a more simplistic one). Physics, grass and trees don't require Godot internals IMO, but we'll see when getting there, it will probably just be an extensive use of HeightMapShape, MultiMesh and more shaders, which are available through GDNative.

@AndreaCatania you could experiment HeightMapShape, since I have no idea how to use it efficiently yet, would be interesting to see how it performs.

[MirceaKitsune]

I am 100% behind this proposal. One of the most important features still missing from Godot 3.0 is the builtin ability to edit heightmap terrains and create large outdoor areas, which is currently only possible by exporting terrains as meshes (a very ugly and limited solution). This module is looking great to me, and if all issues can be solved I really hope we'll see it in a recent 3.x release.

[spaghiajoeojo]

So, how can I try this module? I would help in testing but can't understand if I have to compile a GDNative module or just a standard godot module!

[Zylann]

@lorenzobeccaro for now, just try the non-GDNative module (this current repo).

[spaghiajoeojo]

Thank you! But i'm having some trouble :/ #21