Standard Schema for light support?

[Jean-Colas Prunier]

Is there any plan to add a standard light schema so we can have light support in Alembic? At least to cover the basics such as light type and color, intensity, falloff etc.

Or is it assumed that:

- there's no much dev done to the API anymore, and it's more a matter of maintaining what already exists rather than pushing it any further.

- it's assumed that if one wants support for lights, he/she might want to use something like USD for light source description and use Alembic for geo cache only.

Nothing wrong wither either of the approaches. I am interested to see what strategy is best moving forward.

Thank you for your input). -jc

[Lucas Miller]

Good question!

The building blocks have been there for a while to build out a more interesting light schema, the tricky bit was expressing it in a way the most popular DCCs could support and still be useful.

What DCCs would people like to see light interchange between?

Lucas

--
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-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/alembic-discussion/e652c2e9-c069-48be-a8bc-9334906d0080n%40googlegroups.com.

[Jean-Colas Prunier]

Thanks for your answer, Lucas. Much appreciated. I understand this doesn't mean you are willing to do something about it, but at least we can start with a conversation). That's great.

Alembic's main purpose is to interchange animation data between packages, whereas rebuilding a complex rig or hair system to generate the same geometry from one package to the next is nearly impossible. Camera light geo, too, can be using things specific to a given DCC tool (Blender uses Bezier, as the primary curve type, whereas Maya uses splines), so that we need something like Alembic to bake them out also makes sense.

I see two major use cases justifying the use of Alembic (do you see others?):

- Interchange: You bake things out and send them to a client or another vendor on a project, and they can load them in their DCC tool and keep carrying on with the work. That's one use of Alembic.

- Reviews. You bake an animation out and send it to a client for review. In this case, people are generally not interested in looking at a given animation with all the textures but are focused on looking at the animation itself. So very often, they look at a grey render of the 3D objects, etc. When used in this contest, it can become useful because you can look at this animation from a given camera. Great Alembic supports cameras. Also, in this context, looking at this animation with some indication of what the lighting is supposed to be can reveal to be as equally useful.

To come back to materials. If materials are important, this can be easily done. If UVs are there, based on some naming conventions (name of the objects), one can figure out how to reconnect a set of textures to the right input of a material node. That's not possible with lights. You need the light type, position, color, intensity, etc., or else you can do nothing. That's why there's a fundamental difference between the two. Furthermore, as you suggested, support for lights in Alembic is "almost" there (since the ILightSchema already exists).

Being able to load at least some basic light types with even a restraint but most common parameters would be valuable and would not try to compete with using an alternative solution such as USD. The problem with going with USD to define things not defined by Alembic is that it adds another layer of complexity if the tool you are using for reviewing these Alembic files still needs to handle USD. Having to add USD support for dealing with basic lights is overkilled (and hopefully, I have explained why having lights over material is valuable in using Alembic for reviews). Even if you don't go with the USD route, you still need to import lights separately to the Alembic file, which requires a second export process from the tool from which the Alembic file was exported to some secondary file (and file format). That's a pity, considering Alembic could handle that part so easily.

IMHO, having basic light types supports (point, distant, projector) and basic/common properties such as cone angle, falloff, color, intensity, of course, transformations, etc. would be justified for the Alembic format, and as I mentioned, valuable and thus used. Lights have the same problems as materials. Every place more or less has its own set of rules, naming conventions, etc. One might say, why not include IBL (which might require specifying which texture you are using, etc.), geometry lights, etc? Again I don't think the point is to replace something like glTF, FBX or USD. It's more again that if you have distant (sun), point, or spotlights in the source DCC tool (the tool from which the Alembic was exported), it would be great to carry them along in the Alembic so that we at least have something, even if basic, in the review context out of the bat, rather than having to go through a separate export process.

[Jean-Colas Prunier]

Hi Lucas, everybody.

Would you have any thoughts on this? Any comment or feedback?

Many thanks. Looking forward to your replies.

[Lucas Miller]

It would be useful.

If you provide what attributes you would think should go into a general light schema we can provide a prototype for wider feedback.

Lucas

To view this discussion on the web visit https://groups.google.com/d/msgid/alembic-discussion/0c61c407-5538-487d-a196-4328b5e09320n%40googlegroups.com.

[Jean-Colas Prunier]

Thanks Lucas. Will do. I will suggest some first specs so the rest of the community can provide feedback / discuss.

Thanks again.