Need to expose btHeightfieldTerrainShape as Godot shape for easy terrains

[slapin]

@AndreaCatania how would you suggest exposing btHeightfieldTerrainShape? If that is not accepted politically I will be more than happy to keep the change local, but how do you think this could be done properly for Godot effective use? Thanks!

To others:

btHeightfieldTerrainShape is Bullet primitive shape which is built from heightmap. You can have shader-based terrain (i.e. splatmapping-based) and use this shape as collision, so characters do walk on it. So you do not need to create mesh specially for collision or manually check it every time to not fall through.
Works the same as other Bullet collision shapes. I used it in other engines and it is fast and useful even created at run time.

[Toshiwoz]

Then I'll have to rewrite my code 😩...
But it sounds as a good improvement.
I think this can be related to @Zylann's latest commits..

[Zylann]

It is exposed in PhysicsServer (example of usage in my plugin) but a node surely would be more user-friendly. Could be exposed with an Image property? I use 16-bit half-float for rendering but Bullet doesn't has this type so currently it is converted to either float or 8bit internally.
@Toshiwoz which commit?

See also #24390 about an issue with that shape currently

[Toshiwoz]

@Zylann I was referrring to the following PRs:

• Make heightmap shape usable in PhysicsServer #17806
• Allow to create a heightmap collision shape from an image #20745

I think you already set the premises in order to have such kind of node.

[Zylann]

Yeah I'm just not sure how the image format should be dealt with. The only commonly supported format between Godot and Bullet that works in most cases is float, so people have to import an .exr as such as an ImageTexture just so they can both use it as image on CPU and heightmap on GPU (assuming that you want to spend the weight of that format on GPU), but there is no node supporting visualization so far so that part still needs manual work. At the same time I would find it strange to ask for a Texture while all this shape needs is an Image (or more precisely, a PoolRealArray, the image is not referenced, it is actually copied), so I don't know. Perhaps it would be that way on the node API while the PhysicsServer API offers more details.

In my plugin I included both in a single node handling those details internally anyways because so far I think it's easier to use than building the classic staticsbody/collisionshape/visualinstance by hand and linking the same image in between somehow (especially because it is editable and probably won't stay a single image in my case). In Unity they also hide this away by asking for the same TerrainData resource required by their renderer component.

That could be worth discussing too when such kind of terrain is considered for addition in the engine.

[slapin]

Ah, it is so cool work is being already done! I guess it should be possible to support plain 8-bit/color image for everything (visual/collision) and float should be possible too. I think some conversion API could be implemented to have best possible internal format. My first thought was is there some way to optimize the whole thing so that it would be easier to create seamless paged terrain generated at runtime, so to be able to have chunk up as quickly as possible? In this case the height map will be from some combined noise image/texture.

…

On Mon, Dec 24, 2018 at 1:55 AM Marc ***@***.***> wrote: Yeah I'm just not sure how the image format should be dealt with. The only commonly supported format between Godot and Bullet that works in most cases is float, so people have to import an .exr as such as an ImageTexture just so they can both use it as image on CPU and heightmap on GPU (assuming that you want to spend the weight of that format on GPU), but there is no node supporting visualization so far so that part still needs manual work. At the same time I would find it strange to ask for a Texture while all this shape needs is an Image (or more precisely, a PoolRealArray, the image is not referenced, it is actually copied), so I don't know. Perhaps it would be that way on the node API while the PhysicsServer API offers more details. In my plugin I included both in a single node handling those details internally anyways because so far I think it's easier to use than building the classic staticsbody/collisionshape/visualinstance by hand and linking the same image in between somehow (especially because it is editable and probably won't stay a single image). That could be worth discussing too when such kind of terrain is considered for addition in the engine. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#24548 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAX062StsF-qUAZRL9X2kYrwl9Ppa1Nks5u8An6gaJpZM4Zfh2c> .

[slapin]

Another PCG requirement would be to be able to spawn stuff on top of terrain precisely, i.e. adding roads for traffic simulation/city generation, etc. Also subtractive holes (Torque3D-style) would be nice to implement for subway. So I guess some way to query heightfield for height at Vector2() or closest heightfield point to Vector3 is very important thing to have.

…

On Mon, Dec 24, 2018 at 5:24 AM Sergey Lapin ***@***.***> wrote: Ah, it is so cool work is being already done! I guess it should be possible to support plain 8-bit/color image for everything (visual/collision) and float should be possible too. I think some conversion API could be implemented to have best possible internal format. My first thought was is there some way to optimize the whole thing so that it would be easier to create seamless paged terrain generated at runtime, so to be able to have chunk up as quickly as possible? In this case the height map will be from some combined noise image/texture. On Mon, Dec 24, 2018 at 1:55 AM Marc ***@***.***> wrote: > Yeah I'm just not sure how the image format should be dealt with. The > only commonly supported format between Godot and Bullet that works in most > cases is float, so people have to import an .exr as such as an > ImageTexture just so they can both use it as image on CPU and heightmap on > GPU (assuming that you want to spend the weight of that format on GPU), but > there is no node supporting visualization so far so that part still needs > manual work. At the same time I would find it strange to ask for a > Texture while all this shape needs is an Image (or more precisely, a > PoolRealArray, the image is not referenced, it is actually copied), so I > don't know. Perhaps it would be that way on the node API while the > PhysicsServer API offers more details. > In my plugin I included both in a single node handling those details > internally anyways because so far I think it's easier to use than building > the classic staticsbody/collisionshape/visualinstance by hand and linking > the same image in between somehow (especially because it is editable and > probably won't stay a single image). > That could be worth discussing too when such kind of terrain is > considered for addition in the engine. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#24548 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAAX062StsF-qUAZRL9X2kYrwl9Ppa1Nks5u8An6gaJpZM4Zfh2c> > . >

