Maya visualization of alembic caches

[Chadrik]

hi all,

we all know that maya is not the most efficient at dealing with large
quantities of data. i wanted to throw out an idea on this forum and
see if it sticks. i feel that alembic for maya could really use a
node for visualizing the contents of an alembic cache in OpenGL
without actually generating proper maya objects. this will allow
dramatically more data to be displayed than maya would normally be
able to handle. the node itself would not be renderable, but a studio
could hook it up to a procedural like the one for arnold that is
included with alembic.

some core features would be:
- preview LOD: bbox, points, wireframe, shaded
- include and exclude filters based on name globs (e.g. “foo|bar*” )
- ability to identify each object within a maya node network: useful
for things like generating shader assignments for procedurals
(possibly the node is an MPxComponentShape with each component
corresponding to an object in the cache)

i think cortex might have something like this in it, so i can take a
look at how theirs works to get some ideas. MtoA also has a similar
feature for previewing .ass files (like delayed read archives in
renderman), but it lacks the filtering and shader assignment features.

what do people think of this idea? any feedback, especially previous
experience doing something similar, would be greatly appreciated.

-chad

[Francois Chardavoine]

Hi Chad -

This is definitely a valid idea. I think most large facilities have something similar that they've coded up to read and display their internal geometry formats as efficiently as possible. Here at Imageworks we've implemented such a node (which has seen many iterations over the years, as our file formats have evolved) and it's definitely been invaluable across our pipeline. Unfortunately, it's very tied into our internal asset management systems and isn't something we are able to provide as open source.

Francois.

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

[Nelson Yu]

I'd very interested in working on this with you. I need to emulate
3Delight's RIBArchive preview node (a plugin that draws bounding
boxes) by drawing the bboxes of the Alembic geo in Maya.

I may start on the Maya plugin (will start with a MPLocatorNode
derived from AbcImport and call raw OpenGL) tomorrow. What is your
schedule and plan like? Anybody else interested? Is there existing
Alembic OpenGL drawing code?

Nelson

[Carsten Kolve]

> i think cortex might have something like this in it, so i can take a
> look at how theirs works to get some ideas.  MtoA also has a similar
> feature for previewing .ass files (like delayed read archives in
> renderman), but it lacks the filtering and shader assignment features.
>
> what do people think of this idea? any feedback, especially previous
> experience doing something similar, would be greatly appreciated.

Heya -
another idea would be to write an alembic reader/writer for cortex,
which would then give you gl feedback of alembic caches in
maya/houdini/nuke & standalone as well as the ability to manipulate
the data. However you might not need that flexibility?

Cheers,
Carsten
--
// carsten kolve - www.kolve.com

[Horvátth Szabolcs]

> I may start on the Maya plugin (will start with a MPLocatorNode derived from AbcImport and call raw OpenGL) tomorrow. What is your
> schedule and plan like? Anybody else interested? Is there existing Alembic OpenGL drawing code?

We're definitely interested in this at Digic, actually had it planned for development for the near future.
I'm not really sure how various parties could contribute to it though.

Cheers,
Szabolcs

[olliRJL]

Hi,

We've hacked together a maya locator (we call it animaAlembicHolder)
by using code from the SimpleAbcViewer. It's sort of like a bastard
son of the SimpleAbcViewer and a maya locator. Not particularly clean
in any sense but it also didn't take up too much time to "conceive" it
up either.

Some stuff we implemented and find useful:
- objectPath (like in the RiProcedural - only render part of the
hierarchy)
- output bounding box
- output bb center
- simple geometry manager "layer" (if we have multiple instances of
the locator pointing to the same abc we try not to duplicate the data)

Typically we use this so that we have one of these "holding" and
visualizing the abc file and then that gets hooked up to to a
renderman procedural node so that it gets provided with the bounds and
path information.

The thing that I personally would like to see is that there would be
somekind of an AbcGeomGL lib (wasn't there something like this before
the first official release?) which would provide GL drawing
capabilities for all the supported geometric types. And then all the
GL implementations like the (new, proper, hopefully some day to come)
AbcViewer application and all the visualizer nodes for different DCC
packages would use the same code base. This would keep everything a
lot cleaner and make it easier to add for example new geometry types
if the spec gets extended.

