maya plug-in: load a different abc archive from the same alembic node, is it possible?

[Imre Tuske]

Hi,

I'm currently looking at the Maya import plug-in which has two
limitations. The first one is actually more like a bug -- if the
alembic node refers to a non-existing filename (such as a window path
on linux or vice versa) it'll crash Maya.

This I managed to work around in the plug-in code, but the other
question would require more than my less-than-sketchy knowledge of
alembic internals. :) Namely, if you change the archive file name, the
scene won't update accordingly.

First thing is that the filename attribute doesn't affect the output
attributes (can be changed easily, but far from done!)

Of course I realize that changing the filename would require (in the
general case) to have all imported geometry deleted and everything re-
built from the new cache file. (Especially that there are cases where
some imported geometry has no connections at all to the alembic node,
hence it's more difficult to detect that it belongs there.)

For now I'm looking at a simplest case, namely, to change to a
different abc file, where the exact same hierarchy is cached out, only
with different animation (so no need for rebuilding anything in the
scene). However as far as I looked, the alembic cache data is not
stored as a member variable on the node -- next step is to dive into
the alembic internals to see how things really work.

My question before/while I do that is that 1) how could I trigger a
loading of a new cache file easily (any hints appreciated) 2) is this
a planned feature for the Maya plug-in or is it considered an "every
man for himself" extra functionality? ;)


imre

[Lucas Miller]

You first issue was recently solved, it was discovered as part of this issue here:
http://code.google.com/p/alembic/issues/detail?id=161

As for your second issue:
The easiest way to load a new cache file by using a new AbcImport command.

The Alembic node itself is only responsible for it's plugs, it isn't responsible for any of the DAG nodes, so even if the file path were able to be changed it wouldn't be able to create or delete the geometry.

The reason the file path currently isn't an input to the Alembic node is because any slight reordering, addition, or removal of hierarchy from one scene to another would greatly change what is pushed out on the plugs currently connected to DAG nodes in your scene hierarchy.

Lucas

--
You received this message because you are subscribed to the Google
Groups "alembic-discussion" group.
To post to this group, send email to alembic-d...@googlegroups.com
To unsubscribe from this group, send email to
alembic-discuss...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/alembic-discussion?hl=en

For RSS or Atom feeds related to Alembic, see:

http://groups.google.com/group/alembic-dev/feeds

http://groups.google.com/group/alembic-discussion/feeds

[sleg]

The fact that the path to the abc file doesn't update the animation is a pretty big limitation for us atm. This way of referencing animation data without changing, deleting or creating any node in the scene is the main reason I've ever used such caching tools.
We're currently looking at adding this kind of functionality to it.

[John Patrick]

You can always create a maya reference to a file with a single alembic cache.  As part of the animation publish process, you can create a new .abc file and a new .ma file that only contains that imported alembic archive.  Downstream departments then can reference the .ma file, and update it to newer versions when needed.  In other words, since it's not abcImport's job to be a referencing solution, you can wrap Maya's referencing around it.

-JP

On Thu, Nov 17, 2011 at 1:32 AM, sleg <legran...@gmail.com> wrote:

The fact that the path to the abc file doesn't update the animation is a pretty big limitation for us atm. This way of referencing animation data without changing, deleting or creating any node in the scene is the main reason I've ever used such caching tools.
We're currently looking at adding this kind of functionality to it.

--

You received this message because you are subscribed to the Google
Groups "alembic-discussion" group.
To post to this group, send email to alembic-d...@googlegroups.com
To unsubscribe from this group, send email to
alembic-discuss...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/alembic-discussion?hl=en
 
For RSS or Atom feeds related to Alembic, see:
 
http://groups.google.com/group/alembic-dev/feeds
 
http://groups.google.com/group/alembic-discussion/feeds

--
John Patrick
404-242-2675
jspa...@gmail.com
http://www.canyourigit.com

[Simon Legrand]

We looked at this but for other reasons we're not using Maya referencing. The Houdini Alembic loader behaves exactly as we would expect, so we're looking at coding a similar behavior to the Maya side of things.

