Rodney

Something (actually some things) are definitely out of whack here. I note in the little time that I had to test that some mild distortion around the added circle itself was corrected by changing the in and out bias from 100% to 166%. That really doesn't do anything with the decal images and their apparent inverted-ness however. There is one aspect of this that I'd like to know more about and it is this: Is there any chance that the initial decal was applied onto the model when the normals were facing in other ways than what they are in these test models. In other words, were any normals changed after the decal was applied to correct them? I'm trying to rule out that variable as well as understand how the normals effect the application of the decal itself when it is originally applied. My assumption is that it shouldn't matter as flipping the normal should flip the image applied to that location but there is something nagging at the back of my head regarding why the decal doesn't seem to flip orientation even when the normal itself is flipped. This seems to indicate a flawed decal image and not a flawed model... which is impossible because the test model we are looking at has all of its normals facing out. My pea sized brain is just trying to understand why the decal seems to be flawed and yet the model doesn't. I suppose the easiest way to test this would be to supply a different image (perhaps completely the same color) in place of the one currently applied and review the results. If the decal might have been applied to a model with normals incorrectly aligned perhaps another test would be to reapply the decal again knowing that the normals are all facing the right way. Another question to reduce the variables we are looking at would be to make sure we understand where the decal was initially applied: In A:M, in 3DPainter or in some other place. This is important in knowing if the fix needs to be applied to A:M or some other place. P.S. Thanks for sharing the Project File as that helped in understanding what the problem is a great deal.

Yay! Thanks for confirming that. As of this moment antivirus software is the most common reason that activations don't work.

Pretty amazing stuff. As amazing as this is we can come pretty close to that stuff where they draw on top of the guys hand and it inbetweens the rest automatically with A:M's new 'Snap to Surface' feature. Of course there is a lot more going on than just the matching of animation lines to surfaces in 'Paperman'...

Steve, I see some nice improvement in this last one. There are a few frames (maybe four in total) where the upper leg either stops or moves in the opposite direction that the movement the leg should be going. Extracting those frames seems to make the animation flow a little smoother. This may relate to that comment you made about having her feet on the ground for too long. Attached is a compilation of the run just for the purpose of trying to figure out where everything was going. It may not be of much use to you but noting the change from one image to the next in the arms and legs might help to understand better which way the bones are moving. There was an aspect of weight, squash and stretch that I started looking for in the sequences as well but I didn't get for with that. I suppose you could say that the circled areas represent what I would call extremes and they should tell the story by themselves. You've got some nice poses there but the others don't seem to flow very well into and out of them. The inbetweens just make the motion smooth and finesse the sense of weight and the timing of the motion. If you draw a line on any of her arms and legs you'll see that from frame to frame there isn't much change (in direction or shape) going on and this is working against you in my estimation. These held poses in the extremities should be free flowing and running on smooth arcs. I'd be very curious to see your keyframes and channels. Added: In just looking at the thumbnail image I've attached and glancing from figure to figure you should be able to see the girl running but that isn't happening. You can see a couple poses that read well. Those are really important but there aren't enough of them. In (I think it's frame 10) I made a small note that bringing the other arm/hand up and forward might strengthen that pose.

Simon hit on this aspect and I see the same thing in Robert's video: The range of arm and leg motion is constrained a lot in your animation and more flowing in Robert's video. Interestingly, I thought the arms might bend more on the back swing but you've got that pretty close. It's when the arm goes forward and cross over in front of the chest that yours loses that smooth arcing motion. Similarly, on the movement of the legs backward Robert's fast run has his foot almost up touching his butt while your girl's knees hardly bend upward at all. Aside: I note that that Null (which I assume to be an Eye Target) is moving up and down. Make that a fixed position and you've got it going! Heck, constrain it to another Null that is somewhere off screen. Even if the head moves then the eyes will stay fixed on that location. Back to Robert's video: Note the range of motion of just his upper arm alone. There are some aspects of your video that work 'as is' but almost as if there are missing frames from the end of the sequence. That just so happens to be when the girl's arms would move in front of her.

Just to be clear, I didn't mean to imply Open VDB was like SVN.... I was just responding to the idea of Open VDB as being useful for storing production assets. While it's been said to mean several things at different stages it's name literally means Voxel Databse. At SIGGRAPH one of the developers (Ken Museth) had this to say about Open VDB: I was going to start a different topic to discuss another open source program that focuses on a more SVN-like approach to resource management but with a focus on production management. That program is called 'Tactic'. Look for a topic to be started on it in the near future... or if someone can't wait... they can start a new topic on their own.

