As a random example...I created a nurbsSphere, and just simulated looping over
5000 objects and setting and attrib.
import maya.OpenMaya as om
import time
import maya.cmds as cmds
sel = om.MSelectionList()
om.MGlobal.getActiveSelectionList(sel)
iter = om.MItSelectionList(sel)
obj = om.MObject()
depFn = om.MFnDependencyNode()
start = time.time()
for i in xrange(5000):
iter.getDependNode(obj)
depFn.setObject(obj)
depFn.findPlug("tx").setInt(4)
end = time.time()-start
print end
# 0.0979061126709 seconds
start = time.time()
for i in xrange(5000):
name = "nurbsSphere1"
cmds.setAttr("{0}.tx".format(name), 4)
end = time.time()-start
print end
# 0.261173009872 seconds
On Aug 4, 2012, at 12:22 PM, Justin Israel wrote:
> Some of the big speed increases are using the iterators and not having to do
> a bunch of string operations on dag paths. And the math speedups from using
> the OpenMaya objects with operators.
>
> Your best bet it to just profile some small tests. You can easily make use of
> the python `timeit` module to check the difference in speed of operations.
>
>
>
> On Aug 4, 2012, at 10:53 AM, matt wrote:
>
>> Apologies for the crosspost for anyone on maya_he3d, only remembered this
>> group existed seconds after I posted over there... Have tried to edit and
>> re-word for you smart people. :)
>>
>> Short version:
>> Would using the python OpenMaya module give big speed gains for selecting
>> thousands of objects and modifying their attributes?
>>
>> Long version:
>> We have a python based, text based render pass submission tool for lighters
>> at work. One of its core functions is grabbing whatever geometry is defined
>> by a lighter, and setting attributes. This sometimes means adding attributes
>> first (or connecting our custom attribute node), then setting them.
>>
>> We're getting into the situation where we have _very_ heavy scenes, with
>> thousands of objects. Normally our system will process these scenes within a
>> minute or two per frame, if lighters use wildcards, eg 'set:tree*', that can
>> jump to maybe 6 mins per frame. Not too bad.
>>
>> Things get messy with our alembic style heirachical geo format. It can
>> contain many sub-objects, which our maya plugin doesn't allow us to list or
>> search for sub-objects names easily. Thus, if a lighter wildcards to the
>> sub-object level, eg "set:*|leaves*", the only safe way to do that is to
>> process every object, then every sub-object, unsetting atts those objects
>> which AREN'T leaves, and setting attrs on those objects which ARE leaves.
>> When this happens, processing jumps to 3 hours per frame. Yuck!
>>
>> In the short term we're getting lighters to be more careful with wildcards,
>> in the mid term getting assets collapsed down so they're not so name and
>> sub-object heavy, and in the long term getting our geo plugin more
>> inspectable. So that's good.
>>
>> I was curious though.... could this be helped in the short(ish) term by
>> re-writing that part of the code with the OpenMaya module? I recall reading
>> there's many things which are faster, a few which are slower, and fewer
>> still which have no OpenMaya equivalent and can only be done in mel/python.
>> I have a sneaking suspicion one of those slow things was something
>> fundamental like selection, but I'm hoping I'm wrong.
>>
>> Was curious if the basic idea of 'yeah, manipulating hundreds of objects and
>> their attributes is N times faster with OpenMaya' is worth pursuing.
>>
>> -matt
>>
>> --
>> view archives: http://groups.google.com/group/python_inside_maya
>> change your subscription settings:
>> http://groups.google.com/group/python_inside_maya/subscribe
>
--
view archives: http://groups.google.com/group/python_inside_maya
change your subscription settings:
http://groups.google.com/group/python_inside_maya/subscribe
