#bones question
27 messages in this thread
Hi,
i have been playing with the hand object that came with IM3.0. I made a state
with the fingers closed and one with the fingers open. I made an anim and
morphed them. Unfortunately the points move linear from state "open" to state
"closed" which looks quite bad.
So the bones are only there to deform the object, but in the stage editor
you can only morph between the states you created in the detail editor. Is
this correct or am I doing something wrong?
-David
David,
After considerable help from GreG T and others I tried hand.bon and it works
for me. Here's what I did:
It comes with two states DEFAULT and OPEN.
1. Select DEFAULT state.
2. In Select Object (IMPORTANT) mode select the axis at the end of a
finger.
3. Press R (rotate) press Shift-X (around x-axis). Rotate visibly ~45
degrees.
4. Go to the next axis toward the palm and select it. Repeat 3. Both
axis and the bone between them should move.
5. Go to the next axis down. Repeat 3. All three axis and the two bones
between them should move.
6. Select the entire object. (It's the axis in the middle of the palm I
think.)
7. Select Bones Update in the States menu. All surfaces should move to
correspond to the current setting of the bones.
8. Create a state called CLOSED. You should now have three states:
DEFAULT, OPEN, CLOSED. OPEN and DEFAULT will look the same. Try
moving between OPEN and CLOSED to make sure you are good up to this
point.
9. Set back to DEFAULT state. Save the group. You should still be in
Select Group mode.
10. Go to Action. Add the object from frame 1 to 1 with state OPEN.
(don't use DEFAULT)
11. Add the object again on the same line from frame 2 to 10 with state
CLOSED.
12. Save and go to Stage
13. Make animation from 1 to 10. Should see one finger bending smoothly.
Good luck,
-Marco
Marc,
thanks for your message. I think you didn't understand what I have problems
with. I know how to create states with the bones. But as soon as the object is
in the action editor you can only morph between the states which means the
points (and faces) move on a strait, linear line between the positions. In
most cases it makes almost no visible difference, but in the case of thew hand
you can see th effect very good.
You have a state "open" and one "closed" (hand is a fist) and morph between
them. Position the camera so that you see the hand from the sine and watch the
anim. You will see what I mean.
-David
David,
> You have a state "open" and one "closed" (hand is a fist) and morph > between
them. Position the camera so that you see the hand from the > side and watch
the anim. You will see what I mean.
I don't. I see the fist closing in an arc, which is constrained by the way the
bones are connected together, just like a real hand would.
BTW, I tried the same with the Spline Interpolation button unchecked and could
see no difference. I have no idea what that button does. Did two hand objects
side-by-side in the same animation one with the button checked and one with it
unchecked, so I don't think that is your problem.
It sound to me like your Bones states are not being set properly. The bones
feature is very sensitive to being set up exactly correctly. If it isn't there
are no warnings or error messages, just strange behavior.
Can you give a micro step-by-step explanation of how you are setting your
states? Maybe that will help.
-Marco
>> I don't. I see the fist closing in an arc, which is constrained by the
>> way the bones are connected together, just like a real hand would.
Ok so it's me that is doing something wrong.
…(one hour later)…
I checked the shape box when making the states which is a mistake. Once again
I should have RTFM (=read the fine manual) before. It works fine now. Only one
problem is left. When I use solid (Alt-H) view in Detail editor with a bones
object Imagine crashes each time.
-David
David,
If the points are moving linearly from the open state to the closed state, it
means your states were created with the "shape" button clicked on. This will
memorize the points' location, and morph between them. No, no, no. Instead,
define the closed state with "grouping" turned on; this will only memorize the
axes' (i.e. bones) position/alignement/size, and the morph will be one of
rotating bones (with points following suit), rather than moving points.
Blaq!
Right Blaq, I didn't RTFM colse enough. It works fine now and I added bones to
the cow object. It works great. But making a real looking walk of a cow is
still not easy.
-David
One thing I found with working with bones is this:
"Bones are a wonderful tool to get deformation in an object, but they shouldn't
be thought of as an end-all in modeling."
That is to say, when you make bones and states and such in the Detail editor,
you still might have to do some point-level editing to get the object exactly
the way you want it. Also, because of the linear morphing between states in
the Stage editor, it's often prudent to make intermediate States in a moving
object. Since the states menu lets you Tween states, that's not ususally a
problem.
Bones and States are very powerful tools, but they are just that: tools. Now I
know a guy who uses a pair of pliers as a hammer and a screwdriver, but I think
it makes sense to use several tools. Same with Imagine, use all the tools to
do your modeling and you'll keep your hair longer.
JIM
Your comments are of course opinions, and one error, in regard to
animations in the stage, in Imagine 3.0 all animations are interpolated on a
spline basis, unless of course you eliminate the interpolation. Maybe you
forgot.
Mike
Mike,
I did a 30 frame animation of two identical hand.bon objects side-by-side
closing into a fist. In one I had the spline interpolation box checked, in the
other, I had it unchecked. I couldn't see any difference between the two.
What does that box do anyway?
-Marco
Mike,
It sure is comforting to learn (the postman having still not delivered 3.0)
that the default state for all interpolations is spline. This will make all
animations look much more natural, with no effort on the part of the user.
Especially important when dealing with novice users, who'll be getting
higher-quality results with no involvement on their part. This is what I would
call a good design decision. You know Mike, with this software of yours,
sometimes the simplest things can get you the biggest return-on-effort.
Oh, speaking of which… the idea of a 30 fps Stage wireframe anim preview has
already been tossed your way, and I know I put in my 2 cents' worth. I have
refined the concept, so here goes:
In the Action editor, next to the "highest frame #" field, add a "playback
speed (fps)" field, with a default value of 30. This field will be used when
playing back animations from the Stage wireframe preview, or the Project "Play"
button. The Stage status bar would also show timing according to this value,
i.e. at 15 fps, frame 6 would show up as "Frame 6 (0.33 secs)". Finally, the
Stage wireframe anim playback control panel should be more timing-friendly: (a)
start the slider at the midway point, which would represent the Action editor's
playback speed; a click in the empty area on either side would double (right)
or halve (left) the playback speed; dragging the slider would smoothly change
the speed; and there would be a "frames/sec" field, constantly updated as you
drag or move the slider.
These changes would be relatively self-contained within the program, unlike,
say, an object format change which would affect most every section of Imagine.
In my mind, they would qualify as good "bang-for-the-buck" candidates.
Blaq!
I agree, and while you are at it add an OK button to replace carraige
returns. 'Specially when the next action is to use the mouse to select the
next action.
Just working my way through the action editor.
-ash
PS Does anyone know if DynaCADD Imagine export fn work?
Willie,
I would prefer a more Amiga-like interface, where Tab/Shift-Tab would move from
field to field, Return would be equated to clicking on OK, and Escape to
clicking on Cancel. Oh, and speed up that pesky keyboard routine, which forces
me to slow down or else Imagine loses characters when I enter numeric values.
Oh, and stop splitting fields into separate areas, with cursor motion (when
pressing Return in the current interface) is limited to a single area. I should
be able to move the cursor to any field with the keyboard. (Example: when
setting up an Action editor morph, when I load the target object and get the
"Object file info" requester, pressing Return alternates between the Start and
End Frame fields; I have to use the mouse to click the cursor on, say, the
State Name field.) Finally, when a requester pops up, the first field should
already hold the cursor — no mouse click should be necessary.
Yes, I know, lots of annoying comments, but interface design is one of my main
concerns in computers.
Blaq!
>> Yes, I know, lots of annoying comments, but interface design is one of
>> my main concerns in computers.
Not at all. Your suggestiosn are good. I think the same, once you enter a
value in a requester it should be possible to go to the next line with the
keyboard (maybe using >enter< or TAB or the cursor keys. Mike are you reading?
-David
Dave,
Sure I am reading and I agree, due to the fact that we have stuffed so much
code in such a small space, it gets very hard to do these simple things, but
something wonderfull is going to happen.
Mike
>> but something wonderfull is going to happen.
🙂
Will the first update be ready at Siggraph? Will I be able to pick up my
Digimax there?
-David
Mike,
unlike the Mac and Windows environments, the Amiga world took forever to
enforce an interface standard, and I don't blame you guys for having an odd
interface. When Imagine came out, every program interacted with the user in a
different way. It can also be argued that the programming/design staff at
Impulse prefer spending their time building new functionality into Imagine, and
as much as we complain about a small number of bugs, we keep using Imagine
because it performs so well at a reasonable price. What I have in mind, though
is this: while you may concentrate on raw functionality at the beginning, as a
product matures, you might find time to address some of the smaller features
which make a difference between roughness around the edges, and a streamlined,
well-oiled machine which is a pleasure to work with. You did a lot of interface
work on Imagine 2.0, and I still remember the quantum leap it represented
compared to 1.1. Perhaps the next release of Imagine 3 could see some of those
small features we've mentioned over the past weeks.
And thanks for paying attention. Having a two-way dialogue with the creators of
my favorite software is the reason I spend big bucks on CompuServe.
Blaq!
Hola Blaq! any GOOD NEWS from Canadain Customs yet?
I just got a Lovely 3D Model of Calvin from Calvin and Hobbes Comic Strip
in his "Spaceman Spiff" ship. Will UL it and a few Toon oriented Models
when Time permits.
Aloha Charles!
Some of the interface suggestions you have mirror my own. I'm not familiar
with the conventions used on the Amiga, but this is pretty standard fare on
PC's, Macs, and probably other systems in terms of interface setups. I'd
imagine (ugh no pun intended) this program being the brute powerhouse that it
is probably sacrificed a bit on the interface conventions used in order to get
a lot of features out quickly that works and doesn't have the gawdawful
overhead of training wheels. I'd have probably done the same thing if I was
studly enough to write something like this as well<g>. The CUA Basic Interface
Design guide that IBM put out some time ago still is a good guideline I refer
back to when doing production code at work.
I'd really like to see a couple of things considered unless other design
changes in production would conflict:
1) A default button in BOLD for all the common dialogs that would be activated
by ENTER
a) Usually the most commonly chosen option
2) Being able to ESCAPE from any chooser dialogs that come up
3) The TAB, SHIFT-TAB convention for jumping from field to field
4) A function key to activate the browser (F4 is commonly used in PC-land but
I'm not picky)
5) Hot Keys for attribute settings and other dialog buttons.
a) ex. when you pull up transformations being able to press 'r' for
rotate, 'p' position, 'z' size, etc.
6) A Hot key to bring activate the top menu bar instead of having to move the
mouse.
I was going to post this by itself, and figured I'd post it here in response
to yours since they are on the same general subject matter. I'm a two-hander
when working and I tend to mouse with my right and keyboard with my left. I've
noticed that I have to let go of the mouse and do some finger gymnastics a bit
more than I'd like to. I can get stuff done, but it'd be nice to economize on
the motions a bit.
Still having a blast exploring Imagine 3.0 though!
Aloha,
Sharky
– 70614,2011 @ 07-Jul-1994, 15:50:46 Honolulu, Hawaii
Using: Windows NavCIS PRO 1.2
Hey don't forgat that there is not only NTSC in the world! PAL runs at 25 fps!
Film (the real one<g>) runs at 24 fps everywhere in the world!
-David
David,
And so, the default speed value should perhaps be a Preferences setting, so
European users can set it to 25 and forget about it.
Blaq!
>> speed value should perhaps be a Preferences setting, so European
>> users can set it to 25 and forget about it.
Exactly, that's what I mean.
-David
I can't believe you still don't have 3.0!!!!
Peter,
That's right, and my lover hasn't received a light meter he ordered from
Florida. I'm wondering if Canada Post has decided to wage a silent war on our
household… Have no fear though, Mike has made yet another chivalrous attempt.
Blaq!
OH CANADA!!!! Blimey !!!! Maybe ya should get a PO BOX Cross the Border if
yer a Decent Distance from it of course……..
Bloody Amazing!
Hope yer Imagine 3.0 and yer mates Light meter appear SOON!
Oops. Murphy's Law ensures I would notice a bug in my description the day after
I posted it. When I said that the Stage editor's anim playback speed slider
should start at the center, I forgot that for a default speed of 30 fps, say,
it makes little sense to start the slider at the center, since top speed would
be 60 fps. In this example, the slider would start one "empty-area-click" away
from its rightmost position:
+———+–+–+
| | | |
+———+–+–+
\
\
Slider
Blaq!
>> Since the states menu lets you Tween states, that's not ususally a
>> problem.
Exactly! Try the example I said, use the hand and make one state with the
fingers completely open and one where the fingers (use only one finger if you
don't have the time, effect is the same) are closed (like a fist).
Now make a "tween" of these two states and look at the RIGHT view. See what I
mean!
-David