PDA

View Full Version : Alembic supoprt



Darth Mole
09-07-2012, 10:11 AM
modo as it, C4D has it, Maya has it, RealFlow is getting it... so can we expect to see Alembic support in a future rev of Lightwave?

Damn - can't edit misspelt titles.

Lightwolf
09-07-2012, 10:25 AM
I'd suppose yet. However, proper support (as in: No import but the alembic file _only_ gets referenced) require quite a bit of work in the LW side of things before it's doable.

Cheers,
Mike

jwiede
09-08-2012, 08:42 PM
If I were Newtek I'd definitely wait to try and add proper "referenced" support until after LW has been "unified", as it really needs that level of infrastructure support to efficiently implement. I'm not convinced about how useful Alembic "import/export"-level support would be, either, since so much of the format's benefits derive from using it in "referenced" mode of operation. One more reason (and a pretty dang compelling one, IMO) that LW needs unified infrastructure ASAP.

Cageman
09-09-2012, 04:13 AM
If we exclude mesh-data (objects that is), things like Cameras and deformations could still be referenced. So, I'm willing to use something that allows us LW-users to take advantage of those things that would work (cameras, pointcache, keyframes). If a pointcached object (a character for example) is updated, yes... we have to deal with that in a separate fashion, but I don't see why the rest of Alembic wouldn't work.

I rather have something like that asap, and when LW is unified, get a 100% proper implementation.

drako
09-09-2012, 04:44 AM
Maybe in the 11.5 version we are going to have it.Crossfingers...

GraphXs
09-09-2012, 07:00 AM
Isn't it just a point caching data? It's because LWO are not apart of a one-file format? So if LW took a Alembic file it would only apply to camera,etc? COuld it be used with FBX some how? Maybe FBX can be the mesh part and an Alembic file can be added to that data?

Imagine a Import/Ref file check box for an Alembic file on FBX import, which takes the data and applies it to the FBX converted LW files. Would that work?

Lightwolf
09-10-2012, 06:18 AM
Isn't it just a point caching data?
No, it's a lot more. Hierarchies, motions, geometry (polygons, nurbs, hair splines) - and the paoint cache due to deformations.
All of that designed to be referenced and streamed.


