My ultimate plan is to have reference counting be used to cull assets that aren't being used at all. As I don't have reference counting in yet, through all my demos and tests, my animation, model, and texture trees are growing massive, massive amounts. However, this is exposing something fundamentally flawed with how I was approaching my asset management that reference counting would merely cover up.
How would an artist want to use this tool? (1) To create a new resource for the game and (2) to edit an existing one. But wait, what's the full process of (1)?
>>Character artist:
Hmm... does this texture work? No. I need to up the value here...
>>Animator:
My arcs look terrible there. I'm going to go find a mirror and look silly for an hour. That'll fix everything.
>>Designer:
Oooh! Lemme try that animation. Screw that one. Or this other one. How about this one? Shit I need to redo that blend between the punch and the run.
Aaaand... Well, I don't like any of this. Cancel.
An artist isn't going to start out with final assets in creating the asset. It would be a pain to go through the process of creating a "new" asset, or "editing" an old one (and cancelling the changes later) just to see if your new animation/skin/rig, etc. works.
On top of that, someone like a designer, or an engineer doing stress tests, may try out lots of assets never intended to be in the final tree. It would be foolish to even consider placing them there and not in a temporary area.
So, there's this mode that I'm calling "Demo", an option (3) really. It guarantees no changes to the dev asset tree and the baked asset tree. It's basically a sandbox mode where you don't have to specify any names, whatsoever. Just toss things in and see how they look. Don't like it yet? Rework it and toss it in, live.
With my current system, it initially assumes that all assets being tossed in are intended to be in the final tree, then pruned if nothing ends up using them. This is one step too far, really, because the final asset isn't really defined.
So, what I've come up with are three, well-defined areas:
Dev Assets
- Workable assets completed to some degree
- Not necessarily final, but stable stages of a work-in-progress
- These will be the live assets that artists will modify and re-check-in
Staged Assets
- Local working copy of an artists proposed changes to an asset
- Can be tossed at any time and reset from what's actually in the hierarchy
- Can be committed to Dev and Baked asset trees
- Sourced assets must be in the Dev Asset tree for hard-linking
Baked Assets
- Touched only by the asset tool
- Final game versions of the files
- Tagged with the version control revision number
- Hard-linked to the file in the Dev Asset tree
The difference between the Staged Assets and the sandboxy "demo" view is that Staged Assets require you to be sourcing actual, registered assets. The "demo" mode is intended for informal and rapid iteration of assets. These assets can be located anywhere on the user's computer, on a network drive, or any other location accessible through a path.
Having a required Dev Asset tree guarantees everyone has proper access to all asset files (none of them will get lost on a large team), automated rebaking is guaranteed, and a lookup of an asset that's in-game to its corresponding Max or Maya file is painless.
No comments:
Post a Comment