sprockets TV Commercial by Matt Campbell Greeting of Christmas Past by Gerry Mooney and Holmes Bryant! Learn to keyframe animate chains of bones. Gerald's 2024 Advent Calendar! The Snowman is coming! Realistic head model by Dan Skelton Vintage character and mo-cap animation by Joe Williamsen
sprockets
Recent Posts | Unread Content
Jump to content
Hash, Inc. - Animation:Master

Mitovo

*A:M User*
  • Posts

    53
  • Joined

  • Last visited

  • Days Won

    1

Mitovo last won the day on September 4 2016

Mitovo had the most liked content!

Profile Information

  • Name
    Mike

Previous Fields

  • A:M version
    other
  • Hardware Platform
    Windows
  • System Description
    Home-Built Windows 7 Home Premium - 64Bit AMD FX-8350 8 Core @ 4Ghz Gigabyte 990FXA-UD3 R5 Mobo 8 Gigs DDR3 Ram MSI GeForce 970GTX GPU 1 x 128GB SSD 1 x 500GB SSD
  • Self Assessment: Animation Skill
    Unfamiliar
  • Self Assessment: Modeling Skill
    Unfamiliar
  • Self Assessment: Rigging Skill
    Unfamiliar

Mitovo's Achievements

Apprentice

Apprentice (3/10)

1

