Project Workflow Question on scene management

[Vertexspline]

So as I am gradually tinkering with more and more aspects of AM , the idea of starting to focus all my work towards a project idea has come to the forefront. If there is one single thing that I have learned here is planning is so important. It is just such a huge time saver. (what surprised me more than anything was the need to plan modeling)

 

Anyhow, so when you guys are working on a relatively small project (say 30 -60 secs) do you keep everything in one project file? All the different scenes and chors kept and saved in the one project?

 

I guess I was wondering if there are any issues with AM bogging down if you start having many Chors or models. Again its more of me trying to understand some best practices of project workflow as I try to be doing things in the most efficiently but correct fashion and before I start off something would like any ideas folks might have to share.

[Rodney]

Anyhow, so when you guys are working on a relatively small project (say 30 -60 secs) do you keep everything in one project file?

 

It may surprise you to hear this but... a lot of folks don't even save their Project files. They use the Choreographies instead.

When you open a Choreography in any new project it'll bring all the assets in with it.

 

Of course when we work in A:M we always work in a Project.

There is no getting around that.

[markw]

For me a good organizational structure is always a big help to working whatever size your project is. And as you say plan and think ahead.

Also a healthy dose of paranoia doesn't go amiss!

 

I have an "Active Projects" folder, which is kept outside of the main Animation Master folder, in my Dropbox folder.

Any project that I'm working on has its own folder inside the Active Projects folder and any thing and everything that is related to that active project is kept/copied to an appropriately named folder within it.

 

That way current projects are always backed up online and can be downloaded again, whole or in part, if needed following a disaster!

I'v never needed it in earnest yet but its nice to know should my computer and backup drives be abducted by aliens, I still won't have lost my A:M projects!

 

I also tend to work with multiple .prj files within any given project as well as .cho files. Some here on the forum like working more with the .cho's

rather than the .prj's as they are self contained.

 

But the most important thing to do is "RENAME AND SAVE". OFTEN.

This applies to anything that can be saved in A:M that you're working with. Give things meaningful names and save them in logically named places, with notes if necessary.

You never know when you are going to have to go back to an earlier version of something.

Most important of these are the model files. ALWAYS save a model, after working on it some, with a NEW name. Otherwise changes to it can propagate backwards through any .prj files that used that model.

 

And when you finally get to rendering out something do it as an Image Sequence, tag or jpeg, I prefer tag's, they do make for bigger file sizes but it preserves the alpha channel which you may need later in post.

Again this is a safety thing. Should A:M fall over whist rendering you still have what did get rendered and its easy to cary on from where it left off when its back up and running again.

The images can then be composted in A:M (or other film editing software if you want)

 

How much of this could be described as best practice I don't know but it works for me.

[mouseman]

I would suggest limiting yourself to projects of 30 seconds or less to get your pipeline working. The forum projects are good value that way. Once your skills are honed, then tackle larger projects.

 

Others save with new file names; I save and commit to SVN. I set up an SVN repository before starting and try to commit after every significant change, or at least at the end of the day.

 

It's nice to push things into their own files, instead of having things included in the PRJ file.

 

I also have a backup that runs periodically. It's not A:M specific, it's all data files, so the A:M files get backed up in that process, as well.

 

PNG is a nice file format to render to. I think it also does transparency. Of course we have NetRender.

 

Depending on how complex your project is, you might want to think a lot about how your file hierarchy is arranged. If you have more than 10 models altogether, you might want to separate them under folders such as "Actors", "Props", "Set". Depending on how complex your models are and how many files are associated with them, you might want to have a separate folder per model.

 

Additionally, I try to keep only data that can be checked in under one "data" folder. All renders go to a separate "renders" folder. I have it set to save and use the file paths in the camera and set that in the choreography's shortcut to the camera, so once those are set correctly I get what I want where I want it with no accidental overwrites.

[robcat2075]

If I'm working on animation and the models are already "final" and saved separately then i just save chors and let the chor load whatever models it needs. We did all of TWO like that.

 

When I'm doing experimental stuff like building/rigging a model and maybe have a chor set up that I'm testing it in along the way, I like to save PRJs with everything embedded so I can always backtrack to a complete self-contained environment.

 

And either way I'm always saving with incremented version numbers, I never save over old files.

[Vertexspline]

Thanks you all for your sage advices ------is interesting to see the different ways to do things and it seems there may not be any really wrong thing to do as long as you plan , are organized , save and save as , and backup. Seems AM often gives us options. I appreciate all your feedback guys and will institute many of these here.

 

