Right. It sounds interesting. We have something similar in place. We already have a pipeline which is addressing what you're mentioning below. What I was looking for was more of a separate archive or library where some things from a project can be shelved and identified correctly for future use. The reason is the way we are set up, once we are done and delivered a project, the sandboxes get deleted and only what has been checked in with the pipeline tools is backed up. That way we only have the relevant scenes, assets etc... Once the backup is done, it can take up to 3 weeks to get a project back. We don't always have that kind of time so we want to use a tool similar to ResourceSpace to create a growing library of the kind of assets that gets regularly used. For example we model lots of characters and we're asked to do more and more crowds so having secondary or low characters already available will improve previz quality and turnaround time instead of having to remodel everything or having ugly unibody proxies. ;) And since we're a game company and that we do quite a few shooters we also have tons of different guns at different resolutions. We need to index this properly. We'll be having discussion about all this soon internally. The way I see it right now is probably to go with something like ResourceSpace and include the power of Fabric Engine. Might be overkill, thumbnails might do. We'll see how excited I can get the developers over this. ;)
Thanks Michal and all MAC -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Michal Doniec Sent: Thursday, September 06, 2012 7:13 AM To: [email protected] Subject: Re: Asset viewer / manager I developed one which uses Python/PyQT/SQL and perforce (was used sucessfully on our last project which is about to be shipped), but it's just for lighweight assets (.emdls). Basically all tracking is done using SQL, storage and version control is left to perforce, with only very lightweight wrapper library (I wrote it to simplify perforce interactions only) to interface with asset manager. It works on a higher level than just .emdl, deifning an asset as an abstract database record/entity, so you can have an asset which contains rigs, meshes etc. components. Component is defined as an abstract class with only save/load methods (which come from packagae specific custom module, so in theory should be easy to port to other 3d app) and a couple of properties like version and perforce path, so it's easily extendable to any component type (obj, textures, fbx files I even had some reference pictures etc.. as components within an asset). It makes it easy to add custom properties like root node and bone count for the rigs etc. All these components can be freely instanced between multple assets, so you can have a rig shared between multiple creatures, for example. It is a push system, so when someone modfies and saves an asset, everyone gets it automatically (there is a warning and choice to cancel tho). We used it mainly for characters. I am not sure about performance (load/save/sync speed) when attempting this approach with caches/obj and other heavy data, but I'd think it's mainly dependend on the speed of your network/servers during sync/submit. For lightweight models it was very fast. I generate thumbnails on save and they are stored as plain files in perforce, also store connections between components in SQL records (link withs coming from rig .emdl to mesh .emdl, envelopes, etc), they are recreated on load, so there is no issue having connections between different components or mutiple instances of the same assets in the scene (evelopes and other stuff will connect correctly). QT takes care of the infterface, it's all displayed in a tree like browser with thumbnails. It's really nothing fancy, just simple database tracking with an interface, doing all perforce work for the user in the background. Having everything tracked in SQL database allowed easy comminuctations with our animation production database and export/importscene building tools. I am sure it can be done quicker and better with help of tools like Fabric Engine. On Tue, Sep 4, 2012 at 6:45 PM, Marc-Andre Carbonneau <[email protected]> wrote: > Hi, > > We’re looking into archiving and building a library of assets we have. > > > > By assets I mean: > > 3D assets(.obj, .FBX, .abc, .emdl…) and > > 2D assets(reference images, textures, concept art…) > > > > How are you guys organizing all this in your studio? > > Do you use a system that’s both a viewer and a repository or you’re > using regular windows folders along with a viewer? > > > > Thanks for any advice, info you can give me. > > MAC > > -- ---------- Michal http://uk.linkedin.com/in/mdoniec
