Alembic Conventions

335 views
Skip to first unread message

François Beaune

unread,
Jun 15, 2018, 11:24:43 AM6/15/18
to alembic-discussion
Hi,

I'm trying to understand the conventions used or assumed by Alembic / Imath. I've searched this list and the web quite extensively but I couldn't find a comprehensive list of conventions. This is my attempt at gathering them all in one place.

Here is what I have so far:

    - Right-handed coordinate system
    - Y is up
    - Matrices are row-major
    - Translation components are stored in the bottom row
    - Polygons winding order is clockwise

What I'm still missing:

    - Orientation of cameras when their transform is identity?
    - Orientation of lights when their transform is identity?

Would greatly appreciated corrections and additions!

Best,
Franz

Lucas Miller

unread,
Jun 15, 2018, 5:54:28 PM6/15/18
to alembic-d...@googlegroups.com
> What I'm still missing:
>
> - Orientation of cameras when their transform is identity?
> - Orientation of lights when their transform is identity?

I always mess these questions up the first time I try to answer them,
but I think the orientation for cameras and lights are the same, and
probably Maya-like?

Lucas

François Beaune

unread,
Jun 15, 2018, 6:23:11 PM6/15/18
to alembic-d...@googlegroups.com
Hi Lucas,

And that would be? Pointing toward Z- (i.e. away from the viewer)?

I'm asking these questions because I'm writing an Alembic importer and I'm having all kind of difficulties properly importing geometry and cameras coming from Max, Maya, etc. E.g. I can import geo from Maya just fine but then when importing geo from Max objects are upside down, etc. As for camera import my implementation is currently not working at all despite all my efforts. If I knew what Alembic is expecting exactly it would solve that half of the problem and I could concentrate on finding out the exact conventions of the host system (in this case Assimp).

At this point I'd rather adopt a scientific approach instead of continuing randomly fiddling with things.

Franz

Dorian Fevrier

unread,
Jun 17, 2018, 5:29:01 AM6/17/18
to alembic-d...@googlegroups.com
IMHO, there is no right answer to this:

Each software has it's own axis direction (Maya, Max, Renderman, etc.). I would say alembic doesn't care and have no "standard" axis: Objects are stored the way they are provided.

Once you know this, this mean you need to "detect" from where an alemic came from and provide informations by yourself.

In guerilla, the matrix type is modifiable:

Image en ligne

Guerilla is "renderman axis" by default and apply some modifications (depending on the selected ones) to put imported matrices in its own matrix.

http://guerillarender.com/doc/2.0/User Guide_Scene Graph_Transform.html

So the question is: What is your reference matrix: The matrix of the application you want to import alembics in.

Once you know that, you have to detect (or, even better, provide an explicit way) and convert an imported hierarchy to your application axises.

Hope that helps.

Dorian

François Beaune

unread,
Jun 18, 2018, 3:34:34 AM6/18/18
to alembic-d...@googlegroups.com
Hi Dorian,

I was really hoping that Alembic would specify clearly and unambiguously what coordinate system it uses as this seems fundamental to a baked geometry interchange format, unfortunately I couldn't find such statements anywhere.

That said, my (limited) experience so far seems to indicate that there is a de facto coordinate system convention: I'm able to indifferently import Alembic files generated from 3ds Max or Maya without any special handling, and none of the Alembic importers I could find (Unreal, Unity, 3ds Max, Maya...) allow to specify which way is up. Guerilla is the first importer I've seen that offers this feature. Is it really useful?

Am I missing some documentation that everyone else knows about? I'm aware of the official docs (https://docs.alembic.io/) as well as the old Google Code site (https://code.google.com/archive/p/alembic/wikis) but these are really sparse such as how to properly handle scopes, animation sampling and interpolation, etc.

Franz

--
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.

Dorian Fevrier

unread,
Jun 18, 2018, 6:31:04 AM6/18/18
to alembic-d...@googlegroups.com
> this seems fundamental to a baked geometry interchange format

IIRC, .obj doesn't have any information about coordinate system, this mean you often had to modify the imported geometry depending on which software it was exported.

It's the same for time I guess. Most Alembic exporters use seconds as unit but I'm not sure it's states anywhere. I guess you could technically export in frame base but most applications will not play the animation properly.

But I agree, it's an important thing. I suspect Alembic authors didn't want to "choose" a coordinate system to avoid any friction with various software peoples... I dunno.


> That said, my (limited) experience so far seems to indicate that there is a de facto coordinate system convention: I'm able to indifferently import Alembic files generated from 3ds Max or Maya without any special handling, and none of the Alembic importers I could find (Unreal, Unity, 3ds Max, Maya...) allow to specify which way is up.