Simon Legrand
http://slegrand.blogspot.com/

[Francois Chardavoine]

I'm curious why simply calling AbcImport again isn't a viable
solution? I understand that it certainly "feels" like you should be
able to just set a "filepath" attribute on the node to have it point
to a new animation, but from a pipeline point of view does it really
matter whether you're calling setAttr or AbcImport?

Lucas mentioned some of the risks involved with trying to do that
within the AlembicNode itself: there would be internal bookkeeping
needed in case shape order in the file had changed (to remap,
internally, to the proper output plugs). But on top of that, the
following cases could not be addressed at all from within the node:
- shapes being removed from the cache (what behavior would you expect?
Should it set the output mesh to a null object on the missing shapes?)
- attributes no longer being animated or even set in the new cache:
since we'd still be driving those with plugs, they would simply have
some weird undefined value?
- new attributes being animated: since we can't create new
connections, the scene wouldn't reflect that
-> this is ESPECIALLY important if you're using transforms (and the
new cache has a transform animated which wasn't animated in the
previous cache: your shapes will be in the wrong place)
- any static (non animated) values are simply set on the shapes (and
not driven by plugs): so any changes in static attributes would not be
picked up either (this includes xform values)

Basically, while there's controlled cases where this could work (a pre-
defined set of only deforming geometry, no transforms, and no changes
in which attributes are animated or set, and no changes in static
values at all), the general case is much too unreliable to provide
that as a standard feature.

On the other hand, there could be improvements to the AbcImport
command (or even a separate utility function) to help in swapping in a
new abc cache. We would definitely be open to suggestions here, but
that would depend on why you feel making a new call to AbcImport isn't
currently addressing your needs.
Thanks for the input!
Francois

On Nov 17, 8:58 am, Simon Legrand <legrand.si...@gmail.com> wrote:
> We looked at this but for other reasons we're not using Maya referencing.
> The Houdini Alembic loader behaves exactly as we would expect, so we're
> looking at coding a similar behavior to the Maya side of things.
>
>
>
>
>
>
>
>
>
> On Thu, Nov 17, 2011 at 4:47 PM, John Patrick <jspatr...@gmail.com> wrote:
> > You can always create a maya reference to a file with a single alembic
> > cache.  As part of the animation publish process, you can create a new .abc
> > file and a new .ma file that only contains that imported alembic archive.
> > Downstream departments then can reference the .ma file, and update it to
> > newer versions when needed.  In other words, since it's not abcImport's job
> > to be a referencing solution, you can wrap Maya's referencing around it.
>
> > -JP
>

> > On Thu, Nov 17, 2011 at 1:32 AM, sleg <legrand.si...@gmail.com> wrote:
>
> >> The fact that the path to the abc file doesn't update the animation is a
> >> pretty big limitation for us atm. This way of referencing animation data
> >> without changing, deleting or creating any node in the scene is the main
> >> reason I've ever used such caching tools.
> >> We're currently looking at adding this kind of functionality to it.
>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "alembic-discussion" group.
> >> To post to this group, send email to alembic-d...@googlegroups.com
> >> To unsubscribe from this group, send email to
> >> alembic-discuss...@googlegroups.com
> >> For more options, visit this group at
> >>http://groups.google.com/group/alembic-discussion?hl=en
>
> >> For RSS or Atom feeds related to Alembic, see:
>
> >>http://groups.google.com/group/alembic-dev/feeds
>
> >>http://groups.google.com/group/alembic-discussion/feeds
>
> > --
> > John Patrick
> > 404-242-2675

> > jspatr...@gmail.com

[Simon Legrand]

All very good points.

If the abc file is referenced you cannot make or break connections. We don't want to use reference here so it doesn't affect us, but that would be 1 reason.
AbcImport -ct works fine for now and it is our current workaround. However it still doesn't work with a new hierarchy or differently named objects. So it does not solve the problem of different hierarchies anyway.
We don't want to delete and regenerate the shape nodes at all because thanks to maya's painfully linear workflow this breaks all connections. We could list the connections before delete and resolve them after creation, but considering I'm trying to cater for FX, lighting and rigging, this solution seems like it's going to require constant support to fix connections that weren't properly listed and re-add the objects to selection sets render layers and so on and so on.

