AFAIK meshes, bicubic patches and perhaps iso-surfaces can be transformed
nonlinearly. Or they could if there was functions in POV-ray that was
designed to do this...

I suggest that we begin to think of the possibilities of implementing such
functions. I personally believe that it could improve POV-Ray significantly
in some of the areas where it is currently not as powerful as many other
renderers.

To make such functions useable it would probably be necessary to implement
several different kinds of those nonlinearly transformations. They could all
be contained into a statement such as deform {} or something.

One type of deform could be one that deforms dependent on warps:

deform {
   warp {...}
}

As you can sure imagine, this alone would be a very powerful and general way
of deforming the supported object.

But more complicated ways of deforming may be useful. I have thought of a
feature that would deform objects by several user-specified regular
transforms, each weighted by a 3D field in space. I believe this could be
used for many things. For example it could be used to make a kind of bone
structure. One part of a mesh body could be enclosed by one field which
would be transformed by one linear transform. Another part of the body would
by due to another field be transformed by another linear transform. The
3D-fields could be defined by patterns, which would be very flexible, but
probably also rather difficult to master and somewhat slow, or they could be
controlled in a way similar to blobs, which would be less flexible, but
surely easier to understand, and probably faster. Possible syntax:

deform {
   field_transform {
      sphere {
         location, radius, strength,
         transformations (of the field)
         apply_transform transform_id (of the mother object, such as mesh)
      }
      cylinder { (like sphere, but with end1, end2 instead of location) }
      ...
   }
}

alternative way:

deform {
   field_transform {
      field {pattern_id, transform_id}
      field {pattern_id, transform_id}
      ...
   }
}

The pattern way of field_deform could be used with blob_pattern to achieve
same functionality I guess, but it would probably still be slower.

Other deform types could possible be made too. What do you think of the
whole idea?

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

Rune wrote:
> 
> AFAIK meshes, bicubic patches and perhaps iso-surfaces can be transformed
> nonlinearly. Or they could if there was functions in POV-ray that was
> designed to do this...

Iso-surfaces can be transformed non-linearly by adding transformation
functions within the iso-surface itself. (I just posted an example in 
povray.binaries.images)

But this is very painful !

So other methods to torture them would be very welcome.


Regards,

Tor Olav
-- 
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html

Post a reply to this message

In article <3a5a3a2d@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> AFAIK meshes, bicubic patches and perhaps iso-surfaces can be transformed
> nonlinearly. Or they could if there was functions in POV-ray that was
> designed to do this...

You can apply non-linear transformations to isosurfaces by modifying 
their functions. Bicubic patches, height fields, meshes, and other 
tesselated objects could also be deformed fairly easily without changing 
the rendering method very much, but you would have to make fairly major 
additions to the code.(I once made an attempt at deformable meshes, but 
failed completely)


> I suggest that we begin to think of the possibilities of implementing 
> such functions. I personally believe that it could improve POV-Ray 
> significantly in some of the areas where it is currently not as 
> powerful as many other renderers.

You're a little late...Wlodzimierz ABX Skiba has already been working on 
a deform patch, which apparently can work on all objects. Also, Warp is 
working on a tesselation patch that could be used to do similar things. 
All of this was discussed, including the possibility of using warps. 
Look around in povray.unofficial.patches, it was fairly recent.


> But more complicated ways of deforming may be useful. I have thought of a
> feature that would deform objects by several user-specified regular
> transforms, each weighted by a 3D field in space.
...snip...

I think it would be better to define deformations with a warp, and 
implement a new warp that does this. I think it would be a good idea to 
keep a single syntax for deforming both objects and textures.

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

Chris Huff wrote in message ...
> > I suggest that we begin to think of the possibilities of implementing
> > such functions. I personally believe that it could improve POV-Ray
> > significantly in some of the areas where it is currently not as
> > powerful as many other renderers.
>
> You're a little late...Wlodzimierz ABX Skiba

simpler is write just ABX :-)

> has already been working on
> a deform patch, which apparently can work on all objects

I have changed my previous syntax for simpler usage I think

instead next object in pov syntax I have putted deform into object modifiers
in example :

ttf {
  "arial.ttf" , "Hello world" 0, 1
  texture { ... }
  transform { translate rotate etc.. }
  deform { TYPE PARAMS }
  :
  :
}

also declaration of deforms will be available just like declaration of
transformations, textures or other things

#declare BestTwist = deform { twist .5 }

object {
  MyBox
  texture { MyTexture }
  deform { BestTwist }
}

Every deformation will be defined as something like pattern in pigments : twist,
envelope, curve, stretch etc followed parameters. I plan implement functions as
type of deformations after 3.5 release (I wait for specification of functions) -
deform{function{...}}

Rune's proposition of control points could be possible as part of this stuff but
... I thought about deformation depends of distance point to the bezier patch or
sth

current state of deform patch : geometry works fine, now I play with deformation
of atributes of textures applied to object

ABX

Post a reply to this message

"Chris Huff" wrote:
> You can apply non-linear transformations to isosurfaces by
> modifying their functions.

Deforming functions due to simple mathematical functions can be fine. But
the kinds of transformations I'm talking about are things like for example
animating a character. This can hardly be done by having the user modifying
functions.

> Bicubic patches, height fields, meshes, and other tesselated
> objects could also be deformed fairly easily without
> changing the rendering method very much, but you would have
> to make fairly major additions to the code.

But if it would be as powerful as I wish for, it would be a fairly major
feature.

So far character animation in POV-Ray has always been using robots, or if
organic objects were used, they were not UV-mapped, and if they were, they
were animated in another program and then exported to POV-Ray. I would like
to animate organic, UV-mapped characters in POV-Ray itself. The deformation
features I'm talking about would be an important part of making that
possible.

But is it worth it making such big changes to POV-Ray just to be able to
animate characters? I think yes. I believe good character animation is
considered the highest achievement in the 3d graphics industry. And besides,
the deformations I'm talking about would be useful for *many* other things
too.

> > I suggest that we begin to think of the possibilities of
> > implementing such functions.
>
> You're a little late...Wlodzimierz ABX Skiba has already
> been working on a deform patch, which apparently can work on
> all objects.

