sprockets Nidaros Cathedral Tongue Sandwich A:M Composite Kaleidoscope Swamp Demon Caboose Break Room
sprockets
Recent Posts | Unread Content | Previous Banner Topics
Jump to content
Hash, Inc. - Animation:Master

robcat2075

Hash Fellow
  • Posts

    28,248
  • Joined

  • Last visited

  • Days Won

    399

Everything posted by robcat2075

  1. I've spent more time resplining this ear than it merits but it's like chasing a blob of mercury. I think I can eliminate a 5-pointer by rerouting a spline and then i find I've got a new 5-pointer problem somewhere else. here's a cross-eye 3D
  2. Point taken. So, is rigging really just a process of learned preferences? Is there no really tried & true biped rig? Rigging is knowing the possible tools and recognizing when to use them. There certainly are some common practices but every character has different shape so something different is gong to be done on each one. I always "use" TSM2 because I have become familiar with animating characters that have that set up but i always have to add stuff here and there to accommodate novel circumstances. Rigging is the wall most people who set out to do 3D animation run into. They may learn to model, they may make animation with a character someone else set up but getting their own character rigged is where they run out of gas. A:M is easier than the others because our thin meshes reduce the complexity of what to attach to what bone but it is still not as conceptually obvious as modeling or animating.
  3. Yeah, Robert, I guess the close proximity of control points can create havoc while animating. No, I meant that, the thin characters will be the most forgiving for rigging oversights. Like Woody in "Toy Story" Smartskin can accommodate keys in any direction. I can't think of any cases where you would need more than one smartskin. Maybe there is. My own preference for most joints is to use fan bones. Nice movement is really more about animation than rigging. I thought that looked cool. It almost looked like an animator's red pencil sketch.
  4. I did enjoy that. If you're going to have trouble rigging, a thin character like that is the one to have it with.
  5. That works well, Rodney!
  6. i enjoy making ears. i can't imagine making one without spline modeling but I guess people do somehow.
  7. I've definitely fallen behind my schedule...
  8. Did you ever tell us why you were going off the grid like this? You don't have to, I'm just nosey!
  9. 1:35 is pretty amazing. The time for the computer I had when i made the benchmark scene was over 19 minutes.
  10. I thought I already had that render preset in the benchmark thread but I've put it there now. That should be used in versions 16 or later, but it should be the same settings as in the Benchmark PRJ so i think your test is valid. You might try it on your old computer just to be sure of the comparison.
  11. The 13% figure might represent A:M using one core out of "eight"
  12. the 3.9 figure for your CPU is for "turbo" which I think means it's available when running something that needs just one core (like one instance of A:M) i have no idea if that is automatic or if there is a control for that.
  13. Here's some explanation of "Core Parking" http://bitsum.com/about_cpu_core_parking.php
  14. You are using the render preset that goes with the benchmark, right?
  15. Well, that's disappointing! First thing I would look into is the Control Panel>Power Options and see what is set there for a "plan" You can create and name a new one there and then do "Change Plan Settings">Change Advanced Power Settings> Processor Power Management>Minimum processor state>100% to encourage your computer to run at full speed. Give that a try and report back. I find that even with that set i still have to run three instances of A:M to trick it into running at full speed. I just tested v18 for the first time now... If I run just one A:M the benchmark takes 5:09, if i run three A:Ms it takes 4:52 Those times are with my CPU ostensibly running at 2.4GHz If I use a utility that came with the mother board i can bump it to 3.0GHz and get 3:54.
  16. I'll note that what I meant is to scale the character's model bone in the chor. That will be simplest, but making a new version of the character in the model window might be possible... hmmm... I'm not sure.
  17. If you just need to use the action without transitioning to other actions you could scale the character -100% on one axis (probably X) to mirror him and everything he does.
  18. That's a fine first project!
  19. If anyone wants to try this... switch to regular OpenGL and load this PRJ HandToHand01.prj Select the Red Thom and then switch from Chor mode to Skeletal mode. Does that work? On mine the view window won't change to Skeletal mode and I'll get a freeze if I do a few further things like a zoom or a Turn. But that only happens in regular OpenGL.
  20. Serg, here's a workaround... -Create the Rand() expression like you wanted to. -Set the FPS of the Project to the rate that you want your Rand function to change ( like 3 fps) -"Bake all actions" - set the interpolation of the baked random channel to Hold -set the Project FPS back to the original FPS.
  21. Happy Birthday Dhar! I've had the pleasure of meeting Dhar in person when i've been out to SF and I can report that he is doing well these days!
  22. As an experiment I used QuickTime Pro to convert a JPG numbered image sequence to Quicktime movies in Animation, Photo-JPG and H264 codecs and a TGA sequence and imported those into A:M (32-bit) I tried each one as a camera rotoscope in the default chor. My observation is that A:M doesn't actually load all the frames of these things just because you've imported them, it waits until you need to see a frame, then extracts it from original file and stores the decompressed image in memory for later use. All five formats worked as rotoscopes but the time it takes A:M to initially extract and display frames from Quicktime movies is longer than for image sequences. Scrubbing through an image sequence is fairly responsive but scrubbing through a Quicktime source is pokier until enough frames have been extracted and loaded. Photo-JPG seemed to be the fastest of the Quicktime codecs and H.264 the slowest. It is unlikely you will ever encounter a QuickTime in Photo-JPG, however. The only reason I can think of that you would convert a source to a Photo-JPG QuickTime rather than an image sequence for use in A:M is if you wanted to retain a soundtrack. Numbered Image Sequences are probably your best solution for rotoscopes and decals in A:M
  23. Now an A:M report. Hopefully Steffen can look at that.
×
×
  • Create New...