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

"Rune" <run### [at] runevisioncom> a écrit dans le message de
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

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

Rune wrote:

> 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.

So much I understood. My point still is that if you make a utility that
imports some fileformat and you distribute that utility the format
could become a de facto standard, with all the consequences.

Post a reply to this message

Rune wrote:
> 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.

You will need at least *something* - take, for example, an arm or leg of 
a human model: If it bends to the maximum allowed angle (let's say 170 
degrees), the upper and lower parts would intersect, which would look 
quite odd in an animation.
The easiest solution are IMHO morphs. If you'd have a morph for the 
fully bended arm, you could apply it partially before actually applying 
the rotation:

E.g, if the maximum angle is 170 degrees, and you bend it 50% (85 
degrees), apply 50% of the morph, then rotate the resulting points 
around the joint for 85 degrees.

Once implemented, this method can easily be used to simulate muscle 
movement too.

I've made some experiments a while ago, here's an example of what I mean:
http:/www.jpatch.com/old/arm.mpg

I'm about to implement it in my modeler (which used a spline based 
approach and outputs bicubic patches to pov-ray), and use an xml-style 
file format...

-sascha

Post a reply to this message

Sascha Ledinsky wrote:
> You will need at least *something* - take, for example, an arm or leg
> of a human model: If it bends to the maximum allowed angle (let's say
> 170 degrees), the upper and lower parts would intersect

Not necessarily if the vertices around the joint moves by an average between
the two bones. I think.

> I'm about to implement it in my modeler (which used a spline based
> approach and outputs bicubic patches to pov-ray), and use an xml-style
> file format...

That sounds interesting. I'm curious, how have you managed to get around the
topology problem with bicubic patches? Triangular bicubic patches are not
supported in POV-Ray, and I've never seen three bicubic patches sharing one
corner fit seamlessly together. Well, seamlessly I have seen, but not with a
completely smooth surface...

I'd be interested in hearing more about your plans and the format.

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:

> Sascha Ledinsky wrote:
> 
>>You will need at least *something* - take, for example, an arm or leg
>>of a human model: If it bends to the maximum allowed angle (let's say
>>170 degrees), the upper and lower parts would intersect
> 
> 
> Not necessarily if the vertices around the joint moves by an average between
> the two bones. I think.
> 

Smoothly blending between two bones is nice to have too, but it doesn't 
really solve the problem. Morphs on the other hand have more advantages 
- you can easily fake muscle motion and also doo facial expressions, 
lip-syncing, etc...

>>I'm about to implement it in my modeler (which used a spline based
>>approach and outputs bicubic patches to pov-ray), and use an xml-style
>>file format...
> 
> 
> That sounds interesting. I'm curious, how have you managed to get around the
> topology problem with bicubic patches?

Currently three sided patches are handled as degenerate rectangular 
patches, and five-sised ones are represented by five rectangular patches 
(I will treat the three-sided case similar once I've a better 
implementation). Currently both versions suffer from creases (which are 
visible on reflective sorfaces or surfaces showing sharp specular 
highlights). Here is an example image, modeled with my modeler and 
rendered with pov-ray:
http://www.jpatch.com/gallery/head.jpg

I have not yet solved the problem, but I am sure there is a solution. I 
have found a paper which explains how to convert a bezier triangle into 
four regular bicubic patches. The patches connect seamlessly (with G1 
continuity). I'm quite sure a similar solution exists for five-sided 
patches - I've found the (mathematical) conditions for connecting 
patches with G1-continuity in a book about curves and surfaces, I try to 
apply it to my problem (causing me some headaches, as I'm not a 
mathematician :-/ ...)

> and I've never seen three bicubic patches sharing one
> corner fit seamlessly together. Well, seamlessly I have seen, but not with a
> completely smooth surface...

As I mentioned above, it is possible (see the code at the end of this 
post) - it converts a bezier triangle into three "pov-ray compatible" 
patches. Bezier triangles are not exactly what I need for my three- (or 
five-) sided patch, but it's a start ;-)

> I'd be interested in hearing more about your plans and the format.

I'll let you know when it's ready...

Here's the code:

#macro makePatch()
	#local P00 = T00;
	#local P01 = 1/2 * (T01 + T00);
	#local P02 = 1/4 * (T02 + 2*T01 + T00);
	#local P03 = 1/8 * (T03 + 3*T02 + 3*T01 + T00);
	#local P10 = 1/2 * (T10 + T00);
	#local P11 = 1/18 * (3*T11 + 5*T10 + 5*T01 + 5*T00);
	#local P12 = 1/72 * (3*T12 + 14*T11 + 11*T10 + 11*T02 + 22*T01 + 11*T00);
	#local P13 = 1/12 * (T12 + 2*T11 + T10 + T03 + 3*T02 + 3*T01 + T00);
	#local P20 = 1/4 * (T20 + 2*T10 + T00);
	#local P21 = 1/72 * (3*T21 + 11*T20 + 14*T11 + 22*T10 + 11*T01 + 11*T00);
	#local P22 = 1/54 * (3*T21 + 5*T20 + 3*T12 + 13*T11 + 10*T10 + 5*T02 + 
10*T01 + 5*T00);
	#local P23 = 1/18 * (T21 + T20 + 2*T12 + 4*T11 + 2*T10 + T03 + 3*T02 + 