It's because LWO are not apart of a one-file format?
Not quite. One of the reasons is that some information is only stored in LWOs, like surfacing information.
A LW scene refernecing an Alembic file would have no LWO though - just objects within the scene extracted from the Alembic, but never saved. (You can think of the Alembic file as being read only. It's not designed to be modified. If you do, write a new one from scratch.).


So if LW took a Alembic file it would only apply to camera,etc? COuld it be used with FBX some how? Maybe FBX can be the mesh part and an Alembic file can be added to that data?
One might as well just use an FBX and MDDs or other, native point caches (granted, Alembic files are smaller and more optimised).
The thing is though... once you start to think about importing, as opposed to referencing, then we've got the tools already.
Also, the changes require to leverage Alembic effectively would also make LW a much more powerful tool, so it's a win either way. Heck, it would even start to make sense to use Alembic in projects that rely on LW only.
[/QUOTE]Imagine a Import/Ref file check box for an Alembic file on FBX import, which takes the data and applies it to the FBX converted LW files. Would that work?[/QUOTE]
For the deformations? The problem is that it's quite a dangerous thing. All of a sudden you're depending on two different files as well as comples file formats to be in sync - more or less automatically.
Dangerous in the sense that the "pseudo" automatism would pretend to be a lot more safe than it is. As opposed to a more manual, point cache based, process.

If it's safe, automate it. If not, keep it manual.

Cheers,
Mike

GraphXs
09-10-2012, 08:33 PM
Thanks for the reply and defining what it's all about. I hope LWG supports it, even if it's in steps.

jwiede
09-11-2012, 05:29 AM
If we exclude mesh-data (objects that is), things like Cameras and deformations could still be referenced. So, I'm willing to use something that allows us LW-users to take advantage of those things that would work (cameras, pointcache, keyframes). If a pointcached object (a character for example) is updated, yes... we have to deal with that in a separate fashion, but I don't see why the rest of Alembic wouldn't work.
I'm not sure I understand what you're proposing. Even for the pointcache data, where did the object receiving it come from? Are you suggesting kind of a two-pass approach where first some stuff like object meshes, etc. are "imported" from the Alembic, and then where viable the animation is still referenced directly from the file? How are you envisioning the processing?

TBH, if unification is still so distant that holding Alembic for it isn't reasonable, then I suspect there are aspects of that delay much more life-threatening to LW than that posed by the absence of Alembic support.

Hail
09-12-2012, 07:08 AM
come on guys whats the big deal about this whole alembic holla balloony? file sharing?
Don't we ve the data interchange tools for this sorta thing?
Do we really need these toys?
Aren't there more critical areas for NT to be concentrating dev effort and time on?

Looking at the benefits I personally think it is not worth the effort
Sure would be a nice addon but we can live without it can't we?
Theres way too many problems in lw's core that currently needs fixing for NT to be chasing toys
I m not saying we should'nt ve it but let the outstanding issues be sorted out first and then the iceing can be added
plus we already ve tools that can do this sort of thing (maybe not exactly the same way but we can send files accross various apps cant we?)

NT 'd be better off refining current tools and fixing existing architectural problems which lays a solid foundation for future updates
than chasing fancy toys like these which ll only become obselute in no time

Netvudu
09-12-2012, 11:10 AM
come on guys whats the big deal about this whole alembic holla balloony? file sharing?
Don't we ve the data interchange tools for this sorta thing?
Do we really need these toys?
Aren't there more critical areas for NT to be concentrating dev effort and time on?

Looking at the benefits I personally think it is not worth the effort
Sure would be a nice addon but we can live without it can't we?
Theres way too many problems in lw's core that currently needs fixing for NT to be chasing toys
I m not saying we should'nt ve it but let the outstanding issues be sorted out first and then the iceing can be added
plus we already ve tools that can do this sort of thing (maybe not exactly the same way but we can send files accross various apps cant we?)

NT 'd be better off refining current tools and fixing existing architectural problems which lays a solid foundation for future updates
than chasing fancy toys like these which ll only become obselute in no time

Clearly you havenīt work with Alembic yet ,and also you are not so used to working with several software packages. Try to import a few particle simulations into LW from other package, letīs say nparticles form Maya...problems? Alembic makes it two clicks.

I think this is for me the number two feature Newtek should add to LW(the first one being proper render passes management).

Cageman
09-12-2012, 05:17 PM
I'm not sure I understand what you're proposing. Even for the pointcache data, where did the object receiving it come from? Are you suggesting kind of a two-pass approach where first some stuff like object meshes, etc. are "imported" from the Alembic, and then where viable the animation is still referenced directly from the file? How are you envisioning the processing?

TBH, if unification is still so distant that holding Alembic for it isn't reasonable, then I suspect there are aspects of that delay much more life-threatening to LW than that posed by the absence of Alembic support.

Most, if not all, of our Character meshes comes from outside of LW.

Think about how you would setup an MDD pipline between Maya and LW. The same limitations applies. If you change the polycount of the objects, you need to re-import the source, but if you don't, the reference to the MDDs can stay intact, and can be used in any app that supports MDDs.

What I am proposing (and this is strictly for items that are deformed, not translated), is that as a first pass, you import the characters into LW (which will create the .LWO files). Through Layout, you can then connect these objects to read data from the Alembic file, in this case point cache data. As long as users in other apps do not change the polycount on the characters, it is a safe pipeline. The link between the LW-generated LWOs and the pointcache information in the Alembic file can stay. LW reads these Alembic pointcaches in the same way it reads MDDs or GeoCache Data.

Anything that Layout creates can be referenced! Keyframe data, for example, could use a similar methology that FBX uses... every time you open the LW-scenfile, it reads the keyframe data from the Alembic file and import it and place it on the object(s).

Cameras is the same... everytime you open/reload the LWS, it will re-import the cameras from the Alembic-file.

The only tricky thing, really, are deforming meshes, but if you think about it for a while, and especially if you have worked with a PointOven based pipeline, things are far from as bad as you think regarding implementing Alembic for LW.

EDIT: Of course, it will be a limited edition of Alembic, given certain limitations with LWs separate environment, but with that said, there are also benefits to think about, even though it will be a limited implementation. Cameras and keyframe data, for example...

On that note, I've used a referencing system for keyframe data within LW. Both Jeremy Hardin and Lernie Ang have written tools to facilitate this. Jeremys tools were using the .mot format, while Lernie invented his own format that also could take certain other attributes, for example, cameras.