# Mesh vertex global coordinates?

Hello,

Just a quick question, how would I get the global coordinates of a vertex I have accessed through the Blender module mesh section in the BGE?

If there is no simple way to aqquire them, how would I go about converting local to global?

Does nobody know how to convert these?

``````global_vertex = Matrix(*obj.worldOrientation) * Vector(local_vertex)
``````

If I remember correctly … It’s been a long time since I used the mesh access api.

It might be a bit late to ask this, but where does one get Matrix() and Vector() from?

``````import Mathutils
``````

Thanks everyone, seems to be working.

On second thought, (and very late >.> sorry) it doesn’t seem to be putting the nodes in the right places, any other ways to convert it?

Multiplying the objects world orientation by the vertex’s local coordinates should return the global coordinates. The order in which you multiply is very important unlike other areas of math, it has to be matrix * vector. If that is what you are doing you best post up your script so we can have a look.

Be aware that if the mesh is rigged and animated, you might not get quite the data you are looking for…

This is the function I’m using:

def convert(obj, co):
globalco = Matrix(*obj.worldOrientation) * Vector(co)
return globalco

where obj is the whole blender object that the mesh belongs to, and co is the coordinates of the vertex in question.

Anyone know what’s wrong with that?

The indentation is wrong (use the code tags when posting code).

Also, you should remember that the orientation matrix doesn’t include position information, so you need to include that:

``````globalco = Vector(obj.position) + (Matrix(*obj.worldOrientation) * Vector(co))
``````

If that doesn’t solve the problem, you should make a small example .blend that presents the issue clearly.

Then we can look at that.

Social, your script strangely gets all of the coordinates right except for the X axis one, which seems randomly inaccurate, ranging anywhere from 0.066 off target to 1.8 off target.
I would post an example blend but this problem is buried rather deep in my pathfinding AI and repurposing it for an example is difficult. If an example is nessecary I could probably boil away most of the AI to make it easier to understand.

When isolating one part of your code becomes so troublesome, it means that your design is fundamentally broken.

If you ignore modularity for too long, you will regret it (trust me).

Anyway, regarding the problem at hand:

It turns out that the orientation matrix doesn’t incorporate scale, so that’s something that you need to add for a proper transform matrix.

I made a small demo that seems to work properly in all cases (attached).

### Attachments

local_global.blend (131 KB)

I know about the modularity problem >.< that’s why I tend to stray away from posting examples, cause I sorta neglected (as I always do, stupid me) the planning stage of my project and as a result the thing is not modular in the slightest, and without serious work which I’m not sure I have the time to undertake it’s kinda stuck like that. (While I’m on that topic, any tips on how to do modularity?).

As for the code, that works fine, thanks again!

I always make a number of isolated test blends to get something working correctly and independently. I use def function(): for each part of code so I can lift it out later.
Making the game then equates to just combinging the isolated test modules. If a module doen’t work and I can’t make progress I can just dumpe the module before integrating it, rather than having a situation where I can’t get something to work and now it’s already a big part of my engine.

Of course sometimes the problem is in the intergration… That’s when making something once, and then going back and propery intergrating stuff for a version 2 can help.
Version 1 is just a proof of concept- there are always bugs and things you can’t really see. Version 2 is the working build.

Good luck!

As you already hinted: some level of planning is required.

Generally, you want to create functions/classes which are mostly independent from one another. The demo that is attached to my last post is not the greatest example of that practice, but it does represent modularity on a very basic level.

The functions in that demo are fairly generic, and quite capable of performing their tasks with virtually nothing more than the required input (specified by the function arguments). This makes them easy to swap around, and change, with only slight modifications to the main-line block of code that actually implements them (the last 6 lines of the script).

So, I may have additional AI functions that use localToGlobal, but localToGlobal doesn’t depend on those routines, and therefore I can easily isolate the transformation code into a significantly smaller/simpler example, for someone else to examine quickly.

Ok thanks for that, I’ll remember it for future scripts