Slow Deformer Calculations

[millerjosh7481]

I have been developing a deformer on my Intel Core 2 Duo 2.4 GHz laptop using Windows Vista and now when I run the deformer on my Dual Intel Zeon Quad Core 2.8 GHz workstation using Windows XP 64-Bit I am getting a HUGE slowdown. Essentially this is just a pretty simple noise deformer using the PerlinNoise algorithm. My laptop runs the deformer in 30 fps where as my workstation runs it at 15 fps. I have different modes that calculate the geometry in different ways (directional, vertex normal, and spherical), even when I change the mode to a faster method (i.e directional) the frame rate in Maya remains the same 15 fps. The deformer is derived from the MPxDeformerNode class and uses its deform() function. In the deform() function I pretty much just retrieve the interface elements through the provided MDataBlock, check the methods from the interface, and deform the points accordingly in a for loop using the provided MItGeometry. The for loop is pretty simple in its calculations by doing the following operations in pseudo code

for(iter.reset(); !iter.isDone(); iter.next()){
//get the point position
pt = iter.position();

//transform to correct space
pt *= worldMat;

//calculate noise for point
noiseVal = noise(pt);

//undo the transformation
pt *= worldMat.inverse()

//deform the point
pt += directionalVector * env *weight;

//set the point
iter.setPosition(pt);

}

I have written this same deformer in Cinema4D's C++ API and the code runs really fast. So I know that the noise() runs pretty quickly. Not sure of the huge slowdown in Maya's API though. Any suggestions as to what I am doing wrong? Or is there more info that I need to provide for a better understanding of the problem?

Thanks in advance,
Josh

[joojaa]

Is it smart to have 2 matrix oprations in place? I mean you use 32 calculations for no big purpose. So theres definitely stuff you can optimize here. I would guess you could dorp easily a boost up of 20 times of the owrhead with very little change in code. By trasforming the lookup once and not update it for each point several times.

So no the noise may not be very slow but the dual point multiply certainly sets a limit to effect. Not that i think this necceserily is the bottleneck but the code outside ist is a bit inefficient to start with.

Anyway i dont see any reason why this should be so slow. I mean i can do this pretty easily in a particle expression and it runs fine at 30fps with a 10,000 poly model

[millerjosh7481]

Thanks for the quick reply.

Well, the two matrix operations need to be in there being that it is part of the algo for my deformer =) I allow for the noise to be calculated in different spaces independently of the vertex space. For example, the user may want the vertex in the deformer's handle space and the noise to be in world space. But, I just added worldMat and worldMat.inverse() in the pseudo code to show that I have a matrix multiplication at that point in the for loop. It may or may not be the world matrix depending on what the user sets in the attributes of the node.

But still this slow down doesn't make much sense. Could it maybe have something to deal with the Multiple Cores on both of the machines? Which the compiler is optimizing for, but is there something specific that I need to set in Visual Studio 2005? This is my first plug-in that I have developed through the Maya C++ API so there is definitely a huge chance that I am doing something wrong.

Thanks in advance,
Josh

[joojaa]

QUOTE(MillerJosh7 @ 04/13/09, 08:50 PM) [snapback]305648[/snapback]
But still this slow down doesn't make much sense.

Well thing is you can allways change your algorithm as you can get the same point places with MUCH less intensive calculations.

The fact that your code runs more or less at same speed irrespecively of the fact that what algorithm you sue would reinforce the fact that ist the matrix multplication. Try omitting the noise alltogether and test the speed then. If its still slow yoru kind of limitting your operation on the trasforms.

My main concern is that going back and forth in spaces is in general slow. Also code is allways slow here if your running it in debug mode. I mean for the pouints you can clear out the calculation by heaps in precalculation.

QUOTE
This is my first plug-in that I have developed through the Maya C++ API so there is definitely a huge chance that I am doing something wrong.

Well i would say thats given

[millerjosh7481]

QUOTE
The fact that your code runs more or less at same speed irrespecively of the fact that what algorithm you sue would reinforce the fact that ist the matrix multplication. Try omitting the noise alltogether and test the speed then. If its still slow yoru kind of limitting your operation on the trasforms.

Well I know for a fact that its not due to the matrix multiplications nor the noise function. I removed all three of the lines from the for loop and it still runs really slow.

I compiled the offset node from the devKit and that ran really fast. So it doesn't seem to be compiler related.

I do have a decent amount of attributes applied to the node (~24) that I retrieve in the begining of the deform() using the provided MDataBlock. Could that be causing problems?

Just as a side note: every deformer example I've seen either from Autodesk, The Complete Maya Programming books, or online examples have two matrix multiplications in the for loop of the deform().

Josh

[joojaa]

QUOTE(MillerJosh7 @ 04/14/09, 12:26 AM) [snapback]305669[/snapback]
Just as a side note: every deformer example I've seen either from Autodesk, The Complete Maya Programming books, or online examples have two matrix multiplications in the for loop of the deform().

Yes doesnt mean they need to do it. It shouldnt be a big deal tough but can seriously slow thinsg dowt though for siple stuff especially.

QUOTE
I do have a decent amount of attributes applied to the node (~24) that I retrieve in the begining of the deform() using the provided MDataBlock. Could that be causing problems?

possibly, since maya needs to retrive that data. Its easy to test just hardcode most of them. Just out of curiosity you dont happen to be forcing maya to re eval the network now do you? Also how do you retrieve normals.

Theres aslo distinct possibility the deformer is slow due to how you connected it into the history network.

Also for some more extensive work override deformers compute instead of deform. Ths may apply if you need data thet would be recomputed by maya each time you ask it but you dont need the recomputed data.

[millerjosh7481]

QUOTE
possibly, since maya needs to retrive that data. Its easy to test just hardcode most of them. Just out of curiosity you dont happen to be forcing maya to re eval the network now do you? Also how do you retrieve normals.

Even hardcoding all of my interface items didn't alleviate the speed issue. I'm pretty sure that I am not forcing maya to re-eval the network, but what would cause maya to re-evaluate the entire network? For retrieving the normals I used:

CODE
MArrayDataHandle hInputArray = bloc.inputArrayValue(input, &stat);
hInputArray.jumpToElement(multiIndex);

MObject inputObject = hInputArray.inputValue(&stat).child(inputGeom).data();

. . .

//in normals method
if(inputObject.apiType() == MFn::kMeshData){
meshFn.setObject(inputObject);

}

However even with removing this code from the deform() the deformer was still running slow.

QUOTE
Theres aslo distinct possibility the deformer is slow due to how you connected it into the history network.

Being that my deformer is using the deform() I am letting Maya connect my deformer into the history network using the command deformer -type myNoiseDeformer. I don't see any reason why I would need to change that for using a simple plane.

Thanks for all the help.

Josh

[millerjosh7481]

OK, I found my mistake. In the initialize() I was having my Time input attribute, which was driven via the scene's time node, affect the outputGeom of the deformer (attributeAffects(time, outputGeom)). This caused way more evaluations than the deformer needed.

Thanks so much for the help Joojaa, and sorry for the newbie mistake.

Josh