Content Management (what tool to use?)

Started by
7 comments, last by Kitt3n 16 years, 6 months ago
What would you guys use as a content-management system? It should be easy to check-in/update (think cvs/tortoise), handle many gigabytes (let's say 100-500gb of raw content eg models, animations and textures) and it should be fast. In the ideal case it also supports versioning (and maybe even tagging of a version). I'm interested in open-source/free solutions (maybe subversion?) as well as commercial solutions (eg perforce). There is a slight preference for a windows-based solution, but if there is a do-it-all tool for linux that would also be an option. Any idea on what would be be suited for the task? Thanks!
visit my website at www.kalmiya.com
Advertisement
Quote:Original post by Kitt3n
What would you guys use as a content-management system?


For asset management I heard about Alienbrain and is integrated in Max, Maya, XSI, photoshop and many others (like Visual Studio). I never used any other tool dedicated to asset management.

I guess most people put them in the source repository since it does want they need (keep a history of revisions of assets).

Quote:Original post by Kitt3n
I'm interested in open-source/free solutions (maybe subversion?) as
well as commercial solutions (eg perforce). [...]

Any idea on what would be be suited for the task?


For code versioning I guess people uses tools like Perforce, Subversion, CVS, etc (Google or wikipedia to find a longer list).

JFF
I'd be happy to make some recommendations, but I need you to please clarify something. You are asking about CMS but you use VCS examples. Are you looking to simply store versioned copies of files (using version control systems like subversion and CVS), or are you looking to build a website (and use a content management system like Joomla)? You may have confused Content Management Systems with Configuration Management Systems.
Yeah, I'm using VCS examples because that's my frame of reference
as a programmer. VCS are great for sourcecode (textfiles), but
it's probably a bad idea to add several gigabytes of binaries into it.

So what I'd like to have a version-control system / central repository
for storing 500GB - 1TB of big binaries. "Content" in this context
means textures, models, animations, ...

As a background:

In my experience graphics-guys are always a bit chaotic, they tend
to store their maxfiles everywhere (from local harddisk, to network
user directories to 'tranfer-directories') - and this results in
several version of files floating around the network, modified by
different people.
This gets even messier if external companies are involved

Lately it got really annoying when I made a few change-requests, and I got
answers ranging from
"Nope, we don't have the .max files anymore" (you are kidding, right?!) to
"Yeah... I think John was working on it.. but he's on a holliday,
let's check his computer.. or his user-directory.. or [5 mins later]..
We found some files which *might* be the correct ones.."

So they really need to change the way they work - and a central repository
would be a step in the right direction.
This way, we can also extend the build-pipeline do automate the conversion
into our ingame-format, so the only way they can get their content into the
game,is over the central repository.

Regards
visit my website at www.kalmiya.com
Quote:Original post by Kitt3n
Yeah, I'm using VCS examples because that's my frame of reference
as a programmer. VCS are great for sourcecode (textfiles), but
it's probably a bad idea to add several gigabytes of binaries into it.

So what I'd like to have a version-control system / central repository
for storing 500GB - 1TB of big binaries. "Content" in this context
means textures, models, animations, ...


I never tested that much data on SVN... but it should be able to handle that. Binary files are treated as... binary files... and they are not versionned the same way as text files. Instead of keeping a diff between revisions a whole new copy is kept for all revisions.

Otherwise like I said the only asset management system I know of is Alienbrain. It's integrated into max, maya and others and offers "tools" to manage requests and work of the artists. Plus you can create the files yourself (by using a template) then assign that file the related info (design document, images, etc). Once the file is created you assign the work to an artist. You can also see what is assigned to which artists and see their status.

Alienbrain is pretty expensive through... and you can probably do the same with another source control tool and some kind of management tool for what is missing. In a company I worked we used Microsoft SharePoint to manage the tasks assigned to everybody... and I'm sure there are other tools.



Quote:Original post by Kitt3n
So they really need to change the way they work - and a central repository
would be a step in the right direction.
This way, we can also extend the build-pipeline do automate the conversion
into our ingame-format, so the only way they can get their content into the
game,is over the central repository.


Assets all over the place is not a good way to work, and like you said, it may lead to lost assets. Central repository is a way to fix this but you need to enforce some structure otherwise it will end up being the same.

JFF
We use Perforce here for all of our source/content management needs, while we don't have anything in the range of 500 GB (Really now? what are you storing, our biggest texture isn't even 500MB) we do have some packages that are in the GB range, and the current revision of our project is around 40 GB it has decent integration for our artists, and I hear it has some nice preview plugins as well to help preview assets, this should get you most of the basic Alienbrain level functionality, and it works well over the network. My experience with Alienbrain is that it's in general a bit more of a pain, especially for code if you want to store that as well.

Indy
Quote:Original post by jff_f
Quote:Original post by Kitt3n
Yeah, I'm using VCS examples because that's my frame of reference
as a programmer. VCS are great for sourcecode (textfiles), but
it's probably a bad idea to add several gigabytes of binaries into it.

So what I'd like to have a version-control system / central repository
for storing 500GB - 1TB of big binaries. "Content" in this context
means textures, models, animations, ...

I never tested that much data on SVN... but it should be able to handle that. Binary files are treated as... binary files... and they are not versionned the same way as text files. Instead of keeping a diff between revisions a whole new copy is kept for all revisions.

Not true. Maybe you're thinking of CVS?
Subversion has always used a binary difference algorithm and stores diffs for all files, whether binary or text.

Having said that, I know from experience that committing large files is pretty slow with subversion. Unfortunately I haven't really tried anything else, so I can't offer any alternate recommendations.

John B
The best thing about the internet is the way people with no experience or qualifications can pretend to be completely superior to other people who have no experience or qualifications.
Quote:Original post by Kitt3n
VCS are great for sourcecode (textfiles), but
it's probably a bad idea to add several gigabytes of binaries into it.

Nope, not a bad idea at all. Version control systems can handle huge files just as well as small ones. Subversion with TortoiseSVN as a frontend (or RapidSVN on non-Windows platforms) would work well for the GUI crowd.
Quote:Original post by Kitt3n
[snip]
"Content" in this context
means textures, models, animations, ...

As a background:

In my experience graphics-guys...

Based on what you have described I would suggest using FileHamster. It was designed my MOGware for just the use case you have described. It would be a good idea to take a look at their video tour to see what I mean.
Thanks everyone, looks like the svn seems like a good idea to use :)

ratings++
visit my website at www.kalmiya.com

This topic is closed to new replies.

Advertisement