The primary reason to use PNG is... to display the images with transparency on the internet. Otherwise you'll find TGA to be more robust. Once rendered to TGA it's a pretty simple matter to zap those out to PNG as well. People have such confusion with the various formats that I've considered trying to put together some form of demonstration about image formats but I'm not sure even that will resolve the dilemma. For my own part I am moving toward this: TGA (The tried and true rendering format) EXR (The way of the future) PNG (For internet use) Where possible I am hoping to forego all 'image formats' entirely and move to reviewing scenes in A:M using realtime spline tech alone. Movie files (all formats are optional and some more robust than other for specific targeted viewers) but .MOV is the best for use in the forum. This is complicated by the fact that Apple has moved away from the format and doesn't support it for 64bit) Way back when I made a suggestion that A:M always render to the same files every time but the reference I used was too obscure and people are so locked in to the current paradigm of rendering they got confused. I'm even more convinced than ever that A:M should (behind the scenes) always render to the same format (probably EXR first, then (in parallel) to PNG for a small thumbnail preview, then convert the EXRs to TGA... then branch out to other formats based on user specified input. The render panel would show all options in one view and the user would toggle on the ones they wanted and the user could override the default rendering order. If left alone A:M would render to every format in every size with every option (i.e. maximum waste but lots of product produced). In other words, the A:M renderer would never (completely) stop rendering as it would always have something in the rendering cue and if it were to ever run out of things to do it would begin renderering based on what you most commonly use. There is a lot more to it than this but we can't get beyond the initial steps necessary to even move in that direction.

When I first encountered SVN this is where I thought it was heading... toward a realtime database of production assets. I believe Martin did too but there wasn't enough interest (beyond TWO) to sustain it. So we been having to wait for the rest of the world to catch up.

If you can't get it to connect after that, launch an email to jason@hash.com He'll be able to check to see if your activation code went through on their end.

I'm not smart enough to get A:M data into it but I'm sure there are some folks out there that are. Dreamworks Animation recently released one of their proprietary tools: http://www.openvdb.org I found this while researching a project management program that I'm hoping will work well with A:M.

Do you mean login to the Community window inside Animation:Master, where the chat room is? If so, you should be able to create a new login and access the community login with that. If that isn't it... I don't know where you are trying to login.

But... seriously... you should download v17.0a. If you just purchased on the 24th of August all you need to do is download, install and activate it. v16 is good too though.

Congratulations! There are quite a few ways to get rid of the blue sky. The primary two are: - Turn Alpha Channel setting to 'On' in the Render Panels Buffer setting. (Use a format that can store Alpha Channels though like PNG, TGA, EXR) - Change the color of the Background in the Camera settings A few other methods: - Create a box or sphere and scale that up so your rendered scene is inside the object. Texture that object by adding surface color, patch images, materials, decals etc. - Place objects between the background and the camera that obscures the sky (a good method for cityscapes etc.)** - Use a Rotoscope image on the camera Of course you could use a combination of all of these as well. My preference is to use Alpha Channels because that transparency allows compositing the images later. **Closely related to this one would be adjusting the camera angle so that there is no sky (i.e. a down shot at a group of characters from a high vantage point)

Maybe we can work on getting you better access to the internet?

Hmmm.... something is not quite working there but I can't quite figure out what it is. While I'm looking into it I'll suggest that it seems to me that her head bobbing up and down like that while running at such a fast pace seems wrong. It might move a lot at the launch but after that her head... and eyes... should lock in on the way ahead of her. She is going somewhere quickly and this implies an intent to get there fast and/or making sure she is aware of any obstacles in front of her. Not sure... not sure... not sure... A few of the poses suggest 'jump' ala Trinity from 'Matrix'. Added: Not the best video reference but full of random running at various speeds: And second video: This last one has some nice slow mo analysis. At 4:20 some text crawls up the screen and echo's Robert's suggestion to lead with the hips. Shortly thereafter there is talk about vertical movement (head bobbing) and they talk about 4 inches in movement... but note that the this is the head moving up and down, not tilting forward and back. At approx. 8:20 the video starts talking about Stride Angle and it's relationship to Bounce (head bobbing and vertical movement of the body). At approx. 11:45 there are some olympic runners that come close to hitting the stride of your character and her upper body is held very stably throughout the run. My suggestion would be to place a Null ahead of the character and have the character look at that Null (you don't have to constraint the head or eyes there but you could do that as well). Your girl's run is obviously more exaggerated that most of these real world examples but... Conjecture: The faster the run the more stable the upper body will tend to be to maintain balance and to prepare the runner to occupy the space(s) they will be moving into.

No, you don't need to uninstall anything. You are still getting the dialogue to enter the activation code showing right? Wait a sec... Removing your master0.lic file from v16 folder... why are you doing that??? v16 has nothing to do with a v17 installation. (The master0.lic file can be copied to the new directory but it doesn't have to... I never do... you should be able to just activate the new installation with your code) So, now I'm confused. Look and see if you've got a v17 folder (in either C:\Program Files for 64bit or C:\Program Files (x86) for 32bit). Installation should be a five minute process so this has gotten way too complicated. Let's get you back to square one. The error message you got 'Bad Data Return' is indicative of something interfering with the internet connection with the activation server. This has been confirmed several times by others to be due to anti-virus software intercepting the connection. IMO considering how your antivirus software might be stopping the connection would be a good place to look. Also, make sure you aren't running A:M while installing. For troubleshooting purposes I would close down all other programs too until A:M is installed then reload them. Usually you don't have to do this but sometime programs (like anti-virus) do a bit too good a job protecting us.

Which website did you go to? Was it this? Hash Inc only sells the current version. They don't sell old versions. If you purchased from someone other than Hash Inc I'm not sure what to tell you. If you recently purchased A:M you can download the latest version and activate it with your activation code. If purchasing a CD... the very nature of a CD suggests that what is printed on it can't be the very latest version... for the latest and greatest you have to download and install the latest release. This has always been the case even way back in earlier times... purchase v8? v11? v12? etc. ...download the most recent release, install it and off you go! At this exact moment (assuming you purchased through Hash Inc) that means you've got access to v17a: v17a Release Information When updates are released you can download and install them as well: Release Information (all versions) I'm sorry you think you have access to only v16 but... the good news is that if you purchased through Hash Inc recently you've subscribed to v17.0a... so get to downloading!

That is too Cool Rodger!

Hmmm.... that is odd. If all else fails you might try a 'reset'. I'm not sure what the problem is but perhaps as a workaround you can just drag and drop the image into A:M? (Try dragging into the Chor... once the image is created in the PWS you can delete that Chor)

Using A:M's 'Snap to Grid' in conjunction with "Snap to Surface" will get this done and with a high degree of precision. Grids used with 'Snap to Grid' can be anywhere between .001cm and 10000cm if I am remembering correctly. Changing grid sizes on the fly while modeling is a great way to control precision placement of CPs. In this way, we can get two surfaces really close together without touching one another. Using A:M's 'Snap to Grid' in conjunction with "Snap to Surface" or any of a host of other modeling features will get this done and with a high degree of precision. Grids used with 'Snap to Grid' can be anywhere between .001cm and 10000cm if I am remembering correctly. Changing grid sizes on the fly while modeling is a great way to control precision placement of CPs. In this way, we can get two surfaces really close together without touching one another. Added: Grabbing a group of CPs and moving them doesn't conform to snap-to-grid and I'm not sure if this is by design or error. It seems to me that when 'Snap to Grid' is enabled everything should snap to the grid. There appears to be some tolerance issues in snapping to grid but I need to investigate. Moving with arrow keys always seems to snap the groups CPs to grid while moving with the mouse does not. Edit: It's primary scaling that breaks free of snap to grid. Perhaps the reason is that scaling and snapping to a grid would work against each other?

You'll be the ultimate render wrangler when this is finished.

And boy does that render fast! I need to use that more often.

Here's a topic from last year on the subject: http://www.hash.com/forums/index.php?showtopic=39487 Added: This isn't really game sprites but I thought I'd run a test to see what upscaling with anti-aliasing and then downsampling afterword would produce. I'm liking the clean look of lines.

Consolidate is suppose to recreate your current folder structure so that when unzipped the files go back where they belong. I'm not sure what to make of any empty folders if they are not in some way related to your current directory structure. If I understand what you are saying... That is not creating a folder of where they were but rather it IS a folder of where they ARE. Consolidation does not remove any files it merely copies them, and their location into an archival file. Upon consolidate you then have your original files and the archive. I can't speak to any extra folders except to say that A:M attempt to recreate the structure of where your files are residing as instructions for the archive so that when the files are extracted they go to the place specified.

We can't Embed any external files such as Images and Audio. Embedding is limited to A:M files that are text. Consolidation on the other hand was created to overcome this issue of external files not being collected and shared. Consolidation collects all the various external assets and combines them with the Project, which may or may not have files embedded in them. It should work but there may be some aspects of zipping up files on a Mac that don't allow consolidation. It sounds like an A:M Reportable thing however if someone can confirm that audio files don't Consolidate. Should we assume that Macs don't zip files but rather use Stuffit or some equivalent? Ref: A:M Reports: [bug]6237[/bug] : 32bit WAV Files Not Accepted