mouseman

Hi, Chris, an impressive effort! Interesting character design, and a nice creepy/eerie feel to it, and an interesting twist with the definite "Twilight Zone" feel. My first suggestion would be to put a little more furniture in the first room. I think that would give it a little more homey and lived-in feel. The second suggestion is to try not to get the feet sliding on the walks. No one else mentioned it, so maybe it's just me, but that kind of pulls me out of the world. Getting it right is really hard unless you have inverse kinematics on your feet. Even then, it's still hard. Getting the scene of the battery installation and the final scene where she is one of many other robots to read better would help. For the battery, maybe a bit more of a close-up on the battery so it's clear what it is would help. For the end, maybe it needs more time to read. It would be nice to have him set up one of the other robots for another scene, but I don't think you could squeeze it in given the song length. I look forward to seeing more!

Wow, I think you've produced more seconds of animation than I have in total! It's looking great so far! I'm impressed that you have all the elements to make a whole concept. For the first video (dietly confused), I think the guy at the table lip syncing to "confused, confused, I'm dietly confused" would work well, as would lip syncing when the list of diets is read off. The caveman could have sung his part, too; maybe slightly more of a close-up for him. There are a couple of scenes where the nutritionists' faces and bodies are stiff that could use a little loosening up. For the second video (happy vegans singing), the only thing I could think of was if the woman playing the "guitar" had actions that more closely mimicked the left and right hands of the actual guitar player. Maybe adding a back-yard visible outside the kitchen window. I don't have any particular technical suggestions. You highlighted a lot of the areas you wanted to improve, and I think those are right on. It takes a lot of practice, especially learning to smooth out action without having hundreds of keyframes. Keep it up!

Wikified, and linked from the Plugins page.

Code-wise, having more than one option show up should be quite easy - a single property that takes 10 seconds to change. Did you report a bug?

Wow, what a set of fixes! Thanks especially for 6571: Net Render slaves cannot load camera from Technocrane! I'm sure Jason Hampton will appreciate it, as well.

The license system will work indefinitely for older versions, right? So XP users could still use 18.x but no later.

I see where you're coming from with exporting a bunch of the same object as a single model (i.e. a single mesh). However, as a programmer, having multiple copies of the mesh seems kind of wrong. There are heuristics/guidelines that say "Don't repeat yourself" and "once and only once". We were thinking that the pose action approach would allow us to easily turn on the set for rendering the background and then turn on the characters for foreground. But we'd need to come up with a new way of doing that once we come up with a new idea for composing the sets. The characters will need to interact with parts of the set and with props (e.g. with the coffee machine, the fridge under the counter, coffee cups, the milk pitcher, etc.), so thought will have to go into what is part of the fixed/umovable set and what is a prop that the actors interact with. That sounds like a promising idea. We'll give that a go and let you know how it works. Thanks, Robert!

Steve and I have been using poses in models to compose larger models -- even whole sets -- from smaller models. This is very useful to avoid creating multiple copies of mesh, as well as allowing an easy way of turning on and off various parts of the model. Here are the requirements that we had when the pose idea came up: Avoid having multiple copies of the same mesh. If there are 18 chairs in the set, there should not be 18 copies of the mesh in some model. Ideally, they need to be configurable for different situations. For example, we don't want a separate set for the coffee shop before it opens (less clutter) and after (more supplies, etc. laying around and on shelves). You need to be able to turn things on and off. The sets and large models need to be reusable. That is, you can create a new choreography, drag in a model, maybe change a couple of pose values, and be ready to animation. However, we have run into two show stoppers for this technique, which we outlined in this post. Because of that, we may need to resort to a plan B. Which we don't have! So I wanted to ask everyone: How do you create large sets or large models? Agep mentioned he did the Nidaros Cathedral by doing it "in an action (action objects), so when in the chor I simply drag and drop the action onto the basemodel", and "I sometimes merges two or more models when they are finished, so they are total ends at 30-60K". John Bigboote said of his SOCCER STADIUM: "it is assembled in an action... many parts are reused dozens of times- [ ... ]. I keep my splining real minimal, I keep expecting A:M to 'hit a wall' and be unable to accept any more, but it keeps allowing more and more models to be added via the action." However, on his MANHATTAN post, he said: "No duplicator wizard used, just good old copy and paste and heavy usage of action objects." Any other ideas, or clarifications on those existing ideas? Or problems you've run into? Thanks! Chris