3*T01 + T00);
	#local P30 = 1/8 * (T30 + 3*T20 + 3*T10 + T00);
	#local P31 = 1/12 * (T30 + T21 + 3*T20 + 2*T11 + 3*T10 + T01 + T00);
	#local P32 = 1/18 * (T30 + 2*T21 + 3*T20 + T12 + 4*T11 + 3*T10 + T02 + 
2*T01 + T00);
	#local P33 = 1/27 * (T30 + 3*T21 + 3*T20 + 3*T12 + 6*T11 + 3*T10 + T03 
+ 3*T02 + 3*T01 + T00);
	
	bicubic_patch {
		type 1
		flatness 0
		u_steps 5
		v_steps 5
		P00,P01,P02,P03,
		P10,P11,P12,P13,
		P20,P21,P22,P23,
		P30,P31,P32,P33
	}
#end

#macro bezierTriangle(T003,T012,T021,T030,T102,T111,T120,T201,T210,T300)
	union {
		#declare T00 = T003;
		#declare T01 = T012;
		#declare T02 = T021;
		#declare T03 = T030;
		#declare T10 = T102;
		#declare T11 = T111;
		#declare T12 = T120;
		#declare T20 = T201;
		#declare T21 = T210;
		#declare T30 = T300;
		makePatch()
		
		#declare T00 = T030;
		#declare T01 = T021;
		#declare T02 = T012;
		#declare T03 = T003;
		#declare T10 = T120;
		#declare T11 = T111;
		#declare T12 = T102;
		#declare T20 = T210;
		#declare T21 = T201;
		#declare T30 = T300;
		makePatch()
		
		#declare T00 = T300;
		#declare T01 = T201;
		#declare T02 = T102;
		#declare T03 = T003;
		#declare T10 = T210;
		#declare T11 = T111;
		#declare T12 = T012;
		#declare T20 = T120;
		#declare T21 = T021;
		#declare T30 = T030;
		makePatch()		
	}
#end


background { color rgb 0.5 }
camera {
	location <0,3,-1.5>
	look_at <1.5,0,1.5>
	
}

light_source {
	<0,100,100>
	color rgb 1
}

union {
	bezierTriangle(
		<0,0,0>,<1,1,0>,<2,-1,0>,<3,0,0>,
		<0,-1,1>,<1,2,1>,<2,1,1>,
		<0,1,2>,<1,-1,2>,
		<0,0,3>
	)
	pigment { uv_mapping checker rgb 0.8 rgb 0.4 scale 0.2}
	finish { ambient 0.4 diffuse 0.6 specular 0.5 roughness 0.02
	reflection 0}
}



--sascha

Post a reply to this message

Sascha Ledinsky wrote:

> Rune wrote:
> 
>> Sascha Ledinsky wrote:
>>
>>> You will need at least *something* - take, for example, an arm or leg
>>> of a human model: If it bends to the maximum allowed angle (let's say
>>> 170 degrees), the upper and lower parts would intersect
>>
>>
>>
>> Not necessarily if the vertices around the joint moves by an average 
>> between
>> the two bones. I think.
>>
> 
> Smoothly blending between two bones is nice to have too, but it doesn't 
> really solve the problem. Morphs on the other hand have more advantages 
> - you can easily fake muscle motion and also doo facial expressions, 
> lip-syncing, etc...
> 
>>> I'm about to implement it in my modeler (which used a spline based
>>> approach and outputs bicubic patches to pov-ray), and use an xml-style
>>> file format...
>>
>>
>>
>> That sounds interesting. I'm curious, how have you managed to get 
>> around the
>> topology problem with bicubic patches?
> 
> 
> Currently three sided patches are handled as degenerate rectangular 
> patches, and five-sised ones are represented by five rectangular patches 
> (I will treat the three-sided case similar once I've a better 
> implementation). Currently both versions suffer from creases (which are 
> visible on reflective sorfaces or surfaces showing sharp specular 
> highlights). Here is an example image, modeled with my modeler and 
> rendered with pov-ray:
> http://www.jpatch.com/gallery/head.jpg
> 
> I have not yet solved the problem, but I am sure there is a solution. I 
> have found a paper which explains how to convert a bezier triangle into 
> four regular bicubic patches. The patches connect seamlessly (with G1 
> continuity). I'm quite sure a similar solution exists for five-sided 
> patches - I've found the (mathematical) conditions for connecting 
> patches with G1-continuity in a book about curves and surfaces, I try to 
> apply it to my problem (causing me some headaches, as I'm not a 
> mathematician :-/ ...)
> 
>> and I've never seen three bicubic patches sharing one
>> corner fit seamlessly together. Well, seamlessly I have seen, but not 
>> with a
>> completely smooth surface...
> 
> 
> As I mentioned above, it is possible (see the code at the end of this 
> post) - it converts a bezier triangle into three "pov-ray compatible" 
> patches. Bezier triangles are not exactly what I need for my three- (or 
> five-) sided patch, but it's a start ;-)
> 
>> I'd be interested in hearing more about your plans and the format.
> 
> 
> I'll let you know when it's ready...
> 
> Here's the code:
[snip]

You did not explain what your macro does, and it is a bit hard
to follow without comments but here is what I think you are doing:
Lets call the corners A,B, and C. You split the triangle in three 
patches. One with corners: A, the middle of A and B, the middle
of A and C, and the centerpoint. Then you compute the remaining
points as functions of the originally given points. I can only
assume that the math is correct ;)

