Concerning Alembic...

I’m probably not the only one who was disappointed to hear that the Alembic solution developed for Gooseberry isn’t likely to make it to master. The reason for it, I believe, is because it’s implementation into the UI was very odd and counter intuitive. I watched a Gooseberry weekly that showed the process and I agree it definitely seemed odd.

However, it also appears to be a tool that works, and it’s currently unknown how long it will take for a re-write to happen.

So I, for one, would like to implore the developers to allow this implementation of Alembic into master, at least until a rewritten solution is made available. Alembic as a feature is too important to leave out on account of it not being as nicely implemented as it could be.

Unless it actually DOESN’T work as it is, in which case forget I said anything. :slight_smile:

Code needs to move fast under production deadlines. So features are added in fast, and rushed. Nobody wants to see rushed features jammed into the master codebase. So most of the code produced for the movie branch is left to rot, while a few superficial features get merged to trunk.

It’s true that the open movies can get a lot of features coded quickly, but if they aren’t of an acceptable quality outside of the production team, what’s the point?

As to if it works or not, from what I understand: it works, but only as an internal cacheing system. there is no file i/o with the alembic as implemented, which kinda makes it not so useful.

Really itching for this feature. Since information floating around is a bit confusing, can anyone give an approximation when we might actually see it?

Thank you

Important to do what ? Did you try a gooseberry build ?
You can grab one, here. https://builder.blender.org

It was not an export/import feature between blender and other applications. It was a cache library from a blend file to another.
If gooseberry implementation do what you need; use a gooseberry build.
If it does not; you will have to explain clearly what you expect when restart will begin.

But I seriously doubt that with OpenSubdiv and all viewport improvements that will come into 2.76; goosebery odd cache library is really expected.

People wants an import/export support for alembic, not a cache system alone.

Alembic is basically just a cache file format:
(Copied from the alembic site )

Alembic Would Be Used…

  • …To bake the results of an animated scene for hand-off to lighting & rendering
  • …To hand off an animated creature for cloth or flesh simulation
  • …To store the results of a cloth or flesh simulation for use in lighting & rendering
  • …To hand off animated geometry to a physical simulation engine
  • …To store the results of a physical simulation engine for use in lighting & rendering

Alembic Would Not Be Used…

  • …To transport complex procedural animation rigs between different applications
  • …To make lossless round trips out of and into the same computation context
  • …To construct complex networks of procedural tools

So if it is integrated in blender properly it would be “easy” to get the import/export since it is designed for this exact purpose.

In the ‘2.8 - the Workflow Release’ blogpost (https://code.blender.org/2015/07/blender-2-8-the-workflow-release/) it is mentioned to code the half finished gooseberry stuff well, integrate it nicely and to integrate blender in non-blender pipelines. I guess alembic would be a big part, at least for the second part.

Let’s hope it will make it!

Yes, psy-fi told me that the import/export could be made easilly, but it’s not on the bf plans to make it, just the cache system.

If the BF makes all the effort to get alembic into blender why not just take the final step? A lot of user would benefit from that I guess… I can understand that it wasn’t a goal for gooseberry to get I/O since it was a all-Blender production, but if you have only internal caching I’d call it a half finished feature for blender in general…

AFAIK the reasons why Lukas refuses to prepare the done work on Alembic was on the code side, not on the UI side.

Alembic as a feature is too important to leave out on account of it not being as nicely implemented as it could be.

Although I agree that Alembic is an important feature, I also understand Lukas’ decision to not work towards merging into master what has been developed for Gooseberry.
When it comes to getting a (long awaited) feature, people often forget how important it is to have a good implementation.

It’s obviously also pretty common that people are not willing to accept that a patch is rejected because of ‘not good enough code’ or some people also don’t understand why we take patch reviewing so serious. So I added some info about this on the Developers Q&A site that should justify this, see here.

All I can say is…


P.S: If someone is interested in having real Alembic on Blender then have a look into Octane Render Plugin for Blender.

You can only export with the plugin, and you have to by the Standalone.

Thanks Julian for your reply, it’s always good to get informations directly from a developer. Let’s hope that Lukas will be able to recode the alembic integration in a less stressful environement than the gooseberry production :slight_smile:

Octane Render Plugin for Blender

is bad for transporting mesh between different applications.
Though it seems to export CCW face, alembic is CW.
So, I’m trying to develop an abc exporter using Octane Render for Blender (GPL) and node.js, but it’s very difficult.
(http://blenderabc.render.jp/)
I expect alembic integration in Blender 2.8.

Sorry for chiming back in so late on this one.

There are many reasons why a good functioning Alembic system is important, not JUST for I/O (although that’s one of the most important features for many, including myself).

It’s also an excellent high performance and hugely efficient caching system that can really make or break a production with lots of heavy characters in a scene together, or for managing dense simulation data.

Basically all the reasons Gooseberry needed Alembic, are the same reasons we all here need it too.

I understand not adding it to master if it doesn’t work well. But if it DOES work well, that’s a bit disappointing. Regardless, I respect Lukas’ decision.

It’s not too old to resurrect this thread :wink: I haven’t looked at the Gooseberry branches at all; what exactly have they done to create an Alembic caching system? Is anything missing from the backend (certain libs, etc.) that would preclude success in forking what they’ve done and taking it a step further to make even a rudimentary Alembic IO addon, just as a stopgap until Blender gets real Alembic support?

Or to ask this a different way: if the BF devs have built Alembic with Python bindings and everything, I wonder if it’s possible to see those libs get shared with interested users?

Apparently Lukas is in the process of looking for jobs, and not likely to take on any large projects until he knows more about the future (heard in IRC). Not sure if any other developers feel like taking on alembic, but you never know…

It is really unfortunate that the complete Gooseberry project didn’t make it, because it would have allowed them to complete tasks like this one. Now, it is just an appetizer for the anti open movie section.

from 4 years ago


It May Need to make a crowdfunding every tool needed

-udim
-shadow catcher
-…

That’s really great! Although you can already export FBX to Houdini for animated meshes with non changing vert count. Would be more interesting to have Blender importer/reader for meshes with changing topology*/point count. Perhaps extended MESH CACHE modifier(for example for fluids from RF, Houdini, Bifrost) or Particle cache ( external particle sims).

I just recently worked with Houdini-Blender project with Fluid sim where I struggled with performance of Mantra. Houdini users appreciate Mantra but indies also have very limited resource that hurts when you’re on a deadline. Cycles and overal Blender integration would have been a bliss. There’s a lot of unexploited potential here.

All in all i want to stress again that importer/reader, mainly for meshes with changing topology is what would enable interoperability with houdini, realflow, maya etc and open a lot of doors for professional use. I really hope to see it happen :slight_smile:

Yeah, I started following Est’s blog when I started trying to use Ramen. At the time, I didn’t know how useful Alembic was, so that post didn’t get my motor going. But now I’m wishing he was still working on that. I’ll have to ask him what he was doing there.