So those are the reasons why just changing the path is so attractive. We don't have to change the maya graph at all.
Also it would allow us to simply change the path directly in an maya ascii file and reprocess that file for any update, that would be nice too. :)

In our pipeline the hierarchy would never change unless in very specific cases.

I wish we were using Houdini or Katana for lighting but we're not so we have to make do with Maya's dependency graph.

On Thu, Nov 17, 2011 at 6:33 PM, Francois Chardavoine <francois.c...@gmail.com> wrote:

I'm curious why simply calling AbcImport again isn't a viable
solution? I understand that it certainly "feels" like you should be
able to just set a "filepath" attribute on the node to have it point
to a new animation, but from a pipeline point of view does it really
matter whether you're calling setAttr or AbcImport?

If the abc file is referenced you cannot make or break connections. We don't want to use reference here so it doesn't affect us, but that would be 1 reason.
AbcImport -ct works fine for now and it is our current workaround. However it still doesn't work with a new hierarchy or differently named objects. So it does not solve the problem of different hierarchies anyway.
We don't want to delete and regenrate the shape nodes at all because thanks to maya's painfully linear workflow this breaks a lot of connections. You could list the connections before delete and resolve them after creation, but considering I'm trying to cater for FX, lighting and rigging, this solution seems like it's going to require constant support to fix connections that were properly listed and re-add the objects to selection sets and so on and so on.

[btoogood]

> Basically, while there's controlled cases where this could work (a pre-
> defined set of only deforming geometry, no transforms, and no changes
> in which attributes are animated or set, and no changes in static
> values at all), the general case is much too unreliable to provide
> that as a standard feature.
>

Just wanted to chip in and say I think I'm in the camp of believing
it'd be handy to be able to update the path and get an update of the
outPolyMeshes.
This is how we currently work (for char/prop anim) with gto caches and
the gto deformer for characters, and would make adoption of alembic
easier here.

Though I also see the benefit of supporting as many general cases as
possible, and that a lot of things wouldn't play nice with path
swapping. maybe a choice would be best?

> On the other hand, there could be improvements to the AbcImport
> command (or even a separate utility function) to help in swapping in a
> new abc cache. We would definitely be open to suggestions here, but
> that would depend on why you feel making a new call to AbcImport isn't
> currently addressing your needs.
> Thanks for the input!
> Francois

One of my first tests came a cropper with AbcImport not completely
rebuilding my network properly.
Try this:
- AbcImport "/path/to/my/stuff.abc";
- Select some faces on one of the meshes created.
- Press 'Delete'
- AbcImport -connect "rootNodeName" "/path/to/my/stuff.abc";
- deleted faces are restored. deleteComponent node is left dangling.
Appears to be the same for things like polySmoothFace, polyExtrudeFace
etc. Makes it hard to do much in the way of post caching processing.

cheers - hope that's useful info
Ben

[Yasin Hasanian]

Reviving this thread as we are in the same situation having the ability to update animation by a simple path change could tremendously help us big time! All the model topologies and UVs stay the same. Our pipeline is not friendly with nested references so we can't go the Maya referencing route. So, I'm wondering if there has been any updates to this issue. We are on Maya 2015 ext1

I can see from Maya2016 devkit that this feature is sort of implemented but it is commented in the AlembicNode.cpp source code, has anyone tried to use it? If not, is there any solution that can help this case?

Much appreciated!

[Alex Suter]

If you're willing to write your own import/export code there are ways to implement this using current Alembic objects, but I agree with 2011 Francois quoted below who said for the general case it makes things too unreliable.

It would make certain use cases much simpler, for certain. You could create a workflow where you have what we'd call a rest cache that just stores the static UV and topology information and another cache that has the animated transform and deforming geometry information. How it's implemented can be so pipeline specific, though. Really tough to do in a global way that wouldn't directly conflict with someone else's pipeline or between different packages.

Sorry to be a downer about it...

                             -- Alex

