polygon winding order

[Jonathan Gibbs]

I want to revive this thread again for a moment. Alembic is defined as
using a clockwise (aka left-handed) vertex order, but all the tools we
use seem to be counter-clockwise. In the case of a polygon mesh with
explicit normals, reversing the verts isn't perhaps a big deal,
however the implicit geometric normal flips.

However, in the case of a subd which generally doesn't have explicit
normals, the normal of the implicit surface is flipped when the vertex
order is changed.

It seems tough to deal with Alembic being clockwise when using it to
go between apps which are both counter-clockwise. As long as some apps
exists which are clockwise, we probably have to deal with this one way
or another, but it seems wise for Alembic to go with what seems like
the clear majority (counter-clockwise).

Is it worth considering letting Alembic store either order and tag the
mesh to indicate which order is used?

How are people with mixed pipelines dealing with the difference?

On a related topic, should it be documented specifically for the
NuPatch which way the implicit normal is? (dPdu x dPdv or the other
way?) Houdini and Maya seem opposite in this reguard and it's been a
tremendous pain.

--jono

[brian leair]

Hi Jono,

You are right. We've had a few emails about this on the alembic-dev list that we're documenting one thing, but by coincidence I think everything seems to be reading/writing counter-clockwise.   Regardless, Alembic needs to be consistent and document whichever option we can all converge upon.

In terms of adding a tag and allowing both windings, this would allow the writer to write whatever the native application used without translation, but then the read side would have to be able to support both and translate on read.

If we go with a one single choice, then if your application matches Alembic's definition life is easy, but if not you have to translate on both read and on write.  If only there world had a single standard, but that's the thing about standards, there are so many of them. :)

I'd like to hear the opinions from the rest of the group. Should we have a single option, or should we add a tag and allow both. I have a slight preference for a single choice, but we haven't achieved that yet so...

We've been busy chasing  urgent stuff (bugs, features, the 0.93 release) but this is an important detail so thanks for bringing this issue back up.

-brian

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

If I understand correctly, polygon winding order is independent of
overall handedness.

While there was an earlier message about Alembic assuming left-handed
data, I believe it's actually right-handed.

I've confirmed that we're sending right-handed data to both prman and
arnold out of our in-house tools. (Either renderer can be configured
to be left or right-handed.) We're using the vertex order directly as
currently described in Alembic without issue on both polymeshes (with
user-defined normals) and subdmeshes.

That winding order is opposite of what's described in maya. We do that
flip on the way in or out of maya.

I'd lean toward a single supported winding order. I'm biased towards
the way it is now -- in part because it's working for us across
multiple renderers and packages already.

[brian leair]

Hi Steve,

Thanks for the clarification. The library was consistent, just the doc and my understanding was off. I should have looked at the code first. 

I've corrected the wiki page and doc/Alembic-Geometric-Types.txt, and I agree with what you said. Given that the library has been consistent, let's stick with a single order and coordinate system.

Thanks,
-brian

--

[Pete Segal]

FWIW, I strongly prefer a single winding order (to simplify the code). I
generally prefer CCW, as most packages (including ours) use it, but since I
already have the CW code working, I'm less concerned. As long as it's
documented correctly, it's less of an issue.

Pete

--

[Jeremy Cowles]

I think it's a question of simpler code vs. the ability to optimize
your pipeline. If you know that every tool you use needs CCW or CW
winding, it would be nice to store your data in that format.

A helper function would actually reduce the client code complexity;
it's really just pushing the complexity around, it doesn't go away.

But I agree with Pete, it's really not that big of a deal either way
as long as it's documented and consistent.

--
Jeremy

> For more options, visit this group athttp://groups.google.com/group/alembic-discussion?hl=en

[Jonathan Gibbs]

Thanks for the replies.

+1 on the plan to just lock it down as CW. Looks like it's easier to
flip over than I thought, and the tools are actually more varied
between CW and CCW than I thought.

I would like to lock down too if N on a nurbs patch is dPdu x dPdv or
dPdv x dPdu. I'm pretty sure Maya and Houdini disagree here, and
fixing it in converters is harder because if you reverse U or V to fix
the normal, the parametric UVs are changed.

--jono