For POV to render these without cracks, you also have to
make sure that the division in triangles, as controlled by
u_step and v_step is the same in the patches in the triangle
and in the adjacent quad patches. This simply means that
in the triangle they have to be one lower then outside.
I think that it also forces a flatness of zero in the entire
set of patches. You have to be certain that the edges of
adjacent patches edges are split in the middle, so they
have to have flatness=0 and therefore their neighbours
also etc.

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.

I'm just getting started here.

> Are there restrictions on the angle of the joints?

When I first developed the modeler, I had upper and lower
limits for everything.  Then I decided to simply lock the
angles (if the user wanted them locked).

> 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.

Then don't bend them that far.  I put locking in the modeler mainly
because dragging a 3d end point on a 2d screen is very prone to error if
some form of locking is not in play.  Locking is no longer enforced in
the .INC files, because the animator should know what he/she is doing.

> There is also the issue of the muscle contracting
> giving mesh deformations at the position of the muscle
> and not close to the joint.

The math for soft tissue modeling is not fun, which is why I've not
gotten to developing it yet.

> I think that the one vertex one bone and even the Unreal model are set up
> to fascilitate fast computation.

And a smaller set of data to manipulate.  Right now the modeler only
needs to know the bone to which the vertex is attached, and the
coordinates of the vertex, local to the bone; this allows for a static
data object size.  Allowing for multiple bones greatly complicates
things.

> 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.

My modeler is designed for exporting the coarse meshes for subdivision
surfaces, so mine aren't getting done in real time anyway.

Regards,
John

Post a reply to this message

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 am considering this, or (perhaps) a vertex that is derived from a
weighted sum of other vertices.

Regards,
John

Post a reply to this message

Sascha Ledinsky wrote:
> Rune wrote:
> 
>> 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.
> 
> You will need at least *something* - take, for example, an arm or leg of 
> a human model: If it bends to the maximum allowed angle (let's say 170 
> degrees), the upper and lower parts would intersect, which would look 
> quite odd in an animation.
> The easiest solution are IMHO morphs. If you'd have a morph for the 
> fully bended arm, you could apply it partially before actually applying 
> the rotation:

I'll have to give this some thought.  Right now I'm working on the
subdivision preview (which I'm doing with Bezier patches).

Regards,
John

Post a reply to this message

> You did not explain what your macro does, and it is a bit hard
> to follow without comments but here is what I think you are doing:
> Lets call the corners A,B, and C. You split the triangle in three 
> patches. One with corners: A, the middle of A and B, the middle
> of A and C, and the centerpoint. Then you compute the remaining
> points as functions of the originally given points. I can only
> assume that the math is correct ;)

This is a little off topic now, I think if we continue a discussion 
about bezier patches we should start a new thread.

Anyway, that's exactly what it does. I've found the algorithm in a 
paper, I think it was:
Hu Shi-Min.
Conversion of a triangular Bezier surface into three rectangular Bezier 
surfaces.
Computer Aided Geometric Design, vol 13, 1996, 219-226.

> For POV to render these without cracks, you also have to
> make sure that the division in triangles, as controlled by
> u_step and v_step is the same in the patches in the triangle
> and in the adjacent quad patches. This simply means that
> in the triangle they have to be one lower then outside.
> I think that it also forces a flatness of zero in the entire
> set of patches. You have to be certain that the edges of
> adjacent patches edges are split in the middle, so they
> have to have flatness=0 and therefore their neighbours
> also etc.

You're right, but this is POV-Ray specific.
I've only posted this to prove that it is possible to smoothly connect 
three bezier patches to a triangular patch.
My problem is that a cubic bezier triangle can't be connected smoothly 
to cubic bezier patches - what I'd need is a similar conversion 
algorithm for something like Zheng-Ball patches (J.J. Zheng, A.A. Ball. 
Control point surfaces over non-four-sided areas. Computer Aided 
Geometric Design, 14:807-821, 1977) - discussed in this thread: 
http://news.povray.org/povray.binaries.images/thread/%3C3ff791bf%40news.povray.org%3E/?mtop=160788&moff=20

All those papers have been available for free download on the internet 
once, but now they have disappered and the only way to get them these 
days is to pay $30 for each one at http://www.elsevier.com :-(

Post a reply to this message

Sascha Ledinsky wrote:

