Asset Management


Dear Community,

(for reference: this is about Blender 2.72)

it would be really helpful if Blender had some kind of an asset library or management. It doesn’t need to be a big one like the Poser-9 example above. Just being able to organize stuff like poses, shape keys, materials, objects, armatures etc in submenu structures with thumbnail images would be great.
I have been looking around on the forum but I didn’t find any suitable solution. And I am also wondering: is it really possible that nobody misses such a vital feature? I know about link, append and the copy-and-paste method but these have nothing to do with a management.

Kyraia

Cool!
MUCH better than nothing.
But still, I think this sould be an integrated part of the GUI in the first place. Aren’t there people who use Blender professionally for making money? How do they manage their assets if they have collected thousands of items over the years?
(I admit this is difficult even in Poser with its several Runtimes spread all over your harddisks.)
Anyway, thanks a lot for this download.

Kyraia

It’s the Blender way… for example there never was a material library (like in all other 3D softwares), you have to append stuff from other scenes.

http://gooseberry.blender.org/call-for-feedback-redcurrant-high-level-requirements/

Thanks for that tipoff.

I am involved in a FIRST robotics project to make a safety animation with the robotics team members. They have been studying Blender and we are at the production stage and I’m looking to see if there are any spaces on the cloud that would be good not only for a final render, but optimized for us to use as a “maker space” to store and modify objects, scenes, etc with some kind of version control and communications tools as well as a port to a good online render farm.

Here’s an actual development article to go with it

Seems like the next year will be a big deal for studios who want to take a serious look at Blender, which will be a good thing overall as that could translate into a larger development fund and a larger core team (which means faster development of Blender).

The simple ability to save local information to a blend file with a linked asset, i hope will be achieved in the future. Rather than adding drivers for everything.

Very interesting. I’ll want to keep on top of that.

Until it comes, how have others been doing virtual group projects? Or where in the cloud?

We’ve been using SVN which is not cool. Best would be to write a plugin for Git or fork Git to understand .blend files. And include a Git wrapper in Blender to communicate with a Git repo.

Anway, I would vote for incorporate Git into Blender than build an absolutely new solution. But it’s decided as I see.

Looks like there is nothing really established in terms of group projects. Since my project is a short one, I just opted for online cloud storage. K.I.S.S. Take the finished stuff to a render farm.

You mean use GIT for version control/asset management of data? Last I’ve researched on the topic, GIT is not very good with binary files, SVN was better and Mercurial was best choice. There were threads on these boards a year or two back and some videos on the Youtube about it.

The presentations on the Gooseberry weekly looked nice. I have to take another look to understand the scope but it seems promising.

Using SVN in place of git is the least of the problems.

The killer is this:

We also got some demos from the TACTICteam as well as Damas software, Shotgun, and Thinkbox – with some of them extremely keen to support our project. But after these meetings and demos it was pretty clear that we had to develop our own solution. The main rationale behind this is that we need:

  • A system that we can easily understand and extend
  • Free & open software
  • Something that will fit into the current Blender workflow

Relating to the last point, our pipeline is a little peculiar compared to most film-production scenarios. In general, pipelines and pipeline tools focus on data flow across departments as well as consistent data representation (depending on the context in which the data is required). In this production, we will mostly use the .blend file format (possibly with some Alembic for caching), so some of the main pipeline issues can be addressed later, although we are keeping them in the front of our minds as we design.

Instead of striving to make Blender a good citizen in established pipelines and building on existing tools the long term strategy revolves around a Blender-centric mono-program “pipeline” and a terminal case of Not-Invented-Here syndrome. If anybody had still hopes (aka as pipe dreams) about the future of Blender outside single users/tiny outfits now has no more straws to which grasp: Blender was, is and will always be, safely barricaded in its basement.

End of tramission.