I'm not sure I have the required skills, but I'd like to write a program in
Java that can import a boned mesh in some format, move the bones around,
deform the mesh according to the moved bones and then export the mesh as a
mesh2 for example.

Are there any widely used formats for boned meshes?

It should contain the mesh (typically a character in some standard pose),
the bones in the same standard pose, and data about which vertices are
affected by which bones.

However, in order to deform the mesh correctly, I'd probably also have to
know the algorithm used for the deforming. Even with that available I might
not have the skills, but I can always hope.

I think I have to base it all on a pre-existing format for boned meshes,
because how else would people be able to actually create those boned meshes?
I certainly don't have the skills to create a graphical mesh and boning
modeler/editor.

Any ideas?

Rune
-- 
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

news:412d243a$1@news.povray.org...
> I'm not sure I have the required skills, but I'd like to write a program
in
> Java that can import a boned mesh in some format, move the bones around,
> deform the mesh according to the moved bones and then export the mesh as a
> mesh2 for example.
>
> Are there any widely used formats for boned meshes?

I'm really not sure that there's a format supporting boned meshes that isn't
highly proprietary and tied to a specific modeler. I could be wrong of
course. The Kaydara file format (which is supposed to allow easy exchange
between high-end 3D apps) is possibly the closest thing and it's
proprietary. This is not illogical: bones aren't just geometry, it's how
they interact with the geometry that makes the difference, and modeling
software have different ways to do that (the two I have sure work
differently).

I guess that defining formally the "rest" position of the bones isn't too
difficult, but the influence of the bones on their environment and on the
other bones (IK) seems tricky to conceptualise (heck, it's already difficult
to understand and memorise even going through tutorials with the manual in
hand...) and to store in the bone file in a formal way. The simplest way
seems to give each bone a mathematically-defined "radius of influence", but
that's rather artifact-prone. So a better solution is to link bones to lists
of (weighed) vertices. And after that, some bone-specific information is
still necessary to interpret those "basic" data and the final algo ties it
all together.

G.

-- 
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

Rune wrote:

> I'm not sure I have the required skills, but I'd like to write a program in
> Java that can import a boned mesh in some format, move the bones around,
> deform the mesh according to the moved bones and then export the mesh as a
> mesh2 for example.
> 
> Are there any widely used formats for boned meshes?
> 
> It should contain the mesh (typically a character in some standard pose),
> the bones in the same standard pose, and data about which vertices are
> affected by which bones.
> 
> However, in order to deform the mesh correctly, I'd probably also have to
> know the algorithm used for the deforming. Even with that available I might
> not have the skills, but I can always hope.
> 
> I think I have to base it all on a pre-existing format for boned meshes,
> because how else would people be able to actually create those boned meshes?
> I certainly don't have the skills to create a graphical mesh and boning
> modeler/editor.
> 
> Any ideas?

I also am greatly interested in learning of this, so that I can use an
existing format for my modeler, instead of developing Yet Another File
Format.

Regards,
John

Post a reply to this message

I have been searching a little and the Half-life .mdl format seems to be
widely used. However, that is intended for games primarily and I guess it is
mostly used for low-polygon models. I'm also fairly sure I wouldn't be able
to make a reader for it in Java. But the Half-life SDK can be downloaded and
I've read that a description of the format is available, if anyone's
interested.

One program that is also low-poly is Milkshape:
http://www.swissquake.ch/chumbalum-soft/
It can convert between many different formats, and supposedly it's easy to
write one's own export plug-in too. It's shareware, but not very expensive
($25).

I'd be interested in working together with others to find a solution how to
handle skeletal/boned meshes in POV-Ray. I only know POV-Ray SDL and Java
have no experience reading and writing binary files.

Basically I have a Java program that will control the movements of the bones
in a skeleton, and I'm hoping that I will in some way or another be able to
use this to deform a mesh so that I'm not restricted to animating robots,
crude toon characters and other inorganic shapes.

Rune
-- 
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

in news:412d243a$1@news.povray.org Rune wrote:

> Are there any widely used formats for boned meshes?
> 

Blender supports bone and their source is available, so maibe you can get 
some information from there.