And that's great. But I believe the kind of features I
suggested hasn't been discussed.

> Also, Warp is working on a tesselation patch that could be
> used to do similar things.

Tessellation and deformation is not the same thing. Although it would indeed
make deform features even more useful.

> All of this was discussed, including the possibility of using
> warps.

Not well enough I think.

> > But more complicated ways of deforming may be useful. I have
> > thought of a feature that would deform objects by several
> > user-specified regular transforms, each weighted by a 3D
> > field in space.
> ...snip...

You snipped the most important part...

> I think it would be better to define deformations with a warp,
> and implement a new warp that does this. I think it would be
> a good idea to keep a single syntax for deforming both objects
> and textures.

Chris, that doesn't make sense. Textures and objects are entirely different
things and cannot be deformed in the same way. Allow me to explain.

AFAIK textures are deformed in a backward kind-of-way, while meshes are
deformed in a forward kind-of-way. That means that one piece of a texture
can be copied to several locations (think repeat warp). That is not possible
with meshes.

Meshes work the other way around. That means that several pieces of a mesh
can be moved to the same location (think of a mesh snake that bends and
bites its own tail). This is not possible with textures. Texture space can't
overlap itself.

Even if some texture warps can be used on objects too, they will not give
identical perpetuations on textures and meshes. But saying that *all*
deformations should work for both textures and objects is nonsense. That's
what my logic tells me anyway.

I would appreciate if you would reconsider my suggestions so we could maybe
have a more rewarding discussion about them.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a5adc40$1@news.povray.org>, "Wlodzimierz ABX Skiba" 
<abx### [at] abxartpl> wrote:

> > You're a little late...Wlodzimierz ABX Skiba
> 
> simpler is write just ABX :-)

I often copy-paste my own name... :-)


> I have changed my previous syntax for simpler usage I think
> 
> instead next object in pov syntax I have putted deform into object 
> modifiers

This does look like a better syntax. If your technique allowed warps to 
be used as deformations, it would be perfect...maybe a compromise would 
be a "deform" warp, but there will be a lot of duplication, since people 
will want deforms that do the same things as many of the warps.
Is your technique still limited to deformations that can be "reversed"?

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

In article <3a5b1acd@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> Deforming functions due to simple mathematical functions can be fine. 
> But the kinds of transformations I'm talking about are things like 
> for example animating a character. This can hardly be done by having 
> the user modifying functions.

That would be pretty difficult... :-)


> So far character animation in POV-Ray has always been using robots, 
> or if organic objects were used, they were not UV-mapped, and if they 
> were, they were animated in another program and then exported to 
> POV-Ray. I would like to animate organic, UV-mapped characters in 
> POV-Ray itself. The deformation features I'm talking about would be 
> an important part of making that possible.



> But is it worth it making such big changes to POV-Ray just to be able 
> to animate characters? I think yes. I believe good character 
> animation is considered the highest achievement in the 3d graphics 
> industry. And besides, the deformations I'm talking about would be 
> useful for *many* other things too.

I didn't say they wouldn't...


> > You're a little late...Wlodzimierz ABX Skiba has already
> > been working on a deform patch, which apparently can work on
> > all objects.
> 
> And that's great. But I believe the kind of features I
> suggested hasn't been discussed.

The patch is still in a very early stage...don't expect highly complex 
features from the start.


> Tessellation and deformation is not the same thing. Although it would 
> indeed make deform features even more useful.

What I meant was that objects can now be tesselated into meshes, which 
would be easier to deform than ordinary objects, and it might be 
possible to combine the two processes.


> > All of this was discussed, including the possibility of using
> > warps.
> 
> Not well enough I think.

Did you bother to read those threads?


> You snipped the most important part...

Because it was long. :-)


> Chris, that doesn't make sense. Textures and objects are entirely 
> different things and cannot be deformed in the same way. Allow me to 
> explain.

They are not entirely different...it depends on how you approach things.


> AFAIK textures are deformed in a backward kind-of-way, while meshes 
> are deformed in a forward kind-of-way. That means that one piece of a 
> texture can be copied to several locations (think repeat warp). That 
> is not possible with meshes.

Not without re-tesselating the mesh or doing some pretty ugly 
calculations, true...and it depends on how the deformation is 
implemented. It might be possible to tesselate and deform in one step, 
allowing things like the repeat warp.


> Meshes work the other way around. That means that several pieces of a 
> mesh can be moved to the same location (think of a mesh snake that 
> bends and bites its own tail). This is not possible with textures. 
> Texture space can't overlap itself.
> 
> Even if some texture warps can be used on objects too, they will not 
> give identical perpetuations on textures and meshes. But saying that 
> *all* deformations should work for both textures and objects is 
> nonsense. That's what my logic tells me anyway.

I never said that they should all be available for both, or that they 
would be identical. But for many deformations, like turbulence, black 
holes, "twist", etc... it certainly makes sense to use the common syntax.


> I would appreciate if you would reconsider my suggestions so we could 
> maybe have a more rewarding discussion about them.

Are you confusing me with someone else? You seem to be reacting as if I 
said your suggestions weren't any good...

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

"Chris Huff" wrote:
> Are you confusing me with someone else? You seem to be reacting
> as if I said your suggestions weren't any good...

Nah, I just overreacted a bit on "You're a little late..." and "All of this
was discussed". I like to think I'm contributing with new ideas. But maybe I
misunderstood how much of my message those comments applied to.

> > > You're a little late...Wlodzimierz ABX Skiba has already
> > > been working on a deform patch, which apparently can work on
> > > all objects.
> >
> > And that's great. But I believe the kind of features I
> > suggested hasn't been discussed.
>
> The patch is still in a very early stage...don't expect highly
> complex features from the start.

I don't. Actually I don't specifically have that patch in mind.

AFAIU the deform patch works on all objects, but can only do reversible
functions (so far). Also, the deformation will slow down for every ray
hitting the object.