The fact those applications (Unreal, Unity, 3ds Max, Maya...) are able to read an alembic and translate its coordinate system to their own doesn't mean there is one single coordinate system. Instead, I suppose they "detect" which software was the original exporter and apply a transformation matrix to match their internal coordinate system.

It could be interesting to remove the metadatas from thos Alembic files and see if the softwares can still import them properly.


> Guerilla is the first importer I've seen that offers this feature. Is it really useful?

This parameter is not specific to the Alembic importer, it's a parameter of any transform node. References in Guerilla are not Alembic only but also .obj so yes, it's useful (even for more tricky cases like scripts like rib_to_obj which read a rib and translate to obj. This is not "how it should be done" but the fact you have such parameter make it an option).

Once again, if you import an Alembic in Guerilla, I suspect it will "detect" the original software (metadata) and select the "to guerilla coordinate system" matrix accordingly and apply them to the root.

Guerilla use the same coordinate system than Renderman (left handed Y up).


François Beaune

unread,
Jun 18, 2018, 8:25:29 AM6/18/18
to alembic-d...@googlegroups.com
On Mon, Jun 18, 2018 at 12:30 PM, 'Dorian Fevrier' via alembic-discussion <alembic-d...@googlegroups.com> wrote:
> this seems fundamental to a baked geometry interchange format

IIRC, .obj doesn't have any information about coordinate system, this mean you often had to modify the imported geometry depending on which software it was exported.

Indeed, and that's not a virtue by any measure :)

But I agree, it's an important thing. I suspect Alembic authors didn't want to "choose" a coordinate system to avoid any friction with various software peoples... I dunno.

There is no denying that Alembic has been a success and has been widely adopted by studios, but I would find it rather disappointing if Alembic truly hadn't settled on a coordinate system convention... It simply makes it a lot more painful to use: instead of requiring one coordinate system conversion (Alembic -> host system), you now need to support many (N "flavors" of Alembic -> host system)...

> That said, my (limited) experience so far seems to indicate that there is a de facto coordinate system convention: I'm able to indifferently import Alembic files generated from 3ds Max or Maya without any special handling, and none of the Alembic importers I could find (Unreal, Unity, 3ds Max, Maya...) allow to specify which way is up.

The fact those applications (Unreal, Unity, 3ds Max, Maya...) are able to read an alembic and translate its coordinate system to their own doesn't mean there is one single coordinate system. Instead, I suppose they "detect" which software was the original exporter and apply a transformation matrix to match their internal coordinate system.

That was my suspicion as well but (1) I couldn't find any such detection code in the open source Alembic plugins; moreover I've checked various Alembic files and often times they don't have any relevant metadata that would allow to unambiguously identify the application that created them. Moreover my Alembic importer can import 3ds Max and Maya files without any special handling.

So I don't know, that doesn't seem to be it.

> Guerilla is the first importer I've seen that offers this feature. Is it really useful?

This parameter is not specific to the Alembic importer, it's a parameter of any transform node. References in Guerilla are not Alembic only but also .obj so yes, it's useful (even for more tricky cases like scripts like rib_to_obj which read a rib and translate to obj. This is not "how it should be done" but the fact you have such parameter make it an option).

I see. Then I'd argue that this parameter is not useful in the context of Alembic files. From my experience Alembic files follow an untold convention which in practice makes them host app-independent.

Franz

Francois Chardavoine

unread,
Jun 18, 2018, 12:04:04 PM6/18/18
to alembic-d...@googlegroups.com
To be clear, Alembic is explicit (in its guidelines, if not its code) about the initial items that Francois B listed at the start of this thread - for instance the choice of right-handed coordinate system is listed in this old wiki (which admittedly hasn't preserved its formatting when google code went away and would merit porting to GitHub's wiki):
https://code.google.com/archive/p/alembic/wikis/Alembic_Geometric_Types.wiki

It's true that in some cases we've relied on inferring the standards from the reference implementations like the maya exporter (such as default directions for cameras), which could have been more explicitly stated as part of the spec. Lights I don't recall if it's clearly stated or inferable anywhere.

F.



On Mon, Jun 18, 2018 at 5:25 AM, François Beaune <dic...@gmail.com> wrote:

--
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+unsubscribe@googlegroups.com.

François Beaune

unread,
Jun 18, 2018, 12:10:30 PM6/18/18
to alembic-d...@googlegroups.com
Thanks for clarifying François.

It would be great to list those conventions here (if not on GitHub's wiki). Knowing that it's using a right-handed coordinate system is a good starting point but it's far from enough. Despite considerable investigation (including looking at the code) I haven't been able to get clear, unambiguous statements regarding which conventions are used/assumed.

My importer is now working correctly but I ended up having to transpose matrices coming from Alembic but I don't have a clear explanation for that. In theory I shouldn't have to do that, but I'm not 100% clear on the conventions used by the host system either so there's that..

Franz

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discussion+unsub...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages