Concerning Alembic...

Hi,

What is the status of Alembic in Blender Right now ?

Is it possible with the code in blender to make an import/export right now or we have to wait again ?
I understand that the patch from gooseberry has been rejected, but, what’s the status right now ?

I don’t understand why it’s not a priority for the BF, Alembic is an open source format and that will brind a lot of companies to use blender, so surelly more money for the BF.

It’s a win/win, more professional users, more addons, more project etc.

I know, the bf wants to have a full package with Blender, I like that, but stay closed to other softwares it’s unconsistant with all the work about the FBX import/export.
Alembic should be the priority now it’s supported by all the other softwares, nuke, Houdini, guerilla, maya, max etc etc.

I´m sure it is a priority, but more a focus on the 2.8 project I think. I followed a chat on IRC where Ton asked an artist from a rather big 3D studio what they would expect in terms of workflow, to gather data to be able to plan better their approach to including this in Blender. At least that´s how I read it. let´s wait for more updates to the 2.8 project…

But I´m not a developer, so… take everything I say with a bunch of salt :stuck_out_tongue:

This is covered a bit by Sergey near the end of the latest Blender Institute Podcast episode. Short version: writing an importer/exporter for Alembic would not be very difficult, but the complexities of getting a proper mesh cache workflow working in Blender is a bigger challenge and a more important one to solve first.

Yeah, I understand that’s a design issue. With an Alembic i/o, we could do any kind of simulation in Houdini and import back into Blender, that would be great. Right now PC2 and OBJ sequence are hardly flexible solutions. We don’t need fantastic physics solvers inside of Blender when we have Alembic.

Definitely something Blender devs should focus on. Almost all data exchange nowdays in any pipeline is through Alembic.

Don’t want to be a fan boy but… +1000
The ability to work closely with other softwares could bring blender to a next level.
Can’t wait to see it.

By the way, here is an interesting discussion :
https://developer.blender.org/T41935

To sum up :
A dev called Devon made a patch in order to import Realflow mesh, and Realflow particle sequences (wouaaaw).
Sergey is asking : why adding several cache modifier when :
“We will go with alembic sooner or later and it’ll be good to land some generic system for the caching, for which alembic, obj files etc would be just a backend. I don’t really see huge benefit of having loads of decoupled modifiers.”


Edit : For now the importer is stopped because Alembic will be added later.
However you can download the realflow importer/modifer here (blender 2.75a for win 64bits) :
https://dl.dropboxusercontent.com/u/14364171/blender_meshseqcache_realflow_win64.7z

For OSX :
http://graphicall.org/1150
Tuto :

Sooner or later, more later it seems.

This may just be my personal impression, but isn’t it really the complete opposite? Getting data in and out of Blender has been a big issue for many years. Caching seems more like a nice-to-have.

I think these are two different issues and if one is more easily solved, maybe it should be solved first. I’m also skeptical about whether shoehorning Alembic into what could otherwise be a caching system designed specifically for Blender is the better solution.

Listen to that part of the episode. Maybe I misunderstood what was being said.

I understand that if you want to import alembic, you have to have good bases.
They can now create an import/export and it will work with a lot of things, but for fluid sim, fire, smoke etc, they will have to rewrite the import export later.

So they prefer finish the bases and then add an import/export.

But, the issue is that right now, we don’t know at what stage they are, if it’s abandonned, if it’s planned for this year etc and it’s not in their plans to make this import/export.

The users will have to make it and I think it’s stupid, they should make this import/export themself because that will be better than someone who will never update it.

But, for me the big issue is that they seems to not care about working with other softwares, or this import/export will be in the todo list like the cache system.

I see a lot of people recently who wants to work on blender, but they see we don’t have alembic so they stay on maya or max.
It’s bad for blender because more skilled users is better for everyone.

For better or worse, I think that’s one of the side effects of Blender’s primary mission to be a “complete 3D creation pipeline”. If the goal is to do everything in Blender, then interoperability with other software is just not going to be a priority. As Sergey says at 48:20 in the podcast Fweeb linked to: “Let’s focus on Blender('s) pipeline first then see how can we improve interoperability with other software.”

Personally I agree with you, that’s not a very user friendly strategy, but it certainly isn’t the first time the BF’s strategy has aimed for lofty ideals while skipping over pragmatic improvements that would make the lives of users easier.

Interop should be, IMO, priority number one for 2.8/3.0. Not only would it make a lot of people happy, it would take a lot of the burden off the the devs to immediately fix some of Blender’s weaker areas if more serious artists who rely on such things could simply do things externally and import. Blender is certainly my modeler of choice, but I can’t even come close to recommending it to other artists who work in other parts of the animation/sim pipeline. Some focus on I/O would change that in a heartbeat.

100% agreed.

Perhaps it is helpful If an example is given:

I’m using Blender and Houdini on a small cinematic video (14 shots). In this Blender scene FBX and PC2 cache is imported from Houdini. It works well but vertex count CANNOT change with fbx. Not so with Alembic as it would enable dynamic fragmentation, debries and particles that are spawned from pieces breaking apart and reacting to ground. This is just 1 example. I also had to deal with water (splashes, beach shore, boat waves), pyro, explosions, particles etc. It is just a shame to prerender them to be used as flat planes or to try match camera animations between software to try bring it together in composition. Alembic would really make a huge difference for fluid, efficient pipeline where Blender and Cycles GPU rendering can be utilized to operate on bigger projects.

Thank you for reading

I think it would be useful that there were simple but extensive Alembic test scenes, workflows and files for the rest of us mortals to see what it is about. Alembic does have Python bindings and Blender does support using custom Python libraries. Just saying.

I’m really interested in understanding what Alembic is all about but it doesn’t really belong into my workflow so I have a really shallow understanding what it even does, outside being a smaller and faster caching file that supports animation data.

Just to chime in here, do you think it might be possible for the Blender developers to just outright replace the current cache system that Blender has with Alembic (due to it being compatible with the GPL and all)?

Or is it more or less strictly an I/O format?

http://www.alembic.io/

We use it extensively at work, it has a rather simple workflow and it is very efficient, at least in Maya and Houdini!

Exemple, we use it to import RealFlow sequences, but it goes really well since it sorta bakes everything in a standard file format that can be easily imported into either Maya or Houdini, same goes between Houdi effects into Maya, and so forth!

Maybe we should make a petition, if 5000 or 10 000 persons sign it, the dev’s will listen to us ?

I don’t want to speculate too much, but that might be the idea… though that, too, is a non-trivial task.

But folks, everyone knows how useful Alembic is… but it’s not a panacea. If we want to support the format, we’re going to want to support it properly… with the proper underpinnings. For example, there have long been requests for importing and exporting parametric objects (like solids) in Blender. Technically, it wouldn’t be all that hard to write an importer/exporter to some standardized solids format. However, Blender doesn’t really have native parametric object. So although an importer/exporter could be written, the data would be really nasty and more or less useless for a solid modeling workflow. To get to the point where we have meaningful, useful imports and exports, Blender would the requisite underpinnings to properly support parametric objects. With supporting Alembic and a proper mesh cache pipeline, a similar amount of work would be necessary. Otherwise, that imported and exported data is going to be pretty frustrating to try to use (particularly imported data).

TL;DR - it is being talked about. The developers are listening. It is being worked on. They gained a lot of experience on what works and what doesn’t work during Gooseberry. Give them the time to do it right.

As long as they are working towards the goal of good interop using Alembic and are making that a priority, I’ll continue to be patient. The fear is that the devs have little interest in interop and are only interested in Alembic for internal blender use. Some clarification from devs like Lukas or Sergey would be great.