Hmm... did some experimenting. Using your example as a base, I compared
modifying the castsShadows attr on 8000 spheres. I have them grouped in the
following way:
`-- set
|-- a
| |-- nurbsSphere0001
| |-- ...
| `-- nurbsSphere4000
`-- b
|-- nurbsSphere4001
|-- ...
`-- nurbsSphere8000
I get very similar results for both api and maya.cmds. Interestingly, I get
an incredible slowdown depending on how specific/general I am with the
search:
search = set|*|*|nurbsSphereShape*
api = 27.6180000305
cmds = 27.018999815
vs
search = nurbsSphereShape*
api = 0.956000089645
cmds = 0.403000116348
This is my first few hours playing with openmaya, already made some silly
mistakes (defining function-sets inside the loop is waaaay slower than
outside the loop), but wondering if there's something else I'm missing...
would appear wildcards should just be avoided at all costs. Here's my
contrived example:
import maya.OpenMaya as om
import maya.cmds as cmds
import time
#search = "set|*|*|nurbsSphereShape*"
search = "nurbsSphereShape*"
print ("search = %s" % search )
# API based
start = time.time()
sel = om.MSelectionList()
sel.add( search )
iter = om.MItSelectionList(sel)
depFn = om.MFnDependencyNode()
mObj = om.MObject()
while not iter.isDone():
iter.getDependNode( mObj )
depFn.setObject(mObj)
depFn.findPlug("castsShadows").setBool(True)
iter.next()
end = time.time()-start
print ('api = %s' % end)
# maya.cmds based
start = time.time()
sel = cmds.ls( search )
for each in sel:
cmds.setAttr("{0}.castsShadows".format(each), 1)
end = time.time()-start
print ('cmds = %s' % end)
On Sunday, August 5, 2012 9:14:06 AM UTC+10, matt wrote:
>
> Wow, definitely seems worth investigating. Thanks for the code snippet and
> timing info!
>
> On Sunday, August 5, 2012, Justin Israel wrote:
>
>> 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
>>
>
--
view archives: http://groups.google.com/group/python_inside_maya
change your subscription settings:
http://groups.google.com/group/python_inside_maya/subscribe
