Storing Lights in Alembic?

[Simon]

This probably falls into the category of "renderer-specific so not
considering it yet", but...

Is anyone using Alembic to store lights? I assume if you are, you have
written your own custom schemas, as ones for lights aren't provided by
default.

Is this even a sensible thing to do?

Is everyone so far just using a renderer which has it's own SDL and
therefore no need to use Alembic for anything other than geometry?

[Steve LaVietes]

We've held off on defining lights within AbcGeom thus far as most of
the relevant properties are application or shader specific.

I can imagine some sort of lowest common denominator definition for
which there'd be a reference implementation shader/node per
application. But, I doubt it'd get much use in any real production.

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

[Simon Eves]

Steve LaVietes <steve.l...@gmail.com> wrote:
>
> We've held off on defining lights within AbcGeom thus far as most of
> the relevant properties are application or shader specific.
>
> I can imagine some sort of lowest common denominator definition for
> which there'd be a reference implementation shader/node per
> application. But, I doubt it'd get much use in any real production.

Thats what I figured. No worries.

--
SUPPORT COMMUNITY THEATRE!

[Pete Segal]

Simon,

Fear not, there are indeed others like yourself who are interested in using
Alembic in other ways. Case in point, I have been working on an
import/export plugin for modo.

I could easily envision scenarios where modo could use Alembic data at any
stage in the production pipeline, from modeling in modo and exporting
geometry to other systems, to using modo to render imported animation
sequences, and many combinations in between.

I firmly believe that the current Alembic geometry definitions are a great
starting point, but I also see great benefit to expanding support to include
lights and materials, etc.

I understand Steve's perspective that these might not be used in large
studio productions, but there are also many cases of smaller studios
cooperating on projects. Being able to use Alembic at all stages of the
pipeline, with a variety of products, could be useful to a wide range of
users.

Pete

[Andrew Lyons]

I wonder whether Alembic/HDF5 is the best storage format for storing
generic scene data? HDF5 seems intended for storing hierarchical
numeric data (and references) - which is great for geometry and
volumetric data - but that doesn't necessarily describe
houdini/maya/nuke scene file data - where ideally you really need
something that can store many small blocks of many different types. I
have an interchange/storage system for houdini/maya/nuke scene data
that uses a modified version of python shelves that is hardwired to
use gdbm:

http://docs.python.org/library/shelve.html
http://docs.python.org/library/gdbm.html
http://www.gnu.org.ua/software/gdbm/

The advantages are that the shelve dict uses cPickle to store all
python objects as cStrings in gdbm. Opening a shelve file restores all
python session data. The data does not need to be parsed in order to
reconstruct numerous types. That alone was a pretty attractive feature
for a developer working with limited time. Python is not that fast at
traversing large scene files in houdini/nuke/maya - but that part will
get optimized with select C++ modules in time. The actual shelve/gdbm
file I/O is very fast.

Alembic is great for storing geometry. Perhaps Alembic will be great
for storing animation files in time? Beyond animation and geometry
though, I'm curious to hear other people's thoughts on optimal scene
file storage and interchange systems?

Cheers

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

--
=======================================
Andrew D Lyons | Digital Artist | http://www.tstex.com
=======================================

[Pete Segal]

Andrew,

I'd be happy to concede that Alembic might not be "optimal" for storing
generic scene data, but I don't really see that being much of an issue for
two main reasons:

1) I would expect that the geometric data would dwarf any generic scene data
(especially when storing baked animated samples), so the hit you'd take for
the scene data would probably be minimal.

2) I consider it much more valuable to obtain all of my data from a single
source (where possible), rather than have to deal with multiple components
files / file formats (and multiple importers!)

My $0.02,

[Andrew Lyons]

That's a good point. I guess it will happen at some point. I wonder if
it will be part of Alembic, a layer on top of it, or a branch of it?

Cheers

[Andrew Lyons]

Having said that, Nuke and Houdini store geometry outside their scene
files. Potentially, some renderers, and some rendering scenarios might
benefit from storing geometry in separate files as well. On top of
that many pipelines at large studios are going to prefer that
seperation as part of asset management systems. I can see that the
monolithic Alembic file might benefit certain production types which
use apps which store geometry in scene files - but I'm thinking for
many studios (probably the principle developers included) that won't
be a big goal. I guess it's good to have options though - and at face
value there's probably no reason why Alembic couldn't support all
these scenarios. There's a risk of bloat, and the problems that come
from goal drift, but otherwise...

Cheers

[Pete Segal]

I do recognize that there are certain external files that will almost always
be part of a scene (textures, shaders, material presets, etc.), and I
understand the value of keeping them separate.

OTOH, one of the biggest problems I've seen when passing data around (other
than translation issues) is making sure that *all* the data is passed
around. There are clearly cases where it's desirable to pass subsets around,
but that's not an attribute of the format, rather the export UI.

I personally lean toward allowing the format to have the ability to exchange
as much data as possible, and letting the users decide what they want to
share.