 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] runevision com> 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
|
|
| |
| |
|
|
|
|
| |
|
|
