PDA

View Full Version : Alembic works like a charm. Please Newtek, hurry up



Netvudu
05-15-2012, 11:19 AM
Iīve been testing exporting scenes from Maya 2013 to Houdini (Maya 2012 advertised Alembic, but it wasnīt true. I mean it was the typical "first" from Autodesk. Whenever they first state theyīve added a feature to Maya it ainīt true. It never works. The second times they advertise it, is when it usually works)

My point is...it rocks! Create a scene in Maya, add some dynamics, ncloth or whatever, export with Alembic, import in Houdini, done.

No history deleting, no grouping (polyunite) or similar stuff. Stuff out, stuff in. Works. Cameras, geometry, lights, dynamics...No harm, no fuss.

We REALLY need this, as opposed to any more effort in the stupid FBX format which Autodesk is making a mess of with every version anyway.

Lightwolf
05-15-2012, 04:07 PM
While I agree... the problem is that Alembic would require a bit more base work in LW to make use of it properly.
For one, you'd like to use the Alembic file natively and not have it converted (Otherwise you'd have plenty of problems if the source Alembic file changes in mid-production, which would defeat half of it's purpose) - and that implies that changes (such as surfacing) can be saved in the scene file.

Cheers,
Mike

Netvudu
05-15-2012, 04:10 PM
Well, I know squat about the file format (and you surely know your stuff), but I must say working with it makes things pretty simple

Lightwolf
05-15-2012, 04:23 PM
Well, I know squat about the file format (and you surely know your stuff), but I must say working with it makes things pretty simple
It's less to do with the file format but more with the way LW deals with things.

Ideally you'd want LW to reference the Alembic file in (let's say to render it).
If the Alembic file changes, you'd want LW to pick up those changes.

However, as it currently stands, since LW stores some properties (such as surfaces) in LWOs only, it would need to import and convert the Alembic file to native formats.
And that implies that a changed source Alembic file would require a new import and conversion, essentially destroying your initial work in LW.

The minimum requirement for LW to be able to deal with Alembic properly would thus be (imho) a way to store surfacing overrides within the scene itself. Then you can reference in the Alembic file but LW would allow you to surface it depending on the surface name (surfacing being the prime example here).

Cheers,
Mike

UnCommonGrafx
05-15-2012, 04:26 PM
Isn't that kinda like they do with an obj and mtl?
Or, better said, as in the kind of surfacing objs get with mtls?

I find this a fascinate moment for LW. The Core stuff would serve us all quite well right now.

Lightwolf
05-15-2012, 04:30 PM
Isn't that kinda like they do with an obj and mtl?
Or, better said, as in the kind of surfacing objs get with mtls?
Which is just the basic shading components and no more...
I don't know if LW saves MTLs if you just save everything in a scene that includes native OBJs, I certainly never tried it.


I find this a fascinate moment for LW. The Core stuff would serve us all quite well right now.
Well, it probably wouldn't be such a hard to thing to add... but it would need to be added.
Of course, since it's also the first step to a "proper" referencing system, the question is what implementations it would have for the future.
Which is why there's more to think about than just how to deal with Alembic decently.

Cheers,
Mike

zarti
05-15-2012, 05:06 PM
who cares if material attribs do not get ' teleported ' with an Alembic flight !?

if that wd had been so Important , alembic-makers wd had included that feature .

but indeed , no material survives jumping from app-to-app .

so , why the fear !?

alembic finishes its job just a step ahead of shading and does it pretty well .

for me , personally , thats a key point to update in next LW 'Retry' ..




.cheers

Lightwolf
05-15-2012, 05:12 PM
who cares if material attribs do not get ' teleported ' with an Alembic flight !?

if that wd had been so Important , alembic-makers wd had included that feature .

but indeed , no material survives jumping from app-to-app .

so , why the fear !?

alembic finishes its job just a step ahead of shading and does it pretty well .

for me , personally , thats a key point to update in next LW 'Retry' ..

That's 100% beside my point though.

The questions is: What if you set up a scene with an imported (and thus converted to native LWOs!) Alembic file, have it all set-up for rendering... but then there's a new version of the Alembic file?

