Well, I've gone and done it.  After avoiding taking the plunge for so long,
I've gone and started writing my own patch.  In my patch, I'm attempting to
deform meshes based upon simulations to allow a cloth-style simulation of
non-rectangular surfaces.

For the most part, it's going pretty well.  However, in working with it,
I've found that the vertices of meshes are stored as single-precision
values.  This has caused a lot of problems, since the precision of the
simulation, which requires a lot of small increments, is compromised by
this.  Does anyone out there who's worked in the code more than I know why
meshes are stored this way?  I'd think that you'd want to store vertices as
double precision for the same reason that you store the locations of other
objects as doubles.

So, anyone know why this is the way it is?

Geoff

Post a reply to this message

Geoff Wedig <wed### [at] darwinepbicwruedu> wrote:
: So, anyone know why this is the way it is?

  This is what I have wondered as well. The only reason I can think of
is memory saving.
  As this is not currently really necessary double precision could be feasible.
  You can change the SNGL type to double (in frame.h) and see if it helps.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

It's not related to your question, but how are you doing the simulation?  How
small are your increments and why do they have to be small?

David Buck
Simberon Inc.

Geoff Wedig wrote:

> Well, I've gone and done it.  After avoiding taking the plunge for so long,
> I've gone and started writing my own patch.  In my patch, I'm attempting to
> deform meshes based upon simulations to allow a cloth-style simulation of
> non-rectangular surfaces.
>
> For the most part, it's going pretty well.  However, in working with it,
> I've found that the vertices of meshes are stored as single-precision
> values.  This has caused a lot of problems, since the precision of the
> simulation, which requires a lot of small increments, is compromised by
> this.  Does anyone out there who's worked in the code more than I know why
> meshes are stored this way?  I'd think that you'd want to store vertices as
> double precision for the same reason that you store the locations of other
> objects as doubles.
>
> So, anyone know why this is the way it is?
>
> Geoff

Post a reply to this message

David Buck <dav### [at] simberoncom> wrote:

> It's not related to your question, but how are you doing the simulation?  How
> small are your increments and why do they have to be small?

More or less the standard cloth simulation approach using a springlike
equation between points.  The increments don't have to be small, but larger
increments tend to cause unrealistic stretching and other errors. The
smaller the increments, the less likely there'll be an error where something
misses something else.

So far, other simulation glitches have had more of an effect on the values
than this, actually.  There's a lot of parameters to tweak.  But I've seen
this sort of thing in other simulations, so I know it might be a problem
later.

What I'm thinking of doing is using the standard vector while doing the
simulation, then just change it to the single precision when copying the
final results into the mesh.  It's not ideal, but it'd probably work.

Geoff

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:

> Geoff Wedig <wed### [at] darwinepbicwruedu> wrote:
> : So, anyone know why this is the way it is?

>   This is what I have wondered as well. The only reason I can think of
> is memory saving.
>   As this is not currently really necessary double precision could be feasible.
>   You can change the SNGL type to double (in frame.h) and see if it helps.

Yeah, but that'll change things in lots of other places.  I don't want to
make that kind of global switch.  I could just change it in the mesh code,
but I don't know the code very well, yet, and worried that it'd introduce
subtle bugs.

What I'm probably going to do is simulate using doubles.  After the
simulation is done, I can copy them into the float vector that the mesh
uses.  That way, I get the advantages of the extra precision when it's
necessary, but don't have to worry about it later.

Geoff

Post a reply to this message

Geoff Wedig wrote in message <3b39c23a@news.povray.org>...
> I've found that the vertices of meshes are stored as single-precision
> values.
> ...
> So, anyone know why this is the way it is?


I don't know source for meshes but I've idea that it is automatically converted
to single float to save memory by eliminating (equal after conversion)
neigbours. Perhaps it is some kind of variable EPSILON value. But it is just
idea becouse I don't know anything about storing vertices of mesh.

--
#macro Sig(A,B,X)_(A,B)_(B,X)_(X,A)#end#macro _(A,B)cylinder{<A.x,A.y,3>,<B.u,
B.v,3>.1,9}#end global_settings{max_trace_level 9}light_source{0 1}camera{up y
*4right-3*x}blob{_(<3,1>,<1,-5>)_(<2,-2>,<4,-2>)Sig(x,<-1,1.5>,<1,3>)_(z-1,z-4
)pigment{rgb 1}}box{-3 3pigment{rgb 0}finish{reflection 1}hollow} // POV-Ray31

Post a reply to this message

Wlodzimierz ABX Skiba <abx### [at] abxartpl> wrote:

> Geoff Wedig wrote in message <3b39c23a@news.povray.org>...
>> I've found that the vertices of meshes are stored as single-precision
>> values.
>> ...
>> So, anyone know why this is the way it is?


> I don't know source for meshes but I've idea that it is automatically converted
> to single float to save memory by eliminating (equal after conversion)
> neigbours. Perhaps it is some kind of variable EPSILON value. But it is just
> idea becouse I don't know anything about storing vertices of mesh.

Hmm, I might look to see, but I don't think so.  The parse routine for the
mesh2, at least, doesn't do anything so clever as far as I've seen.  Maybe
mesh does, though.

Right now, that's the least of my worries.  I'm getting some really weird
behaviors which culminate in a segmentation fault from the triangles.  Some
kind of data corruption.  At this point, given the nature of my output, I'm
starting to suspect the compiler, which isn't a good thing.

Geoff

Post a reply to this message

Geoff Wedig <wed### [at] darwinepbicwruedu> wrote:
: Right now, that's the least of my worries.  I'm getting some really weird
: behaviors which culminate in a segmentation fault from the triangles.  Some
: kind of data corruption.  At this point, given the nature of my output, I'm
: starting to suspect the compiler, which isn't a good thing.

  If you start messing with meshes (pun intended), you'll get problems :)

  I still don't know why my tesselation patch (which tesselates an object
into a mesh) doesn't work. There's something REALLY odd with POV-Ray's mesh
code, and nobody seems to fully understand it.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:

> Geoff Wedig <wed### [at] darwinepbicwruedu> wrote:
> : Right now, that's the least of my worries.  I'm getting some really weird
> : behaviors which culminate in a segmentation fault from the triangles.  Some
> : kind of data corruption.  At this point, given the nature of my output, I'm
> : starting to suspect the compiler, which isn't a good thing.

>   If you start messing with meshes (pun intended), you'll get problems :)

>   I still don't know why my tesselation patch (which tesselates an object
> into a mesh) doesn't work. There's something REALLY odd with POV-Ray's mesh
> code, and nobody seems to fully understand it.

Oh, I'm getting there, slowly.  The mesh code isn't too hard to understand,
with a few eceptions.  I've already found one bug in there, or at least
something that could cause bugs (the initialize routine doesn't set all
the variables to null values, but I'm not sure if it affects anything in the
POV code, though it did affect *mine*)

What I'm thinking of doing is getting rid of the meshes interally.  I can do
my simulations on vertices with velocities and masses, then copy the results
into a mesh.  There's really no reason to use the mesh until the simulation
is finished.  Hopefully that'll clear up this memory issue.

Geoff

Post a reply to this message