What I'm thinking of is a feature that works on mesh-like objects only. The
good thing is that the deformation only has to be calculated for the
vertices (and vertice normals). That would happen in the parsing, not the
rendering, and thus I think it would be much faster. Also, more complicated
deformations could be done.

> > Tessellation and deformation is not the same thing. Although
> > it would indeed make deform features even more useful.
>
> What I meant was that objects can now be tesselated into meshes,
> which would be easier to deform than ordinary objects.

Exactly.

> All of this was discussed, including the possibility of
> using warps.

> Did you bother to read those threads?

Yes, but what I would like to discuss in *this* thread is not tessellation,
not deformation in general, not even warps in general, but some specific
types of deformations I've thought of. Those are the types I talked about in
the original message.

> > You snipped the most important part...
>
> Because it was long. :-)

Well, can we go back and talk about that specific part?

> > Textures and objects are entirely different things and cannot be
> > deformed in the same way.
>
> They are not entirely different...it depends on how you approach things.

I should make clear that I'm talking about deforming done by moving mesh
vertices. For this type of deform all warps would work "backwards" compared
to textures.

A turbulence warp would look almost the same to the untrained eye.
A black_hole warp would push things away instead of attracting them (except
when inverted).
A repeat warp would slice a mesh and then move all the slices to the same
location!

Some warps would be rather similar for meshes and textures, while others
would work entirely different.

> I never said that they should all be available for both, or
> that they would be identical. But for many deformations, like
> turbulence, black holes, "twist", etc... it certainly makes
> sense to use the common syntax.

Yes, even though they wouldn't give identical results, they'd look quite the
same for both meshes and textures.

But now, I will start a new branch of this thread where I hope my
field_deform idea can be discussed.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

"Rune" wrote:
> I have thought of a feature that would deform objects by several
> user-specified regular transforms, each weighted by a 3D field
> in space.

I thought this method could work for meshes only, since it would do moving
of vertices.

The idea was that each vertice would be transformed by an average of several
regular transform matrixes. The weights of the different matrixes in a given
point would be determined by the values of their fields in that point.

I have though of two field-types: Absolute and relative.

