POV-Ray : Newsgroups : povray.general : Request: deform : Re: Field_deform (was: Request: deform) Server Time
8 Aug 2024 18:20:20 EDT (-0400)
  Re: Field_deform (was: Request: deform)  
From: Chris Huff
Date: 13 Jan 2001 09:53:13
Message: <chrishuff-67BB10.09544813012001@news.povray.org>
In article <3a5de3eb@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> > It might be a better idea to just implement a bone system.
> > Maybe a new kind of mesh..."boned_mesh"...would be the
> > easiest way to do things.
> 
> I don't think that's a good idea. You said to me recently that you 
> preferred the flexible feature that could be used for many things 
> over the specialized feature. And I agree. To create a whole new 
> object type just to be able to pose figures seems odd to me.

The flexibility argument is *why* I think a new object type would be 
useful...you could probably get more flexibility with an object designed 
for this purpose. There is potentially a lot of new data for this thing 
that wouldn't really fit with ordinary meshes.
However, that data is really only used in the parsing stage...maybe 
something that will generate a mesh:
mesh {
    // usual mesh stuff...triangles, etc
    boned_mesh {vertex and bone data}
}
The best of both worlds...it could let you define "ownership" of each 
individual vertex, or use "deformation fields" to do the job, and would 
result in a mesh, and not save irrelevant data or interfere with the 
existing mesh syntax. The boned_mesh keyword would take a mesh, deform 
it to fit the bones, and add it to the containing mesh. Similar to my 
idea of letting you add tesselations and triangle-based objects to a 
mesh...you would lose some object-specific optimizations when you use 
this feature, but could combine whatever objects you want, and use new 
mesh features on them.
mesh {
    tesselate {}
    height_field {}
    bicubic_patch {}
    mesh {}
    boned_mesh {}
}


> > but inverse kinematics features could be worked into a
> > boned mesh feature,
> 
> I've been working with inverse kinematics for a while now, and if 
> there's one thing I've learned, it is that no general all-round IK 
> solution can be made. You can make so many different IK systems with 
> different ways of handling things. One system would never be 
> satisfactory for all tasks. Some 3D software has acceptable 
> solutions, but then, they have GUI too, and that a completely 
> different situation.

The syntax would probably not be very useable anyway...better to add a 
general "bones" feature and let macros/includes do the IK.


> > Patterns would be the most flexible way. Remember, you can
> > make blob-like fields with a pattern, too. You might even
> > be able to use the blob pattern. :-)
> 
> You're a bit late. I already mentioned that in my first message.
> Did you bother to read that message?

Ouch... :-)
I did, but I must have misinterpreted what you were saying...I thought 
you meant blob-like fields controlled by something else, not the blob 
pattern.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.