>> You did not explain what your macro does, and it is a bit hard
>> to follow without comments but here is what I think you are doing:
>> Lets call the corners A,B, and C. You split the triangle in three 
>> patches. One with corners: A, the middle of A and B, the middle
>> of A and C, and the centerpoint. Then you compute the remaining
>> points as functions of the originally given points. I can only
>> assume that the math is correct ;)
> 
> 
> This is a little off topic now, I think if we continue a discussion 
> about bezier patches we should start a new thread.
In a sense this is actually very on topic, it is on how one can use
such a technique in POV. But I agree that it is a separate subject
that crops up every now and then. Perhaps there should be a tutorial
on advanced bezier techniques, but I do not have the time to write
that :(

> Anyway, that's exactly what it does. I've found the algorithm in a 
> paper, I think it was:
> Hu Shi-Min.
> Conversion of a triangular Bezier surface into three rectangular Bezier 
> surfaces.
> Computer Aided Geometric Design, vol 13, 1996, 219-226.
> 
>> For POV to render these without cracks, you also have to
>> make sure that the division in triangles, as controlled by
>> u_step and v_step is the same in the patches in the triangle
>> and in the adjacent quad patches. This simply means that
>> in the triangle they have to be one lower then outside.
>> I think that it also forces a flatness of zero in the entire
>> set of patches. You have to be certain that the edges of
>> adjacent patches edges are split in the middle, so they
>> have to have flatness=0 and therefore their neighbours
>> also etc.
> 
> 
> You're right, but this is POV-Ray specific.
That is exactly why I posted it.
> I've only posted this to prove that it is possible to smoothly connect 
> three bezier patches to a triangular patch.
> My problem is that a cubic bezier triangle can't be connected smoothly 
> to cubic bezier patches 
Sorry, you lost me there. Exactly what is your problem?
(you may decide to go to povray.off-topic, I read that also)

> - what I'd need is a similar conversion 
> algorithm for something like Zheng-Ball patches (J.J. Zheng, A.A. Ball. 
> Control point surfaces over non-four-sided areas. Computer Aided 
> Geometric Design, 14:807-821, 1977) - discussed in this thread: 
>
http://news.povray.org/povray.binaries.images/thread/%3C3ff791bf%40news.povray.org%3E/?mtop=160788&moff=20

> 
> 
> All those papers have been available for free download on the internet 
> once, but now they have disappered and the only way to get them these 
> days is to pay $30 for each one at http://www.elsevier.com :-(
I am quite sure that I downloaded and printed that article then.
The paper will be in a stack somewhere and I probably have the PDF on
a backup disk.
There is a new elsevier policy that allows the authors to have a PDF
of their article for download at a page of their institution.

Post a reply to this message

> (you may decide to go to povray.off-topic, I read that also)

it's not off-topic to povray.general, just off-topic to "Boned mesh file 
formats?" - anyway, we can continue it here until someone complains ;-)

>> My problem is that a cubic bezier triangle can't be connected smoothly 
>> to cubic bezier patches 
> 
> Sorry, you lost me there. Exactly what is your problem?

the "standard" rectangular (tensor product) patches in povray are 
bicubic, thus they have 16 controlpoints.

A "standard" cubic bezier triangle 
http://www.google.at/search?q=bezier+triangle has got 10 controlpoints 
(the outlines are cubic bezier curves, and there is one center-point). 
As far as I know, you can't smoothly connect such a triangle to 
rectangular (cubic) patches. I think (but I'm not sure) that it would be 
possible for bezier-triangles of order 4 (quartic) - (by degree 
elevating http://www.google.at/search?degree+elevation the outlines) 
bacause it has three inner controlpoints...

The only three- and five-sided patches I know of, which can be smootly 
connected to the rectangular ones are Hosaka/Kimura (M. Hosaka and F. 
Kimura. Non-four-sided patch expressions with control points. Computer 
Aided Geometric Design 1(1): 75-86, 1984.) for the cubic case, and 
Zheng/Ball for the general case (arbitrary degree).

Thus, I'm looking for a conversion scheme for such patches, similar to 
that one for "classical" bezier-triangles into "standard" rectangular 
patches (as in my macro).

> I am quite sure that I downloaded and printed that article then.
> The paper will be in a stack somewhere and I probably have the PDF on
> a backup disk.
> There is a new elsevier policy that allows the authors to have a PDF
> of their article for download at a page of their institution.

I have a zip archive with the zheng/ball publication (it was available 
for download on Mr. Zhengs webpage some time age), but I don't know if 
it is legal to share it.

It's a little bit beyond my math skills, so I'd be interested in reading 
the Hosaka/Kimura version, but I'Ve never found a download link :-/

Elsevier: I'm not a student, do you know if universities have (free) 
access to such material?
Would it be legal to share such a paper within an open-source project 
(i.e. not for commercial use)?

 > Perhaps there should be a tutorial
 > on advanced bezier techniques, but I do not have the time to write
 > that.

We could start with a discussion about "advanced bezier techniques" to 
share expirence and discuss all that scary math stuff ;-)
It could eventually become something like a tutrial with tips on using 
bezier patches in povray.
Not sure what the best platform would be - a thread in p.advanced-users?
Alternatively I could add a forum on my webpage's phpbb board 
http://www.jpatch.com/forum_frameset.html
or a wiki...

-sascha

Post a reply to this message

Sascha Ledinsky wrote:

>  > (you may decide to go to povray.off-topic, I read that also)
> 
> it's not off-topic to povray.general, just off-topic to "Boned mesh file 
> formats?" - anyway, we can continue it here until someone complains ;-)
> 
>>> My problem is that a cubic bezier triangle can't be connected 
>>> smoothly to cubic bezier patches 
>>
>>
>> Sorry, you lost me there. Exactly what is your problem?
> 
> 
> the "standard" rectangular (tensor product) patches in povray are 
> bicubic, thus they have 16 controlpoints.
> 
> A "standard" cubic bezier triangle 
> http://www.google.at/search?q=bezier+triangle has got 10 controlpoints 
> (the outlines are cubic bezier curves, and there is one center-point). 
> As far as I know, you can't smoothly connect such a triangle to 
> rectangular (cubic) patches. I think (but I'm not sure) that it would be 
> possible for bezier-triangles of order 4 (quartic) - (by degree 
> elevating http://www.google.at/search?degree+elevation the outlines) 
> bacause it has three inner controlpoints...
> 
> The only three- and five-sided patches I know of, which can be smootly 
> connected to the rectangular ones are Hosaka/Kimura (M. Hosaka and F. 
> Kimura. Non-four-sided patch expressions with control points. Computer 
> Aided Geometric Design 1(1): 75-86, 1984.) for the cubic case, and 
> Zheng/Ball for the general case (arbitrary degree).
> 
(to be honest I did not know that the standard bezier triangles had
only 10 control points, so that explains my confusion)
IIRC the Zheng Ball triangles had 3 inner control points. That implied
that every edge had 4 neighbour control points in the triangle
(two inside and 2 at the other edges). The derivative perpendicular
to the edge was defined by these 4 control points, just as in quad
patches. connecting to quad patches was thus conceptively simple.
Therefore, I think that patches with 12 control points will be more
useful for POV users, and true bezier triangles are only of academic
interest. You already seem to have a bezier patch with 12 control
points and I assume(hope) that they have the same properties as
the Zheng Ball triangles. So for all practical purposes my question
is: why look further?
And (just to annoy Thorsten): can we get Zheng Ball triangles and
pentangles as primitives in the next version of POV?
> Thus, I'm looking for a conversion scheme for such patches, similar to 
> that one for "classical" bezier-triangles into "standard" rectangular 
> patches (as in my macro).
If you insist, you can always compute the real 3D coordinates of the
points you want to use as the control points of your three patches
and invert the bezier computation to get the actual control points
that are needed by POV.
> 
>> I am quite sure that I downloaded and printed that article then.
>> The paper will be in a stack somewhere and I probably have the PDF on
>> a backup disk.
>> There is a new elsevier policy that allows the authors to have a PDF
>> of their article for download at a page of their institution.
> 
> 
> I have a zip archive with the zheng/ball publication (it was available 
> for download on Mr. Zhengs webpage some time age), but I don't know if 
> it is legal to share it.
Ah, getting off-topic. Yes an interesting IP question. I downloaded
it also and at that time it was free to use and distribute. Now,
it appears that it is not anymore. Is my copy still free and free
to distribute or am I not allowed anymore to share it. Basically
the question is can you change the legal status of a document
later without consent and without informing the holder of that
document.
> 
> It's a little bit beyond my math skills, so I'd be interested in reading 
> the Hosaka/Kimura version, but I'Ve never found a download link :-/
> 
> Elsevier: I'm not a student, do you know if universities have (free) 
> access to such material?
No, unless they have a subscription to the paper.
> Would it be legal to share such a paper within an open-source project 
> (i.e. not for commercial use)?
Ask a lawyer :)
I guess it is, as the paper is not a part of the project, only
secondary literature.
>  > Perhaps there should be a tutorial
>  > on advanced bezier techniques, but I do not have the time to write
>  > that.
> 
> We could start with a discussion about "advanced bezier techniques" to 
> share expirence and discuss all that scary math stuff ;-)
> It could eventually become something like a tutrial with tips on using 
> bezier patches in povray.
> Not sure what the best platform would be - a thread in p.advanced-users?
> Alternatively I could add a forum on my webpage's phpbb board 
> http://www.jpatch.com/forum_frameset.html
> or a wiki...
I do not know either.
> 
> -sascha

Post a reply to this message

> My problem is that a cubic bezier triangle can't be connected smoothly 
> to cubic bezier patches - what I'd need is a similar conversion 
> algorithm for something like Zheng-Ball patches (J.J. Zheng, A.A. Ball.

It was my own inability to find a way to stitch the patches smoothly
togeher that led me to developing a hybrid suface subdivision scheme.
This makes POV-Ray parsing a lot slower, though.

Charles Loop has been working on S-patches, which can have any number
of sides and can be as smooth as the modeler needs.  The problem with
them is that they require a s***load of control points.

Regards,
John

Post a reply to this message

I did this **in povray** for this anim:
(6 MB download:  http://www.irtc.org/ftp/pub/anims/2004-04-15/ought.mpg )

I used Mike William's file for extruding a mesh along a spline.  I had
another walk cycle which generated the points of the skeleton, then simply
put a natural spline along them. Mike Williams then generates the mesh 2.
See also smaller anims at:

http://news.povray.org/povray.binaries.animations/thread/%3C4088703a%40news.povray.org%3E/
http://news.povray.org/povray.binaries.animations/thread/%3C4036deea%40news.povray.org%3E/?ttop=197897&toff=50

So I think it is tres cool to keep it all in povray.

The Next Big Thing in this arena would of course to go beyond the "walking
worm" to the "walking pair of pants."  That is, have some code which
provides for a smooth leg-hip-otherleg.



"Rune" <run### [at] runevisioncom> wrote in 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?
>
> 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

Or even cooler, do it in a povray INC.
"andrel" <a_l### [at] hotmailcom> wrote in message
news:412### [at] hotmailcom...

>
> So much I understood. My point still is that if you make a utility that
> imports some fileformat and you distribute that utility the format
> could become a de facto standard, with all the consequences.
>

Post a reply to this message

Greg M. Johnson wrote:
> I did this **in povray** for this anim:
> (6 MB download:
> http://www.irtc.org/ftp/pub/anims/2004-04-15/ought.mpg )
>
> I used Mike William's file for extruding a mesh along a spline.  I had
> another walk cycle which generated the points of the skeleton, then
> simply put a natural spline along them. Mike Williams then generates
> the mesh 2.

Extruding a mesh along a spline which happens to go through some points in a
skeleton is not the same as deforming a mesh directly according to the bones
in a skeleton.

Your technique no doubt worked for your specific alien characters (that look
like they're made of sphere_sweeps) but are you claiming it can be used as a
general method to animate mesh characters such as your MIME Man or my AL the
Alien character (provided they were meshes to begin with)?

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" <run### [at] runevisioncom> wrote:
>
> Extruding a mesh along a spline which happens to go through some points in a
> skeleton is not the same as deforming a mesh directly according to the bones
> in a skeleton.
>
> Your technique no doubt worked for your specific alien characters (that look
> like they're made of sphere_sweeps) but are you claiming it can be used as a
> general method to animate mesh characters such as your MIME Man or my AL the
> Alien character (provided they were meshes to begin with)?
>



Good question. First of all, rather than "boning", I would use the term if
we're talkig povray of "transforms".  I have shin transforms, right eye
transforms, forearm transforms, even left index finger middle digit
transforms in my system.  If you set up transforms, then you can have
"anything" you want move to the same set of transforms. I primarily think
in transforms but I can have it spit out points if I choose.


There are several levels of difficulty to the problem you describe, perhaps
it's best to consider individually:

1).  Animation of a "single long stocking"-- say going from a foot to an
ankle to a knee up to the crotch.   This I believe is quite doable using
(hoping I'm not insulting him by invoking his name  and quality macro in
assocation with my mediocre work) the Mike Williams method.  I made
(perhaps unpublished?) a simple example like this and think it's quite
"workable" with a more professional-quality construction if one were to
choose.   If you don't care exactly how smoothly Al's arms connect to his
torso, if you'd settle for mere overlapping objects, then the answer is a
flat "yes".

2). Animation of "a pair of pants" or a "sweater"-- say two independently
moving legs which smoothly join to a "hip & but" or two independently
moving arms smoothly joining to a "torso". (A more complex version would be
multiple fingers joining a hand).  This is currently over my head, although
I'm currently skeptical that it's impossible with the Mike Williams method.
I think it's just a slightly bigger coding headache and this discussion is
almost about made me want to try it.

3). Animation of a moving jaw within a mouth with an opening.  This I think
is doable, too.

Post a reply to this message

gregjohn wrote:
> "Rune" <run### [at] runevisioncom> wrote:
>>
>> Extruding a mesh along a spline which happens to go through some
>> points in a skeleton is not the same as deforming a mesh directly
>> according to the bones in a skeleton.
>>
>> Your technique no doubt worked for your specific alien characters
>> (that look like they're made of sphere_sweeps) but are you claiming
>> it can be used as a general method to animate mesh characters such
>> as your MIME Man or my AL the Alien character (provided they were
>> meshes to begin with)?
>
> Good question. First of all, rather than "boning", I would use the
> term if we're talkig povray of "transforms".

It's basically the same thing. You need one or two transforms to specify the
alignment of a bone.

> If you don't care exactly how smoothly Al's arms connect to
> his torso, if you'd settle for mere overlapping objects, then
> the answer is a flat "yes".

But I do. That's kind of the whole point with the technique.

> 2). Animation of "a pair of pants" or a "sweater"-- say two
> independently moving legs which smoothly join to a "hip & but" or two
> independently moving arms smoothly joining to a "torso".

> I think it's just a slightly bigger coding headache and
> this discussion is almost about made me want to try it.

If you mean it'd be a new coding headache every time you have a new model or
skeleton, then you're missing the point. Deforming a skeleton according to
bones is a general technique that, once coded, don't require any additional
coding no matter how different the models and skeletons are. If on the other
hand you think you *do* have a general-purpose solution, then I wish you
good luck coding it.

> 3). Animation of a moving jaw within a mouth with an opening.  This I
> think is doable, too.

Again, this should be possible using the same code as for the pants and
sweater.

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" <run### [at] runevisioncom> wrote in message
news:41324cbb$1@news.povray.org...
> > 2). Animation of "a pair of pants" or a "sweater"-- say two
> > independently moving legs which smoothly join to a "hip & but" or two
> > independently moving arms smoothly joining to a "torso".
>
> > I think it's just a slightly bigger coding headache and
> > this discussion is almost about made me want to try it.
>
> If you mean it'd be a new coding headache every time you have a new model
or
> skeleton, then you're missing the point. Deforming a skeleton according to
> bones is a general technique that, once coded, don't require any
additional
> coding no matter how different the models and skeletons are. If on the
other
> hand you think you *do* have a general-purpose solution, then I wish you
> good luck coding it.
>


Consider the 'sweater' example.  I can envision a general model which works
of course for the first character you design with it. But if everything is
procedurally generated, then you can tweak skeletal points as well as the
splines that define the arm diameters as well as the spline that defines the
shape of the torso.  It shouldn't be too hard to go from robot to man to
woman to puppy dog once you've got the system.  You would however be locked
into designing the character within this system--or to put another spin on
it, blessed by having a totally procedurally generated, portable, 100%
povray, SDL-only character.  I intuitively appreciate this philosophy,
especially if it were politically incorrect with certain artsy-fartsy types.
To quote a recent winner of an IRTC Animation round, (from memory),  "Using
povray for character animation must be a complete waste of time".

Post a reply to this message

Greg M. Johnson wrote:
> It shouldn't be too hard to go from robot to man to woman to puppy
> dog once you've got the system.

Those all have four limbs, placed relatively the same way. How about bird,
dragon, three-armed alien, spider, worm?

> You would however be locked into designing the
> character within this system--or to put another spin on it, blessed
> by having a totally procedurally generated, portable, 100% povray,
> SDL-only character.

You just don't do detailed or realistic models that way. You haven't done
it, I haven't done it, nobody have yet. Meshes are the way to go for any
serious purposes (or possible bicubic patches). And I know you can do
procedural meshes, but those too are not of the detail level you can do with
a modeler. If you only need toons, you might do fine, but for serious work
it won't do.

> I intuitively appreciate this philosophy,
> especially if it were politically incorrect with certain artsy-fartsy
> types. To quote a recent winner of an IRTC Animation round, (from
> memory),  "Using povray for character animation must be a complete
> waste of time".

I've been very much a POV purist. My animation attempts with AL the Alien
proves that. Despite that I've come to the conclusion that doing character
animation *completely* within POV-Ray *is* a waste of time. That is, if
you're not satisfied with blobby toons, unsmooth joints etc.

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" <run### [at] runevisioncom> wrote:

> If you only need toons, you might do fine, but for
> serious work it won't do.
>


I take offense at the implied dichotomy between "toon" and "serious". (Not
personal, but intellectual or ideological offense).  "The Incredibles",
Pixar's next film, I predict, will earn GOBS of cash (a professional
achievement) and will represent a technical achievement on the par  of
Jar-Jar Binks or Gollum.


> Despite that I've come to the conclusion that doing character
> animation *completely* within POV-Ray *is* a waste of time. That is, if
> you're not satisfied with blobby toons, unsmooth joints etc.
>


I guess my view is that going from a serious modeller to povray is a waste
of time.  It's just another tracer.  The coolness of povray (perhaps a
rarely held opinion) is in its being freeware and allowing the script-based
generation of objects. If I were to get another program to make the
objects, it would seem to make sense to have that program take the
pictures, too.

