Looking for algorithm to transfer XYZ coordinates into UVSpace

#1

In general, I have the following starting point:

There is a position in 3d object space (a new vertex) which should receive an appropriate UVPosition relative to a specific face.
The newVtx may lay inside or outside the face, but a proper UV should be extrapolated even if the vtx lays outside.

Since I extract all the meshdata from Maya, and work on it using my own routines, and pass it back to Maya, I should implement everything on my own.

Being precise, it I need to properly sample UVs for a solidChamfer/chamfer algorithm which is supposed to keep the UVs.
My approach would be (and partly is) as follows:

First: Create the newVertices/Position

Second: Find the closest point on the specific face. This would be another slight problem since I would need to triangulate it first. I think maya uses delauney triangulation by default, but it is not implemented yet in my own “mesh manager”. Finally, finding the closest point on a triangle shouldn`t be a problem :).

Third: Find an appropriate UVPosition. I already have some sampling algorithm, but it seems to be different from the one used by Maya, so you see distortions - more or less intense.
It is not based on the actual mesh triangles - perhaps thats the/one of the reason(s).

So my final question is: Does anyone know which algorithm is exactly used to sample a UV Position according to a specific XYZ point?
Is it completely based on triangles as I assume now?

I really do not want to use the procedures available in MFnMesh since it will check the whole UVSet (instead of just on specific face ), and I think it will fail if there is no UV at this position.

I don`t know if I could explain it so very well, which is why I attached a screencapture :).

Please have a look! (5MB; WMV)

Thanks,
Byron

#2

a) You likely have a bug, as it does not work even with square faces. As you don’t describe how you get your new uvs, noone will be able to help you.
b) Your algorithm seems awfully complex for a trivial thing.

Think of cutting edges. All your new points are always along an edge and you can describe your new vertex position as being a percentage between the two original vertices (forget about your chanfer being able to move the vertex along the polygon normal, which is irrelevant).
Thus, it stands to reason that if you place a new vertex in the middle of an edge, your new UVs should be the midpoint of the UVs of the vertices of that edge.
There shouldn’t be any need to sample anything.

For the algorithm, look up barycentric coordinates. You may indeed run into issues with >4 sided faces, but until 4 sided faces work fine, don’t worry about it.

#3

Well, you really want to be working on triangles. First, it makes it easy, second everything in Maya is triangles anyway.

Take a closer look at the MItMeshPolygon class and you’ll see you can extract the triangles very easily. All you need to do is copy the triangulated mesh into your own mesh manager.

Okay, so once you’ve got the triangles, you need to extract the UV positions for all the vertices. Do this with MFnMesh. You can then use either MFnMesh or MItMeshPolygon/MItMeshVertex to get the uv index for each vertex you’re concerned about.

AFAIK you MUST specify a uv for each vertex-per-face when you create a mesh, so I guess Maya follows this rule itself. In any case, having UVs for every vertex in the mesh would be a starting requirement for your algorithm, so if that’s not the case you need to inform the user and get them to provide a full uv set.

Then all you need to do is find out the closest point on the closest triangle for your new point, calculate the barycentric coordinates for that point (iirc there was a discussion on how to do this in this very forum a while ago), then interpolate the uv positions of the vertices of the triangle to get your new uv.

Let me know if this isn’t clear enough, it should be a relatively trivial operation.

The slightly trcky bit is keeping track of what goes where so you can build the new mesh and give it back to Maya, but that’s more book-keeping than anything else.

#4

Thanks :).

I will take a look at those barycentric coordinates :).

@gga:

Because some of the new vertices I create are the results of intersections between two edges, so the new vtx does not nessecarily lay on an edge.
Of course, there are some of the new vertices that lay on an edge, and in that case the UVs will be based on a ratio of the edgelength, as you suggested.

@playmesumch00ns:

Yes, I probably that will be the thing I have to do: Using Maya procedures to get the triangles which will be fine for the version I currently work on.
But finally, I want be able to do everything on my own :).