I just wanted to let everyone know that there are currently two major problems with this technique. 1. NetRender does not pick up all of the contained action objects. Things will render as expected in the main application, but not in NetRender. This is ticket 6617. 2. Multiple levels of poses don't work. By this, I mean if you have a car model with only the body, and create a pose that adds 4 wheels, then you include that model in a set that is a race track, the wheels will appear in the wrong position. This is ticket 6620. These are show-stopper bugs. Until these issues are fixed, this technique will be more of a hindrance than a help.

This is now ticket #6617. I created a simple project and attached it to that ticket. Here is the sample project rendered from within A:M and from within NR. The ears are attached as action objects within a pose; they are inactive in the pose=OFF setting, and active in the pose=ON setting, as I was doing in the tutorial video I'd posted previously here. In A:M: In NetRender:

Hey, jakerupert, The rig was made in v18. I'm not sure how much the file format has changed since v15, but I think the rig is just straight bones and constraints and maybe a few expressions which I suspect haven't changed since then. It wouldn't hurt to load in the rig (or a sample rigged character) and see what you get.

It's been a while since I've visited this thread, as I've been working with Steve on the Cupid project. However, we were looking for things to put in the scene, and Steve suggested the school bus. So I put a bit of work into it with the grille and the headlights as well as fixing some structural things you can't see here. I also wanted to make the seats use a model embedded multiple times via poses, but there were issues when I tried to make constraints (they always added to the first or last action object in the pose). Work remaining: I want to add the special mirrors on the front, which will require moving the turn signals back. Possibly "dirty" it up a bit. At that point it may be good enough for what we'd need it for in Cupid. There's also a quick animation. SchoolBus1.mp4

But is there a way to accumulate small changes based on the distance? Or just have it automatically accumulate based on a velocity that you can set based on the distance away? I'm sure that the existing Flocking feature does this internally, but there's not enough control over the particulars to get the kind of effect Rodney is looking for.

To expand a bit on Gerald's answer, part of the reason is that if you position and rotate everything in the OFF position, you have only one key frame for both OFF, and the hold after is inherited in the ON pose. It's in the same position regardless of whether the pose is ON or off, and if you add a bone or something else later on, it will be where the object is by default, not at 0,0,0. But if you positioned it in the ON position, then you'd have a keyframe of 0,0,0 in the OFF position created by default, and whatever you set it to in the ON position. If you forgot to hide the bones, you'd have all of these bones at 0,0,0 when the pose was inactive, instead of where they would be when the pose is ON. The Active and Hidden properties for the bones (not shown) must have different values in each pose. The position and rotation and scaling only need one, and setting the value in the OFF pose setting achieves that. It's a slightly picky thing, and probably wouldn't hurt if you had different keyframes in both ON and OFF settings. All else being equal, I'd consider 1 keyframe better than 2.

I'm glad you guys found this useful! It feels almost like a game-changer for both modelling and animating. For example, for the school bus I worked on a couple of years ago, I copied the passenger seats multiple times to fill out the bus. I could have just created one passenger seat, and then included it 22 times in a pose. Why stop there? I could have had poses that stretched the bus, and at 1% had one row of seats, 2% 2 rows of seats, etc. Maybe this technique could be combined with the DressMe plugin and pose sliders to change what the person is wearing. Or using the hair cap method that John Bigboote, have different hair styles in different models active only for specific pose values for different looks. (e.g. Clothing style 4=gym suit, hair style 3=tied back in a ponytail.) Workflow-wise, I used to create a choreography with the set objects, and then animate multiple scenes on the same choreography to avoid having to re-create the entire set for every choreography. I switched to using action objects for a while, but it was still kind of klunky. Now with one model for the set, I can create a new choreography, drag in the set and the 3 or 4 characters I need, turn on and off a couple of poses, and start animating! That's a game changer, at least for me. I'm sure some of the studios have stumbled across this idea, but I think it will greatly increase the re-usability of models and scene/shot start-up. We're kicking around other ideas for how we could use variations of this technique for other purposes ... we'll let you know if we come up with anything else cool.

