Planet terrain #278
Planet terrain #278
Conversation
Capital-Asterisk
force-pushed
the
planet-terrain
branch
from
e7e1003 to
fd174c1
Compare
# Conflicts: # src/planet-a/SubdivTriangleMesh.cpp # src/planet-a/icosahedron.cpp # src/testapp/sessions/vehicles_machines.cpp
Capital-Asterisk
force-pushed
the
planet-terrain
branch
from
fd174c1 to
4a1bf4b
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| } | ||
|
|
||
| /** | ||
| * @brief Anger the address sanitizer for invalid array views / spans / similar containers |
There was a problem hiding this comment.
Why do you want to make the address sanitizer mad on purpose?
What were you using this for?
There was a problem hiding this comment.
There's cases where I had an array view that exists, and I wanted to assert that it points to valid memory. There's no uses of it right now, but at the time it was actually quite helpful.
There was a problem hiding this comment.
Ah interesting.
In windows there's actually a OS api to let you explicitly check that at runtime.
No idea how to go about doing it in linux though.
| print("inline constexpr std::array<float, 10> const gc_icoTowerOverHorizonVsSubdiv\n" | ||
| + "{\n" | ||
| + " " + ", ".join(nstr_float(edge_length) for edge_length in tower_heights) + "\n" | ||
| + "};\n") |
There was a problem hiding this comment.
Noting the existence of this python script. The icosahedron stuff here use to be calculated at runtime, but only with doubles and implementation-defined std::sqrt. Precalculating all this with much much higher precision is a far more practical
Capital-Asterisk
force-pushed
the
planet-terrain
branch
from
2c7cfad to
bb3e935
Compare
Capital-Asterisk
force-pushed
the
planet-terrain
branch
from
5a1234d to
d1aa439
Compare
Capital-Asterisk
force-pushed
the
planet-terrain
branch
from
d1aa439 to
1e6efc1
Compare
|
Added docs with the pictures: https://github.com/TheOpenSpaceProgram/osp-magnum/blob/1e6efc187ec045493a8be14c027176110337ccdf/docs/planeta.md |
Capital-Asterisk
merged commit a5c4ea4
into
TheOpenSpaceProgram:master
This PR works on the incomplete planet terrain generator 'planeta' in
src/planet-a.Planet terrain is created by first managing a "Skeleton." The Skeleton is a triangle mesh that uses int64 coordinates, able to represent large planets. Each triangle is subdividable into 4 more triangles (triforce style), forming a quad tree of triangles (vertices are shared and handled accordingly).
High detail triangle grid meshes (called 'chunks') can then be created, copying coordinated from the skeleton triangles. This can be used for rendering or physics colliders. This is currently not yet implemented.
Certain invariants constrain the skeleton in such a way that generated meshes are completely closed and seamless (a manifold mesh). This allows it to work well with vertex shaders with displacement, such as ocean waves.
I'm thinking of making an infographic as part of the docs, to help describe some of the inner workings.
Terrain test scenario
New test scenario! This uses the existing camera controls to move around a 3D scene, containing a single 'planet' which subdivides and increases in detail when close to the camera's target (the green wireframe cube). A chunk mesh of the entire planet is managed in the background (there's no code that sends it to the GPU yet). Every 10 seconds, The mesh is exported is exported as an .obj file to the current directory, where it can be viewed with 3d modelling software like Blender.
Important non-planet related changes:
🐦 --- 🌐
fun fact: The 'a' in planet-a refers to it being the first planet implementation, as if there was going to be a 'b'. The letter was never incremented even after a major rewrite. It might as well just be "planeta" as the Spanish or Filipino word for planet.