That being said, I think it would be a great boon if someone were to make a
bending bicubic patch animatable within povray.

Post a reply to this message

>  The coolness of povray (perhaps a
> rarely held opinion) is in its being freeware and allowing the
script-based
> generation of objects.

The script based generation is nice, but from my viewpoint, nothing I have
ever seen or used beats POV-Ray for control over light.  Many times, I've
placed point sources only .001 POV unit away from an obstruction to get the
light exactly where I wanted it to come from.  Interior lighting with Poser
has been nothing but frustration, I'll normally export the scene without
lights and do the lighting in POV.  Clumsy, inefficient, but exactly what
I'm seeing in my head.  Pretty hard to beat.

Greybeard

(Who isn't going to spend a kilobuck to get what POV allows me to do.)

Post a reply to this message

Rune wrote:

> I've been very much a POV purist. My animation attempts with AL the Alien
> proves that. Despite that I've come to the conclusion that doing character
> animation *completely* within POV-Ray *is* a waste of time. That is, if
> you're not satisfied with blobby toons, unsmooth joints etc.

Organic shapes of any kind are far, far, easier to do with a modeler
than with hand-written SDL.

Case in point:  The green aliens in my April 2004 entry would have taken
weeks to create using hand-edited SDL code.  Using the modeler I've
developed, I generated the model in only a couple hours.  This enabled
me to move on to other portions of the work.

It's true that the aliens ride floating carts which are done in SDL,
but SDL *is* good for some things.

SDL can procedurally generate a small subset of organic shapes, such as
trees.  The petrified trees that appear in most of my Rusty animations
were generated this way, but I *never* let the camera get close enough
to reveal how little detail they have; the limbs and trunks are eight-
sided prisms, with smoothed normals, and there are only three different
trees (each being copied many hundreds of times).

It's also true that all the time Greg has spent trying to get a decent
human from SDL has probably resulted in development of some useful
scripting techniques.  Whether this is worth the immense amound of time
invested is another matter.

I'm reminded of some of Howard Day's stuff.  Instead of doing procedural
textures, he simply rendered an silhouette of the model, used a paint
program on the resulting image, and then made the image into an
image_map and applied it to the model.  He'd probably still be getting
some of the textures right if he'd stuck with SDL, but instead he was
able to devote more time to the ticky parts of the work.

Regards,
John

Post a reply to this message

gregjohn wrote:

> "Rune" <run### [at] runevisioncom> wrote:
> 
>>If you only need toons, you might do fine, but for
>>serious work it won't do.
> 
> I take offense at the implied dichotomy between "toon" and "serious". (Not
> personal, but intellectual or ideological offense).  "The Incredibles",
> Pixar's next film, I predict, will earn GOBS of cash (a professional
> achievement) and will represent a technical achievement on the par  of
> Jar-Jar Binks or Gollum.