In our Cupid project, we ran across a problem with big models and big sets. While considering this issue, I stumbled across a technique for composing models from other models. I'm sure others have come across it before, but I don't think it's common knowledge. vM8caqBArDg or here In the first part of the video, I unfortunately refer to the inner models as street lights instead of traffic lights. Hopefully that's not too distracting. Additional information I did not mention in the video: An additional use for this technique would be rendering an animation with the foreground objects turned off to get the background only. The foreground can then be rendered on its own and the videos can be composited back together. Additionally, you can import models that already have been composed of other models. One disadvantage to this technique is that light lists may not deal well with these contained objects. I created the tutorial with CamStudio, and put together the 4 segments with NCH VideoPad free version.

Wikified.

Yes! Small teams with small projects. As Steve Shelton said earlier, we have had a lot of success working together. I'd love to see the people with the most all-round skills help lead/mentor a group to come up with a storyline, design a set and characters, model / texture / rig them all, and do a short. As far as I can tell, some of the people (off the top of my head, I'm probably missing a lot) with the best all-round skills that are recently active are probably Robcat and Nancy, followed by Largento and John Bigboote and xtaz; others with lots of skills include mtpeak, itsjustme, Gerald, William Sutton. Put together a few teams, divide the work, help each other out, do something and get it done and out there in a relatively short time (3 months?), then break up and reform different teams. Use Skype and/or Google+ to communicate; share files in SVN and/or Dropbox.

It was recently suggested that Steve and I blog a bit about what is going on with our project. We've slowed down a bit in the last few weeks due to real life, but here's what I've been doing when I've found the time. First, the coffee shop was originally created by Steve as 4 big models. I have been thinking it would be nice to split them apart into individual models so they could be managed a little easier, then composing them using Actions that contain Action Objects. I was a little worried about how that was going to work, and I learned that some things worked better than I expected and other things not as well as I expected. For the uninitiated, the idea is that you can have a "base" object, for example, an empty room or even just the floor. Then you can create an Action for that object. Then drag in various objects, such as walls, doors, chairs, couches, end tables, lamps, coffee table, newspaper, etc. As you drag the objects in, they become "Action Objects". Basically, you compose the contents of the scene within the Action. Then, you drag the "base" object into the Choreography and drag the Action onto that object, and your set is ready to use. One thing I was worried about was that I would not be able to interact with and manipulate the Action Objects in the Choreography. Well, it turns out that you can! When you are in the Choreography, select the object with the Action, go to Skeletal Mode (F8) and there are the bones of the Action Objects! Select one of the bones and the Action Object is now in the tree, and you can do stuff with it there, even play with its pose sliders. However, you do not have the ability to change its render mode, which is something I would like greatly, and you cannot drag other actions onto it, which I would also like greatly if we could do that. For example, it might be nice to have a coffee brewing machine, build up an action with coffee pots, and then bring the coffee brewing machine into the set as an action object and add the coffee pot action object to the coffee machine. Another thing I did was add lights into the coffee shop model. I added a tiny bit of volumetric lighting which is a really nice effect, but I am afraid the render times will be too much when we have everything together. We'll see. Another issue we had was that whenever we'd open up a project, we'd get a bunch of dialogs asking for one of the models ("Cindy_Final2.mdl") or for some resource of no name. After some fiddling, I found that there were many assets with something like this in it: <Plugin Properties> <NewtonProject> NewtonProjectMatFile=../Cindy/Cindy_Final2.mdl </NewtonProject> </Plugin Properties> I went through all of the .mdl and .act and .prj files that had something like that and just got rid of that NewtonProject section altogether. And now the project loads without asking for any files (named or otherwise)! I'll have to watch to see if they start reappearing again.