For the absolute type, if for a given point one field had a value of 0.1 and
another field had a value of 0.3, the first field would contribute 10% of
the transformation matrix, while the other field would contribute with 30%.
The remaining 60% would be contributed by the index matrix (a matrix that
doesn't do anything).

For the relative type, if for a given point one field had a value of 0.1 and
another field had a value of 0.3, the first field would contribute 25% of
the transformation matrix, while the other field would contribute with 75%.
The index matrix would never contribute with anything.

The absolute type would be useful when you want one part of your object to
be deformed, and the rest to stay undeformed.

The relative type would be useful for things like bone systems, where every
part of the mesh is deformed, and the original locations of the vertices
should not have any affection at all. In this case you would want to make
sure that your entire mesh is enclosed by the fields.

I still don't know what would be the best way to define the fields with.
Patterns, blob-like fields, maybe both options, or maybe something entirely
different?

I personally think blob-like fields would be best. Remember that possible
patterns would not deform the mesh directly, but only be used as weights for
some linear transformations. Therefore I think the usefulness of complicated
patters to control this is rather limited.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

Rune <run### [at] inamecom> wrote:
> AFAIK meshes, bicubic patches and perhaps iso-surfaces can be transformed
> nonlinearly. Or they could if there was functions in POV-ray that was
> designed to do this...
>
> I suggest that we begin to think of the possibilities of implementing such
> functions. I personally believe that it could improve POV-Ray
significantly
> in some of the areas where it is currently not as powerful as many other
> renderers.
>
> To make such functions useable it would probably be necessary to implement
> several different kinds of those nonlinearly transformations. They could
all
> be contained into a statement such as deform {} or something.
>
> One type of deform could be one that deforms dependent on warps:
>
> deform {
>    warp {...}
> }
>
> As you can sure imagine, this alone would be a very powerful and general
way
> of deforming the supported object.
>
> But more complicated ways of deforming may be useful. I have thought of a
> feature that would deform objects by several user-specified regular
> transforms, each weighted by a 3D field in space. I believe this could be
> used for many things. For example it could be used to make a kind of bone
> structure. One part of a mesh body could be enclosed by one field which
> would be transformed by one linear transform. Another part of the body
would
> by due to another field be transformed by another linear transform. The
> 3D-fields could be defined by patterns, which would be very flexible, but
> probably also rather difficult to master and somewhat slow, or they could
be
> controlled in a way similar to blobs, which would be less flexible, but
> surely easier to understand, and probably faster. Possible syntax:
>
> deform {
>    field_transform {
>       sphere {
>          location, radius, strength,
>          transformations (of the field)
>          apply_transform transform_id (of the mother object, such as mesh)
>       }
>       cylinder { (like sphere, but with end1, end2 instead of location) }
>       ...
>    }
> }
>
> alternative way:
>
> deform {
>    field_transform {
>       field {pattern_id, transform_id}
>       field {pattern_id, transform_id}
>       ...
>    }
> }
>
> The pattern way of field_deform could be used with blob_pattern to achieve
> same functionality I guess, but it would probably still be slower.
>
> Other deform types could possible be made too. What do you think of the
> whole idea?

If you would like to experiment a little with mesh and patch deformations,
without modifying the POV code just yet, perhaps you should look at the
Compressed Mesh macro file in conjunction with Warp's Mesh Compressor:

   http://www.geocities.com/ccolefax

The Compressor and Macros combined give you access to the vertices of meshes
(including bicubic patch models), and you are free to warp these at will.
Using various MegaPOV features (such as eval_pigment), you could even try
out ideas like your pattern warps.

Post a reply to this message

In article <3a5ba55b@news.povray.org>, "Chris Colefax" 
<chr### [at] tagpovrayorg> wrote:

> The Compressor and Macros combined give you access to the vertices of 
> meshes (including bicubic patch models), and you are free to warp 
> these at will. Using various MegaPOV features (such as eval_pigment), 
> you could even try out ideas like your pattern warps.

And don't forget the vwarp() function... ;-)
Actually, combined with the displace warp, vwarp() can do anything 
eval_pigment() could be used for.

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

Chris Huff wrote in message ...
> This does look like a better syntax. If your technique allowed warps to
> be used as deformations, it would be perfect...maybe a compromise would
> be a "deform" warp, but there will be a lot of duplication, since people
> will want deforms that do the same things as many of the warps.
> Is your technique still limited to deformations that can be "reversed"?


yes I think there is compromise between my deform and warps
every deform has defined methods just like methods for objects
this way there could be simple to write type of warp
warp { deform { TYPE PARAMS } }
which call method not assigned to object
and calculate coordinates without duplication of code

I'll check it before release of patch

ABX

Post a reply to this message

Rune <run### [at] inamecom> wrote:
: AFAIK meshes, bicubic patches and perhaps iso-surfaces can be transformed
: nonlinearly. Or they could if there was functions in POV-ray that was
: designed to do this...

  No, meshes and bicubic patches can't be transformed non-linearly.

  If you apply a true non-linear transform to a mesh, that would bend the
individual triangles. This is very hard to do.
  You can, however, move the vertex points (with the triangles still being
flat) to get the impression of a non-linear transform.
  This, however, often introduces artifacts. With a very coarse mesh the
artifacts are more clear (just imagine trying to twist 180 degrees a cube
made of 12 triangles).

  And besides, you can already do this with the PCM macros.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

"Chris Colefax" wrote:
> If you would like to experiment a little with mesh and patch
> deformations, without modifying the POV code just yet,
> perhaps you should look at the Compressed Mesh macro file in
> conjunction with Warp's Mesh Compressor:
>
>    http://www.geocities.com/ccolefax
>
> The Compressor and Macros combined give you access to the
> vertices of meshes (including bicubic patch models), and you
> are free to warp these at will. Using various MegaPOV
> features (such as eval_pigment), you could even try out
> ideas like your pattern warps.

Yes, I've thought of that too. Actually I downloaded the said utilities a
little while ago for that exact reason.

I haven't tried out my ideas yet, but since quite a few
calculations-per-vertice have to be done, I think it will be rather slow in
POV-script. It is worth a try though.

Thanks for the feedback!

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

"Warp" wrote:
> Meshes and bicubic patches can't be transformed non-linearly.

How comes I just knew you would say that?

>   If you apply a true non-linear transform to a mesh, that
> would bend the individual triangles.

That would be a perfect non-linear transform. I'm talking about an
approximation. If things have to be perfect in order to be "true", there's
lots of things POV-Ray and MegaPov can't do:

TRUE atmospheric effects.
TRUE radiosity.
TRUE caustics.
TRUE focal blur.
TRUE fractals.
TRUE area lights.
TRUE motion blur.
...and the list goes on...

How come you never complain when people say these things can be done?

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

I wrote:
> "Warp" wrote:
> >   If you apply a true non-linear transform to a mesh, that
> > would bend the individual triangles.
>
> If things have to be perfect in order to be "true", there's
> lots of things POV-Ray and MegaPov can't do

> How come you never complain when people say these things can
> be done?

Sorry, I think "complain" is not the right English term here. I can't find
the right word right now. Anyway, no offence is intended...

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a5b8dfc@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> I thought this method could work for meshes only, since it would do 
> moving of vertices.

Then it should probably be a specialized feature of meshes, not of a 
"deform" feature...hmm, am I the only one who has noticed there seems to 
be a lot more mesh ideas/patch work being done lately?


> The relative type would be useful for things like bone systems, where 
> every part of the mesh is deformed, and the original locations of the 
> vertices should not have any affection at all. In this case you would 
> want to make sure that your entire mesh is enclosed by the fields.

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'm 
not sure the "deform fields" idea will be very easy to use...but inverse 
kinematics features could be worked into a boned mesh feature, and it 
might be easier to make a new kind of object instead of trying to work 
the additional data/algorithms/syntax into the existing mesh object.


> I still don't know what would be the best way to define the fields with.
> Patterns, blob-like fields, maybe both options, or maybe something 
> entirely different?

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

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

Rune <run### [at] inamecom> wrote:
: How come you never complain when people say these things can be done?

  Usually people ask somethink like "is it possible to _simulate_ motion
blur with povray?".

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?putchar('\n'):m)for(_
=(c>>2)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}  /*- Warp -*/

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3a5d98ee@news.povray.org...
>
>   Usually people ask somethink like "is it possible to _simulate_ motion
> blur with povray?".
>

...as opposed to hurling the monitor across the room or firing it out of a
cannon?

Post a reply to this message

Tom Melly wrote:

> "Warp" <war### [at] tagpovrayorg> wrote in message
> news:3a5d98ee@news.povray.org...
> >
> >   Usually people ask somethink like "is it possible to _simulate_ motion
> > blur with povray?".
> >
> ...as opposed to hurling the monitor across the room or firing it out of a
> cannon?

... or standing in front of the screen and moving one's head back and forth
very fast ? Oh right, that's faking it.

G.

--

**********************
http://www.oyonale.com
**********************
Graphic experiments
Pov-ray gallery

Post a reply to this message

"Chris Huff" wrote:
> "Rune" wrote:
> > I thought this method could work for meshes only, since
> > it would do moving of vertices.
>
> Then it should probably be a specialized feature of meshes,
> not of a "deform" feature...

Whatever. Call it what you want... :)

> hmm, am I the only one who has noticed there seems to
> be a lot more mesh ideas/patch work being done lately?

And you think it's a coincidense?

> > The relative type would be useful for things like bone
> > systems, where every part of the mesh is deformed, and
> > the original locations of the vertices should not have
> > any affection at all. In this case you would want to
> > make sure that your entire mesh is enclosed by the
> > fields.
>
> 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.

> I'm not sure the "deform fields" idea will be very easy
> to use...

There are a whole lot of features in POV-Ray and MegaPov that are not very
easy to use. Usually people learn to use it eventually, especially with the
help from each other.

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

> > I still don't know what would be the best way to define
> > the fields with. Patterns, blob-like fields, maybe both
> > options, or maybe something entirely different?
>
> 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?

:)

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

