Anim8or Community
General Category => General Anim8or Forum => Topic started by: Owl on September 28, 2015, 04:04:46 am
-
Got my self in trouble, committed to doing a Anim8or project for work, and am stuck. It is just a mechanical simulation, few moving parts.
Have all the parts made and some animation. Is there someone who could fix it up? Will compensate.
Thank You
PS: Who has access to the documentation? Found an area I believe has a mistake. Spent hours trying to get one small procedure to work and finally found the solution, which is different than what works.
-
Mechanical simulation is not what animator was really geared towards. And a lot of the documentation isn't matching up with what you're seeing because some of the documentation is made for the builds after .98 (available on the forums here). So what you see depends a LOT on what version you're using.
-
Hello Owl,
Attach the Anim8or file for your project so we can have a look.
-
Mechanical simulation is not what animator was really geared towards.
Good play on words, +1
Yeah, I'd like to see that file as well
-
You've got everything mashed up as object01. I assume you want to parent the cage to the quad frame (object04). In that case, you could simply copy the cage portion of object01 itself over to object04, and you should be good to go. I tried it and it works.
Now, if you want the cage to spin on that "rod," you'll need to make it a separate object, which you can then pull into your scene, still parent it to the frame, but now you can rotate it along the z-axis.
BTW, since your object is strictly a hard mechanism, not organic, it's really quite easy to animate without using bones or a motion sequence. Though, I suppose bones helps when an object has multiple moving parts. and repeating a sequence in a scene might be a tad easier than copying and pasting frame data. I would simply insert four instances of the blade object into the scene, position and parent them to the frame. Virtually the same as you have in your figure, but this makes it much easier to alter individual elements. Just an observation.
Interesting scene, BTW.
-
Owl ---
Just an observation...
Any time you model something you intend to animate rotationally, make certain that you center each object at its individual center of rotation. Offsetting it from zero makes it much more difficult to manage once you try to combine it with another object.
Think in terms of an airplane, with pitch, yaw, and roll orientations. The plane (normally) rotates about its center of gravity, not its nose, tail, or wings.
-
Thanks Rudy - you were a big help and my presentation was very successful.
For others, the approach Rudy taught me was in OBJECT, create one object, called say "composite object" that contains all the elements. That way you can get all the elements in proper registrations. Then for each moving part create a new object and populate it with copy/paste from the elements of the "composite object" This creates the proper parent/child relationship.
-
Mmmmm, not exactly, Owl. But the important thing is that you achieved the results you were after, which is really all that matters!
OK, so let me expound just a bit on a generic approach to modeling, rendering, and animation, at least from my perspective.
It's important to "think ahead" about what it is you're trying to do. A top-level, "composite object" model can be good for gathering ideas, but it doesn't provide the necessary flexibility when you want to modify one or more elements. It's often better to treat your model like you would a model car or airplane --- as a bunch of individual piece parts that come together. And of course, the approach you take to modeling also depends on whether you want something simple to convey an idea or something that looks convincing.
Creating a stick, box, or blob figure is relatively quick and easy to model and animate, and can be quite useful at conveying ideas and, because of how the brain "fills in" details, even emotions.
On the other hand, if you're modeling something organic, such as a face or a human body, in order to appear convincing, you need to mimic what a real face/body does: moving one portion of the mesh can affect another portion. For instance, when you smile, it's not just your mouth that moves; your cheeks plump up, your ears move, creases appear below your eyes, wrinkles appear, your lips may part, revealing teeth. These are not independent actions, but with careful modeling and --- in this case --- bone setup, you can control each action independently.
For non-organic models, such as your quad, it's best to keep the parts that move separate and independent from the parts that don't move, and then "build" the model and establish the parent-child relationships within your scene. And, obviously, it's important to understand the relation between the parts that move and those that don't. For instance, the props rotate and provide the lifting force to move the frame in real life, but they are fixed in place on the frame. So in your animation scene, the frame is the parent of the prop, not the other way around. And as I've said in a previous post, bones are great for organic models, but aren't necessary for "hard" objects. X-Y-Z translations and Roll-Yaw-Pitch orientation should be adequate within the scene.
Likewise, the cage may rotate, but it is attached to the frame. So, the frame is also the parent of the cage. That is, you want the cage to follow the azimuth (right-left) motion of frame, but you want the cage to rotate in pitch and be independent from and have no effect on the frame pitch motion.
With more time and experience with Anim8or (or any other modeling package) these things have a way of becoming more apparent. My basic recommendation to folks just starting out is to model fixed and movable piece parts as individual objects, and then "build" them in the scene. I already said that though, didn't I.
Oh, and one final observation. For any object that translates or rotates, make certain that, in Object Mode, you locate the rotational axis (axes) at the origin. Otherwise, you're liable to get some weird motion in your scene that you will end up fighting.
Good luck and good Anim8ing...
-
Id like to add that by Object here I am pretty sure he means Objects held in the object menu and not seperate 'Meshes' Within an object.
Sometimes it can be confusing and a mesh can quite correctly be concieved as a seperate object, but in the terms of this modeling it is not.
I have of course just realised what is going on here and infact have already done this approach with guns in GoldenEye.
Trev
-
RudySchneider is spot on, great bit of "Anim8or 101" there. Interestingly, for complicated mechanical things like steam engines I do tend to do what Owl suggested, creating a single composite Object that contains all the meshes. This allows me to make sure all the parts are modeled correctly and fit together properly. Once I'm happy with it each moving part is cut and pasted into a new Object and correctly centred, with the original Object (now missing the bits that move) becoming the base parent Element in the scene. As all the Objects are introduced into the Scene as Elements and given the correct parent/child relationship I can be confident that they will fit together perfectly as they did in the original composite Object.
To each their own. Anim8or allows for many different approaches to animation within in its (brilliant) Object/Figure/Sequence/Scene architecture.
-
I got to thinking about parenting and independent relationships and threw together this short video for folks to ponder...
-
Nice overview, Rudy. I generally use the 'static mesh' method' when I have something that needs to match an already existing shape, and then cut it apart for things to move. but hierarchical building is a bit more flexible.
Anim80r lacks the sort of 'constraint' system that a mechanical modelling software would have, though (Anim8or isn't made for that, after all!), so really complicated things are going to be a mess all the way around.
-
Need more Help, can only read the documentation and forum so long before signing in for a rescue.
Why in MODE>SCENE when a parent and child are selected and then displaced on a keyframe do they move different amounts and thus loose their relative locations??
If I select only the parent and not the child they do move together?
Thank You
PS: Maybe related, even though that say they are parent child, they are on the same line under World.
-
It's not necessary to choose both parent and child. The child should "tag along" with the parent's motion. Conversely, you should be able to move the child independent of the parent. If you sel;ect both and move, you may get results you're not after. Did you see what I posted here?: http://www.anim8or.com/smf/index.php/topic,5281.0.html?
-
Owl, think of the parent as the child's 'zero' location, and the child's position as being relative to the parent's position. So, if you move the parent only, the child moves with it since its location relative to the parent hasn't changed. If you move both parent and child in a single frame you are moving both the child's reference AND the child's position relative to that reference. Any movement of a parent will result in movement of a child, but the reverse is not true, as RudySchneider pointed out.
One way to visualise parent/child relationships might be to think of your arm. Your fingers are 'children' of your hand, which is a child of your forearm, which is a child of your upper arm, which is a child of your shoulder. If you move your upper arm, your forearm, hand and fingers all move too since they are 'attached', even though you haven't flexed any finger, hand or elbow muscles.
Setting a skeleton in Figure mode essentially constructs a parent/child hierarchy, but for non-organic things (ie. meshes that don't deform) such as a robot arm you could assemble the parts in Scene mode using a parent/child relationship without using Figure mode at all.
-
Thank you - good info.
1) Rudy, Very nice, had not seen this ( http://www.anim8or.com/smf/index.php/topic,5281.0.html ) So did you finish the explanation?
2) ENSONIQ5, good description. This is what you told me the best: " move both parent and child in a single frame you are moving both the child's reference AND the child's position relative to that reference ". Therefore if I move both together say 5 units, the child moves 5 with the parent and 5 with-respect-to (wrt) the parent, so the child moves 10 units.
What was distracting me was the version (0981) didn't have the child under the parent in MODE>Scene, timeline. The latest beta version (1185) has the child under the parent.
Thank You
-
Now using Build 1185
Next problem, Added color in MODE>Object, using MATERIAL EDITOR>Surface Properties>Two Sided. Looks as expected in OBJECT. BUT only with RENDER>RENDERER...>Scanline. But NOT with ART and OpenGL, they don't set different colors on each side.
Is that normal?
Thank you
-
...But NOT with ART and OpenGL, they don't set different colors on each side.
Is that normal?
yep - not sure about OpenGL, but that's definitely normal for ART.