AFAIK, Fbx and MDD, PC2 don&t support changing point count per frame. So thats one reason for Alembic, other would be performance since it can be read hierarchically (transform), as well as custom attributes support.
Yes, MDD doesn’t support Camera animation. But it’s not really meant for that. It’s meant for exchanging simulations and character animation between apps. But Alembic does not support the transfer of materials either. I’m not sure where you saw that? Some of the implementations can send basic material information (like color) back and fourth. But on the whole Alembic is actually really bad about materials. This is actually why we don’t used Alembic at work. Maya can send out the material partition information but most of the other applications we tried to get that data into, didn’t like it or just ignored it. Modo for instance, just ignores materials entirely. All you get into modo is grey shaded models.
The way that this kind of workflow is supposed to work is that you send an abc from Maya (just as an example), and open it in Modo or wherever. Then, what should come in is a model with a type of deformer on it that stores the point cache data in it. That deformer then intern, moves the points around. Then when you update the animation, you save out another .abc and update the deformer on the model in Modo (or whatever program). This is what all cacheing formats are for. The issue however, and one that I hope Blender devs are aware of is that alembic is a “dumb” format that contains everything each time you export. So the issue is one of updating the data once you’ve imported it. most other programs don’t do the deformer setup for you. They just import all the data again. Model with cache data and basic material partitions. So the original model that you textured in Modo has now either been replaced with a new grey shaded model or still there in the scene along side the new one. It’s not been updated. The is the major failing with alembic in my experience. It works great once but when you need to update the animation, it just re-imports everything in a really stupid way.
I think there are a few implementations that do it the right way. Maya for instance puts the deformer on the mesh and you can find the alembic importer node in the graph and replace the link to the original data so that you don’t loose all your materials. I think Houdini might do this too. But on the whole, the rest of the programs don’t. It’s just simple File>import>Alembic and that’s all you get.
Hopefully, Alembic support will show up in Blender as an importer that imports the initial model and camera data in along with a point cache modifier that contains a link to the external .ABC file. That’s the most beneficial and flexible way to work with alembic.
I really don’t think you can say “The whole film industry”. I’m in the film industry (well, I mostly work on commercials) and I don’t use alembic. Not to mention that the one of the biggest programs in the industry, 3DSMax doesn’t even have Alembic. I agree that we do need alembic though. it’s a great format when it’s been implemented properly.
Actually, I didn’t know that alembic did that. That’s good to know. For that we have just been using real flow .BIN files. They suck but it’s get’s the job done.
I disagree with this, if you have a perfect I/O from your scene but without the camera data it usually ends up in a non-usable pipeline. The big point of Alembic is that whatever you see in your host application you will see it in your external application, without the camera data is pointless. I had to use MDD and PC2 from Softimage to Blender and the animations were fine but because the lack of camera data I had to re-create the camera movement by tracking elements from a dummy plate made in softimage and tracked in Blender, in other words… a big pile of crap and not a 100% accurate method due to the limitations on the formats. At that time I really wished to have Alembic, hopefully one day.
Looks like Lukas is doing a lot of work on this lately. Good news.
Collada supports camera animation and last time I checked also Fbx.
bls, try to use collada and FBX from Softimage to Blender and you will see what I’m talking about.
Importing and exporting camera data between blender and Maya would be huge. I don’t care which format gets it done, as long as it gets done.
I havent tried exporting to agter effects and then from after effects to maya… That actually might work…
Blender is not Maya. You cannot share a modifier between several objects in blender.
It seems to be a bad idea to use a modifier to link several objects data to same cache.
If you change the cache file, you have to modify each modifier’s links.
IMHO, in current blender design, it would be better to see it as scene property shared by group membership like rigid body sim cache.
It would have benefit to also include camera.
No and you can’t in Maya either. 
What I was saying is that the importer adds a point cache modifier to each object automatically. This is how it normally works with Alembic when it’s done right.
It seems to be a bad idea to use a modifier to link several objects data to same cache.
If you change the cache file, you have to modify each modifier’s links.
IMHO, in current blender design, it would be better to see it as scene property shared by group membership like rigid body sim cache.
It would have benefit to also include camera.
Yes that sounds good too.
We can already do that in blender with MDD/PC2. I’m using an importer that hooks up a modifier for each mesh upon import. If the mesh cache changes, as long as the names and location remain the same (which it should if your doing it right), then blender automatically gets the changes. Alembic could (and should) work in a similar fashion.
By film I am referring to the silver halide, not the TV. Full feature film pipeline is much different than the TVC workflow.
Not quite right. Autodesk has made a first implementation with alembic, and it’s horrible implementation.
When done right Alembic files are read as a procedural where you can make material overrides in the hierarchy. So you don’t actually have any geometry in the scene at all, more of a OpenGL representation of the alembic file. So in the end the Geo is read in render time, not inside the host application.
There is a example how that works in Gaffer, http://vimeo.com/93273775
Alembic can also be used as a point cache or animation transfer, or as a Geo Asset format. The later is good since it enables you to be able to generate models that can be read in most applications. There are layers to how you can use Alembic, not just one way.
Alembic is a industry standard, all the major studios that I have worked has in in-place or a variation with their own packing system. The last few years I would say that Alembic and OpenVDB is becoming more and more of a norm in caching formats. OpenVDB is especially interesting now when Dreamworks is also releasing point support. The talks at Siggraph was interesting on how OpenVDB was used in many cases.
Anyhow… to summarise. Alembic should be read as a procedural or you can read animation data… or just transform nodes (anim curves). There is no right or wrong, only different implementations.
regards
stefan andersson
Right, but that’s really just an Uber version of what I was talking about. The important part is that the cache data it’s easily updated without messing up or destroying the material data you have added on top of it. It would be totally amazing if it actually worked the way you described though. This is kind of similar to how the Vray proxy object format works too. It can store cached animation data too and it’s only read in at render time. Obviously, you can have the host application load and display the data too. For something like this to work in Blender it would need some way of getting down into the data of the file and overriding the materials. Currently I don’t think blender supports any kind material overriding.
I just watched that video and noticed that it wasn’t actually using Alembic. It was using the Cortex in-house caching format. They said, that it could have just as easily used Alembic. Your point is still valid, I just thought you might have missed that part or maybe you linked to the wrong video.
Okay so just for the record, I’m not saying we shouldn’t have Alembic in Blender. that’s not it at all. It would be a great feature and go that much farther in bridging Blender with the rest of the professional 3D community. All I’m saying is that we can already do a lot of what Alembic proveds with other tools and formats. And, the only reason I say that is because it seems like there are people acting like they can’t get data back and fourth between Blender and other apps until they get Alembic. That’s simply not true. With all the features out there that we want added to Blender (openVDB anyone?) this, at least to me, is one of the least important. And what worries me more is that it’s obviously very easy to get it wrong as most of the standard 3D applications have proven.
And yes, if the Belnder developers can make in implamentation of Alembic that is actually useful, then I’m all for it. All I’m offering here a word of cation to be carful and think about how it’s going to be used once the data is in Blender. Don’t just add it in as generalized import/export format like so many other applications.
You have to understand, my experience with Alembic so far is that in Maya, Modo and C4D to some extent, (and totally missing from Max) it doesn’t deliver. So, of course I’m skeptical when everyone and their mother says “It’s the standard!” when obviously, if most of the standard 3D programs can’t even get it right then how can it be the standard. My guess is that most of the studios have their own custom implementation that works for their pipeline needs. And, with so many different implementation and so any different ways of using it, that obviously means that there is no standard way to implement it. I understand that it’s that way by design and that it offers flexibility. But, that also encourages fragmentation.
But if we can have a “Cache everything and open it in any program” feature, then I’m all for it.
So, I’ll stop talking about this and just hope and pray that it gets done in a useful way.
If anyone is interested, just install Houdini and import a Alembic file (preferably something more complex) and try it out and see how it works, because the way they did it is just about right. They basically emulated the way inhouse tools do it or Katana or Gaffer, hope Blender once it gets the basics in does the same.
Whats needed:
1.Easy hierarchy navigation for the whole tree without unpacking the archive into Blender scene (with that mode of operation optionally), preferably in the outliner. That would imply outliner enhancements to handle editing of additional properties as needed (alembic node representation for example).
2.Property override
3.Alembic update without losing overrides
Thats just offhand, based on a recent project involving Maya->Houdini via Alembic I did recently.
I completely agree. Alembic implementation in Houdini is very good indeed. I hope Blender dev take a look at how they implemented it.
What industry are you talking about? 3DSMax’s user base is now mostly architecture, and obviously they don’t really need to do caching. Alembic is the perfect format for caching and even more. It’s open source, highly customizable, super compact, also support nurbs, point clouds, curves, custom attribute(per point or not), and there is a python bindings so you can access and modify the internal data by script. Also it can be use for more than caching, I’m using it to transfer enveloped character from a DCC to another, and you can even include the constraints if you need.
In fact it can even be used a 3D scene description, and it’s definitely a must have.
my 2 cents
Presumably people saw last weeks’ Gooseberry wrapup video? Lukas was demoing the start of Alembic implementation with a cache of the Sintel dragon. It was running quite slow as it was being subdivided on the fly (no sure why it wasn’t demoed without it), but it is an exciting start to the long awaited Alembic functionality. I am very much looking forward to bringing in .abc files from other packages to render in Cycles 
So according to this:
http://gooseberry.blender.org/bam-building-the-asset-manager/
first Alembic implementation will be limited to caching? If so, are there ANY plans to implement Alembic import into Blender with features similar to other software (Alembic tree inspection, delayed loads, overrides, general lighting and shading tools) that we can look forward in foreseeable future? I think a lot of people (including me) would love to do bulk of work in other software and render/shade in Blender.
Or is Alembic in Blender supposed to be limited to replacement to current caching functionality?
That sounds like it’s initial purpose, yeah. What’s with the “all-or-nothing” attitude? Doing a full 100% implementaion of Alembic in blender is probably a HUGE job, so the devs are implementing it a step at a time.
FYI, this is what ALL software devs do. Maya, for example, has been working on implementing Opensubdiv for a year or two now. It’s currently in Maya 2015, but it’s a barebones release. No GPU acceleration, no dynamic topology. It’s not a very good implementation at all, but in another year or two, it might be. And Maya’s Alemebic implementation is pretty rough as well. So even AUTODESK needs YEARS to properly implement Open source libraries into their software.
Give our poor devs a break and be patient.
Lets not pretend to not know what happens with features that a just good enough for the time being in Blender ecosystem. For blinding example just look at state of fluid simulator or compositor. My fear (lets hope it to be unfounded) based on previous experience with features implemented during GSOC or BF projects is that they will leave them finished just enough to fill the base need (caching in case of Gooseberry). And in case of Alembic proper import is not on their charts as I really can’t see a big need for Gooseberry since its 100% Blender centric.