"Tom Melly" wrote:
> "Warp" wrote:
>
> >   Usually people ask somethink like "is it possible
> > to _simulate_ motion blur with povray?".
>
> ...as opposed to hurling the monitor across the room
> or firing it out of a cannon?

LOL!

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

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

"Chris Huff" wrote:
> The flexibility argument is *why* I think a new object
> type would be useful...

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

Sounds better.

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

I agree.

To define "ownership" of each individual vertex is exactly what I had been
thinking about. However, several bones should be able to own the same
vertex, controlled by weights. That would be a huge amount of data to
generate and to store. That's why I talked about letting strengths control
the weights, so calculations can be done on the fly and don't have to be
stored. This will probably be slower though than just reading stored data,
and identical calculations would have to be done for every frame, which is
kind of a waste. Experiments should be done to find the most advantageous
method.

Anyway, how would you define a bone? I've thought of it as a line between
two points. A field with a user-defined strength and radius would surround
this line segment and affect vertex points and normals near it. They would
be transformed by a transformation assigned to that bone. But actually it
would be better to have *two* transformations assigned to each bone. One for
each end. That's because in reality when we twist our limbs (for example our
wrist), the twisting actually occurs along the whole limb and not just at
the joints. So there should be two transformations assigned to each bone, or
maybe one transformation and one twist amount.

Have you had any thoughts on how a bone would work? I'd be very interested
in this.

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

Never mind! It was a joke kind-of... :)

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a607978@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> To define "ownership" of each individual vertex is exactly what I had 
> been thinking about. However, several bones should be able to own the 
> same vertex, controlled by weights. That would be a huge amount of 
> data to generate and to store.

I was thinking of having each bone have an ID number. Maybe limit the 
number of bones to 255... So for each vertex, you just have to store a 1 
byte number and a floating point weight value for each bone that affects 
it. (ID 0 would be "no bone") Even the ID/weight pairs would be 
identical among many vertices, so they could share them. (there would be 
many vertices that only belong to one bone)


> That's why I talked about letting strengths control the weights, so 
> calculations can be done on the fly and don't have to be stored. This 
> will probably be slower though than just reading stored data, and 
> identical calculations would have to be done for every frame, which 
> is kind of a waste. Experiments should be done to find the most 
> advantageous method.

Also, how do you decide which bone affects the vertices when the fields 
intersect? I think this method would have problems individually 
controlling things like an arm resting next to a flexing leg.


> Anyway, how would you define a bone? I've thought of it as a line 
> between two points. A field with a user-defined strength and radius 
> would surround this line segment and affect vertex points and normals 
> near it. They would be transformed by a transformation assigned to 
> that bone. But actually it would be better to have *two* 
> transformations assigned to each bone. One for each end. That's 
> because in reality when we twist our limbs (for example our wrist), 
> the twisting actually occurs along the whole limb and not just at the 
> joints. So there should be two transformations assigned to each bone, 
> or maybe one transformation and one twist amount.

I was actually thinking of defining them with 4 points: two "home 
position" points and two "current position" points, and POV would 
compute the transformations. That should make things very easy to 
define. Maybe some kind of orientation vector would also be useful, so 
you could have a twisting from bone to bone, but that could probably be 
emulated with multiple parallel bones.

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

"Chris Huff" wrote:
> I was thinking of having each bone have an ID number.
> Maybe limit the number of bones to 255...

That would be enough in most cases but eventually people would complain over
it like they currently do with the limit for color_maps.

> So for each vertex, you just have to store a 1 byte number
> and a floating point weight value for each bone that affects
> it. (ID 0 would be "no bone") Even the ID/weight pairs would be
> identical among many vertices, so they could share them. (there would be
> many vertices that only belong to one bone)

For a high quality mesh wouldn't that be a lot of data indeed?
(I'm not saying it is, I'm just asking.)

> how do you decide which bone affects the vertices when the
> fields intersect?

The fields would have S-curved strengths like blob components. For each
vector all weights would be adjusted to add up to 1 (or 100%).

> I think this method would have problems individually
> controlling things like an arm resting next to a flexing leg.

In the "home pose" limbs not affecting each other would have to be separated
with a little distance between them. For example the home pose could be
designed with the arms going to the sides instead of downwards. It would not
always be a perfect solution though.

I think the best approach is a combination of both methods (storing weights
and calculating weights based on fields). First the fields "roughly"
determine all the weights; then the individual weights can be adjusted and
fine-tuned by the user or by some tool.

I've read about a bone tool that used a similar approach. First fields were
used to assign all weights, then the user could adjust those weights. Seems
sensible.

> > Anyway, how would you define a bone?
>
> I was actually thinking of defining them with 4 points: two "home
> position" points and two "current position" points, and POV would
> compute the transformations.

Two points can't define an object's alignment in space. At least three
points are needed. With four points the twisting can be stored too. That
would be 4 points for the "home position" and 4 points for the current
position. However, the points for the current position doesn't have to be
stored, as they are only relevant for the current frame.

The 4-point alignment system is better than my idea with 2 matrix
transformations, as it's much more effective. The reason I thought of
matrixes is because that would be my own approach if I were to make a bone
system in POV-script. Actually my recent matrix question in p.a-u was about
this. I would use an inverse matrix for the "home pose" and then a forward
matrix for the "current pose".

> That should make things very easy to define. Maybe some kind of
> orientation vector would also be useful, so you could have a
> twisting from bone to bone, but that could probably be emulated
> with multiple parallel bones.

That seems to be an awkward way of doing it. When posing a figure it's
*always* relevant how the limbs are aligned. You can't just specify the
locations of the limbs and then hope they're facing in the right direction.
Go for two points plus two orientation vectors; that's the most sensible
approach.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a60e9e1@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> > Maybe limit the number of bones to 255...
> 
> That would be enough in most cases but eventually people would 
> complain over it like they currently do with the limit for 
> color_maps.