Great design and modelling! Can't wait to what you do with her.

Sorry for my delay in responding. Is it possible that an effective workaround might be to avoid naming actions with a number at the end? Or perhaps spelling that number out (i.e. FacialAnimThree)? The thing I was referring to was not the names of choreographies themselves (though we had a different issue with that which I also mentioned later). The issue I'm mentioning is that choreography ACTIONS that were given a name without any number on them (such as "FacialAnim") would have a number appended to it at some point by A:M. Then it would later be changed in future saves. I realize I should probably put some effort into finding out what sequence of steps causes it and create a report. I believe it is in no part related to Subversion. I'd like to know more about why you believe this is the case. Besides people's general aversion to using versioning systems I thought SVN was pretty good for maintaining collections of assets. I do understand that SVN is a centralized and not a distributed model like Git and Mercurial and that is a little problematic. But it shouldn't be too difficult to use SVN for file sharing with small teams. If one of the issues is that it's hard to keep track of what is new/old/updated at a glance by just looking at the directory structure then I think I know what you mean. A versioning system is good for things that need to have a history tracked. This is important in things like source code, where you need to be able to track down when a bug was introduced into the code (and who did it, what were they trying to accomplish when the bug was introduced, etc.). A repository/versioning system technically could be used as a file transfer system, where one person adds and commits a file to the repository, and when the other person gets the file when they update their own working copy. But it's not an ideal use of the repository. One disadvantage of a versioning system is that you have a copy of every version. This means every version uses disk space. While disk space is getting cheaper and cheaper all the time, the reality is that the disk that the central repository is on is of a finite space. Assuming there are backups of that server, the backup time takes longer as there are more files and takes more space. Also, if you check in a huge file, then others will be downloading it the next time they do an update, and might be quite annoyed with the wait. There is a "cost" of sorts for checking something in. Obviously, you should check in your PRJ files, your CHO files, your MDL files, your texture files/images, and other assets directly needed to re-render your work. No question to that. Reference drawings or videos? Probably that's fine. Now, if I render a test render with weird options to a sequence of PNG or JPG files and when it was done used them to generate an MP4 video, would those PNG or JPG files need to be checked in? Well, assuming everything needed to create them was checked into the repository, they are things that can be regenerated by exporting the old revision of the tree and re-rendering from that. You would probably not need to go back to reference that file after it was used to generate an animation. Also, there is little likelihood that you would need to differentiate frame 739 from one test render to another. There is no need to have a history of the generated file and there is no need to ever refer back to it, so it doesn't make sense to put it into the versioning system. Similarly, the video files of the test renders usually don't need to be kept for posterity, so putting them in the repository so the other person can see what it looks like is not an optimal use of the repository. In short, any item whose value is known to be a very short time is not a good candidate for putting into the repository, and would be better handled by some other transfer means.