The question is thus not what is stored within the Alembic file... but what changes does LW need to properly reference it as opposed to a one shot import option.

Precisely because Alembic (rightfully!) stops just before shading and because it's that information which LW currently stores within native LWOs only.

Cheers,
Mike

zarti
05-15-2012, 05:27 PM
That's 100% beside my point though.

The questions is: What if you set up a scene with an imported (and thus converted to native LWOs!) Alembic file, have it all set-up for rendering... but then there's a new version of the Alembic file?

The question is thus not what is stored within the Alembic file... but what changes does LW need to properly reference it as opposed to a one shot import option.

Precisely because Alembic (rightfully!) stops just before shading and because it's that information which LW currently stores within native LWOs only.

Cheers,
Mike

hi ,

.. well thats point ! , thats NTs job .

and because Alembic ( rightfully ! ) imports geos , hierarchies and caches .. there might be some interest and partial benefits even in its basic implementation . Or not ?



.cheers

Lightwolf
05-15-2012, 05:30 PM
hi ,

.. well thats point ! , thats NTs job .
PRecisely, that's what I've been trying to say, it needs design changes.


and because Alembic ( rightfully ! ) imports geos , hierarchies and caches .. there might be some interest and partial benefits even in its basic implementation . Or not ?

I'd say without referencing you lose around 80% of the advantages of using it in the first place. You'd basically end up with a different kind of FBX.
Unless you never have changes in your projects... (yeah, right. ;) )

Cheers,
Mike

zarti
05-15-2012, 05:38 PM
PRecisely, that's what I've been trying to say, it needs design changes.

yea'hh ! design Changes .. thats what we 've Been praying for so long .. ;)


..

I'd say without referencing you lose around 80% of the advantages of using it in the first place. You'd basically end up with a different kind of FBX.

..
no'ppe . sorry here , these are the days for Alembic and FBX to say ' goodbye ! ' to each other . =)

will NT be there ? .. let see .




.cheers

Lightwolf
05-15-2012, 05:48 PM
no'ppe . sorry here , these are the days for Alembic and FBX to say ' goodbye ! ' to each other . =)
Only if Alembic can be leveraged to be used in a better workflow... which in turn goes back to LW.

And before you ask... I've been following the development of Alembic very closely right from the first announcement and spent a bit of time to find a satisfactory way to implement it within the confines of LW. And I haven't found a satisfactory way to deal with it properly so far.
And I don't think that an implementation that doesn't really leverage the advantages is helping anybody - including NT themselves (they'd be bombarded with complaints in no time after releasing it).

Another downside is the fact that some of the entities that can be stored within an Alembic file can't be represented in LW as is - but in that case I'd say it's safe to ignore them for a start (Curves and Patches to be precise: http://code.google.com/p/alembic/wiki/Alembic_Geometric_Types).

Cheers,
Mike

Lewis
05-16-2012, 02:02 AM
So is this means LWs split application approach is going to bite us (agian) on this or? I see modo supports Alembic but then they have *.LXO format which stores all in one file - right ?

Lightwolf
05-16-2012, 02:07 AM
So is this means LWs split application approach is going to bite us (agian) on this or? I see modo supports Alembic but then they have *.LXO format which stores all in one file - right ?
It's not necessarily the split application approach... only the fact that LWS doesn't allow for overrides on a scene level.
Modo allows for references (you can also reference a .LXO into another one, just like a LWO in LW, but have the master LXO override certain aspects).

Cheers,
Mike

Lewis
05-16-2012, 02:10 AM
Hmm well maybe it's time for them (NT) to make proper referencing system in LW then and finally decide which properties goes where (like Clipmaps in LWS and not in LWO)... But then again all that would be easier in unified app/environment.

Lightwolf
05-16-2012, 02:16 AM
Hmm well maybe it's time for them (NT) to make proper referencing system in LW then and finally decide which properties goes where (like Clipmaps in LWS and not in LWO)...
Which is pretty much what I've been trying to hint at all along this thread... :D

But then again all that would be easier in unified app/environment.
It actually wouldn't make much of a difference for a change.

Mind you, a good referencing system is something that takes more than one release to get right - a lot more if you look at some of the competitors (here's looking at you Maya ;) ).

Cheers,
Mike

Lewis
05-16-2012, 02:28 AM
Mind you, a good referencing system is something that takes more than one release to get right - a lot more if you look at some of the competitors (here's looking at you Maya ;) ).


True BUT postponing it to later and later release when more features/stuff goes in it'll just be even more harder to make it.

Lightwolf
05-16-2012, 02:33 AM
True BUT postponing it to later and later release when more features/stuff goes in it'll just be even more harder to make it.
Not necessarily. If a future architectural change within Layout is planned, one that takes referencing into account (as well as other topics, such as NLA for example), then it may actually be easier to wait.

Cheers,
Mike

Lewis
05-16-2012, 02:41 AM
then it may actually be easier to wait.


Easier for who? Users need it like yesterday :D :D ;).

Lightwolf
05-16-2012, 02:47 AM
Easier for who? Users need it like yesterday :D :D ;).
Then they should pick a package that covers their needs now.
Anything else is just a gamble either way. ;)

