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