Recently, I have wished to use the BGE for functions like navmeshes and other such applications. Unfortunately, the way in which the BGE Mesh API is written means that one cannot rely on using vertices as waypoints, for in cases (as documented here in the API) where the data for vertices is non-identical, position aside.
There are many applications whereby using such a system may benefit the end user, but often any user who wishes to interact with a mesh expects there to be shared vertices between polygons, and not the current vertex splitting method.
Thus, i’ve written a form of “wrapper” - MeshBridge
- MeshBridge will behave in most cases exactly like the previous api.
- It creates new custom vertex, polygon and mesh instances for a mesh, building its own functions for attribute modification
- It has certain tradeoffs, and benefits
The current implementation should work in the same way as the existing API. You can move vertices, setXYZ, setUV etc. I’ve added a new feature that permits you to move the location of a polygon, as well as the normal.
New style polygons have child vertices. These are new style vertex instances.
New style vertices have child (base) vertices. These are the original vertices found in the BGE Mesh data for an object. When you find a vertex using mesh.getVertex(matid, vertid), it is no longer a single vertex. It is a list of vertices that share the same location within a distance threshold. These vertices are stored on a list, and when you transform a vertex parameter, it applies the same deformation to all vertices.
This is where one limitation comes into place. As it takes the mean of all the vertices for any list data (e.g normal, position), it may be that things such as UV coordinates don’t function correctly. I’m not sure, please report back with your own findings.
The limitation that I am aware of is vertex normals. In the case of a cube, in the BGE the vertex normals typically face the direction of the face. In this bridge, it takes the mean normal of all the child vertices. In the case of a cube, it would mean that the normal would face away from the center of the object.
I expect that any transformations will run slower than a single vertex transformation (as they are applied to all vertices). The same goes to reading vertex data (as it sums it and then gets the mean).
To use this, create a text file in Blender called “mesh_bridge.py”.
Import “Mesh” from mesh_bridge -
from mesh_bridge import mesh
Now, simply take the mesh of the object, and instantiate the Mesh class with it
Look for mesh bridge.py on BlenderArchive