Ingo

Post a reply to this message

Rune wrote:
> I'd be interested in working together with others to find a solution how to
> handle skeletal/boned meshes in POV-Ray. I only know POV-Ray SDL and Java
> have no experience reading and writing binary files.
> 
> Basically I have a Java program that will control the movements of the bones
> in a skeleton, and I'm hoping that I will in some way or another be able to
> use this to deform a mesh so that I'm not restricted to animating robots,
> crude toon characters and other inorganic shapes.

I was going to explain how my bone system works in my modeler, but the
system is acting strangely (probably from a bug introduced during a
prior bugfix :-( ), so I can't verify everything I was going to say.

I'll fix it and come back with some commentary.

Regards,
John

Post a reply to this message

Rune wrote:

> I have been searching a little and the Half-life .mdl format seems to be
> widely used. However, that is intended for games primarily and I guess it is
> mostly used for low-polygon models. I'm also fairly sure I wouldn't be able
> to make a reader for it in Java. But the Half-life SDK can be downloaded and
> I've read that a description of the format is available, if anyone's
> interested.
> 
> One program that is also low-poly is Milkshape:
> http://www.swissquake.ch/chumbalum-soft/
> It can convert between many different formats, and supposedly it's easy to
> write one's own export plug-in too. It's shareware, but not very expensive
> ($25).
> 
> I'd be interested in working together with others to find a solution how to
> handle skeletal/boned meshes in POV-Ray. I only know POV-Ray SDL and Java
> have no experience reading and writing binary files.

In my bone system, I have a set of two transforms for each bone,
one for the start and one for the end.

The start transform is derived from a rotation around one or two axes,
followed by the application of the end transform of the parent bone (if
there is a parent bone) or by a translate (if there is no parent).

The end transform is derived from a translation around the z-axis,
followed by a rotation around z, followed by the application of the
start transform just calculated.

The vertices that are attached to each bone are local to either the
start or the end of the bone.

The rotations to be done depend on the kind of joint between the parent
and the current part.  The joint type is a way of interpreting the
angles supplied by the user.

The first kind of joint I use is the uni joint.  In it the shaft of
a bone is rotated around the x-axis, then the y axis.  In the following
example, the part has no parent.

#declare Part1_tb=transform {
    rotate <Part1_ax,Part1_ay,0>
    translate Part1_p
}

The second kind of joint I use is the ball joint.  The shaft of the bone
is rotated around an axis passing through the base of the bone; the 
direction of this axis is determined by another angle of rotation.
The following example shows the rotations for this joint.  This bone
has a parent bone (the previous one).

#declare Part2_tb=transform {
    rotate -z*Part2_ay
    rotate <Part2_ax,0,Part2_ay>
    transform Part1_te
}

The third kind of joint I use is the hinge joint.  The shaft of the
bone is rotated around the horizontal axis, but there is no rotation
around the vertical axis.  This seems redundant with the uni joint,
but I developed it because the hinge and uni provide for different
ways of posing the model when the end point is dragged by the mouse
in my modeler.  In the following example, the bone is a child of the
second bone above.

#declare Part3_tb=transform {
    rotate x*Part3_ax
    transform Part2_te
}

The end transform for all three bones is calculated in the same
way:

#declare Part1_te=transform {
    rotate z*Part1_az
    translate z*Part1_sl
    transform Part1_tb
}

#declare Part2_te=transform {
    rotate z*Part2_az
    translate z*Part2_sl
    transform Part2_tb
}

#declare Part3_te=transform {
    rotate z*Part3_az
    translate z*Part3_sl
    transform Part3_tb
}

You can base the objects on these transforms:

cylinder { 0,Part3_sl,rRadius transform Part3_tb }

My modeler works in conjuction with my subdivision surface
macros.  If the original mesh has some vertices based on one
bone, and other vertices based on another bone, the faces
that span the two bones will show stretching when the bones
are moved relative to each other.

Hope this helps,
John

Post a reply to this message

John VanSickle wrote:
> In my bone system, I have a set of two transforms for each bone,
> one for the start and one for the end.

Mee too.