Cheers,
Mike

Netvudu
05-16-2012, 03:41 AM
IMHO, Lightwolf you pointed that without the referencing part Alembic is pretty much like FBX, but there are two important points there to mention.

Firstly, that the export/import workflow is already way more comfortable than its FBX counterpart. You donīt have to delete history or make anything remotely technical for it to work.

Secondly, it is not developed by Autodesk, and many high-end studios are using it on a daily-basis which will only result in further improvements. Frankly, Iīm tired of new FBX versions working partially or not at all...

Lightwolf
05-16-2012, 03:43 AM
IMHO, Lightwolf you pointed that without the referencing part Alembic is pretty much like FBX, but there are two important points there to mention.

Firstly, that the export/import workflow is already way more comfortable than its FBX counterpart. You donīt have to delete history or make anything remotely technical for it to work.
That's a problem on the other side of the fence so to speak though. I.e. not LW related.


Secondly, it is not developed by Autodesk, and many high-end studios are using it on a daily-basis which will only result in further improvements. Frankly, Iīm tired of new FBX versions working partially or not at all...
Collada... :D

Cheers,
Mike

zarti
05-16-2012, 05:14 AM
..

Collada... :D

Cheers,
Mike

:D .. if it still keeps developing .




.cheers

warmiak
05-16-2012, 10:35 PM
:D .. if it still keeps developing .




.cheers

Collada is like ASCII fbx times 10 + ambiguity (gratis).

djlithium
05-17-2012, 12:25 AM
If everyone is so hopped up about LW to Maya and back interchange I suggest looking at "The Beaver Project". It works. It works well, and I hope we can see a mighty return of it soon.

geo_n
05-17-2012, 02:39 AM
Its more than interchange. Its adapting standards.
Unify layout and modeller or bust.

Netvudu
05-17-2012, 04:57 AM
Kat, The Beaver Project is awesome, but itīs commercial, not a free interchange format.
Not only that, but itīs only for LW/Maya. If Alembic keeps with way it will be useable by everybody as a cross-plattform format.
Iīm already using it for Houdini 12 and Maya 2013 at work (I donīt own a license of Maya at home, canīt afford it).
And IīM IMPORTING PARTICLES FROM MAYA INTO HOUDINI. And not just regular, but also NParticles. This is all stuff not doable through FBX. (mind you, Iīm importing Maya particles into Houdini as an experiment. I usually donīt run my particle simulations in Maya. Plus I can see how this could be useful for many Lightwave users)

And also the workflow is so much better. You donīt even have to import objects, then cached animation, etc (which you have to do with FBX as soon as you want to import dynamics or similar stuff beyond keyframing)...You just click import, bam! everything there.

jasonwestmas
05-17-2012, 07:39 AM
I like the alembic interchange so far between modo and maya. I hope this comes to Lightwave merely for the point cache support that we don't have to setup ourselves. I say 'merely' very loosely as I find it to be a big deal actually.

