hoimar/planet-generator

A procedural planet generator addon for Godot with terrain LOD.

👋 Hi there, I'm Hoimar

• 🔭 I’m currently working on my Bachelor's degree
• 🤓 I'm a geek interested in computer science, software engineering, tinkering, free open source software, game development and simulations.
• 😄 Pronouns: he/him

planet-generator's Issues

UV coordinates between different TerrainFace chunks/tiles don't match up

See screenshot below.
This might simply be due to the lower vertex density (which stretches the texture) but could also be caused by an error in the MinMax calculation where the colors / UV coordinates are defined. I'm not yet sure.
Though this is mainly visible in the editor but not as much when viewed from the camera.

Also visible is how the normals don't align where the edges meet, but that's a separate issue which will be fixed.

Atmosphere with clouds

Hi, I just pushed a new branch with improved atmosphere and water. I am now working on implementation of optional clouds. In the meantime you can check the changes I made and do some corrections if you want.

Generating planet(s) frequent crashes the Godot Editor or the application

This happens randomly and is definitely related to the multithreaded generation of the TerrainFaces. I'm probably accessing non-thread safe APIs (e.g. the scene tree or my own variables) from multiple threads.
Started working on this issue. Help would be appreciated, but I'm not stuck (yet).

Correctly calculate TerrainFace seams

Currently when TerrainFace meshes meet, they only match up when they have the same resolution, as the same noise value will be sampled for all vertices in the same position. When different LOD levels meet however, between two vertices in the coarser mesh there will be an extra vertice in the finer mesh (see screenshot) which samples a different value.

The first solution I'll try is to use the median between the left and right vertice for every odd edge vertice in the finer mesh to align to the coarse mesh. This way I won't have to deal with creating additional geometry and/or stitching the meshes (for now at least, will see how this works out).

Add Bilboard mode to the Sun corona

Add this in the Corona shader of the Sun. In the Vertex method. I tried it and works

From: godotengine/godot#16561

Planet terrain editor

How can i share the prototype terrain editor as a "pull request" so that i can get some help in fixing a few issues with it?

terrain editor thread:
#42 (comment)

Occasional multithreading related crashes (especially benchmark scene)

When running the benchmark scene, it sometimes crashes it's running Godot process. This happens with one worker thread but is amplified when using more. It also seems to happen independently from using or not using the "feeder thread" in JobQueue.

Next steps would be to make a minimal reproduction project to narrow down what makes it crash. Perhaps it's a missing mutex or something else that could lead to memory corruption, or even an engine bug.

Edit: This also sometimes happens when launching the editor and when saving scripts in the editor (hot reloading related). I also had a crash once in the running solar system demo scene that may be related.

The crash usually looks like this:

Iteration 1 finished in 12.598ms.
Iteration 2 finished in 488.927ms.
Iteration 3 finished in 5.576ms.
Iteration 4 finished in 19.339ms.
Iteration 5 finished in 284.263ms.
Iteration 6 finished in 15.944ms.
Iteration 7 finished in 299.750ms.
ERROR: _ref: Condition "!success" is true.
   At: core/array.cpp:55.
handle_crash: Program crashed with signal 11
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
Iteration 8 finished in 17.251ms.
[1] /lib/x86_64-linux-gnu/libc.so.6(+0x46210) [0x7f7cb12d3210] (??:0)
Iteration 9 finished in 299.121ms.
[2] /path/to/Godot() [0x1fc9233] (/godot-source/./core/cowdata.h:138)
Iteration 10 finished in 250.297ms.
Generated 10 times in 1693.066ms.
[3] /path/to/Godot() [0x20e384c] (/godot-source/core/variant_op.cpp:2991)
[4] /path/to/Godot() [0x4ee2bf] (/godot-source/modules/gdscript/gdscript_function.cpp:1442 (discriminator 3))
[5] /path/to/Godot() [0x49d740] (/godot-source/modules/gdscript/gdscript.cpp:1208)
[6] /path/to/Godot() [0x202eae6] (/godot-source/core/object.cpp:898 (discriminator 1))
[7] /path/to/Godot() [0x20984b8] (/godot-source/core/variant_call.cpp:1149 (discriminator 1))
[8] /path/to/Godot() [0x4e8400] (/godot-source/modules/gdscript/gdscript_function.cpp:1089)
[9] /path/to/Godot() [0x49d740] (/godot-source/modules/gdscript/gdscript.cpp:1208)
[10] /path/to/Godot() [0x202eae6] (/godot-source/core/object.cpp:898 (discriminator 1))
[11] /path/to/Godot() [0x20984b8] (/godot-source/core/variant_call.cpp:1149 (discriminator 1))
[12] /path/to/Godot() [0x4e8400] (/godot-source/modules/gdscript/gdscript_function.cpp:1089)
[13] /path/to/Godot() [0x49d740] (/godot-source/modules/gdscript/gdscript.cpp:1208)
[14] /path/to/Godot() [0x202eae6] (/godot-source/core/object.cpp:898 (discriminator 1))
[15] /path/to/Godot() [0x20984b8] (/godot-source/core/variant_call.cpp:1149 (discriminator 1))
[16] /path/to/Godot() [0x4e8400] (/godot-source/modules/gdscript/gdscript_function.cpp:1089)
[17] /path/to/Godot() [0x49d740] (/godot-source/modules/gdscript/gdscript.cpp:1208)
[18] /path/to/Godot() [0x202eae6] (/godot-source/core/object.cpp:898 (discriminator 1))
[19] /path/to/Godot() [0x21dea93] (/godot-source/core/bind/core_bind.cpp:2758)
[20] /path/to/Godot() [0x2124d4d] (/godot-source/core/os/thread.cpp:76)
[21] /path/to/Godot() [0x23804d4] (thread.o:?)
[22] /lib/x86_64-linux-gnu/libpthread.so.0(+0x9609) [0x7f7cb15dd609] (??:0)
[23] /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f7cb13af293] (??:0)
-- END OF BACKTRACE --

Save the patches in cache?

I think that the performance of the plugin it's good more or less, talking about the GPU.
The problem comes with the CPU, when you get near the planets surface, the CPU process goes extremaly high, because needs to patch a lot of terrain with only a little movement.

I think it would be a good idea to save every patch in the ram (or disk too) so it will not be necessary to load it every time.

Should I try to implement it?

Planet's mustn't move

When I move the planets (cause I want them to rotate around the Sun), they don't patch the Terrain when ship aproximing to them.
I think that is because every quadnode stores his position when loaded and they don't refresh it.

Applying custom visual shader to the planet?

An idea: A feature which allows users to apply their custom shader to the planet, and allow height map based on that shader. Is something like this possible? I tried changing the material but it doesn't override what was there before as seen in the test below.

Below is example of a texture I may try to apply:

Planetary collisions

Any idea, how to implement fast enough collisions? I've managed to generate a convex collision shape from mesh, but it's slow and inaccurate. I am now trying to add a CollisionShape on runtime using PhysicsServer but with no luck so far?

Doesn't work on HTML5

It simply doesn't patch the terrain, goes completely black.

Specs:

• GPU: GTX 750 (GLES 3.0)
• Browser: Opera, Chrome

And throws this error every time that tries to generate the terrain:

• GL_INVALID_OPERATION: It is undefined behaviour to have a used but unbound uniform buffer.