Attaching Points to Bones

Anything related to a beta release of JPatch: Bugs, enhancements, general discussion...

Attaching Points to Bones

Postby dcuny » Wed Oct 19, 2005 11:33 pm

I know, it's not been coded yet (or, at least, not published yet ;)), but I'll ask anyway.

To attach mesh points to bones, I'm assuming that you'll be able to select a bone, and then select a Attach Points to Selected Bone button. In that mode, the mesh points will take on the color of the bone they're attached to. You'll be able to select points as usual, and then Attach or Detach.

Obviously, some points will need to be shared between bones, so that the mesh deforms correctly - for example, at elbows. So a point may have one of the following states:
  • Attached to nothing. What color would these be?
  • Not attached to the selected bone. I assume that you're going to follow the A:M method of applying the bone's color to the point, and using a mix of colors when the point is attached to several bones.
  • Attached to the selected bone.
  • Attached to the selected bone, but shared.
I think that some of the following features might be useful. I can't really say for sure, since I haven't done much of this:
  • Show all unattached mesh points. Useful for identifying orphaned points.
  • Show only points attached to this bone. Since shared points will have blended colors, this will make them easier to see.
  • Attach points exclusively. With a normal Attach Point operation, it would keep the prior attachement to other bones as well as the new attachment. So to quickly build a mechanical object, you could pick a bone, pick a Selection, and click Attach Points Exclusively.
In looking for information about this, I ran across a product called WeightMover which does some interesting things. One interesting thing that it's got is the concept of a No Flex Groups, where objects can be flagged not to share weights across more than one bone. (I also suspect that smoothskin-like functionality will solve some of the issues they discuss).
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Thu Oct 20, 2005 9:32 am

Ok, here's how it's going to work:

Assigning points to bones manually is quite cumbersome, so I'd like to have a good auto-assignment feature - after the auto-assignment, the user could of course fine-tune the point-to-bone assignments.

For auto-assign, each bone will have two "influence-radius" parameters (one for the start and one for the end of the bone). These will define a volume of influence for each bone (the volume is a capped cone, with sphere-segments on the caps). Within that volume, a bone's influence fades from 100% (at the bone) to 0% (at the boundary of the influence-volume). Each point gets attached to the bone with the highest influence.
In addition, for each controlpoint the closest point on the bone is calculated - devided by the bone-length this results in a value between 0 (the point is close to the bone-start) and 1 (the point is close to the bone end).
This value will be used to compute a "per-degree-of-freedom" weight. Take, for example, the lower arm and imagine controlpoints on your skin. They'll react differently if you twist the lower arm or if you bend the elbow. Bending the elbow would result in all controlpoints following the lower-arm bone, except those very close to the elbow joint (in terms of weight, almost all point would have weight 1, except those very close to the elbow joint, where the weight would quickly fall off to 0). Now imaging you twist the lower arm by 90 degrees. Your hand will turn 90°, yet your elbow won't move. The points in the middle would turn by 45°. Expressed in weights, points at the end of the bone would have weight 1, and the weight would drop linearily to 0 (for points at the start of the bone). As you can see, this is not possible if only one weight parameter is defined for each controlpoint. Instead, the position of the point (relative to the bone) is used to compute a weight for each degree-of-freedom.
The DOF will have a flag that tells wether to use the "rigid" mode (all points have weight 1 except those close to the joint) or not (weight will be distributed linearily).

Of course you'll have the ability to set the point-to-bone assignment manually (e.g.by selecting a set of points and one bone and choosing "assign points to bone" from a popup menu). Setting the weights for each point and DOF manually would be overkill (and you don't have full control - it would be a trial and error game: setting the weights, look how the points react, tune the weights agein, etc...) I think there's a better way:
The mechanisms described above should already lead to feasible results. The smartskin feature could then be use to fine tune the result by adding morphs (each morph will be bound to a specific DOF). In case you're not happy with how the points behave after the auto-assignment, you can specify their exact behavior by simply moving them into the position you want them to be.

I think this concept has two major advantages: 1) You can get good results in no time: Add the bones (they'll have some sensible default influence-volumes), click on auto-assign and you're done. 2) In a fine-tuning step, you can use smart-skin morphs. This is intuitive (as you can simply move the points to where you want them to be instead of fiddling with abstract weight values) and gives you full control over the result.

I've had such a system up and running already with my first experiments and I was quite happy with it. I think I'll implement it into JPatch exactly this way again. Once that's done we can discuss further improvements.

The point-to-bone assignments will be displayed using the bones color on the controlpoints. Unassigned points will be shown in white.