One issue that is important is the ability to get the *exact* effect you
want with the minimal expenditure of time.  SDL can do everything, but
the investment of lifespan is too long for some effects.

>>Despite that I've come to the conclusion that doing character
>>animation *completely* within POV-Ray *is* a waste of time. That is, if
>>you're not satisfied with blobby toons, unsmooth joints etc.
> 
> I guess my view is that going from a serious modeller to povray is a waste
> of time.  It's just another tracer.  The coolness of povray (perhaps a
> rarely held opinion) is in its being freeware and allowing the script-based
> generation of objects.

Another beneift of POV-Ray is that I can use the SDL to make alignments
of objects far more precisely than any modeler can allow for the same
amount of lifespan invested.

Regards,
John

Post a reply to this message

Rune a écrit :

> 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
You may have a look at this
http://projects.blender.org/projects/makeh

I havn't look further whet it is exactly but I thought it might be usefull.

--
Clipper

Post a reply to this message

"GreyBeard" <r.b### [at] sbcglobalnet> wrote in message
news:4132b2a2$1@news.povray.org...
>
> The script based generation is nice, but from my viewpoint, nothing I have
> ever seen or used beats POV-Ray for control over light.  Many times, I've
> placed point sources only .001 POV unit away
>


I'm sure my computer lingese is lacking. I guess this is in a way a benefit
of "scripting."