--

You received this message because you are subscribed to the Google Groups "alembic-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brad]

I think I have an answer for this to help out if either of you want to give me a direct email. The design if my current pipeline uses our dso to call separate material file, abc uv, abc geo (weather deformed or not) and binds all at render time so you can modify all independent.

Cheers

Brad

Sent from my iPhone

[Yasin Hasanian]

That's good to know Alex. I'm curious however what those inconsistencies are that it makes. In theory it should be trivial enough just to work like GPU cache or Geo cache that changing their path, update the anim on the fly. I'm down with rebuilding the maya alembic if I know where to change in the code as long as it allows just for this feature.
 
bfalk, is that using the exact built-in maya alembic with some added features?

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discussion+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "alembic-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discussion+unsub...@googlegroups.com.

[Brad]

That is using our compiled alembic but it's compatible with maya built in alembic. 

Sent from my iPhone

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discuss...@googlegroups.com.

[Yasin Hasanian]

Cool! As long as it is compatible with the Maya alembic and just lets us update the path, I'm interested to have a look at.
yasin.h...@yahoo.com

Thanks a lot!

[Alex Suter]

Maybe I'm misunderstanding what you want to do, if so I apologize. 

One problem we had with a similar system (not using Alembic) was things getting out of sync between animation and the model. By caching them into one you lose the flexibility of mixing and matching, and it can be a time and disk space hit, but most of the time these days when the lighter gets the cache more of the different elements are in the right places. The animator cached it with exactly the right version of the model for that animation, because that's the one they were using.

Something like Brad's system sounds like what you want... we tend to handle shot composition tasks (which animation goes with which geometry) like you're talking about at a different level than Alembic. 

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discuss...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "alembic-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discuss...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "alembic-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discuss...@googlegroups.com.

[Yasin Hasanian]

That's a very valid point Alex. We are indeed making sure the models are exactly the same as the one coming from anim and not changing topology in order to avoid such inconsistencies which is indeed predictable and should be avoided. On the other hand, having this system in place, would help a lot easily swapping between different animations and have the shot be updated instantly.

Thanks for your input.

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discussion+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "alembic-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discussion+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "alembic-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discussion+unsub...@googlegroups.com.

[Brad]

I think we can show a way to easily switch between versions of each element (material, uv, abc) where if you do reach inconsistency you can easily revert. 

Sent from my iPhone

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discuss...@googlegroups.com.

[Paolo Berto]

Hello everyone,

Multiverse handles this very nicely.

Let's make a braindead example: 1 second of animated (deforming) poly
torus with motion blur (2 motion samples). That is a total of 48
samples.

On the very same "torus.abc" multiverse repo:

35 kb ... initial commit P uv
+ 26 kb ... re-layout all the UVs (same P)
+ 14 kb ... normalize the UVs (same P)
+ 11 kb ... change the P anim completely (deformation) (same UV as previous)
+ 11 kb ... again change the P anim completely (deformation) (same UV
as previous)
+ 84 kb ... smooth P (4x more P and UVs)
======
181 kb total

(I did not speak about materials, but we fully support Maya shading
networks from Maya/3Delight/Arnold) *embedded* in the ABC cache, so
you an also version your material for any revision.

User can interactively swap all these revisions right from the
Multiverse for Maya/Houdini UI.

Of course the more edits, the more gain. We are about to release a new
version of Multiverse with *very exciting* improvements.

Stay tuned.

http://multi-verse.io/plugins/maya/updates/

Paolo

> --
> You received this message because you are subscribed to the Google Groups
> "alembic-discussion" group.

> To unsubscribe from this group and stop receiving emails from it, send an
> email to alembic-discuss...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
paolo berto durante
j cube inc. tokyo, japan
http://j-cube.jp

[Yasin Hasanian]

Just managed to get it compiled with this feature enabled by using some lines from maya2016! So far so good :) Hopefully, it won't surprise us later as long as we can the UV and topologies exactly the same.

Paolo, nice stats. However, we are far enough in production that we should ensure we are staying consistent with the tools we have been using so far.

Thanks all for chiming in.