oLLi.

[Nelson Yu]

This might be a better long-term solution seeing that Alembic lacks a
python binding and a geometry processing API (not its focus). For
basic rendering purposes, most of us only seem to need a "visual
placeholder" that we can also tag with rendering info.

[brian leair]

Hi Nelson,

We're working on python bindings, but they aren't ready just yet.

The self bounds and child bounds properties were debated initially as to whether they would be useful, but as we're are building workflows their usefulness keeps coming up, which has been great. In several places these "visual placeholders" mean the file can load much faster, and use less memory.

There has been discussion on the alembic team about a stand alone GL library and just in general improving the SimpleAbcViewer, but right now it's ways off on our list of have-to-do tasks.  The SimpleAbcViewer is functional, though it's code structure, and features are very much "Simple".  As always we'd love to see what people come up with in the community.

cheers,
-brian

[Chadrik]

this seems like something that everyone is working on, which is great,
because hopefully we can pool our resources. honestly, the best way
for this project to get started is for someone who already has some
basic raw material -- nothing fancy required -- to make a clone of
the alembic repo, and put their plugin in there and start working in
public. others will latch on, and improve it, and if they also work
in public as well, soon momentum will build and we'll end up with a
solid tool that's part of the official release.

obviously that requires someone to take the first step.

so, why should you release your tool as part of alembic instead of
keeping it for yourself?
1) someone else will end up improving your tool and you'll benefit
from this
2) you won't have to maintain the source yourself 'til the end of time
3) without this open source project your tool couldn't exist in the
first place

1 & 2 are perfectly selfish, and perfectly valid, reasons to
contribute to open source, and they're strong motivators. luma
contributed the color-per-vertex feature to the maya alembic plugin
and 1 & 2 featured heavily in our decision ;)

i certainly hope to get some time scheduled away from MtoA -- my
current primary "psuedo" open-source project -- to work on this
project.

-chad

[olliRJL]

Hi Chadrik,

I absolutely agree with all of your thoughts and I would like to
contribute in some way. However I'm not sure if our implementation is
an ideal starting point for anything sustainable. It is/was hacked
together in middle of a production to give an immediate solution and
as such isn't anything pretty. It currently also lives outside the
alembic source tree and uses our custom build system and also contains
duplicated code from the SimpleAbcViewer so it would need quite a bit
of refactoring to make it sit nicely in a clone repo.

Nevertheless if anyone wants to take a peek I'm more than happy to
share our current solution... so if anyone's interested I can send it
off list or maybe put it somewhere online.

cheers,

oLLi.

[Ashley Retallack]

hi oLLi

Could you put it somewhere for us to see, that way we could start helping with the integration or clean up?

- Ash

[olliRJL]

Hi,

You can grab my code from:
http://tmp.anima.fi/animaAlembicHolder/animaAlembicHolder.zip

In the package there's also a Linux x86_64 Maya2011 build for those of
you who want a quick try without all the building hassle.

Have fun!

o.

On Nov 18, 6:52 pm, Ashley Retallack <ashley.retall...@gmail.com>
wrote:

> hi oLLi
>
> Could you put it somewhere for us to see, that way we could start helping
> with the integration or clean up?
>
> - Ash
>

[Nelson Yu]

Both Olli and I use the OpenGL drawing classes from SimpleAbcViewer,
but I'm finding that it's not very efficient as it updates and draws
everything per frame - which is rather slow for large meshes. i.e A
large "relatively static" mesh takes up to 5x longer to draw than
simply using the existing AbcImport/AlembicNodes (which uses Maya's DG
and can selectively update modified meshes + transforms).

Anybody have implemented a non-SimpleAbcViewer design for Maya-based
Alembic preview?

[olliRJL]

Hi Nelson,

We mainly use our "alembicHolder" on characters - I just did a quick
test with a sequence with two characters and our "holder" easily
outperformed AbcImport... I got ~120fps (75fps with bounds calculation
taking 2 samples) against ~50fps of AbcImport (all this ofcourse after
system file cache had done it's job).

...but I guess characters aren't a case of "relatively static"
geometry which you point to... you mean something like a whole scene
in one abc - location+characters?

o.