PDA

View Full Version : MFnMesh.setPoint / MFnMesh.setPoints never succeed?


kattkieru
10-03-2008, 02:42 PM
Hi all,

I'm working on a proper blenshape mirroring tool (none of the ones I've found online work 100% of the time, and most either fail or crash Maya). At first I tried all in MEL. I did the following:

1) Get all point positions on base mesh.
2) Generate a match list by checking within tolerance for verts on the opposite side of the X axis. IE, I flip the sign on the X axis value and search through all the verts for a match. If a match is found I store the match like so:

vertMatchList[i] = j;
vertMatchList[j] = i;

so that I don't have to double up on those calculations. Center verts within a tolerance are skipped.
3) Get the blendshape vert positions.
4) Move each blendshape vert position to the position of it's oppositely-numbered vert based on the vertMatchList created from the mostly-symmetrical base shape.

Doing this in MEL made Maya crash, a lot, so I switched to Python and used MFnMesh and MPointArrays. Everything is working now except for one thing: setPoint/setPoints!

I've tried it two ways:


# smarter way
# m == maya.OpenMaya

mPointArray = m.MPointArray()
for i in range(0, bPointArray.length()):
mPointArray.append(bPointArray[vertMatchList[i]])

stat = blendFn.setPoints(mPointArray, m.MSpace.kObject)
if (stat != m.MStatus.kSuccess):
print "EPIC FAIL! (You lose.)"



# less-smart way

for i in range(0, bPointArray.length()):
if not vertMatchList[i] == i:
stat = blendFn.setPoint(i, bPointArray[vertMatchList[i]], m.MSpace.kObject)
if not stat == m.MStatus.kSuccess:
print "%i) Quasi-epic fail." % i


Neither function EVER returns a success, and the meshes remain as they are. The point arrays were grabbed in object space. bPointArray is the points from the original blendshape mesh. None of the shapes are connected and there's no history. Any hints as to where I'm going wrong? Thanks in advance.

kattkieru
10-03-2008, 03:21 PM
Even stranger is the following:


for v in range(0, mPointArray.length()):
print sel[s] + ".vtx[" + str(v) + "]"
c.select(sel[s] + ".vtx[" + str(v) + "]", r=True)
print "%i) moving to %f, %f, %f" % (v, mPointArray[v].x, mPointArray[v].y, mPointArray[v].z)
c.move(mPointArray[v].x, mPointArray[v].y, mPointArray[v].z, a=True, ls=True)


If I run this on vertices range(0, 100), then it actually flips the points. If I run it on the whole object, then no points move.

edit: Well, if I run c.currentTime(c.currentTime(q=True)) every 100 verts, the verts move. It's a solution, although not a great one. At least it lets me move the points and figure out where some of my math went wrong. I'd still like to know why the other stuff fails.

Robert Bateman
10-06-2008, 09:43 AM
Does the mesh you're modifying have history? If it does (i.e. a polyCreator node) then the results of your modification will get overridden next time the DG updates. The easiest way to test is to delete the history on the node you are testing, and see if that works (since it'll be the only node in the DG computation). In general, if you're using MFnMesh within a command (or script), then you're doing it wrong. You should be looking at writing a polyModifier node to modify the mesh data as it passes down the DG connections - anything else, and MFnMesh::setAnything wont work.

Keilun
10-06-2008, 04:51 PM
Another catch here is your usage of setPoints.

MFnMesh::setPoints expects a full vertex point list. You set them all or you set none. By the looks of your code, you are potentially adding just the vertices you're interested in and trying to set them. That would result in a MS::kFailure if ( pts.length() != numVertices() ).

kattkieru
10-07-2008, 12:48 AM
Thanks to you both for the replies.

Actually I've made quite sure that all history is removed.

I was attempting to set all vertices with setPoints. The code I pasted above might be a bit hard to understand sans context... Basically, I run all the vertices through some math to massage the point locations into the spots I'd like. The number of verts should be the same getting set, although I can check that again later.

I eventually brute-forced this problem by taking all the positions and running a move command per vertex. It's slow (massively so), but it works in all situations provided I jog the timeline every hundred verts or so. I wanted to avoid writing the node, but if it's a faster solution I can have a look into it. Is that a solution you've personally used in the past? What's the speed of execution like?

Thanks again. Sometimes it's nice to know that other people have coded workarounds, especially when you're the only coder in the studio. ^_^;

CGTalk Moderation
10-07-2008, 12:48 AM
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.