I know that there are some systems that allow a point to be attached to multiple bones, but IMHO they don't make sense for JPatch: Using them is difficult and sometimes counter-intuitive. Those systems might make sense for high-poly models (whery adjusting thousands of controlpoints manually is difficult), but JPatch is a patch-modeller: To add a smartskin morph, you probably have to move just a few controlpoints. Another usage for such systems is in games or realtime graphics - blending the matrices could possibly be done in hardware, so once the character is rigged, setting up a the points for a given pose is very fast. In JPatch it doesn't matter if posing a model takes some milliseconds - when working in the modeler, you'll normally work on a single model only, and if the animator needs half a second to set up the poses for 20 models in a frame: Who cares? Rendering (and even subdivision) will take much longer.
Last edited by sascha on Thu Oct 20, 2005 11:56 am, edited 1 time in total.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby pndragon » Thu Oct 20, 2005 11:41 am

How would you use bones in something like eyes?

Use a single, small bone and center the pivot? So that the eyes can roll up as well as side to side?

--- Jim
pndragon
 
Posts: 591
Joined: Sun Dec 05, 2004 1:27 am
Location: North Carolina

Postby sascha » Thu Oct 20, 2005 11:55 am

You'd use one bone inside the eye (it's start point being the center of the eyeball) and attach two DOFs to it (you can move the eye up/down and lef/right).
This bone of course needs to be attached to the "headbone".
This is a good example for something you'll need the manual assignment: Auto-assign will probably assign all point to the head, you'd then have to select the eyes and assign them to the eye-bones manually.

I was thinking about a special "look at..." mode for eyes, but then it might just be possible to use IK targets for eyes too (with the additional benefit that the character would try to follow the target with its eyes, and if it can't it would start turning the head and eventually the body too). But it's too early to think about the details of an IK implementation (I know, I have to study AOI's IK system ;-) )
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby pndragon » Thu Oct 20, 2005 12:10 pm

It's not good when you give David's answer's before he can :D

--- Jim
pndragon
 
Posts: 591
Joined: Sun Dec 05, 2004 1:27 am
Location: North Carolina

Postby dcuny » Thu Oct 20, 2005 6:14 pm

Yes, you really should check out AoI's IK system. :)

AoI has some really slick constraints as well. Here's the example from the AoI manual showing off the Constraint Track:

Image

In most animation rigs, both eyes have an Orient Like constraint to a proxy eye bone. That proxy bone can then be constrained, or manually moved. This prevents the "cross eyed" effect that you have in the above example.

As another aside, you should have a look at the AoI manual as an example of a really excellent example of nicely done documentation. It does a good job showing off what all the features do, and includes lots of animated GIFs in the animation section. It's maintained by one of the users, not the actual author of AoI, but I think much of the success of AoI can be attributed to their documentation.

(And no, I didn't just volunteer to write the JPatch manual ;)).
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Thu Oct 20, 2005 8:06 pm

And no, I didn't just volunteer to write the JPatch manual

Too bad. Until this line it sounded like you would ;-)

Seriously, there are 3 reasons why I think somebody else should write the docs:
1) The less time I spend with other things, the more time is left for developing JPatch.
2) I'm not a native english speaker.
3) I'm the developer, that means that I naturally see JPatch from a different angle than a user - I'm perhaps not the most suitable person to write a user documentation.

I will of course maintain a minimum of documentation (some reference material and a few tutorials). Most of it is already in the Wiki, and everybody is invited to improve it :-)
Even small things help: if you spot a spelling or grammar mistake, please correct it, if you think that the wording is inaccurate, just rewrite that sentence, etc...
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Thu Oct 20, 2005 10:48 pm

I agree - not having to write the documentation as a developer really takes a burden off you.

I can certainly help edit; I'm fairly good at that. (Well, except for an overuse of semicolons and parentheses). But I suspect that there's not a whole lot of point in putting together a manual until bones and the animator have stabilized a bit more.

Then again, I'm much more interested in animation than modeling, so that just shows my personal bias. ;)

I'm also not saying that I won't help write the documentation. I'm just not volunteering at this point. I've got so many other projects going on right now that I'm spread a little bit too thin. I also think that writing documentation before the Animator module stabilizes a bit more would be premature.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby squirrelhavoc » Fri Oct 21, 2005 12:03 am

sascha wrote:3) I'm the developer, that means that I naturally see JPatch from a different angle than a user - I'm perhaps not the most suitable person to write a user documentation.


Since you made the program, you know it's in's and out's, and you know about every feature it has.

Why not just stick with the Wiki for documentation, and let anyone who knows add the info?
Squirrel Havoc

We live as we think, very very slowly....
squirrelhavoc
 
Posts: 180
Joined: Tue Jun 28, 2005 11:17 pm
Location: Oklahoma, USA

Postby pndragon » Fri Oct 21, 2005 5:17 am

The Wiki offers too many viewpoints on solving problems and can confuse a new user.