Post a reply to this message

"John VanSickle" <evi### [at] hotmailcom> wrote in message
news:4132b83d$1@news.povray.org...
> Case in point:  The green aliens in my April 2004 entry would have taken
> weeks to create using hand-edited SDL code.  Using the modeler I've
> developed, I generated the model in only a couple hours.  This enabled
> me to move on to other portions of the work.
>


Questions:
1) Are they also part of the lion snake modelling system?  I was about to
download and try it out once, but the weekend I had free to do it was when
your ISP was refusing attempts.

2) One thing I've always been wanting to ask about your system.   I'm
assuming you're talking about the aliens which got bit by the tomatoes.  Has
your system therefore reached the "pants" level of acheivement-- to use my
earlier terminology-- where the "body" is like the hip/but" of a pair of
pants, and the two eyestalks are the "legs"?   If so, is this part of
something you have released-- lionsnake??

Thanks.

Post a reply to this message

Greg M. Johnson wrote:

> "John VanSickle" <evi### [at] hotmailcom> wrote in message
> news:4132b83d$1@news.povray.org...
> 
>>Case in point:  The green aliens in my April 2004 entry would have taken
>>weeks to create using hand-edited SDL code.  Using the modeler I've
>>developed, I generated the model in only a couple hours.  This enabled
>>me to move on to other portions of the work.
> 
> Questions:
> 1) Are they also part of the lion snake modelling system?  I was about to
> download and try it out once, but the weekend I had free to do it was when
> your ISP was refusing attempts.