Well, the memory requirements of the ID number would increase by 1 byte 
(I don't think people will complain about ~64K bones any time soon).


> For a high quality mesh wouldn't that be a lot of data indeed?
> (I'm not saying it is, I'm just asking.)

Yes, but much less than a bone ID and weight per vertex. Remember that 
as the number of vertices increases, the number of vertices that can 
share the same information also increases, so the extra storage could be 
a little over 2 extra bytes per vertex on average. Much less than 
per-vertex textures, for example.


> > how do you decide which bone affects the vertices when the
> > fields intersect?
> 
> The fields would have S-curved strengths like blob components. For each
> vector all weights would be adjusted to add up to 1 (or 100%).

That is what I had assumed.


> > I think this method would have problems individually
> > controlling things like an arm resting next to a flexing leg.
> 
> In the "home pose" limbs not affecting each other would have to be 
> separated with a little distance between them. For example the home 
> pose could be designed with the arms going to the sides instead of 
> downwards. It would not always be a perfect solution though.

True, it isn't as bad as I had thought...


> I think the best approach is a combination of both methods (storing 
> weights and calculating weights based on fields). First the fields 
> "roughly" determine all the weights; then the individual weights can 
> be adjusted and fine-tuned by the user or by some tool.
> 
> I've read about a bone tool that used a similar approach. First 
> fields were used to assign all weights, then the user could adjust 
> those weights. Seems sensible.

This would seem to be a modeller feature used to set up the bone 
data...it could be used to set "default" values in POV, but you should 
be able to override those values. It could be something that happens 
"behind the scenes" when that data isn't specified.


> > I was actually thinking of defining them with 4 points: two "home
> > position" points and two "current position" points, and POV would
> > compute the transformations.
> 
> Two points can't define an object's alignment in space. At least three
> points are needed. With four points the twisting can be stored too. That
> would be 4 points for the "home position" and 4 points for the current
> position. However, the points for the current position doesn't have to be
> stored, as they are only relevant for the current frame.

But we aren't defining an object's alignment. And some information could 
be inferred from the vertex's position relative to the bone's initial 
position...I think. Maybe. Anyone who actually knows something about the 
algorithms behind this stuff is welcome to chip in... ;-)


> That seems to be an awkward way of doing it. When posing a figure 
> it's *always* relevant how the limbs are aligned. You can't just 
> specify the locations of the limbs and then hope they're facing in 
> the right direction.
> Go for two points plus two orientation vectors; that's the most sensible
> approach.

I think this would be needed to do joints correctly anyway...when you 
rotate your arm, your elbow doesn't slide like a ball joint, your whole 
upper arm twists around the bone.
However, what should the orientation vectors be? Unit-length vectors 
indicating direction (maybe non-unit length to indicate some weighting 
value?), or a position vector indicating a point next to the bone?

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

"Chris Huff" wrote:
> "Rune" wrote:
> Well, the memory requirements of the ID number would increase
> by 1 byte (I don't think people will complain about ~64K bones
> any time soon).

That's what I was thinking of too. :)

> > For a high quality mesh wouldn't that be a lot of data
> > indeed? (I'm not saying it is, I'm just asking.)
>
> Yes, but much less than a bone ID and weight per vertex.

But isn't that what we're talking about? I mean, sure optimisations could be
done, but we're talking about a bone ID and weight per vertex, as opposed to
field-based weights, right?

> > In the "home pose" limbs not affecting each other would
> > have to be separated with a little distance between them.
>
> True, it isn't as bad as I had thought...

What? When? Why?

> > I've read about a bone tool that used a similar approach.
> > First fields were used to assign all weights, then the user
> > could adjust those weights. Seems sensible.
>
> This would seem to be a modeller feature used to set up the
> bone data...it could be used to set "default" values in POV,
> but you should be able to override those values. It could be
> something that happens "behind the scenes" when that data
> isn't specified.

That's what I meant. You should be able to specify weights for just some of
the vertices, and for the rest of the vertices the fields would be used to
assign "default values".

> > Two points can't define an object's alignment in space.
>
> But we aren't defining an object's alignment.

Yes we are! That's what posing a character is all about!
Ask anybody who has posed a figure if it's enough to specify where the hand
is, or if it is also necessary to specify in which direction the palm is
facing.

> And some information could be inferred from the vertex's
> position relative to the bone's initial position...I think.

NO! These must be completely independent of each other!
If you rotate a whole pose 180 degrees its alignment relative to the home
pose is different, but that shouldn't make any difference! The home pose and
the current pose could be miles apart from each other and it should still
work.

> Maybe. Anyone who actually knows something about the
> algorithms behind this stuff is welcome to chip in... ;-)

I've worked a lot with things like this, although only in POV-script. I feel
I know something about it.

> > Go for two points plus two orientation vectors; that's
> > the most sensible approach.
>
> I think this would be needed to do joints correctly anyway...
> when you rotate your arm, your elbow doesn't slide like a
> ball joint, your whole upper arm twists around the bone.

As I said earlier. :)

"That's because in reality when we twist our limbs (for example
our wrist), the twisting actually occurs along the whole limb
and not just at the joints."

> However, what should the orientation vectors be? Unit-length
> vectors indicating direction

That's what I thought.

> (maybe non-unit length to indicate some weighting value?),

No, those two things have little to do with each other, so I think it's not
a good idea.

> or a position vector indicating a point next to the bone?

This is basically the same as the unit-length idea isn't it? I go for unit
lengths.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a6190cf@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> > Yes, but much less than a bone ID and weight per vertex.
> 
> But isn't that what we're talking about? I mean, sure optimisations 
> could be done, but we're talking about a bone ID and weight per 
> vertex, as opposed to field-based weights, right?

But the bone ID and weight can be packaged into one piece of 
information. The vast majority of vertices will belong to a single bone 
and use the same weight, so the bone-ID/weight pairs can be kept in an 
array (with no duplicates) and accessed with ID numbers, so all you have 
to store per-vertex is a couble data-ID numbers (usually one, only more 
than one ID when multiple bones influence the vertex), and separately an 
array of bones, and an array of bone-ID/weight pairs. The total memory 
usage for an ordinary use of this feature will be far less than a list 
of bone-ID/weight pairs for each vertex.


> > True, it isn't as bad as I had thought...
> 
> What? When? Why?

I had been thinking there would be problems when the bone fields moved 
and intersected each other, but they wouldn't...


