 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> Have you thought about more complicated things, like
> some flesh bulging out when a join moves? Simply because
> of conservation of volume.
No, I think the problem we are facing is complicated enough without
considering these things. I'm also fairly sure that while it might be
possible to find existing formats for skeletal meshes that it would be
possible to support, such formats would not include such advanced features
(or specifications on how to implement them).
> Are there restrictions on the angle of the joints?
I'm not working on a graphical bone-editor, so restrictions on joints is not
my department. Might be relevant for John VanSickle though.
> There is also the issue of the muscle contracting
> giving mesh deformations at the position of the muscle
> and not close to the joint.
Again, way too complicated when we don't even have the basics down yet.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle wrote:
> 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.
The Milkshape 3D ASCII format might do the trick, at least it's the only one
I've been able to find a clear specification on (though I don't understand
it 100% yet). It can include animation data of the bones, but if you don't
need that I guess you can ignore the irrelevant parts.
Explanation of format here:
http://yallara.cs.rmit.edu.au/~wbecker/Interactive3D/milkshape.txt
Also see this page:
http://www.swissquake.ch/chumbalum-soft/ms3d/download.html
Look for this: "MsViewer MilkShape 3D ASCII Viewer for demonstrating how to
process the bones and vertices, full source code included)"
This format too attaches one bone to each vertex only, so in that regard
it's similar to yours.
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:
>
> Again, way too complicated when we don't even have the basics down yet.
I know, I only brought them up now, so you would not be surprised
later, when it turns out you need it but your fileformat can
not support it. Just look at the specifications if there might
be a possibility to fit these things in.
Always remember that whatever you do might evolve in some
(POV) standard, even if you do not want that bacause you think
it is much too primitive.
I made this sort of mistake a couple of times :(
Andrel
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> Always remember that whatever you do might evolve in some
> (POV) standard, even if you do not want that bacause you think
> it is much too primitive.
No, because I'm not going to make a new format at all. That's why I'm
looking for existing formats.
My plan is to then import data in such a preexisting format, manipulate the
data, and export it as a regular mesh2.
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
|
|
| |
| |
|
|
|
|
| |
|
|