All the details about how the transforms are generated and the various joint
types are not important to me, since my system will take care of generating
the transforms in its own way. The only thing that matters is that the end
result is compatible. And the end result is for both of our systems two
transforms for each bone, one for the start and one for the end.

> The vertices that are attached to each bone are local to either the
> start or the end of the bone.

The "local" part here I'm not sure I understand. Surely all vertices in the
model are modeled in a global coordinate space? I presume by local you only
mean that the vertices are "attached" to either the start or the end of the
bone?

> #declare Part3_te=transform {
>     rotate z*Part3_az
>     translate z*Part3_sl
>     transform Part3_tb
> }
>
> You can base the objects on these transforms:
>
> cylinder { 0,Part3_sl,rRadius transform Part3_tb }

Shouldn't that be z*Part3_sl there?

> My modeler works in conjuction with my subdivision surface
> macros.  If the original mesh has some vertices based on one
> bone, and other vertices based on another bone, the faces
> that span the two bones will show stretching when the bones
> are moved relative to each other.

Yes. Your format and the game-related formats I was looking at seem to have
in common that each vertex is attached to one bone only, not multiple bones,
each with a weight of influence. This restricts the format to being useful
for low-detail models only. I know that subdivision takes care of creating
additional triangles, but a smooth subdivided mesh will still be as
low-*detail* as the model it is derived from even though it is
high-*polygon*. This doesn't mean that such formats aren't useful, it just
mean that there are certain restrictions to how detailed models one can work
with.

I tried out your LionSnake modeler, but I must admit I failed to create
something as simple as a regular box. But then, I have no experience with
other modelers either. I'd be curious to see what more talented modelers
could create with your modeler. The sample object that comes with the
program (which resembles a sheet of paper) is not a very good indication of
what the program can be used for I think.

Anyway, the things I need to know if I am to support this format is not so
much the joint types, but rather what the format itself looks like, i.e. how
is the information stored in the file?

Rune
-- 
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Rune wrote:
> Yes. Your format and the game-related formats I was looking at seem
> to have in common that each vertex is attached to one bone only, not
> multiple bones, each with a weight of influence.

Actually the Unreal skeletal model format does have multiple-bone influence
on vertices, as it can be seen in this document:
http://udn.epicgames.com/Two/SkeletalSetup

My guess is that any serious skeletal mesh format that is under active
development will end up supporting this. Having each vertex attached to one
bone only simply is too restrictive.

Rune
-- 
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Have you thought about more complicated things, like
some flesh bulging out when a join moves? Simply because
of conservation of volume. Are there restrictions on the
angle of the joints? Both things are not so well done
in Poser IMHO, there it is too easy to overstrecht and
even do 360 turns on any joint, which horribly deforms
the mesh. There is also the issue of the muscle contracting
giving mesh deformations at the position of the muscle
and not close to the joint.

Rune wrote:

> Rune wrote:
> 
>>Yes. Your format and the game-related formats I was looking at seem
>>to have in common that each vertex is attached to one bone only, not
>>multiple bones, each with a weight of influence.
> 
> 
> Actually the Unreal skeletal model format does have multiple-bone influence
> on vertices, as it can be seen in this document:
> http://udn.epicgames.com/Two/SkeletalSetup
> 
> My guess is that any serious skeletal mesh format that is under active
> development will end up supporting this. Having each vertex attached to one
> bone only simply is too restrictive.
> 
I think that the one vertex one bone and even the Unreal model are set up
to fascilitate fast computation. In the context of ray tracing this is
not so much an issue (unless we do real time ray tracing). If I had
to do it I probably start with something of the Unreal model as a first
approximation and then for a number of angles of the joint compute
the position of the vertices. Then do a sort of relaxation step to get
the mesh a bit nicer, and perhaps account for compression effects.
Finally fit a curve through the positions as a function of the joint
angle. That is a lot of computation, but it has to be performed
only once for the model.
I did something like that in my butterfly model
http://news.povray.org/povray.binaries.scene-files/thread/%3C402136A0.7020206%40hotmail.com%3E
(yes I know I had only one 'joint' and a combination of joints makes
it more difficult)

	Andrel

Post a reply to this message