Another bug, or something else?

I’m getting some data from poly proxy and mesh proxy to create a custom walkmesh.

However poly proxy returns the wrong vertex indexes when a mix of quads and triangles are used on the mesh.

If all quads are used, or all triangles, the result is fine, but otherwise it gets verts from all over.


poly_problems.blend (495 KB)

The two structures above are identical, except one of them has two of its quads split to triangles. I’m putting the vert data in to a list and then illustrating it with render.drawline. I’ve also tested it by getting v1, v2,v3 and v4 as an alternative to getVertexIndex() but same result.

I think it could be related to this bug:
https://developer.blender.org/T38030

flagged by agoose77, but the bug was declared fixed and closed.

Are you aware that KX_MeshProxy.getVertex(matid, index) works on materials rather than polygons?

KX_PolyProxy.getVertexIndex(vertex) returns the index within the polygon, which is 0…3 for tris and 0…4 for quads. This has no relationship to the material.

Unfortunately the API is not that clean that it is easy to get what index is meant.

I usually follow the method shown in the example. This works pretty well.

If you’re interested, in my bghelper moduleI have a class (Mesh) that allows you to grab polygons and vertices in a deterministic manner (i.e. the first polygon in the Mesh.polygons_list is always the bottom-front-left most polygon, and then the next one is to the right, and so forth). The index increases on the X axis, and then the Y axis, and finally the Z axis.

when you were testing that class did you try it with mixed triangle/quad meshes? You will probably get a similar problem. the code in blender is returning the wrong vertex indicies for the poly proxies. So when i get the verts from the mesh proxy using (material_id,vertex_index) they are not always the verts that form that poly.

Not sure what blender version you’re using, but I reported this a while ago, but was unable to reproduce, as I had forgotten what caused the issue. I narrowed it down to a patch by campbell that caused the issue I believe.

So you may have recalled why it happens for me :slight_smile:

I’m using the latest version (updated last night because I thought it might have been fixed in newer versions).
The good news is that if you use all quads, or all triangles the result is as you’d want. Otherwise you get very messy results.

I can illustrate it better by using different colors for each poly and leaving the object visible:


The objects have only one material. I tested with two materials on an all quad mesh and it messes up the vertex indicies there too.


Why do I need this info? Well there’s lots of reasons you might want to get the verts of a mesh sorted in to poly groups.
I want it for a custom nav mesh.

When using a pathfinding routine I need a graph, which needs to include both node positions and node connectivity. One way of getting connectivity in a graph is to use regular spaced nodes and get their neighbors. This is inefficient, because the grid is usually too fine (slow pathfinding) or too course (bad pathfinding) So I want to create a graph for pathfinding from mesh objects which will contain “poly” objects, each of which include several elements.

First I need the centroid of the poly, calculated by averaging vertex positions, this will be the waypoint used for navigation. I also need the vertex positions which make up the poly (rounded), these will be checked against each other_poly in the dictionary to see which ones share two vertex locations, these will be flagged as neighbors and added to the “poly” object’s neighbor list. I can also check other navmeshes and see if their poly edges line up with any poly in this one (rounding vertex positions reduces the possibility of edges not lining up), then they can linked as neighbors too. Then I can have multiple navmeshes added at runtime, calculated and merged.

The alternative is to use vertext positions as waypoints, but vertexes on their don’t have any inherent connectivity, I’ve been using ray cast and distance checks to build connectivity in the graph, but this usually creates a graph which is over connected (too slow) or under connected (not adequate for pathfinding). There’s a work around to preserve conectivity, but I’d rather use the mesh data.

Anyway, maybe I should try to get the bug report reopened, or should I post it as a new bug? I’m sure anyone can reproduce the results by using the blend at the top of this thread.

This is the same reason I noticed the bug in the first place :slight_smile:

If you’re curious about this navmesh design, I’ve a relatively functional example in the resources somewhere.

Better reopen the bug, posting a comment if you can’t.

Ah, my mistake. I must have mis-read / misunderstood your bug description. Sounds like a solid bug, indeed. Hope it gets fixed, and good to know that it can easily be worked around by triangulating your faces before play.