> > I think this would be needed to do joints correctly anyway...
> > when you rotate your arm, your elbow doesn't slide like a
> > ball joint, your whole upper arm twists around the bone.
> 
> As I said earlier. :)
> 
> "That's because in reality when we twist our limbs (for example
> our wrist), the twisting actually occurs along the whole limb
> and not just at the joints."

Hey, it was late, I was tired. :-)


> > (maybe non-unit length to indicate some weighting value?),
> 
> No, those two things have little to do with each other, so I think 
> it's not a good idea.

After more thought, this value wouldn't be necessary...


> > or a position vector indicating a point next to the bone?
> 
> This is basically the same as the unit-length idea isn't it? I go for 
> unit lengths.

One could be calculated from the other, the same information is being 
specified, but one might be easier to use than the other. Don't want 
people forced to use macros so they can input the data the way they 
want...but unit-length vectors seem to make more sense.

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

"Chris Huff" wrote:
> The vast majority of vertices will belong to a single bone
> and use the same weight,

The weights are relative, so vertices belonging to one bone only means that
the weight of that bone is 100%.

> so the bone-ID/weight pairs can be kept in an array (with
> no duplicates) and accessed with ID numbers, so all you
> have to store per-vertex is a couble data-ID numbers
> (usually one, only more than one ID when multiple bones
> influence the vertex), and separately an array of bones,
> and an array of bone-ID/weight pairs.

I don't understand that method. Since the weight of a bone is relative to
the weights of other bones, it does't make sense to single out individual
bone-ID/weight pairs. Besides, the probability that several vertices share
the same bone-ID/weights is minimal except in the case where a vertex
belongs to just one bone. Perhaps this method could be used:

For vertices that are influenced by more than one bone, store all relevant
bone-ID/weight pairs for that vertex. For vertices that are influenced by
one bone only, just store the bone-ID. The weight is always 100% in those
cases, so it doesn't have to be stored.

Also, some vertices could have no bone information at all. In that case the
field-weights would be used. This would have the advange that much less bone
data would have to be stored, and the disadvantage that the field-based
weights would have to be calculated for every frame. I don't know if that
would be slow?

> I had been thinking there would be problems when the bone
> fields moved and intersected each other, but they wouldn't...

Correct.

> but unit-length vectors seem to make more sense.

I agree.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a61d051@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> The weights are relative, so vertices belonging to one bone only means 
> that the weight of that bone is 100%.

The vast majority would have a weighting of 1, then...but that 1 will 
only need to be stored once per bone.


> For vertices that are influenced by more than one bone, store all 
> relevant bone-ID/weight pairs for that vertex. For vertices that are 
> influenced by one bone only, just store the bone-ID. The weight is 
> always 100% in those cases, so it doesn't have to be stored.

That would...not be easy to code. You would have to make room for the 
data anyway. If the ID/weight pair method is used, each vertex could 
store an array of IDs of those pairs.
The method you suggest would require all vertices to have 2 pointers, 
one to an array of bone IDs and one to an array of weights, actually 
more memory for the simplest case vertices (you will have to allocate a 
pointer to the array of weights whether you use it or not).

While the weight for the single-bone case isn't needed, because it is 
always 1, it would only have to be stored once for each bone, so the 
memory usage would be quite low for meshes with lots of single-bone 
vertices. Say n vertices share a single bone: storing one bone-ID/weight 
pair, n pointers to a pair ID, and a n ID's (one of each per vertex) is 
less than storing n bone IDs, n pointers to those IDs, and n unused 
pointers to a nonexistent weight value. One wastes 1 float value, the 
other wastes n pointers to float values.


> Also, some vertices could have no bone information at all. In that 
> case the field-weights would be used. This would have the advange 
> that much less bone data would have to be stored, and the 
> disadvantage that the field-based weights would have to be calculated 
> for every frame. I don't know if that would be slow?

I was thinking all the information would be stored, and the fields would 
simply initialize the data...this would make cleaner code and be a 
little (maybe a lot) faster. The information wouldn't have to exist for 
long (it wouldn't be needed in the rendering stage, just in the parse 
stage), and I don't think it will be a lot anyway (an average of a 
little over 1 ID and 1 pointer per vertex, plus lists of bones and 
bone-ID/weight pairs).

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

Let me see if I understand your storing system.
There's an array full of bone-id/weight pairs with no duplicates.
Each element in the array stores exactly one bone-id/weight pair.
For each vertex in the mesh there's one or several pointers bone-id/weight
pairs.
Is that right?

What I don't understand is how it makes sense to store individual weights.
The weights are *relative to other weights* so storing just one
bone-id/weight pair at a time makes no sense.
Or does it? Can you explain?

> I was thinking all the information would be stored, and
> the fields would simply initialise the data...this would
> make cleaner code and be a little (maybe a lot) faster.

Yes, maybe that is better.

> The information wouldn't have to exist for long (it wouldn't
> be needed in the rendering stage, just in the parse stage)

I know! I already mentio- ... Never mind.

Anyway, the data would be stored as a part of the scene/include file, just
like mesh vertices are, right? But how would the data be generated?

We agree that fields could initialise the data, but how would this be done?
External utility? I don't think that's a good idea.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a6227e4$1@news.povray.org>, "Rune" 
<run### [at] inamecom> wrote:

> Let me see if I understand your storing system.
> There's an array full of bone-id/weight pairs with no duplicates.
> Each element in the array stores exactly one bone-id/weight pair.
> For each vertex in the mesh there's one or several pointers 
> bone-id/weight pairs.
> Is that right?

Close. There is also an array of bones themelves, the bone IDs are just 
indexes for this array. And each vertex has an array of indexes for the 
array containing the bone ID/weight pairs.


> What I don't understand is how it makes sense to store individual 
> weights.
> The weights are *relative to other weights* so storing just one
> bone-id/weight pair at a time makes no sense.
> Or does it? Can you explain?

