Handness in Alembic format?

[Syoyo Fujita]

As Colin Doncaster pointed out in "UV inversion or not" discussion thread,
How Alembic format defines its handness in the specification is also
important for exchanging Alembic data between CG softwares as a
"industry-standard" format.

I have just digged into alembic source but cannot find any information
on handless, so it seems at this time Alembic borrows most of
geometrical properties from Maya(i.e, handless is left-handed).

I think we also need to clarify how Alembic defines handness,
orientation, up vector and other geometrical properties for an
industry strength format.

--
Syoyo

[Steve LaVietes]

While much of it is defined, we'll need to make sure the
documentation/specification is clearer about this stuff.

A few things which have come in discussions before:
1) Alembic is "right-handed"
2) Polygon winding order is counter-clockwise (matches RenderMan,
opposite of Maya)
3) Y is up

-stevel

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

[Francois Chardavoine]

This is actually pretty explicit in the geometry types wiki document:
http://code.google.com/p/alembic/wiki/Alembic_Geometric_Types
(although we haven't yet added the clarification on how UV coordinates
are expressed to that document)

Francois -

[Syoyo Fujita]

Thanks Steve and Francois!

> This is actually pretty explicit in the geometry types wiki document:
> http://code.google.com/p/alembic/wiki/Alembic_Geometric_Types

Ah, I have not noticed that wiki page claims geometric properties...

>> 2) Polygon winding order is counter-clockwise (matches RenderMan,
>> opposite of Maya)

But wiki says Polygon order is clockwise. Which is correct?

[Steve LaVietes]

I was mistaken about the direction in my previous mail. It's clockwise. I was correct about matching RenderMan and being opposite of Maya, though. The reference implementations of the Maya reader and writer flip the winding order on the way in and out.

-stevel

[Syoyo Fujita]

Hello Steve,

On Mon, Oct 17, 2011 at 3:17 PM, Steve LaVietes
<steve.l...@gmail.com> wrote:
> I was mistaken about the direction in my previous mail. It's clockwise. I was correct about matching RenderMan and being opposite of Maya, though. The reference implementations of the Maya reader and writer flip the winding order on the way in and out.

Ah, OK.

BTW, RenderMan specification is very elastic on geometric properties,
it can change handness and orientation dynamically in the scene
description.
One exception is the coordinate system where shading is done. it is
handness dependent, thus you cannot share single shader with
left-handed primitives and right-handed primitives.
But the shading is not the scope of alembic format... so we might not
need to discuss it here.

> On Oct 16, 2011, at 11:00 PM, Syoyo Fujita <syoyo...@gmail.com> wrote:
>
>>
>>>> 2) Polygon winding order is counter-clockwise (matches RenderMan,
>>>> opposite of Maya)
>>
>> But wiki says Polygon order is clockwise. Which is correct?
>

[Steve LaVietes]

If I understand correctly, "Orientation" in RenderMan terms is
handedness. That is configurable in RenderMan.

The "clockwise" I mention is the winding order of the vertices of a
polygon within a mesh. I don't believe this is impacted by the current
"Orientation" state.

-stevel

[ericg]

Hi All,
First post to this forum... so sorry if I'm late to the discussion.

Excerpt from RenderMan docs:

"The geometric normal of the polygon is computed by computing the normal of the plane containing the polygon (unless it is explicitly specified). If the current orientation is left-handed, then a polygon whose vertices were specified in clockwise order (from the point of view of the camera) will be a front-facing polygon (that is, will have a normal vector that points toward the camera). If the current orientation is right-handed, then polygons whose vertices were specified in counterclockwise order will be front-facing. The shading normal is set to the geometric normal unless it is explicitly specified at the vertices."

Renderman maintains BOTH orientation for the current coordinate system AND for the current primitive:

"The current orientation of primitives is maintained as part of the graphics state independent of the orientation of the current coordinate system. The current orientation is initially set to match the orientation of the initial coordinate system, and always flips whenever the orientation of the current coordinate system flips. It can also be modified directly with RiOrientation and RiReverseOrientation. If the current orientation is not the same as the orientation of the current coordinate system, geometric primitives are turned inside out, and their normals are automatically flipped."

I think it not uncommon to see primitives that have been flipped while modeling (reflection, or symmetric edits) get expressed with CCW vertices and an Orientation or ReverseOrientation call to inform the renderer.