Reputation

  1. Here we go again. Some things never change. Let's take a trip back in time. Back several years ago, when I was originally using v12, I got the same exact sort of response when I reported issues. It was the same apologist "it's not the software, it's you", type of nonsense. Every time. In every case, it was either *not* my fault, but in fact (reluctantly) *confirmed* to be an issue on the software side, or it was some quirk or "gotcha" with the software that wasn't explained at all. Still, in every case, the immediate response to those issues was effectively "it's not the software, it's you". In the cases where it was acknowledged to be something on software side, it was *still* spun to somehow be something *I* did wrong. As one example, when the copy and paste mirrored function didn't work correctly on the "Take A Walk" tutorial, due to a faulty rig (as would *finally* be admitted), the immediate response was "you shouldn't be doing it that way. You should be doing the whole thing manually". Basically, it was my fault for following the steps in AoAM, not the software's for having a faulty rig. I finally got fed up with the apologist nonsense, and walked away. Fast forward several years and A:M versions. I decide to check in on A:M again, and learned that it had, apparently, greatly improved in my time away. I learned that version 18 was far more stable and improved over older versions, with many, many bugs squashed (I found the mere acknowledgement of bugs existing in A:M to be a positive sign). Encouraged, I decided to give it another go. I always liked the concept behind A:M, but had issues working with it. I came back with a fresh perspective and an open mind. I was further encouraged, amused, and - I won't lie - pretty vindicated, when it was *finally* admitted during last Saturday's hang-out that yes, earlier versions of A:M - particularly v12 - in fact had a lot of issues. I was told of how a number of users requested that focus be put on fixing the many bugs, instead of adding new features. I thought "Wow, that's a huge improvement over last time. They finally accept that A:M - like any software - is imperfect and will have bugs". Well, I was only partially right. Turns out, you'll eventually acknowledge issues in A:M, but only in the past-tense. Because, here we are with version 18, and it seems the default, knee-jerk response to reports of issues cropping up is still effectively, "it's not the software, it's you". So much for being encouraged. Rodney... Did you see the video I uploaded? Notice how everything looks fine? The ball follows the path, nice and smoothly? Believe it or not, I did that, on my own, by following the instructions in AoAM (once Robcat confirmed where they were). The ball is rolling fine. It's facing the right direction. It's staying on the path. No quirks. No bugs. No problems. Clearly, I'm not an idiot, and am capable of following instructions. So, in the future, please knock it off with the passive-aggressive remarks like those quoted above. Okay? When I say the bone is changing its orientation on its own, without me touching it, I mean exactly that. When I say I set up the bone in model > bone mode, and then left it alone after that, I mean exactly that. I set it up, and then left it alone. I'm not lying to you. I'm not hallucinating. Everything was fine up to and including my rendering the video out to better illustrate the question I was asking (about how to move the ball along the path faster). The bone changed - on its own - *after* that. The path-following problem didn't occur 'til *after* I followed Robcat's video on changing the ease parameter, and replicated what he did there. After that, the ball was swerving off the path like a drunken driver. I didn't change anything else. I didn't touch anything else. Not the action. Not the ball. Not the bone. Still, instead of simply asking me direct questions, or simply saying "can you upload the prj file so we can look at it?", you type up this long lecture, condescendingly over-explaining things to me, like I'm a child, or some kind of idiot. I will not be spoken to like that. If you can't address me respectfully, like one reasonable adult speaking to another, then this discussion is over. You refused to accept that there were problems with v12 way back then, only to later admit that yes, actually there were a number of them. Yet here you are, right back in that same mindset with v18. Seriously, this apologist mentality of "it's not the software, it's you", really needs to die already. It's not helpful, nor warranted. And with that, I'm done.
  2. Ahhh... So it's a different setting that's adjusted. Okeedoke. I still need to figure out why the bone for the ball is being rotated 180 degrees in between sessions when I'm not touching it. I set up the bone in Model>Bones mode, and that's it. I'm not touching it after that. But it keeps reorienting itself. Annd... hold the phone. A:M has just randomly screwed something else up. I just tested out what you show on the vid... Blue bar, etc. Now the ball isn't even staying on the path. It's following the curve of the path, but swerving off of it to either side, like a drunk driver. Seriously, I have no words at this point. It's as though the software is going out of its way to convince me not to buy a full license, and it's quickly starting to win.
  3. Hmm.. that didn't seem to help. It speeds up the speed of the spin, but not the speed of the ball along the path. I rendered out a vid to maybe better explain what I mean. Currently, it takes 12 seconds for the ball to get to the end of the path (the video ends exactly when it hits the end of the path). I'd like to alter it so it gets to the end in half the time, so the video is only 6 seconds long (or, really, whatever duration I'd like it to be). Also, why is the bone attached to the ball occasionally flipped around 180 degrees when I open the project? I save it with the bone rotated appropriately (so the ball is rotating the right way). I'll save it with the bone oriented correctly. The next time I open it, the bone is flipped around the wrong way, and I have to fix it again. It's happened a few times now, and it's a bit annoying. Not sure why A:M keeps changing things that I'm not messing with. Here's the vid... ballroll.avi
  4. So, I've managed to get the ball rolling along the path. A problem I'm running into is I can't figure out how to get the ball to move along the path faster. For example, I want a ball to roll along a path, reaching the end of it in 10 seconds, and rolling, say 10 times, at 1 second per turn. I have the settings so it'll complete the 10 rotations, 1 second each. However, it's not moving along the path fast enough to reach the end before it completes the 10 rotations. So, it gets halfway through the path, and then just stops and slides along the path without rotating. It would basically require me to double the length of the clip for it to complete the full distance, and I'm sure there has to be a way to fix it. How do you make it move along the path more quickly?
  5. See, I knew it was in the book! I even looked at that bit, but somehow missed the page about putting it on a path. Go figure lol. Okay thank you for confirming that. I thought I was going crazy.
  6. Well, I've gotten a smooth rolling animation created for the ball. Just working out how to get it moving along a path correctly in a Choreography. Can't find any tutorials on that, and can't seem to figure it out on my own. I could have sworn I saw a tutorial for that somewhere.
  7. I will confess that using A:M and proxies for creating storyboards is not mine. The proxies I'm using for Papa Bear were created by Mark Largent , and what was his idea to use A:M, I'm just carrying on his fine tradition. But, yes, each scene/camera cut is set up in a chor and then a single frame is rendered off. And before you think, "gee that sounds like a lot of work", consider that if you are diligent in saving each individual chor, named for the scene, when you decide that something needs to be altered (you most certainly will) then it is a simple job to open that chor up, make the adjustment, and rerender. It sounds like less work than drawing everything over and over, that's for sure . I'll have to look into that. I want to do a couple smaller tutorials on using actions/chors before I dive into my own project, just to get a feel for how the workflow is. But once I get to my own project(s), I may well give that approach a try. The one Robcat suggested sounds interesting, too. Will probably be a process of just seeing which "feels" better for me; kinda like figuring out which approach to use for head/character modeling.
  8. Hmm.. that's something to possibly experiment with. Not quite sure I follow, but that's because I haven't really dug into A:Ms animation beyond the basic tutorials yet.
  9. Animatics is an animated storyboard, used to get basic timing down. My personal opinion is that while it can be done in A:M, I wouldn't. My main reason is that you would most likely wind up with one chor for the entire animation, and that gets tougher to manage than necessary. Ideally, your script is broken up into scenes, then the storyboard further breaks down the scenes into the camera movements/framing, then the animatic is simply the storyboard put together in a movie with a simple soundtrack. In A:M, each scene, camera cut is animated in a separate chor. I use celtx for my script writing, story boarding, and animatics. I do use A:M to help with the storyboards, using proxies, simply because I can't draw worth a tinkers damn! I see! Thank you for all that info! I'm not quite to where I think I'd need an animatic, yet, but I feel like it's something that will be beneficial. Though I do find your mention of using proxies to set up storyboards in A:M intriguing. So, do you set up the proxies as they'd be in a given shot, and then do still renders as each storyboard "frame"? That might not be a bad way to go about it for me, as I'm not the biggest fan of my own hand-drawing, either. Plus, my hand tends to get tired if I write or draw for very long.
  10. Welp, had other stuff sidetracking me, but have put together the model elements I intend to use for this project... Pretty much a basic cast of characters Figured out the ball thing. Then decided to challenge myself with creating a rounded cube (which worked!), and a boring backdrop/floor. Now to work out what sorta animation I want. By the way, is it ideal to set up animatics in A:M? I think that's the right term... where you take storyboards and can set up them sequentially to tweak timing of scenes, etc?
  11. Hmm.. yeah they are effectively discussing the same challenge, just with a different application. I considered that as an option (using multiple groups so none of the selections are adjacent), but that seemed extremely and needlessly tedious and I was sure there would have to be a more straight-forward approach. I figured, surely wanting to use alternating colors of some sort has been a common enough requirement that some way of doing so was implemented, or otherwise discovered. I guess not! lol Thanks for the link!
  12. Hello! Two questions in a single hour! Crazy! Anyway, I'm trying to create a beach ball sort of coloring pattern, and am running into a problem. I've tried selecting alternating columns, using the patch select tool, and by selecting CPs, but when I assign a color, it's affecting the entire ball. So, I tried applying the color to just one group, and then adding more patches to that group, and I can't seem to make that happen, either. When I select a patch on the next column, it does a kind of "select everything in between original group and new selection", kinda like shift-selecting an entire line or paragraph of text in a word document. Does the same thing if I try to Ctrl-Select. I then tried to set the entire ball to one color, then go back and use "Remove from Group" on the stripes I don't want in that color , and that seems to be affecting patches I'm not selecting as well. I don't see any option to select patches and then "add them to group". So, I'm kinda at a loss here, but I'm sure there's a way to do it. Here's a pic where I have at least one column colored, so you can see the way I'm looking to color it. I'd like it to have alternating blue and orange stripes. Thanks!
  13. Ah okay, that makes sense. I forgot that CPs aren't like vertices on a polymesh. Thanks!
  14. Hiya, So, I actually could/should have asked this during the get together, but I didn't think to. I've noticed that for some functions to work, you have to "click-select" a node. You can't box select it. Lathe is an example. Why is that? Is it something to do with how splines work? Or is it just something that was programmed that way, and remained so through all the versions? It's not a problem. It's just as easy either way, I was just curious if there was a reason behind it. Thanks!
  15. As someone who has spent some time playing World of Tanks, and been obliterated by the opposition, this vid hits home for me lol. Nicely done!
×
×
  • Create New...