for(int i=0; i<points.Length; i++){
st.AddVertex(points[i]);
}
This is adding a vertex for every point of the sphere as you got them from the collision shape. I believe those points really don't work the same way as what the rendering engine expects (which is understandable since they come from the physics engine). Visual meshes require to be built by defining triangles (vertices connected together by groups of 3).
If all you want is to spawn a sphere matching the size of your collision shape, you can just use a SphereMesh
. However your sphere comes from a ConvexPolygonShape
, which is quite a strange choice for such a simple shape (you could have used SphereShape
).
So in order to try to help still with that specific situation, I generated a convex polygon shape from a simple CubeMesh
and used the same code as yours. While the points obtained are not just the 8 cube corners, that still doesn't work, as it looks like points are listed quite randomly. If that's the case, it makes reconstruction as a visual mesh near impossible, as the orientation of faces also plays a role in the order they come in...
It's quite chaotic. For example I tried to plot which triplets of vertices I got, and it was describing triangles going in diagonal through the cube, not even faces, which makes no sense.
So I had a look at the code in the engine to see at least how it was drawing them as lines (not even solids!), and there I found it uses a C++ internal helper to compute a hull from it: https://github.com/godotengine/godot/blob/66b0b0c153aa6b811c4ea3c0e5edddd7f2cb8062/scene/resources/convex_polygon_shape_3d.cpp#L43
For which there is no binding to GDScript. Looks like points
of a ConvexPolygon
are completely useless here.
However, that doesn't mean you can't generate a sphere from code. It just means "generating a mesh representing the same points as those found on a ConvexPolygonShape
solely using the script API is not possible".