The weights for each vertex will always total to 1, is that what you 
mean?
The weight value determines the influence of a specific bone, right? So 
it makes sense to pair them up..."xx% of the influence comes from y 
bone". There will be duplicates in this information, especially when 
several vertices belong to one bone and only that bone, so those 
duplicates can be eliminated by making a separate list of data pairs and 
referring to the pairs in that list by ID number.
I'm not really certain what you are asking...each vertex is affected by 
each bone that "owns" it by a specific amount depending on proximity to 
that bone and other bones that "own" it, right? POV would calculate the 
effect of each bone, and add the bone ID and weight to the array for 
that vertex.


> I know! I already mentio- ... Never mind.

Er, ok. :-)


> Anyway, the data would be stored as a part of the scene/include file, 
> just like mesh vertices are, right? But how would the data be 
> generated?
> 
> We agree that fields could initialise the data, but how would this be 
> done?
> External utility? I don't think that's a good idea.

No, it would be done in the parsing stage. The bone and vertex 
information would be parsed in, and the bone fields would be used to 
"fill in" the unspecified weights. The data would then be passed to the 
code that actually moved the vertices, which won't care *how* the data 
was generated. That bit of code (and the one-field code) may be useful 
somewhere else separately, no real reason to make them integral with 
each other. It should also be a little easier to maintain.
From the user's perspective, it just lets them specify everything, 
nothing, or just a few points, while POV automatically computes anything 
they leave out with no extra syntax.

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

Let's see if we understand each other so far.

In the scene file there will be a block of bone information.
Maybe like this (like you suggested):

mesh {
   boned_mesh {
      mesh_data...
      bone_data...
   }
}

Or maybe like this (as I find more logic):

mesh {
   mesh_data...
   bone_deform {bone_data...}
}

A bone consists of an ID number, two times two points and two vectors and a
radius and a strength. Maybe like:

bone_deform {
   bone {
      ID-number,
      home_end1, home_dir1, home_end2, home_dir2,
      curr_end1, curr_dir1, curr_end2, curr_dir2,
      radius, strength
   }
   bone {...}
}

The fields defined by the strengths and radii of the bones will control how
much each vertex is influenced by each bone.

> From the user's perspective, it just lets them specify everything,
> nothing, or just a few points, while POV automatically computes
> anything they leave out with no extra syntax.

Yes, the user can specify the weights for individual vertices to gain
greater control. But what would the syntax for this be?

bone_deform {
   weights {
      ???
   }
}

One way or the other we will end up having one weight for each bone for each
vertex. This information may be stored in a compact way as we've discussed
earlier.

This information will be used to deform the mesh by moving the vertices
according to the bones and the weights. After the deformation has happened,
all the bone information can be deleted again. In the rendering stage the
mesh will render just like any other mesh.

As you see, the only real question I have now is about the user-defined
weight data. But this is only provided that we agree about all the rest,
which I doubt... :)

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

Suddenly the discussion stopped and I wondered why.

I wrote:
> As you see, the only real question I have now is about the
> user-defined weight data. But this is only provided that we
> agree about all the rest, which I doubt... :)

Oops, I realise now that this could be completely misunderstood!

What I meant was that in case we didn't agree about the rest, I would have
not just one, but many questions left. I certainly *didn't* mean that I only
wanted to discuss further if we agreed!

So if you have anything to say, I'd be glad to continue the discussion :)

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a644a6a@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> Oops, I realise now that this could be completely misunderstood!
> 
> What I meant was that in case we didn't agree about the rest, I would 
> have not just one, but many questions left. I certainly *didn't* mean 
> that I only wanted to discuss further if we agreed!

That wasn't it...yesterday was Monday. School. ;-)

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

In article <3a633135@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> Let's see if we understand each other so far.
> 
> In the scene file there will be a block of bone information.
> Maybe like this (like you suggested):
...snip...

I would prefer the boned_mesh syntax, because it will let you specify 
data along with each vertex instead of separating it all out into a 
deform:
boned_mesh {
    bone_list {bone{} bone{} ...}
    triangle {P1, P2, P3// normals when smooth_triangle is used
        bones {[Bone1, Weight] [Bone2, Weight] [Bone3...}
        // the Weight values would be optional
    }
}

And this would be useable as a independant object and as a "mix in" for 
meshes. (This is a separate idea I have been thinking of...letting you 
mix triangle-based objects like height fields or bezier patches along 
with the triangles.)
A more compact syntax for machine generation could also be added 
(analogous to mesh2).


> A bone consists of an ID number, two times two points and two vectors 
> and a radius and a strength. Maybe like:
> bone_deform {
>    bone {
>       ID-number,
>       home_end1, home_dir1, home_end2, home_dir2,
>       curr_end1, curr_dir1, curr_end2, curr_dir2,
>       radius, strength
>    }
>    bone {...}
> }
> 
> The fields defined by the strengths and radii of the bones will 
> control how much each vertex is influenced by each bone.

That is something I haven't thought much about...the simplest way would 
be to let the user specify the ID number, but I would prefer a cleaner 
method letting the user name each bone (the names would only be valid 
within the boned_mesh block, of course) and refer to them by name, the 
names would then be translated to ID numbers by the parser. I don't know 
how to implement this, though...


> This information will be used to deform the mesh by moving the 
> vertices according to the bones and the weights. After the 
> deformation has happened, all the bone information can be deleted 
> again. In the rendering stage the mesh will render just like any 
> other mesh.

Exactly.


> As you see, the only real question I have now is about the user-defined
> weight data. But this is only provided that we agree about all the rest,
> which I doubt... :)

Well, I can't think of a good way to do it with the bone_deform 
syntax...maybe specify the weights in the same order as the triangles, 
but that seems to be a really ugly and problem-prone solution.

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

"Chris Huff" wrote:
> I would prefer the boned_mesh syntax, because it will let
> you specify data along with each vertex instead of separating
> it all out into a deform

Ok.

> I would prefer a cleaner method letting the user name each bone

Fine with me.

I feel we have reaches a point where our exchanging of thoughts and ideas
has resulted in us agreeing about mostly everything about the bone feature.
That's nice!

So now we just need someone to code it. Hehe...

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

"Chris Huff" wrote:
> yesterday was Monday. School. ;-)

:)

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message