AFAIK you MUST specify a uv for each vertex-per-face when you create a mesh, so I guess Maya follows this rule itself. In any case, having UVs for every vertex in the mesh would be a starting requirement for your algorithm, so if that’s not the case you need to inform the user and get them to provide a full uv set

A full UVSet is not nessecary - you can specify exactly, while writing the mesh back to maya, which face shall have UVs .

Besides that, a much bigger problem is that I was not able yet to write back additional UVSets.
This is because I always get errors once I try to create a new UVSet on my newly created MFnMeshData.
This is alright since UVSets have to be associated with an MFnMesh.
So I tried to pump my MFnMeshData into the MFnMesh located downstream, and then create the new, additional UVSet, but it didn’t work :(.

So I thought that maybe my meshdata didn’t arrive yet in the MFnMesh, so I created an onIdle Callback which was supposed to create a newUVSet - I didn`t work too.

Its really strange. There are so many attributes directly on the meshNode - perhaps I have to manipulate that manually?

Nonetheless, I hope that I will be able to write back several UVSets someday :).

#5

If your using OpenGL, you could try gluUnproject to convert from object space to screen space and just use screen space as UV (X = U, Y = V) space… Not that I’ve tried it but it sounds feasible… Right? :wink:

-=GB=-

#6

Hey Byron!

Just e-mailed you a ‘barycentric UV’ info doc.

Hope it’s of use to yer - thanx again for the great work:thumbsup:

Atwooki

#7

@ngrava:

Yes, exactly :). And then I could shoot a ray through that X,Y Position along the ZVector of the camera into the scene, intersect with the mesh, get th UV at the intersectionPoint and there we go =) .
Yes, I think I will do that ;).

@Atwooki:
Thank you :). If you already sent it, then it didn`t arrive here :(.

Regards
Byron

#8

Originally posted by Byron
[B]A full UVSet is not nessecary - you can specify exactly, while writing the mesh back to maya, which face shall have UVs .

Besides that, a much bigger problem is that I was not able yet to write back additional UVSets.
This is because I always get errors once I try to create a new UVSet on my newly created MFnMeshData.
This is alright since UVSets have to be associated with an MFnMesh.
So I tried to pump my MFnMeshData into the MFnMesh located downstream, and then create the new, additional UVSet, but it didn’t work :(.

So I thought that maybe my meshdata didn’t arrive yet in the MFnMesh, so I created an onIdle Callback which was supposed to create a newUVSet - I didn`t work too.

Its really strange. There are so many attributes directly on the meshNode - perhaps I have to manipulate that manually?

Nonetheless, I hope that I will be able to write back several UVSets someday :). [/B]

Oops, yep, my bad, you can specify a number of 0 uvs per face. Still, the point is, your user should have supplied a mesh with a full set of uvs, otherwise it’s pretty nonsensical for you to be creating uvs for them. If the faces the user is working on have no uvs assigned, then you needn’t worry about them, surely?

As for creating and assiging new uv sets, it is a bit of a complicated process. Look on the highend3d maya-dev list archives for more info. I believe Brian Ewert has some info on his website: www.ewertb.com/maya/api/

I’m not sure I completely understand the gluUnproject idea, but surely it’s a bit limiting to have your users work only with camera projections? What if they’ve spent hours setting up a nice uv mapping, shouldn’t you simply extend that?

#9

Thank you so much for that link!

He found out quite a lot of nice information there that is not mentioned anywhere in the docs.

I already supposed that there is something wrong with the API, but at last I came to the conclusion that it must be my own stupidity - as so often.

I’m not sure I completely understand the gluUnproject idea, but surely it’s a bit limiting to have your users work only with camera projections? What if they’ve spent hours setting up a nice uv mapping, shouldn’t you simply extend that?

This GLUnproject thing was nothing more than a joke, I guess, first from ngrava, and I extended that joke a bit. I should have put more of those :wink: in there :stuck_out_tongue: .

Thanks
Byron

#10

Aaah. Ok. doh.

#11

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.