Emmanuel
05-17-2012, 09:32 AM
Well, considering how long it took NT to give LW users a GoZ plugin, I wouldnt hold my breath for alembic.

zarti
05-17-2012, 12:23 PM
:D quick test ??

3 cache formats tested in Blender ( Linux-x64 )

only the mdd export time wasnt reported from exporters , so time was measured with a watch .
FBX exported only one frame . couldnt make it work =)

the geometry was simple ;
a huge grid 83521 points .
a simple ripple deformer was applied to it for 250frames .
PC2 and ABC cache files were exported with 1 sample / frame to match MDDs missing option ..

the OBJ itself took more than 3sec to be saved .

final cache size files : ABC - 192.9MB / PC2 - 238MB / MDD - 239.9MB .
export times : ABC - 39.13sec / PC2 - 322sec / MDD - 191sec


[ screenshot attached ]

--

http://forums.newtek.com/attachment.php?attachmentid=104424&stc=1&d=1337278761

--



.cheers

Netvudu
05-17-2012, 04:38 PM
And just to complete that, my tests indicate that reading times are also faster

Cageman
05-17-2012, 05:11 PM
Two possible solutions?

A Master plugin that acts as Surface Editor and stores data separately from the LWS. It uses namematching to apply Surface Overrides at rendertime...

OR... an intermediate state...

First time you get an Alembic file, it is converted to whatever LW needs (an LWS with a bunch of LWOs referenced) and the hook to the chaches are still directly read from the Alembic file.

As long as the objects with the Alembic-file aren't changed from the source (Maya), but only the caches are, this would work in a similar fashion to how MDDs works now, wouldn't it?

Keyframe data and camera data shouldn't be hard to support without actually having to re-load the objects from within Alembic?

jasonwestmas
05-17-2012, 05:30 PM
Well, considering how long it took NT to give LW users a GoZ plugin, I wouldnt hold my breath for alembic.

I never have to hold my breath.

Lightwolf
05-18-2012, 05:32 AM
Two possible solutions?

A Master plugin that acts as Surface Editor and stores data separately from the LWS. It uses namematching to apply Surface Overrides at rendertime...
Which isn't directly possible. The only way for something like that to work would be an override in the surface itself... and that in turn would then need to be stored again (similar to the shader plugin that shaderMeister uses). Back to square one.


OR... an intermediate state...

First time you get an Alembic file, it is converted to whatever LW needs (an LWS with a bunch of LWOs referenced) and the hook to the chaches are still directly read from the Alembic file.

As long as the objects with the Alembic-file aren't changed from the source (Maya), but only the caches are, this would work in a similar fashion to how MDDs works now, wouldn't it?

Keyframe data and camera data shouldn't be hard to support without actually having to re-load the objects from within Alembic?
It would indeed, and I'd also stream in keyframing data. After all, this is what Alembic is optimised for.
However, since the dev team do have access to the LW source code, I'd still rather see them adapt the behaviour within LW before adopting Alembic as opposed to kludging it in. Especially if it would provide benefits beyond Alembic (such as the scene local surface overrides).

Obviously, if a third party was to provide Alembic i/o then you need to work within the existing confines. I certainly found the limitations to be too severe to look into it any further after Alembic was initially announced.

Cheers,
Mike

rcallicotte
05-18-2012, 07:01 AM
Lightwave devs have my vote. Go devs!

Tobian
05-18-2012, 08:41 AM
LW doesn't have support for curves rendering, but I wonder if the curves primitives could be used with FFX? That said I'd prefer to see a curves/hair primitive period in LW, and not bother with the ffx shader. They are nearly there with FFX as it can generate geometry, but not in layout, and not on the fly.

I for one would love surface referencing, and referencing in general, so you could assemble scenes from smaller scenes (an lwx format?) regardless of if it was for Alembic, but certainly it would be a huge asset for LW to have it!

erikals
08-13-2012, 11:30 PM
 
RealFlow 2013 is getting Alembic...
http://www.realflow.com/rf_2013.php