Critical performance issue exporting animated object

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a simulation using the DMM for Maya plugin (which is bundled with 
Maya2012sp1)
2. Cache the simulation with Alembic

What is the expected output? What do you see instead?

Exporting one frame should take a few seconds, instead it takes 12 hours.

What version of the product are you using? On what operating system?

Alembic 1.0.3, Maya 2012sp1, fedora13

Please provide any additional information below.

The offending lines of code are:

http://code.google.com/p/alembic/source/browse/maya/AbcExport/MayaMeshWriter.cpp
#159
http://code.google.com/p/alembic/source/browse/maya/AbcExport/MayaMeshWriter.cpp
#161

If I comment these lines out (i.e. force the mIsGeometryAnimated flag to be set 
to true), the scene is cached quickly; the performance issue is in one of those 
two lines. If the animated flag is set to either true or false, there is still 
no performance issue. Lines 159-161 take 3.7 seconds to run on an extremely 
simple mesh, whereas with those lines commented out the entire iteration of 
AbcWriter::setup takes just 0.008 seconds (measured by profiling this method 
http://code.google.com/p/alembic/source/browse/maya/AbcExport/AbcWriteJob.cpp#37
7).

Original issue reported on code.google.com by arcgr...@gmail.com on 16 Nov 2011 at 4:44

[GoogleCodeExporter]

Could you provide a simple scene as an example?

Original comment by miller.lucas on 16 Nov 2011 at 5:10

[GoogleCodeExporter]

Hi Lucas,

I have attached an example scene. The problem occurs using this export command:

AbcExport -j "-fr 1 1 -ro -uv -file /tmp/test.abc"

This scene takes about 20 seconds to export for me, even though this is an 
absolutely trivial scene. You can see how long each cube takes to export, as it 
throws a warning for each object. It takes less than a second to export with 
the changes I mentioned. Using the command below seems to fix the problem also, 
however I am guessing that is because the suspect code is not called when you 
don't specify a frame range:

AbcExport -j "-ro -uv -file /tmp/test.abc"

I hope this helps, please let me know if you can't reproduce the issue.

Original comment by arcgr...@gmail.com on 17 Nov 2011 at 10:56

Attachments:

• alembic_bug_example_v01.ma

[GoogleCodeExporter]

Unfortunately because I don't have access to the full version of DMM, I can't 
evaluate your full scene without the "Please buy this" warning box popping up.

If I trim down your scene to just the first 100 cubes and export the first 10 
frames.
AbcExport -j "-fr 1 10 -ro -uv -file /tmp/test.abc"

It is taking about 22 seconds to export.

If I time just the evaluation of the scene (in python):

import time
a = time.time()
for x in range(1, 11):
    cmds.currentTime(x)
print time.time() - a

It is taking about 19 seconds.

The setup time for 100 cubes is taking about 3 seconds, but I suspect this may 
also include the evaluation time of the frame.

As expected individual frame evaluation time is taking about 2 seconds.

Is this similar to what you are seeing?

Original comment by miller.lucas on 17 Nov 2011 at 6:19

[GoogleCodeExporter]

Yes, that is similar to what I'm seeing. The slowdown definitely scales in the 
order of O(n^2). In your case it's just a few seconds, but my production scene 
has 3000 (very simple) objects in it, and it's taking 4 seconds per object. 
Maybe it's triggering some kind of huge DAG evaluation that is not actually 
needed.

Original comment by arcgr...@gmail.com on 17 Nov 2011 at 6:30

[GoogleCodeExporter]

For your more complex scene, how long is it taking to evaluate a new frame?

Original comment by miller.lucas on 17 Nov 2011 at 6:34

[GoogleCodeExporter]

To evaluate the simulation? I am using a DMM cache, so it's only taking about a 
second to load in each frame. If I didn't have a cache, it would still only 
take about 5 minutes per frame. Caching with the release version of Alembic 
takes several hours per frame, caching with my modified version takes about a 
minute per frame. The resulting cache is about 25MB per frame.

Original comment by arcgr...@gmail.com on 18 Nov 2011 at 10:14

[GoogleCodeExporter]

Original comment by miller.lucas on 9 Dec 2011 at 5:25

• Added labels: Component-Maya_Export, EstimateInDays-NULL

[GoogleCodeExporter]

Original comment by miller.lucas on 9 Dec 2011 at 5:25

• Added labels: WorkOrder-NULL
• Removed labels: EstimateInDays-NULL

[GoogleCodeExporter]

Although this might not fix your issue, I rearranged the isAnimated call to 
check the connected plugs first, before trying calling MAnimUtil::isAnimated 
(which could be fatally slow under some circumstances)

http://code.google.com/r/millerlucas-dev/source/browse/maya/AbcExport/MayaUtilit
y.cpp#256

Original comment by miller.lucas on 18 Jun 2012 at 5:47

• Changed state: PleaseVerify

[GoogleCodeExporter]

Fixed in the new released 1.1

Original comment by miller.lucas on 2 Aug 2012 at 11:11

• Changed state: Verified

[GoogleCodeExporter]

I know this is an old thread, but we ran into a similar issue, even in the 
latest Alembic (1.5.5).  When a large number of objects are connected to one 
shadingEngine node (in this case, ~5000 objects in initialShadingGroup), calls 
to MAnimUtil::isAnimated() increased the export time from ~30 seconds to ~20 
minutes.

We submitted a ticket to Autodesk.  They acknowledged the issue and put in a 
change request: MAYA-43891

If you have similar issues, I'd encourage you to ping them and tell them it's a 
priority.

Original comment by mike1...@gmail.com on 18 Sep 2014 at 5:38

[GoogleCodeExporter]

Ahhh, so skipping the shading engine doesn't help in this case because 
traversing to something that has that many incoming connections is slow?

Original comment by miller.lucas on 18 Sep 2014 at 5:48