Funny enough we were just discussing this issue this morning, and we think that not being able to express winding order on a per-primitive basis causes some problems in other parts of our pipeline where we are creating vertex order dependent data (baked per-face textures) that is external to the geometry files, and travels through the pipeline (under the assumption that topology is not changing).

[Steve LaVietes]

Thanks for the further clarification. We must have checks earlier in
our pipeline for this as we haven't historically encountered
per-primitive orientation changes at our facility (going to either
prman or arnold.).

As Alembic is less flexible than the RenderMan spec on this issue, it
seems that whatever tool has enough knowledge to flag a per-primitive
Orientation or ReverseOrientation call would have enough knowledge to
flip the vertex order when writing out to Alembic.

I'm not sure what impact that would have for baked per-face textures, though.

-stevel

[ericg]

On Monday, October 17, 2011 2:41:51 PM UTC-7, Steve LaVietes wrote:

As Alembic is less flexible than the RenderMan spec on this issue, it
seems that whatever tool has enough knowledge to flag a per-primitive
Orientation or ReverseOrientation call would have enough knowledge to
flip the vertex order when writing out to Alembic.

These are very different tools at opposite ends of the pipeline.
In the first case it's modeling tools (Maya) and a large number of plugins and exporters,
coming from different places, some built internally, some 3rd party.

Rib generation happens much further down the pipe, after many tools have touched that data,
and some of the data may have gone through other data transformations.

In baking volumetric and topology dependent texture data, and passing that down through the pipeline,
we can't be changing the corresponding topology without somehow changing that data as well.
This is especially difficult where a lot of the tools working w/ the geometry aren't aware of that external data,
so it's imperative that we can either keep the topology unchanged, or explicitly tag it such that it can be corrected
when consumed downstream.

Textures are just one example, but this an issue for any topology dependent data stored in external caches/data files
that need to be passed down and consumed in the renderer (either by shaders or other procedurals).

Thanks,
Eric

[Steve LaVietes]

This is a tricky case.

We have to balance adding flexibility against its resulting burden
upon each reader/writer client.

In previous public discussions, the consensus was consistently, "pick
one way" -- even though there wasn't always agreement about which "one
way."

Most systems are not as flexible as prman in this regard and I'm
personally reluctant to force every tool be aware of these
possibilities. I understand that might be a difficult fit into your
existing workflows but I'm not sure how common a problem this is
elsewhere. If this is a unique need, Alembic does allow custom
properties and metadata to be attached to any object.

-stevel

[Syoyo Fujita]

Hello Steve and all,

Thanks for valuable information.

> If I understand correctly, "Orientation" in RenderMan terms is
> handedness.

Ah, yes, you are right.
Handness is configurable with "Orientation" and "Scale" camera space.

> In baking volumetric and topology dependent texture data, and passing that down through the pipeline,
> we can't be changing the corresponding topology without somehow changing that data as well.
> This is especially difficult where a lot of the tools working w/ the geometry aren't aware of that external data,
> so it's imperative that we can either keep the topology unchanged, or explicitly tag it such that it can be corrected
> when consumed downstream.

Ah, I forgot baking/texture things. Yes it will definitely happen in
that configuration...
Thanks for pointing out the problem.

--
Syoyo

[Aghiles]

Hello,

On Nov 3, 12:55 pm, Syoyo Fujita <syoyofuj...@gmail.com> wrote:
> Hello Steve and all,
>
> Thanks for valuable information.
>
> > If I understand correctly, "Orientation" in RenderMan terms is
> > handedness.
>
> Ah, yes, you are right.
> Handness is configurable with "Orientation" and "Scale" camera space.

It is not _exactly_ that. RiOrienation and RiReverseOrientation do
define the orientation in which the geometry is presented to the
renderer (Note that RiOrientation can take 4 differents values:
inside, outside, lh and rh).
There is also the orientation of the current coordinate system, which
can either be left-handed or right-handed (the determinant of the
current matrix is used to determine that).
Both these informations are used by the renderer to properly orient
the normals.

You were probably referring to RiScale because a negative scale will
change the orientation of the current coordinate system but there are
other ways to achieve this result in RenderMan (RiTransform ... )

Here is a post from Rick Lamont, circa 1998, that will gives some more
insight.

http://groups.google.com/group/comp.graphics.rendering.renderman/browse_thread/thread/fe1cfb226fd4141d/3d3ae2971a5db355

-- aghiles