abc. geo not matching in maya
2,933 views
Skip to first unread message
NunoPereira
May 3, 2012, 11:58:03 AM5/3/12
to alembic-discussion
Hello guys,
We would like to have your input on something that has been happening
to us here at Prime Focus with when exporting an abc. cache.
The export runs and seems to output no errors. When we import the abc
cache back into maya some of the objects are not correctly rotated as
they
were in the initial animation. All the objects have the same topology
and configuration (duplicated bricks) and it only happens to some of
them. This happens happens (so far) only in one specific example and
the objects have RTS and visibility transforms applied only.
What we found quite odd is that no matter what we do the alembic cache
always comes out the same way. Initially we thought on local
transforms not going through, or world space vs local space etc but
none of these has an effect at all the way alembic seems to write the
abc file. The animation comes out apparently fine but the final
rotation of the objects is completely wrong. This seems to happen only
with rotation.
What is not making sense for us is, if alembic writes out pure vertex
data just like as a point cloud, object rotations or scaling should
not have any impact on the final output of the .abc file, since for
alembic every transform is just another vertex translation.
On the development process of implementing alembic in our pipeline we
only came across with this behavior on this specific instance. It
doesn't seems to be a major issue since no one else, to our knowledge,
has experienced this. It's just a bit worrisome that we don't seem to
be able to reproduce the problem nor debug it properly. We did
everything we can think of to rule out user error but that always
remains a possibility...
Any thoughts?
Cheers,
Nuno
We would like to have your input on something that has been happening
to us here at Prime Focus with when exporting an abc. cache.
The export runs and seems to output no errors. When we import the abc
cache back into maya some of the objects are not correctly rotated as
they
were in the initial animation. All the objects have the same topology
and configuration (duplicated bricks) and it only happens to some of
them. This happens happens (so far) only in one specific example and
the objects have RTS and visibility transforms applied only.
What we found quite odd is that no matter what we do the alembic cache
always comes out the same way. Initially we thought on local
transforms not going through, or world space vs local space etc but
none of these has an effect at all the way alembic seems to write the
abc file. The animation comes out apparently fine but the final
rotation of the objects is completely wrong. This seems to happen only
with rotation.
What is not making sense for us is, if alembic writes out pure vertex
data just like as a point cloud, object rotations or scaling should
not have any impact on the final output of the .abc file, since for
alembic every transform is just another vertex translation.
On the development process of implementing alembic in our pipeline we
only came across with this behavior on this specific instance. It
doesn't seems to be a major issue since no one else, to our knowledge,
has experienced this. It's just a bit worrisome that we don't seem to
be able to reproduce the problem nor debug it properly. We did
everything we can think of to rule out user error but that always
remains a possibility...
Any thoughts?
Cheers,
Nuno
Francois Chardavoine
May 3, 2012, 12:15:43 PM5/3/12
to alembic-d...@googlegroups.com
Hi Nuno -
Alembic does not write out "pure vertex data" - it actually stores any transform data (such as rotations or scales) at each level of the hierarchy, and shape vertex positions are stored in local space.
As far as troubleshooting, it would be great if you could send us a file that exhibits the problem (with the exact AbcExport and AbcImport commands you're using). Perhaps send us a private email if you'd rather not post the scene on the "Issues" bug tracker. Otherwise, from a troubleshooting point of view, I might check to see if the rotation orders (or maybe rotation pivots) are different on the specific bricks that are behaving wrong. Alembic should handle all that properly, but it's certainly possible that there's a bug somewhere.
Francois.
Alembic does not write out "pure vertex data" - it actually stores any transform data (such as rotations or scales) at each level of the hierarchy, and shape vertex positions are stored in local space.
As far as troubleshooting, it would be great if you could send us a file that exhibits the problem (with the exact AbcExport and AbcImport commands you're using). Perhaps send us a private email if you'd rather not post the scene on the "Issues" bug tracker. Otherwise, from a troubleshooting point of view, I might check to see if the rotation orders (or maybe rotation pivots) are different on the specific bricks that are behaving wrong. Alembic should handle all that properly, but it's certainly possible that there's a bug somewhere.
Francois.
Luke Emrose
May 3, 2012, 12:35:51 PM5/3/12
to alembic-d...@googlegroups.com
Just to tick off a few things I've seen that tend to crop up in similar scenarios.
--
Luke Emrose
aka evolutionary theory
www.evolutionarytheory.com
www.soundcloud.com/evolutionarytheory
www.reverbnation.com/evolutionarytheory
http://www.facebook.com/pages/evolutionary-theory/110717958952413
1.) Are you sampling the file at exactly the same points in time at which is was written? i.e. are you removing interpolation from the list of possible issues?
2.) Are you writing out the same sample times for the mesh and transform data blocks? i.e. are you ensuring that any data is written out "in lock step" across both vertex and transform data?
L
--
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
Luke Emrose
aka evolutionary theory
www.evolutionarytheory.com
www.soundcloud.com/evolutionarytheory
www.reverbnation.com/evolutionarytheory
http://www.facebook.com/pages/evolutionary-theory/110717958952413
NunoPereira
May 3, 2012, 12:49:27 PM5/3/12
to alembic-discussion
Hi Francois,
Thanks for the quick reply. We were really under the impression that
alembic was writing caches pretty much like as point cloud system.
Thanks for the insight. It's good to know that it actually wirtes out
transform data on hierarchic levels. We are still at a very early
development stage but this surely seems to open our game with pipeline
implementation possibilities.
As for the export commands, the explained behaviour even happens with
the standard UI Maya export command and through the script editor with
simply the following:
import maya.cmds as cmds
objLs = cmds.ls(sl=True)
cmds.AbcExport(j="-file C:\\PATH\\%s" % objLs[0] + ".abc -fr 1001 1150
-uv -wfg -ws -wv -rt %s" % objLs[0])
Nuno
On May 3, 5:15 pm, Francois Chardavoine
Thanks for the quick reply. We were really under the impression that
alembic was writing caches pretty much like as point cloud system.
Thanks for the insight. It's good to know that it actually wirtes out
transform data on hierarchic levels. We are still at a very early
development stage but this surely seems to open our game with pipeline
implementation possibilities.
As for the export commands, the explained behaviour even happens with
the standard UI Maya export command and through the script editor with
simply the following:
import maya.cmds as cmds
objLs = cmds.ls(sl=True)
cmds.AbcExport(j="-file C:\\PATH\\%s" % objLs[0] + ".abc -fr 1001 1150
-uv -wfg -ws -wv -rt %s" % objLs[0])
Nuno
On May 3, 5:15 pm, Francois Chardavoine
NunoPereira
May 3, 2012, 1:23:59 PM5/3/12
to alembic-discussion
Hi Luke,
Originally we had in fact a mismatch of sampling and step evaluation,
as the animation had
fractionary keyframes and we were evaluating every 1.0 frames. We
thought that had had to be it, but after
evaluating up to very 0.0001 frames we get the same result. We also
snapped all the animation samples in maya to an integer and
re-exported re-evaluating at every 1.0 frame. Same result. One thing I
should mention though is that *all* pivots are off center outside the
bbox of the objects.
We don't think that should have an impact on the export process as the
issue only happens in specific blocks.
Again we did all we could think of but nonetheless we keep having the
feeling that we keep missing something pretty basic or silly on our
end.
We just wanted to put this out there so a few more seasoned heads
could throw their 2 cents at it.
@Francois
We have sent a .ma that reproduces the problem via weTransfer.
Thanks guys.
Nuno
On May 3, 5:35 pm, Luke Emrose <evolutionarythe...@gmail.com> wrote:
> Just to tick off a few things I've seen that tend to crop up in similar
> scenarios.
>
> 1.) Are you sampling the file at exactly the same points in time at which
> is was written? i.e. are you removing interpolation from the list of
> possible issues?
> 2.) Are you writing out the *same *sample times for the mesh and transform
> aka *evolutionary theory*www.evolutionarytheory.comwww.soundcloud.com/evolutionarytheorywww.reverbnation.com/evolutionarytheoryhttp://www.facebook.com/pages/evolutionary-theory/110717958952413
Originally we had in fact a mismatch of sampling and step evaluation,
as the animation had
fractionary keyframes and we were evaluating every 1.0 frames. We
thought that had had to be it, but after
evaluating up to very 0.0001 frames we get the same result. We also
snapped all the animation samples in maya to an integer and
re-exported re-evaluating at every 1.0 frame. Same result. One thing I
should mention though is that *all* pivots are off center outside the
bbox of the objects.
We don't think that should have an impact on the export process as the
issue only happens in specific blocks.
Again we did all we could think of but nonetheless we keep having the
feeling that we keep missing something pretty basic or silly on our
end.
We just wanted to put this out there so a few more seasoned heads
could throw their 2 cents at it.
@Francois
We have sent a .ma that reproduces the problem via weTransfer.
Thanks guys.
Nuno
On May 3, 5:35 pm, Luke Emrose <evolutionarythe...@gmail.com> wrote:
> Just to tick off a few things I've seen that tend to crop up in similar
> scenarios.
>
> 1.) Are you sampling the file at exactly the same points in time at which
> is was written? i.e. are you removing interpolation from the list of
> possible issues?
> data blocks? i.e. are you ensuring that any data is written out "in lock
> step" across both vertex and transform data?
>
> L
>
> step" across both vertex and transform data?
>
> L
>
Luke Emrose
May 3, 2012, 7:12:26 PM5/3/12
to alembic-d...@googlegroups.com
Hi Nuno,
Can you please send me the details about the file and the scene to investigate further?
Also, you might already know this, but I'd advise against using the pivot offsets available in maya.
In general they are pretty evil, and whilst I know that most riggers seem to be obsessed with them, they simply add complexity to the otherwise simple concept of a transform matrix. When you add up all the "hidden" transforms in maya, you end up with 14 of them, if you animate the pivot offsets you are even more screwed, because mathematically, that's the equivalent of taking a bunch of data, and flattening it out - removing most of the original meaning, so when you imagine that these are all concatenated together "magically" in the background, you can see this can be a recipe for disaster.
I could probably recommend attempting to re-organize the rig with physical transforms replacing the pivot offsets and giving that a go, which would indicate whether Alembic is getting that part right (which, by definition, if Maya IS getting it right, which is what you see, and you are exporting everything correctly, then it has to be Alembic).
Just looking at the code now I see that Alembic tries to capture the bizarre pivots and joint transforms that Maya stores, when I think it should really flatten that stuff out by calling something like MFnDagNode inclusiveMatrix - which flattens out all the internal maya offset matrices. Since Alembic is intended to be a format for data transfer, I don't see why it needs to cater for Maya's transform storage when it's the only 3D application I am aware of that doesn't store a transformation matrix as a single matrix. There are loads of places this could be wrong, and my assumption is that Alembic is not capturing ALL of the matrices that you can affect in Maya.
If you wrote out the transforms in world space this could be a reasonable solution also, since the pivots are not needed after you leave Maya, I presume?
regards,
L
Steve LaVietes
May 3, 2012, 7:22:53 PM5/3/12
to alembic-d...@googlegroups.com
Alembic itself allows you store a stack of transform operations per
object -- similar to RenderMan's transformation statements. (One of
the operations is equivalent to RiConcatTransform so you can always
store a single matrix if you choose.) The API allows you to query that
as a single matrix or as the individual operations. We did this to
maintain flexibility without losing interoperability.
If application reader/writer plug-ins want to preserve specific
transform fields, they can construct combinations of operations which
are identifiable to themselves without requiring other reader clients
to know anything about it.
The Maya reference implementation does try to preserve its own fields
when possible. If it's doing it incorrectly in some cases, that's
probably a bug in the plug-in rather than the Alembic library or
format. Additionally, it'd be perfectly reasonable for the Maya writer
to have an option to write only a single matrix per object.
-stevel
object -- similar to RenderMan's transformation statements. (One of
the operations is equivalent to RiConcatTransform so you can always
store a single matrix if you choose.) The API allows you to query that
as a single matrix or as the individual operations. We did this to
maintain flexibility without losing interoperability.
If application reader/writer plug-ins want to preserve specific
transform fields, they can construct combinations of operations which
are identifiable to themselves without requiring other reader clients
to know anything about it.
The Maya reference implementation does try to preserve its own fields
when possible. If it's doing it incorrectly in some cases, that's
probably a bug in the plug-in rather than the Alembic library or
format. Additionally, it'd be perfectly reasonable for the Maya writer
to have an option to write only a single matrix per object.
-stevel
Luke Emrose
May 3, 2012, 7:37:46 PM5/3/12
to alembic-d...@googlegroups.com
Thanks for the clarification Steve, that's what I meant though, it sounds from Nuno's description that the Maya specific plug-in code might be freaking for their user-case.
I think the internal design decisions of Alembic all make perfect sense, I just don't think the Maya plug-in should try and preserve Maya's matrix stack, since that's what .ma and .mb files are for. After you leave Maya (which imo from the Alembic statement of usage on the front page http://www.alembic.io/ states that Alembic IS NOT "...A replacement for native application scene file formats"), you should leave Maya's strange matrix stacks at the door and leave clean.
At least I've found that, or a lot of studios simply replace maya's transform node entirely to avoid the hassle of debugging 14 * 14 possible combinations of errors from their concatenation.
YMMV
regards,
L
--
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
Steve LaVietes
May 3, 2012, 8:01:29 PM5/3/12
to alembic-d...@googlegroups.com
At SPI, we enforce use of a subset of Maya's transform fields -- which
is why we probably haven't encountered the issue. There are cases in
which it's useful to preserve the maya-style fields (at least the ones
we use) so I wouldn't want to get rid of that as an option. I'm all
for an option to bake down to a single matrix for when that
information isn't needed, wanted or easily correct.
-stevel
On Thu, May 3, 2012 at 4:37 PM, Luke Emrose
is why we probably haven't encountered the issue. There are cases in
which it's useful to preserve the maya-style fields (at least the ones
we use) so I wouldn't want to get rid of that as an option. I'm all
for an option to bake down to a single matrix for when that
information isn't needed, wanted or easily correct.
-stevel
On Thu, May 3, 2012 at 4:37 PM, Luke Emrose
NunoPereira
May 4, 2012, 4:50:57 AM5/4/12
to alembic-discussion
Hey Guys,
Here at PF we are also under the impression that it is adsk
implementation of Alembic in Maya
that is not behaving properly, which it is quite odd in itself since
at least that very one should be able to interpret correctly
maya's internal transform matrices. We also suspect that of-center
pivots may be the key for this case, but as Luke said, since riggers
are pretty keen on offsetting pivots all the time it's something that
we need to thoroughly test and rule out. It's almost impossible to
police the non usage of techniques like that
and it's good to know what's going to blow up before the problem
propagates insanely further downstream on the pipeline.
Nonetheless we also feel that maya's matrix stacks should be left out
the door when alembic writes out transformations so, as a software-
agnostic format, alembic can be clean as clean can be. Though we are
also under the impression that it should be possible to compare
transform matrices from both sides rule out the differences adding
them to a final output. This would ensure that whatever you could see
in maya you would get the same result in an .abc. Not sure how
feasible this is or if it's even possible, though.
In any case we'll do some tests down the pivots route and will get
back to you with more news.
@Steve
We'll send you over via weTransfer the same Maya scene we sent to
Francois reproducing this behavior.
Thanks.
Nuno
On May 4, 1:01 am, Steve LaVietes <steve.lavie...@gmail.com> wrote:
> At SPI, we enforce use of a subset of Maya's transform fields -- which
> is why we probably haven't encountered the issue. There are cases in
> which it's useful to preserve the maya-style fields (at least the ones
> we use) so I wouldn't want to get rid of that as an option. I'm all
> for an option to bake down to a single matrix for when that
> information isn't needed, wanted or easily correct.
>
> -stevel
>
> On Thu, May 3, 2012 at 4:37 PM, Luke Emrose
>
>
>
>
>
>
>
> <evolutionarythe...@gmail.com> wrote:
> > Thanks for the clarification Steve, that's what I meant though, it sounds
> > from Nuno's description that the Maya specific plug-in code might be
> > freaking for their user-case.
> > I think the internal design decisions of Alembic all make perfect sense, I
> > just don't think the Maya plug-in should try and preserve Maya's matrix
> > stack, since that's what .ma and .mb files are for. After you leave Maya
> > (which imo from the Alembic statement of usage on the front page
> >http://www.alembic.io/states that Alembic IS NOT "...A replacement for
Here at PF we are also under the impression that it is adsk
implementation of Alembic in Maya
that is not behaving properly, which it is quite odd in itself since
at least that very one should be able to interpret correctly
maya's internal transform matrices. We also suspect that of-center
pivots may be the key for this case, but as Luke said, since riggers
are pretty keen on offsetting pivots all the time it's something that
we need to thoroughly test and rule out. It's almost impossible to
police the non usage of techniques like that
and it's good to know what's going to blow up before the problem
propagates insanely further downstream on the pipeline.
Nonetheless we also feel that maya's matrix stacks should be left out
the door when alembic writes out transformations so, as a software-
agnostic format, alembic can be clean as clean can be. Though we are
also under the impression that it should be possible to compare
transform matrices from both sides rule out the differences adding
them to a final output. This would ensure that whatever you could see
in maya you would get the same result in an .abc. Not sure how
feasible this is or if it's even possible, though.
In any case we'll do some tests down the pivots route and will get
back to you with more news.
@Steve
We'll send you over via weTransfer the same Maya scene we sent to
Francois reproducing this behavior.
Thanks.
Nuno
On May 4, 1:01 am, Steve LaVietes <steve.lavie...@gmail.com> wrote:
> At SPI, we enforce use of a subset of Maya's transform fields -- which
> is why we probably haven't encountered the issue. There are cases in
> which it's useful to preserve the maya-style fields (at least the ones
> we use) so I wouldn't want to get rid of that as an option. I'm all
> for an option to bake down to a single matrix for when that
> information isn't needed, wanted or easily correct.
>
> -stevel
>
> On Thu, May 3, 2012 at 4:37 PM, Luke Emrose
>
>
>
>
>
>
>
> <evolutionarythe...@gmail.com> wrote:
> > Thanks for the clarification Steve, that's what I meant though, it sounds
> > from Nuno's description that the Maya specific plug-in code might be
> > freaking for their user-case.
> > I think the internal design decisions of Alembic all make perfect sense, I
> > just don't think the Maya plug-in should try and preserve Maya's matrix
> > stack, since that's what .ma and .mb files are for. After you leave Maya
> > (which imo from the Alembic statement of usage on the front page
> > native application scene file formats"), you should leave Maya's strange
> > matrix stacks at the door and leave clean.
> > At least I've found that, or a lot of studios simply replace maya's
> > transform node entirely to avoid the hassle of debugging 14 * 14 possible
> > combinations of errors from their concatenation.
> > YMMV
> > regards,
> > L
>
> > matrix stacks at the door and leave clean.
> > At least I've found that, or a lot of studios simply replace maya's
> > transform node entirely to avoid the hassle of debugging 14 * 14 possible
> > combinations of errors from their concatenation.
> > YMMV
> > regards,
> > L
>
Luke Emrose
May 4, 2012, 8:53:51 AM5/4/12
to alembic-d...@googlegroups.com
Nuno,
I have your file, and unless someone beats me to a solution, I'll try and solve it tomorrow.
I don't feel it will be particularly difficult given the excellent state of the Alembic code base.
I imagine a few logical tweaks should fix it, if it is indeed a bug.
regards,
L
Francois Chardavoine
May 4, 2012, 12:03:47 PM5/4/12
to alembic-d...@googlegroups.com
Thanks Luke -
Nuno, I forwarded your scene internally to Lucas and Steve yesterday, but we're pretty swamped right now. If anyone figures out a fix before we do, we'll be happy to integrate it in the next release!
Francois.
Lucas Miller
May 4, 2012, 1:24:29 PM5/4/12
to alembic-d...@googlegroups.com
This appears to be a bug in AbcImport, as the data appears correctly in both Katana and SimpleAbcViewer.
Currently I'm guessing that an incorrect MSpace is being used when setting the pivots, or the pivot order is being set incorrectly?
I'll update the thread again when I have a fix.
Lucas
NunoPereira
May 8, 2012, 6:09:40 AM5/8/12
to alembic-discussion
We carried on with some more testing internally mainly narrowing it
down to pivots but unfortunately we feel that the focal point keeps
eluding us. We are still getting
the same behavior with all pivots are centered as they should. It does
not even seem to matter if the geometry,before cache, has stored
transform data or not. this seem to apply to construction history as
well. The cache is always apparently written/read the same way.
Once again we only seem to witness this in this particular case.
It may very be a case of calling the wrong MSpace when setting pivots
but it may help to know that even with all the pivots centered for
each individual object before cache, exporting it out this way and
importing back the issue persists.
One thing that we noticed during our tests though is that when
importing the .abc cache all the individual objects seem to have the
pivot offset has we would expect.
Though instead of offset down as we did some of the object pivots come
in offset to either right or left of the object, not down.
We are currently undergoing with some more testing with the suspicion
that this may be linked to either bad inheritance of transform/
rotation order or a wrong Y up scenario.
We are starting to have the feeling that the issue is not with the
pivots being offset themselves but rather that this may be triggering
one of this two possibilities.
@Lucas
Does the geometry come up alright inside Katana and SimpleAbcViewer
with animation?
What's your gut feeling guys?
On May 4, 6:24 pm, Lucas Miller <miller.lu...@gmail.com> wrote:
> This appears to be a bug in AbcImport, as the data appears correctly in
> both Katana and SimpleAbcViewer.
>
> Currently I'm guessing that an incorrect MSpace is being used when setting
> the pivots, or the pivot order is being set incorrectly?
>
> I'll update the thread again when I have a fix.
>
> Lucas
>
> On Fri, May 4, 2012 at 9:03 AM, Francois Chardavoine <
>
>
>
>
>
>
>
> francois.chardavo...@gmail.com> wrote:
> > Thanks Luke -
> > Nuno, I forwarded your scene internally to Lucas and Steve yesterday, but
> > we're pretty swamped right now. If anyone figures out a fix before we do,
> > we'll be happy to integrate it in the next release!
> > Francois.
>
> >>> > >http://www.alembic.io/statesthat Alembic IS NOT "...A replacement
> >> aka *evolutionary theory*
>
> read more »
down to pivots but unfortunately we feel that the focal point keeps
eluding us. We are still getting
the same behavior with all pivots are centered as they should. It does
not even seem to matter if the geometry,before cache, has stored
transform data or not. this seem to apply to construction history as
well. The cache is always apparently written/read the same way.
Once again we only seem to witness this in this particular case.
It may very be a case of calling the wrong MSpace when setting pivots
but it may help to know that even with all the pivots centered for
each individual object before cache, exporting it out this way and
importing back the issue persists.
One thing that we noticed during our tests though is that when
importing the .abc cache all the individual objects seem to have the
pivot offset has we would expect.
Though instead of offset down as we did some of the object pivots come
in offset to either right or left of the object, not down.
We are currently undergoing with some more testing with the suspicion
that this may be linked to either bad inheritance of transform/
rotation order or a wrong Y up scenario.
We are starting to have the feeling that the issue is not with the
pivots being offset themselves but rather that this may be triggering
one of this two possibilities.
@Lucas
Does the geometry come up alright inside Katana and SimpleAbcViewer
with animation?
What's your gut feeling guys?
On May 4, 6:24 pm, Lucas Miller <miller.lu...@gmail.com> wrote:
> This appears to be a bug in AbcImport, as the data appears correctly in
> both Katana and SimpleAbcViewer.
>
> Currently I'm guessing that an incorrect MSpace is being used when setting
> the pivots, or the pivot order is being set incorrectly?
>
> I'll update the thread again when I have a fix.
>
> Lucas
>
> On Fri, May 4, 2012 at 9:03 AM, Francois Chardavoine <
>
>
>
>
>
>
>
> francois.chardavo...@gmail.com> wrote:
> > Thanks Luke -
> > Nuno, I forwarded your scene internally to Lucas and Steve yesterday, but
> > we're pretty swamped right now. If anyone figures out a fix before we do,
> > we'll be happy to integrate it in the next release!
> > Francois.
>
> > On Fri, May 4, 2012 at 5:53 AM, Luke Emrose <evolutionarythe...@gmail.com>wrote:
>
> >> Nuno,
>
> >> I have your file, and unless someone beats me to a solution, I'll try and
> >> solve it tomorrow.
> >> I don't feel it will be particularly difficult given the excellent state
> >> of the Alembic code base.
>
> >> I imagine a few logical tweaks should fix it, if it is indeed a bug.
>
> >> regards,
>
> >> L
>
>
> >> Nuno,
>
> >> I have your file, and unless someone beats me to a solution, I'll try and
> >> solve it tomorrow.
> >> I don't feel it will be particularly difficult given the excellent state
> >> of the Alembic code base.
>
> >> I imagine a few logical tweaks should fix it, if it is indeed a bug.
>
> >> regards,
>
> >> L
>
> >>www.evolutionarytheory.com
> >>www.soundcloud.com/evolutionarytheory
> >>www.reverbnation.com/evolutionarytheory
> >>http://www.facebook.com/pages/evolutionary-theory/110717958952413
>
> >> --
> >> 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
>
> > --
> > 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
>
> ...
> >>www.soundcloud.com/evolutionarytheory
> >>www.reverbnation.com/evolutionarytheory
> >>http://www.facebook.com/pages/evolutionary-theory/110717958952413
>
> >> --
> >> 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
>
> > --
> > 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
>
>
> read more »
Luke Emrose
May 8, 2012, 8:19:08 AM5/8/12
to alembic-d...@googlegroups.com
Could it be to do with freeze transforms?
I seem to remember the EVIL EVIL EVIL freeze transforms "feature" of Maya adding a transform that's hidden to the transformation stack rather than actually moving the vertex positions, and that coming back to bite previously.
Maybe that's crept in there?
Lucas Miller
May 9, 2012, 10:06:58 PM5/9/12
to alembic-d...@googlegroups.com
Yup, the animated geometry appears correct when viewed in Katana or SimpleAbcViewer.
If you have time and the resources try out this fix:
For some reason, rotateBy wasn't working very well, so I tried setting the Euler components directly.
Let me know if you have any problems with the fix.
Lucas
NunoPereira
May 10, 2012, 7:44:15 AM5/10/12
to alembic-discussion
Thanks for the fix Lucas. I am downloading the code and pass this on
to our rnd team.
As soon as we have some free resource we'll try this out and will get
back to you with news.
Cheers,
Nuno
Just as a double check as we are now setting Euler rotations directly
the rotation order needs to be preserved/maitained al
On May 10, 3:06 am, Lucas Miller <miller.lu...@gmail.com> wrote:
> Yup, the animated geometry appears correct when viewed in Katana or
> SimpleAbcViewer.
>
> If you have time and the resources try out this fix:http://code.google.com/r/millerlucas-dev/source/detail?r=2dc3f75b31ed...
> > > >>> > >http://www.alembic.io/statesthatAlembic IS NOT "...A replacement
> ...
>
> read more »
to our rnd team.
As soon as we have some free resource we'll try this out and will get
back to you with news.
Cheers,
Nuno
Just as a double check as we are now setting Euler rotations directly
the rotation order needs to be preserved/maitained al
On May 10, 3:06 am, Lucas Miller <miller.lu...@gmail.com> wrote:
> Yup, the animated geometry appears correct when viewed in Katana or
> SimpleAbcViewer.
>
>
> For some reason, rotateBy wasn't working very well, so I tried setting the
> Euler components directly.
>
> Let me know if you have any problems with the fix.
>
> Lucas
>
> For some reason, rotateBy wasn't working very well, so I tried setting the
> Euler components directly.
>
> Let me know if you have any problems with the fix.
>
> Lucas
>
>
> read more »
NunoPereira
May 10, 2012, 7:48:52 AM5/10/12
to alembic-discussion
Just as a double check as Euler rotations are being directly set
the rotation order needs to be preserved/maitained all the time.
I am guessing this as to be kept as the default XYZ rotation order in
maya. Or would any other rotation order work as long it's kept the
same?
Cheers,
Nuno
*apologies for the double post
> > > > >>> > >http://www.alembic.io/statesthatAlembicIS NOT "...A replacement
> ...
>
> read more »
the rotation order needs to be preserved/maitained all the time.
I am guessing this as to be kept as the default XYZ rotation order in
maya. Or would any other rotation order work as long it's kept the
same?
Cheers,
Nuno
*apologies for the double post
>
> read more »
Lucas Miller
May 10, 2012, 4:19:53 PM5/10/12
to alembic-d...@googlegroups.com
You can use whatever rotation order you like, the order will be maintained.
Lucas
> ...
>
> read more »
--
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
Milan Kolar
Sep 3, 2013, 12:42:28 PM9/3/13
to alembic-d...@googlegroups.com
Hi Lucas.
I'm resurrecting this one as we are running into same issues. Caches exported from maya freak out on subframes when imported back to maya, but are fine in any other package. I wanted to try your fix but can't get it to compile whatever I try. Any chance you, or someone here have it compiled for maya 2014 and can confirm, that it fixes the rotation problems?
Thanks
Milan
> >>> > >> alembic-discussion+unsub...@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
>
> >>> > > --
> >>> > > Luke Emrose
> >>> > > aka evolutionary theory
> >>> > >www.evolutionarytheory.com
> >>> > >www.soundcloud.com/evolutionarytheory
> >>> > >www.reverbnation.com/evolutionarytheory
> >>> > >http://www.facebook.com/pages/evolutionary-theory/110717958952413
>
> >>> > > --
> >>> > > 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
> >>> > > 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
>
> >>> --
> >>> 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
> >>> 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
>
> >> --
> >> Luke Emrose
> >> aka *evolutionary theory*
> >>www.evolutionarytheory.com
> >>www.soundcloud.com/evolutionarytheory
> >>www.reverbnation.com/evolutionarytheory
> >>http://www.facebook.com/pages/evolutionary-theory/110717958952413
>
> >> --
> >> 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
> >> 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
>
> > --
> > 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
> > For more options, visit this group at
>
> ...
>
> read more »
--
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
Lucas Miller
Sep 3, 2013, 1:00:44 PM9/3/13
to alembic-d...@googlegroups.com
The AbcImport xform code is up to date in Maya 2014.
Do you have a simple example of this "freak out on subframe"?
Is it an issue with the rotations themselves?
There is an open known issue with the rotations axis here:
Hopefully someone from Autodesk can chime in with a better suggestion on how to set all of the various components of Maya's transform stack.
Lucas
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/groups/opt_out.
Milan Kolar
Sep 3, 2013, 1:46:44 PM9/3/13
to alembic-d...@googlegroups.com
I see.
Well I've done some extra testing and I seem to have narrowed the problem down to Maya parent constraints. The attached scene is really simple rig (let's say a plane with propeller) with one standard parent and one parent constraint. I've exported alembic with Euler filtering turned on and off for comparison. In maya these two are wildly different after import (the one with Euler filter is better but far from perfect), however when imported into Houdini they are identical and reconstruct the animation cleanly and without any glitches in subframes.
I though the problem was the same as mentioned before, but if it's already implemented in maya 2014 that there's clearly some extra dirt going on in maya.
Milan
Lucas Miller
Sep 3, 2013, 2:28:21 PM9/3/13
to alembic-d...@googlegroups.com
What subframes are you sampling on?
You can write out extra subsamples via the -step/-s flag (or -frs / -frameRelativeSample for shutter open and shutter close situations)
AbcExport -j "-root pCube1 -fr 1 48 -s 0.5 -file /tmp/test.abc"
Lucas
--
Diego Garces
Sep 4, 2013, 1:10:18 AM9/4/13
to alembic-discussion
We ran into the same issues. The problem we saw is that the parent constrains likes to flip the rotation axis when you less expect it, so when the alembic node tries to interpolate it it doesn't know which way to go and the interpolated rotation looks bad.
I haven't looked into the newest version, but my conclusions were that the solution would be to reconstruct the whole transformation each time, using quaternions (similar to the fix Lucas did), but since the alembicNode is connected component by component to the transform node, it's not that easy. I guess we would have to change the compute of the node and always connect all the transform attributes, so that the whole transformation can be modified at once during the animation.
Giovani Meneghel
Sep 4, 2013, 9:07:43 AM9/4/13
to alembic-d...@googlegroups.com
> At the end, we end up not using the parent constraint and solved it with skinning and using other constraints as exporting the alembic with extra subsamples resulted in huge files
We do the same here. Sometimes our workaround is to replace constrains with skinning, sometimes we export with more subsamples.
Giovani Meneghel.
Milan Kolar
Sep 4, 2013, 9:55:44 AM9/4/13
to alembic-d...@googlegroups.com
We've done skinning and more subsamples until now too, however the file sizes on certain assets become ridiculously big.
So we ended up mirroring rig hierarchy using the meshes that need to be cached and linking transforms from controllers to geometry directly. then we simply cache the root of the geo hierarchy. So far this seems to be working smoothly, but it's likely to give us problems down the line somewhere I presume.
One way or another, I really hope, that this will get eventually resolved. Preferably on autodesk side.
Milan
Reply all
Reply to author
Forward
0 new messages