Yes.  I moved the download to a new site (the old page will link to it).

> 2) One thing I've always been wanting to ask about your system.   I'm
> assuming you're talking about the aliens which got bit by the tomatoes.  Has
> your system therefore reached the "pants" level of acheivement-- to use my
> earlier terminology-- where the "body" is like the hip/but" of a pair of
> pants, and the two eyestalks are the "legs"?   If so, is this part of
> something you have released-- lionsnake??

Yes.  The eyestalks are chains of three or four bones each.  At the end
of each stalk there is a two-bone fork, to support both the upper and
lower lid of each eye.

The mouth is done with eight bones, one for each corner of the mouth and
three for each lip.

The modeler applies only the most basic limits to the bones, namely that
bones can share start points, but not end points, and that the end point
of any bone can be the starting point for as many bones as your memory
will allow.  I'm working on a model of a creature with six legs and two
arms (I forget whether I gave it a tail).  I still haven't modeled the
bone support for the mouth or the eyelids (or the mesh to serve as the
skin).

The actual reason I started working on the modeler was that after seeing
some of the initial concept art for the IMP I concluded that a real
modeler was essential for some of the work planned.  This was shortly
after the IMP was launched, and to be honest I haven't paid much
attention to the IMP since then.

Regards,
John

Post a reply to this message

"Rune" <run### [at] runevisioncom> 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.

I was going to point you to the h-anim work that has been done for VRML, but
a lot of that seems to have disappeared off the web3d site. The people who
did the h-anim work have kept some of it up and available at
http://www.hanim.org
It might help, but will probably leave you more puzzled than anything.
H-anim and VRML are open formats.

A better place is a young guy's site here in Australia. He calls himself
Thyme and is very friendly and helpful. He makes his program Seamless3d
available free from his website at
http://www4.tpg.com.au/users/gperrett/seamless3d/index.html
It does animation of single-mesh avatars by moving the points in the mesh as
you were saying. He really is the best person you could talk to on this.
His work is all in VRML, but really that is similar in many ways to
POV-Ray; just that VRML is real-time and POV-Ray is raytraced and geared
more to complex, beautiful images.

If you want to see some of the examples they used to have on the h-anim site
and the web3d site email me back and I'll send them to you. Luckily I saved
them to my hard drive a while ago.

Best wishes,

- miriam (at) werple . net . au

Post a reply to this message

I should have mentioned that conversion between VRML and POV-Ray is easy.
They are both ASCII 3d scripting languages with some similarities, and
there are a number of tools that will convert automatically (pov2vrml,
AccuTrans, etc).

VRML continuous mesh avatars can use java to manipulate the mesh vertices or
VRML's own scripting to do it. I have examples of both. At the very least
this would help you work out a way to get POV-Ray to do it.

I have been using VRML for several years and have become a little unhappy
with the development effort there in recent years. I've always thought
POV-Ray had one of the coolest communities and has a very economical
language. It always seemed to me that being able to model and move things
in POV-Ray in realtime would make a lot of sense, so that when you are
happy with the layout of the scene you could render that as the raytraced
final image. It surprises me that this never happened. When I was manager
of a 3d multiuser world for kids a little while back I had the wonderful
experience of watching kids as young as 5 years old building things by
moving them around inside the virtual world. It is a very powerful way of
doing things. Imagine if we could do that with POV-Ray!

(Sorry, that last bit is a little bit off-topic.)

Post a reply to this message