Closed GoogleCodeExporter closed 9 years ago
Could you provide a simple scene as an example?
Original comment by miller.lucas
on 16 Nov 2011 at 5:10
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:
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
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
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
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
Original comment by miller.lucas
on 9 Dec 2011 at 5:25
Original comment by miller.lucas
on 9 Dec 2011 at 5:25
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
Fixed in the new released 1.1
Original comment by miller.lucas
on 2 Aug 2012 at 11:11
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
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
Original issue reported on code.google.com by
arcgr...@gmail.com
on 16 Nov 2011 at 4:44