And Chris I agree with keeping things very short to learn from --actually right now not doing anything longer than 5 secs.....smiles ---this way I can see exactly what I am doing especially with the timeline items -

[Fuchur]

I do it this way:

- First all my models etc. are embedded in the project-file. I often save in several versions (depending on the project I can save 100 different versions).

- When I reach a state where a model is very complex and cool, I save it externally to backup it.

- After saving the model externally, I reembed everything in the project-file again. That way I can open the project-file in a year again and I will get the same state I had a year before... that is often very important if you are doing something for a customer, etc.

- When I need the model (etc.) from the project for another model, I will use the externally saved model-file... it is important, that it is no longer connected to the project-file for two reasons:

1.) I can alter the model-file and still keep the same state of the other project-file so in a year, when the customer wants me to for example render another perspective of the same scene, I don't run into trouble.

2.) Sometimes you will move a model-file away, because of some new folder-structure, etc. This is no problem, when everything is still embedded in the projectfile...

 

In other situations, it can be useful to use only an external saved file so...

- The project-file can get corrupt... but you still have your model. Be careful so... you should save that one although in several versions!

- If you change something important and want it to effect all the projects it is used in, it is very easy to do it this way.

- You can easily create a large library of objects etc. from which you will just reference your models.

 

---------------------------------------------------------------------------------------------------------------------------------------------

 

It highly depends on what you want to do... For me it is important to save something and get it back later on in the exact same state. If this isnt important you can do it the other way and it will offer the advantages mentioned above.

 

See you

*Fuchur*

[Vertexspline]

Thanks for your ways Fuchur too......really nice responses to my query thanks to you all .

[TheSpleen]

I save chors not proj.

[Vertexspline]