IMHO, the Wiki should be offered as a secondary source, a place to find alternative solutions to modeling problems while a user's manual along the lines of AoI's documentation would be the last word on what any feature actually does, with examples.

--- Jim
pndragon
 
Posts: 591
Joined: Sun Dec 05, 2004 1:27 am
Location: North Carolina

Postby sascha » Fri Oct 21, 2005 11:21 am

Since you made the program, you know it's in's and out's, and you know about every feature it has.

Yes, sure :)
I didn't say that I won't writy any documentation. In fact the reference manual is meant to do just that: Documenting every feature JPatch has.

What my point 2) was referring to is that I see JPatch from a different point of view than a user who doesn't know (and doesn't have to know) about its internals. So I'm not really qualified to introduce JPatch to new users since I don't know what the typical problems a new user faces are. If, on the other hand, a user faces a problem and solves it - he could document the problem and the solution in the Wiki - this will help other users who are probably facing the same problem.

IMHO, the Wiki should be offered as a secondary source, a place to find alternative solutions to modeling problems while a user's manual along the lines of AoI's documentation would be the last word on what any feature actually does, with examples.

Yes, but the Wiki could be used as a tool for collaboratively working out this "definitive" user-guide. See it as a CVS for text-documents instead of source-code. It might be a bit early and I'd wait until the bones and animation features have stabilized a bit. But even then, I could of course input all the details, but it would be nice if someone with some background in didactics would lay out the overall structure, and a native english speaker would review and edit everything.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby pndragon » Fri Oct 21, 2005 11:45 am

Sascha wrote:Yes, but the Wiki could be used as a tool for collaboratively working out this "definitive" user-guide. See it as a CVS for text-documents instead of source-code.

That is almost exactly what I meant. Thanks for clarifying my thoughts.
It might be a bit early and I'd wait until the bones and animation features have stabilized a bit.

It is never to early to start planning structure... Consider the manuals for PHP or MySQL. I am relatively sure that these documents were in the planning stages for some time.


--- Jim
pndragon
 
Posts: 591
Joined: Sun Dec 05, 2004 1:27 am
Location: North Carolina

Postby Torf » Fri Oct 21, 2005 6:10 pm

I'd be glad to help out with the manual. Although i'm no native English speaker myself, but I guess it'd be enough if a native would proof read the whole thing. I wouldn't do it alone, though. First of all, I haven't done any animation in JPatch, yet, so someone else would have to cover that. Secondly, a documentation written by one person could be very much biased by his viewpoint. That's not a good thing :D

Before the real work can start, there are several things to consider, like format, style, etc.

So if anyone wants to join, just shout out loud.

As a last note: Spare time doesn't grow on trees over here, neither, and my time is limited, too. OTOH JPatch is not too big right now - if we get it right from the beginning, it'd be less work later :wink:
Torf
 
Posts: 155
Joined: Mon Nov 08, 2004 8:45 pm
Location: Germany/Konstanz

Postby squirrelhavoc » Fri Oct 21, 2005 6:30 pm

Torf wrote:So if anyone wants to join, just shout out loud.


I have only been using Jpatch for a few months, but I would still like to help. I am a native english speaker, but my spelling and grammar are horrendous (and I doubt I spelled that correctly :) ).
Squirrel Havoc

We live as we think, very very slowly....
squirrelhavoc
 
Posts: 180
Joined: Tue Jun 28, 2005 11:17 pm
Location: Oklahoma, USA

Postby sascha » Fri Oct 21, 2005 7:51 pm

About the format: I've got no expirence with LaTeX, docbook, SGML and so on. The best thing is to keep it plain old HTML. To collaboratively work on it, the Wiki would be useful - Dokuwiki can do some basic formatting and you can also insert html tags.
If we keep it simple enough it could be included as help - Swing supports HTML 3.2 with basic stylesheets.
Perhaps we should (just for the documentation) don't use Wiki formatting but only HTML - this would make it easier to use the documents as offline documentation or within JPatch.

About the form: I don't know. We could use the forum and the wiki to discuss it. If somebody suggests a table-of-contents, he could make a wiki page with just the chapters. We could discuss and possibly rearrange it then.

IHMO it should cover:
  • A short intoduction and overview.
  • Download and installation guides for a Sun JRE, JPatch and possibly JOGL for all supported platforms (I can only test on Linux and Windows).
  • A quick "walk through" with a lot of screenshots to get an overview about what can be done with JPatch and what can't.
  • Detailed documentation about every single feature.
  • Tutorials with screenshots and downloadable JPatch models at each step.
  • Instructions about how to download and install the most popular renderers (e.g. POV-Ray and one RenderMan renderer), and how to set up JPatch to use the renderers.
  • FAQ
What do you think?
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Next

Return to Beta

Who is online

Users browsing this forum: No registered users and 1 guest

cron