 | | | pipeline development theory (Alienbrain) | pipeline development theory (Alienbrain) 2005-06-16 - By André Adam
Back
On the Alienbrain topic, we use it over here as a version control system
for our game data (not using the XSI integration, btw). In this regard
it's pretty unrivaled, since every other out-of-the-box system I have
seen so far was designed for code files and collapsed when pushing heavy
sized data to it.
I don't know about the internals of the Alienbrain database; I can
confirm though that the system definately isn't the fastest thing on the
planet. On the other hand its performance doesn't seem to be related to
the overall content stored in the system and it's perfectly stable, we
use it for five years now and it never lost anything fed to it. One can
call it the core element of our production pipeline and we're happy with it.
-Andr�
xsibrad@(protected) wrote:
>Quoting Helge Mathee <helge.mathee@(protected)>:
>
>
>
>>I hope you are aware of that you just started one of these really long
>>threads.... ;-)
>>
>>
>
>thats ok. Softimage has the bandwidth to spare. I think :)
>
>
>
>>and yes, we do this kind of stuff here at Omation. ;-)
>>
>>
>
>Really? Now my interest is peeked.
>
>
>
>>1. I looked at Alienbrain, and the main reason for not using it right now is
>>its database.
>>Alienbrain uses a text and file based database (and please correct me if I
>>am wrong) and
>>the typical SQL relational database features are missing. Especially when it
>>comes to
>>searching.
>>
>>
>
>yikes. flat files? Thats enough to make me stay away. a relational database
>can always be upgraded for performance as long as its designed intelligently.
>But flat files cannot. Thanks for the info.
>
>
>
>>The main
>>limitations we
>>encounter are Overrides and Hair, because there's simply no object model for
>>these.
>>Other than that, I was able to implement storage and regeneration for all
>>kinds of
>>objects through XML.
>>
>>
>
>Wow, so not only is it possible, but its been done. thats pretty much what I
>was contemplating as a potential solution. I was thinking in terms of tossing
>the meta-data into a sql database and the binary XSI data as EMDL files in a
>subversion repository myself. But it sounds like there's more than a few
>solutions here.
>
>
>
>>As far as refmodels go: They're what keep Omation
>>running.
>>The referenced model architecture might be 'still rough around the edges',
>>but they're production proven as far as we are concerned. There's a few
>>kinks,
>>but as long as you are able to rebuild scenes and 'clean' the referenced
>>model
>>animation clip by rebuilding it, it's fine.
>>
>>
>
>So basically if a feature doesn't ref in correctly you toss the requied data
>into XML for safe keeping. Then when you bring it in again, you wipe out the
>remnants of the broken feature and use your XML data to build a new one?
>
>Hrm... come to think of it... if you use this type of system it overcomes all
>the annoying renaming and guid hashing issues.
>
>Whoa... you're right... I should have though more carefully before starting
this
>thread. Now I want to start R&D on something like this rather than meeting my
>deadline for SIGGRAPH.
>
>Must... keep... on... schedule...
>
>Thanks Helge.
>
---
Unsubscribe? Mail Majordomo@(protected) with the following text in body:
unsubscribe xsi
|
|
|