[slapin]

For hole mapping you need to inherit from btHeightfieldTerrainShape and override processAllTriangles. There you drop triangles according to some mask or terrain material index (for hole brushes). And use the resulting instead of btHeightfieldTerrainShape. Hole mask could be another image or stored within heightfield itself. Also triangles can be processed separately, but that would be harder.

…

On Mon, Dec 24, 2018 at 5:31 AM Sergey Lapin ***@***.***> wrote: Another PCG requirement would be to be able to spawn stuff on top of terrain precisely, i.e. adding roads for traffic simulation/city generation, etc. Also subtractive holes (Torque3D-style) would be nice to implement for subway. So I guess some way to query heightfield for height at Vector2() or closest heightfield point to Vector3 is very important thing to have. On Mon, Dec 24, 2018 at 5:24 AM Sergey Lapin ***@***.***> wrote: > Ah, it is so cool work is being already done! > > I guess it should be possible to support plain 8-bit/color image for > everything (visual/collision) and float should be possible too. > I think some conversion API could be implemented to have best possible > internal format. My first thought was is there some way to optimize the > whole thing so that it would be easier to create seamless paged terrain > generated at runtime, so to be able to have chunk up as quickly as > possible? In this case the height map will be from some combined noise > image/texture. > > On Mon, Dec 24, 2018 at 1:55 AM Marc ***@***.***> wrote: > >> Yeah I'm just not sure how the image format should be dealt with. The >> only commonly supported format between Godot and Bullet that works in most >> cases is float, so people have to import an .exr as such as an >> ImageTexture just so they can both use it as image on CPU and heightmap on >> GPU (assuming that you want to spend the weight of that format on GPU), but >> there is no node supporting visualization so far so that part still needs >> manual work. At the same time I would find it strange to ask for a >> Texture while all this shape needs is an Image (or more precisely, a >> PoolRealArray, the image is not referenced, it is actually copied), so >> I don't know. Perhaps it would be that way on the node API while the >> PhysicsServer API offers more details. >> In my plugin I included both in a single node handling those details >> internally anyways because so far I think it's easier to use than building >> the classic staticsbody/collisionshape/visualinstance by hand and linking >> the same image in between somehow (especially because it is editable and >> probably won't stay a single image). >> That could be worth discussing too when such kind of terrain is >> considered for addition in the engine. >> >> — >> You are receiving this because you authored the thread. >> Reply to this email directly, view it on GitHub >> <#24548 (comment)>, >> or mute the thread >> <https://github.com/notifications/unsubscribe-auth/AAAX062StsF-qUAZRL9X2kYrwl9Ppa1Nks5u8An6gaJpZM4Zfh2c> >> . >> >

[Toshiwoz]

At the same time I would find it strange to ask for a Texture while all this shape needs is an Image (or more precisely, a PoolRealArray, the image is not referenced, it is actually copied), so I don't know.

@Zylann Somehow I do use a PoolRealArray as parameter instead of image or texture, I do decode that from an image first.
The reason is because heightmaps can be encoded/decoded with different tecniques, for example Mapbox uses this formula:
height= -10000 + ((R * 256 * 256 + G * 256 + B) * 0.1)
While it seems you use only one channel
in another case (heightmap generated from NoiseTexture) I used the sum of the 3 channels, and I'm quite sure out there there are several other ways to encode/decode height data.

So it actually does make sense to use something more specific than a texture, and maybe by adding another layer that actually decodes images into a PoolRealArray. For example add a string parameter with the decoding formula, and then have it evaluated internally.

Hope this makes sense to you.

BTW, in the latest patreon vote PCG have taken some attention:
https://www.patreon.com/posts/november-2018-23510558

[Zylann]

@slapin after investigating the issue I linked earlier, I also found that processAllTriangles function, so I could also work on supporting holes because my plugin also supports that by packing the last bit of the alpha channel in the color map (the rest of alpha being used for AO), and can be stored in RAM as a bitmap for physics.
I would also need to expose the triangle layout setting because I use diamond tiles instead of zigzag tiles (because less orientation artifacts).

[OBKF]

This looks interesting, I am following this.
By the way @Zylann your terrain plugin is amazing :D .

[bojidar-bg]

I think the Heightmap shape is now implemented when using Bullet, correct?

[clayjohn]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!