That's interesting Gene ---why do you prefer that over saving the projects ? what's the advantages you feel makes that work best for you? (side note -I really like this thread seeing how some of the guru's operate.)

[NancyGormezano]

why do you prefer that over saving the projects ? what's the advantages you feel makes that work best for you?

 

I also prefer working with and saving chors.

 

Primarily because I prefer to have more control over saving my individual tweaks and variations on materials, models, actions, chors.

 

I do not like working with projects because when you save a project, it saves everything that has been changed (yikes!). I do lots of tweaking, testing of different combos, and it can be a disaster if I accidently save the project, and I'm not yet satisfied with some component of the project. I save my materials, models, actions, and chors all in separate files, and I will increment and save with a new variation number of the material, model, action, chor (in that order) only when I am really happy with the individual components tweak.

 

I never embed anything while still developing. I might embed all when I am done and want to archive the project in a frozen state.

[robcat2075]

Perhaps the most important thing is to understand what you are saving and why you are saving it. Then you can do anything you want.

[Vertexspline]

Robert, you are very right. I guess that's the key to saving and really a part of project management that if done wrongly could make you very ill.

[dblhelix]

this is a surprisingly important thread, thanks Vertexspline for bringing this up!

i read it when it was going on and misinterpreted everything..

have just touched ground after one of those memorable newbie-moments

where i've wrecked an entire project when just wanting to add final touches.

 

it seems a good idea if there was a pdf for the progression, explaining

the different varieties of saving and their consequences, starting from detail

going upward to project. i re-read this now and while helpful, it goes back and forth

quite a bit.

 

i could describe what i did, but that would only be one specific situation of all the possible ones.

 

incidentally, could someone be so kind as to mail me a Gala from the am standard models

to %doublehlx%at%yahoo%dotcom (without the '%' of course),

mine's, errrhmm.. all face now

[dblhelix]

and to no one's surprise, it's robcat to the rescue. thank you!

got you the Infinite Jest from your list, delivery round Nov 9.

you life saver, you!

[robcat2075]

Tell me if these clear it up...

 

Rule 1: If you save anything, using the same file-name you had before, your previous version of that file is gone. That has been true since the dawn of time. If you've changed something, always save your new version with a new name. Version numbers are great for this.

 

A:M special rules:

 

Rule 2: If you make something new (a model, chor, material or action) in a Project and save the Project, the new thing is built into the PRJ file.

 

Rule 3: if you save a model, chor, material or action from your Project, it is no longer built into your PRJ. Your PRJ now has a only a link to that item's saved file.

 

Rule 4: If you save the PRJ in Rule 3 now, it will be saved with that link and will look for the saved item when you later reload that PRJ.

 

Rule 5: If you dont' save that PRJ in Rule 3, your old version of the PRJ still has the built-in model, in whatever state it was in when that PRJ was saved and does not have a link to the new version of the item that you saved out in Rule 3.

 

Rule 6: If you load something (a model, chor, material or action) into a Project, it is not yet built into your PRJ. It is like the items in Rule 3, it is only linked to by the PRJ.

 

Rule 7: IF you edit the thing (a model, chor, material or action) you loaded into your PRJ in Rule 6 and save the PRJ, this forces a same-name save on the edited thing also, overwriting the file you loaded previously.

 

Rule 8: If you load something (a model, chor, material or action) into a Project, and embed it, it is now copied and built into your PRJ. It is no longer linked to the file on disk you loaded. That file on disk is still there, but your PRJ no longer looks to it nor uses it.

[Rodney]

i re-read this now and while helpful, it goes back and forth quite a bit.

 

That's mostly because saving files is never a one-solution-fits-all endeavor.

Although we tend to try to make it work that way.

I believe the main lesson to be learned is to Save often and Save Incrementally no matter how you choose to save.

 

Another thing to consider is that Saving and Backups are not the same thing.

Backups are duplicate copies that you store in a separate/safe place.

Something people do tend to forget is that in order for a Backup to be truly effective it must be tested periodically to make sure it will still work as originally intended. Creating a Backup that will not open when you need it is time ill spent.

 

Edit: Robert listed his Rules of Engagement for Saving while I was typing. Great information. If you begin to save often and incrementally (Robert's Rule #1) you'll learn the other rules more quickly. Don't overwrite a file when you can simply add a number to the end of the file's name.

[Vertexspline]

wow ..this thread has become even more valuable then ever ----awesome insights -------thanks Robert and Rodney for adding even more words of wisdom.

[robcat2075]

This problem of understanding what gets saved when is something I want NewTaoA:M to cover. I've started it by having them just save PRJs in the first exercise and then I hope to introduce the various complications as other exercises run into them.

 

 

 

and to no one's surprise, it's robcat to the rescue. thank you!

got you the Infinite Jest from your list, delivery round Nov 9.

you life saver, you!

 

Thank you! I hereby declare you paid up in advance for quite a long time for any future question having you may have.

[dblhelix]

that was valuable information! just like the compendium on PWS/chor/model/action windows you guys

made when i first came here. it's always the "little" things!

 

after decades in PS and one in AE, saving is second nature.

in a:m i save everything everywhere. models, chors and prjs.

it was the embedding that was new. coming to this thread A.D. (after disaster)

Fuchurs sentence on re-embedding was the only thing i had not done.

i embedded only once, maybe in prj 2. i thought i'd gotten it's function backwards.

but the situation was far from that simple. for those with lab-experience and a fondness for

white mice, i'll recount, others: proceed ony if you already brushed your

teeth and changed into jammies.

 

tried to re-hair a modified Gala with a hair model stripped from a previous version of modified Gala.

begun to hide parts to access hair only to assign it to head bone.

something went wrong and the shift clicking in hierarchy did not take, but the entire model flickered

in an ordered succession from head to toe.

maybe the hiding should have been done in model window.........

but i didn't think of it 'cause i was just orienting in the PWS.

i knew what the flicker meant.

revert, reboot.

 

by an absolute, sheer coincidence the first thing that happened was

i selected group "Head/no tongue" and in the window the entire body got selected.

newbie goes to Panic Room: "oh no there was no undo on this!"

clicked the chor open and allrighty mess it was, the visible bones were in the right pose

but the entire body had gone another route, and her dress a third.

 

Baz Luhrmann might find the hour that followed inspiring but he's not here.

 

tried previous Galas, and here my reasoning is fuzzy due to trauma.

i tried the previously faulty "Head/no tongue" in others,

because i deducted that to be the obvious reason for the separation of bones/geometry in chor

because (by sheer coincidence!) it was the obvious visible connection between the two!

- and clicking "Head" etc, the entire body got selected. in all versions.

"i've assigned her entire body to her head bone. in ALL versions?!"

 

as it turns out there's a mistake in the original Gala.

the group "Head/no tongue" is her body, or, most of it. not her right eye.

and my shift click assigned her entire body to the root bone.

 

what a mess, eh? and if you see the weirdest continuity in the underlying logic of events,

today i find the project ""crashed"" in another way. even though robcat saved me with Gala.

as if it was an omen. All Saints Halloween to you too!

 

robcat, the book clears like a half of my backlog here, and last night you

got me to put all the sharp utensils back into the kitchen drawer. it's lucky for

me we don't live in a just world

[robcat2075]

In most other programs, graphic or or otherwise, saving is saving is saving everything you see before you.

 

In A:M, the desire to reuse models and actions and stuff made it necessary to add the possibility of saving them as separate files that can be used by later by other chors or PRJs.