These are some of the general things we learned on this project. We thought we would present them here in hopes that others might find it useful. Lessons Learned GENERAL, PLANNING Less is more. Don't add too much material. Longer video length means longer render times, and more to fix if there is a problem to be fixed. Just do it. Get in and do it. If you mess up, it can be fixed or re-done. Don't be afraid to show your work early and often. Have your work reviewed, don't be intimidated. (And on the reviewer side, focus on what could be added or plussed.) Script - get specific ideas laid in as soon as possible. Having specific plot points is great, but you need the in-between stuff figured out, too, otherwise the characters are just wandering. COLLABORATION "One man, one machine, one movie" has its limits. You can do a lot more together. Working with another person is a gold mine. Different point of view, different ideas for ways of doing something. Video conferencing is invaluable. Skype has the best quality, but no longer has free screen sharing. GTalk/google hangouts is acceptable and has screen sharing, but is not as good for live movement (i.e. playing an animation). We may tinker with Microsoft Lync in the future. Having a set schedule of times to talk is important. Although some flexibility is necessary (family obligations, etc.), regular interaction helps. We met twice per week. REVISION CONTROL / SUBVERSION Need to have someone that knows Subversion well, including how to deal with problems such as conflicts. There is a little bit of a learning curve. Need a host. The repository acts a location for backing up the project; if you lose your machine, you can re-get everything from the repository. Everyone needs to be up to date on how to do it; maybe have training sessions though GTalk. Commit often so the others have access to your latest work. Commits are, to an extent, a measure of progress. Always add a comment. It is important to create non-changing file names and not change them, not even for alternate versions. (One exception might be having a pre-exported version of a rigged character and a post-exported version of the rigged character.) References to assets from other files can get easily messed up and point to the wrong version. If you want to make a local backup that you don't want to commit, use explorer and hit CTRL-C to copy and CTRL-V to paste. Otherwise, just commit the current version of the file. You can always get access to older versions through SVN. Multiple people cannot work effectively on a single choreography at the same time. There must be a hand-off procedure. Versioning systems are good for creating versions of assets. However, it is not good for a general file sharing or transfer system. Consider using dropbox or an FTP site or something similar, although these often have storage or transfer limitations. The versioning system is also not a place to store or transfer copies of generated files (such as the final rendered animation sequence). Always be mindful of what you are checking in. Animation:Master currently adds nonsense changes to files, especially choreographies. These have no real meaning, and can cause merge conflicts in the future that will need to be resolved. This is especially frustrating if one person is making significant changes to that file and the other person is not. Revert any changes you can't account for. Non-changes that A:M keeps adding or changing: A:M changes names of chor actions - adds a different number, e.g. FacialAnim3 becomes FacialAnim2 (when we never added a number ourselves) Lots of empty ROTOSCOPE entries in choreography files. CHANNELDRIVER ANIMATION Cloth: Combine cloth to model, pre-roll. But you don't have to do it. No sudden movements; start in a neutral pose, let cloth relax, then do movements. Rigging: Don't be afraid to do your own sub-set of rig. We might be heading towards creating own face rig, but we'll try them all first. Shoulder and hips are still hard to weight correctly. Weighting is always hard. Remember to weight only to geometry bones (and fan bones). Reuse models wherever possible, or rework them (e.g. we made a chair into a sofa and a single bed into a double bed). Don't model if it's not visible. (e.g. we had a door that wasn't in the set, but didn't need to be visible; we didn't model it, just made the characters act as if it were there.) Animating helps us learn about how to model and rig better. For example, when you move some bones in a reasonable fashion and the mesh deforms in an undesirable way, it may be due to a bad choice for which direction the splines go. We will always model with a spline that goes from the side of the mouth to where the hinge of the jaw would be. RENDERING Create presets to do animations of the entire scene but with a high step value. The presets include start and end times and the step value, so you may need at least one for each choreography. Make sure enough options are turned on to be able to judge things like hair, particles, and lighting (or even custom to one feature). Avoid committing to a big render until you are happy with the quick animations. For NetRender, Multiple machines and cores - understand the basics of networking itself. How to do a shared file/folder. The slave machines must have the exact same paths to the data files on all machines. If there is a problem, look for permission issues; make sure the client can create files in the data folders.

I only pop into the 32 bit version when I need Quicktime. Otherwise, I work entirely in the 64-bit to get the faster render times. I usually render either individual frames or render to an AVI with uncompressed frames and then re-encode it in Handbrake, so I don't usually have a direct need for Quicktime from within A:M.

Looks quite good. It might be interesting to have just a little more air time (and correspondingly a very slight amount more height) after the push off. But it's quite good as is.

Excellent link, Rodney. Excellent.