I have found two bugs in the Windows version of povray 3.1g.  Both bugs
pertain to individually-textured triangles and smooth_triangles inside
of mesh objects.

This first bug is the failure of individually-textured triangles
to texture properly when the mesh that they are a part of is
transformed.  Quite simply, the texture is *not* transformed along
with the mesh.  The scene code below declares an mesh object and then
invokes two instances of it.  Some of the triangles are textured by
the overall texture assigned to the object, and they appear the same
in each object.  The other triangles are individually-textured
within the mesh, and do *not* appear the same.  This should not be,
according to the docs.  I changed the triangles to smooth_triangles
and the same thing happens.

The other bug causes a crash when all of the following are true:

1.  A mesh has triangles with individually-assigned textures.
2.  Those textures use a pattern in their pigment.
3.  No color_map is specified for the pigment.

These conditions can be met in the code below by commenting out
the line that declares the color_map in the texture.

This should cause the renderer to use the default color_map, but
instead povwin 3.1g crashes when the first ray hits one of the
offending triangles.  The same bug occurs if the triangles are
changed to smooth_triangles.  I don't know if it happens for all
patterns, but it does for the granite pattern.

These are serious bugs, not only for the obvious reasons, but
also because they were present in the DOS version of POV-Ray 3.0,
and are likely to exist in other versions as well.  I tried reporting
the bugs back then, but apparently no action was taken.

Anyway, here is the code which makes the bugs manifest:

// START OF SCENE CODE

#local Sample=texture {
  pigment { granite
// comment out the line below to get the second bug I mentioned
    color_map { [0 rgb 0][1 rgb 1] }
  }
}

#local Octa = mesh {
  triangle { x, y, z }
  triangle {-x, y, z texture { Sample} }
  triangle { x,-y, z texture { Sample} }
  triangle {-x,-y, z }
  triangle { x, y,-z texture { Sample} }
  triangle {-x, y,-z }
  triangle { x,-y,-z }
  triangle {-x,-y,-z texture { Sample} }
  texture { Sample }
}

object { Octa translate -x }
object { Octa translate  x }

camera {
  location <.1,1,11>
  direction z*2.5
  look_at 0
}
  
light_source { <0,10,1000> rgb 1 }

// END OF SCENE CODE

Post a reply to this message

John VanSickle wrote:
> 
> I have found two bugs in the Windows version of povray 3.1g.  Both bugs
> pertain to individually-textured triangles and smooth_triangles inside
> of mesh objects.
> 
> This first bug is the failure of individually-textured triangles
> to texture properly when the mesh that they are a part of is
> transformed.  Quite simply, the texture is *not* transformed along
> with the mesh.  The scene code below declares an mesh object and then
> invokes two instances of it.  Some of the triangles are textured by
> the overall texture assigned to the object, and they appear the same
> in each object.  The other triangles are individually-textured
> within the mesh, and do *not* appear the same.  This should not be,
> according to the docs.  I changed the triangles to smooth_triangles
> and the same thing happens.

This was reported on 03-23-1999 by Gordon and the Pov team should be aware
of it. In fact you commented on it on 04-24-1999 mentioning that the bug
still exsisted in Pov v3.1e but it doesn't hurt to remind them I suppose.

-- 
Ken Tyler

Post a reply to this message

On Sat, 07 Aug 1999 21:20:55 -0400, John VanSickle
<van### [at] erolscom> wrote:

>This first bug is the failure of individually-textured triangles
>to texture properly when the mesh that they are a part of is
>transformed.  Quite simply, the texture is *not* transformed along
>with the mesh.  

This is a scary side-effect of the fact that the same instance of 
the texture is shared by all triangles it is referenced in.  
Unfortunately, the transformation that is to be applied to a
texture is a part of the texture itself, so you clearly couldn't
just transform such textures at parse time.  They need to be
transformed at render time, which is not exactly a walk in the
park given how things are put together.  It can be done, though.

>The other bug causes a crash when all of the following are true:
>
>1.  A mesh has triangles with individually-assigned textures.
>2.  Those textures use a pattern in their pigment.
>3.  No color_map is specified for the pigment.

This is another case of Post_Texture not getting called.  Post_Pigment
is responsible for setting a default color_map when one hasn't been
applied, but it isn't called for mesh textures.  I haven't
investigated the ramifications of calling it twice for the same
instance of a texture.  If that is safe, then the fix would be
trivial.  If not, it would be straightforward to make textures carry a
flag stating whether they had been already posted.

Post a reply to this message

Ken wrote:
> 
> John VanSickle wrote:
> >
> > I have found two bugs in the Windows version of povray 3.1g.  Both
> > bugs pertain to individually-textured triangles and smooth_triangles
> > inside of mesh objects.
> >
> > This first bug is the failure of individually-textured triangles
> > to texture properly when the mesh that they are a part of is
> > transformed.  Quite simply, the texture is *not* transformed along
> > with the mesh.  The scene code below declares an mesh object and
> > then invokes two instances of it.  Some of the triangles are
> > textured by the overall texture assigned to the object, and they
> > appear the same in each object.  The other triangles are
> > individually-textured within the mesh, and do *not* appear the same.
> > This should not be, according to the docs.  I changed the triangles
> > to smooth_triangles and the same thing happens.
> 
> This was reported on 03-23-1999 by Gordon and the Pov team should be
> aware of it. In fact you commented on it on 04-24-1999 mentioning that
> the bug still exsisted in Pov v3.1e but it doesn't hurt to remind them
> I suppose.

Since it popped up again in 3.1g, it's possible that they forgot, or
whoever's turn it was to monitor the group was out that day.

Regards,
John

Post a reply to this message

This bug also appears in Pov3.1g for dos.

Post a reply to this message

I've found a way around both bugs.  For the crash bug, don't leave it up
to Pov to define a colour map, do it yourself, even if it's the same as
the default colour map.  For the other one, declare your mesh as a macro
and then invoke the macro inside an object statement.

Post a reply to this message

Steven Jones wrote:
> 
> I've found a way around both bugs.  For the crash bug, don't leave it
> up to Pov to define a colour map, do it yourself, even if it's the
> same as the default colour map.

Well, yeah, but it's still a bug.

> For the other one, declare your mesh as a macro and then invoke the
> macro inside an object statement.

Re-declaring the mesh (which is all that your procedure would use)
defeats one of the primary reasons for using the mesh:  Memory savings.
I have a model made of 21 mesh objects, for a total of 30,336 triangles.
If I had re-declared each mesh, each of these models uses 4.5 megs of
memory.  If I copy the meshes, each model uses about 32K or so.

Regards,
John

Post a reply to this message

Ron Parker wrote:
> 
> On Sat, 07 Aug 1999 21:20:55 -0400, John VanSickle
> <van### [at] erolscom> wrote:
> 
> >This first bug is the failure of individually-textured triangles
> >to texture properly when the mesh that they are a part of is
> >transformed.  Quite simply, the texture is *not* transformed along
> >with the mesh.
> 
> This is a scary side-effect of the fact that the same instance of
> the texture is shared by all triangles it is referenced in.
> Unfortunately, the transformation that is to be applied to a
> texture is a part of the texture itself, so you clearly couldn't
> just transform such textures at parse time.  They need to be
> transformed at render time, which is not exactly a walk in the
> park given how things are put together.  It can be done, though.
> 
This is fixed in UVPov (and maybe in the SuperPatch... if all of my
mesh changes made it there?).  The solution is to duplicate all of
the textures once they have all been read in and hashed... it is a
final step after reading in the mesh but before reading the object
modifiers.

Old:
  for (i = 0; i < number_of_textures; i++)
  {
    Object->Data->Textures[i] = Copy_Texture_Pointer(Textures[i]);

    /* now free the texture, in order to decrement the reference count */
    Destroy_Textures(Textures[i]);
  }

Or maybe the old was:
  for (i = 0; i < number_of_textures; i++)
  {
    Object->Data->Textures[i] = Textures[i];
  }

Either way, the new is:
  for (i = 0; i < number_of_textures; i++)
  {
    Object->Data->Textures[i] = Copy_Textures(Textures[i]);

    /* now free the texture, in order to decrement the reference count */
    Destroy_Textures(Textures[i]);
  }


-Nathan

Post a reply to this message

Nathan Kopp wrote:
> 
> This is fixed in UVPov (and maybe in the SuperPatch...

The problem persists in my version of UVPov (5.4)
The following scene exhibits the problem in both UVPov and official 3.1g (and
causes the malloc error in the Superpatch).

//Begin scene

camera{orthographic location <0,.7,-5> up y*4*.75 right x*4 look_at y*.7}
light_source{-20*z color 1}

#declare Tex=
texture{pigment{spherical color_map{[.3 rgb 1][.3 rgb x]}}}

#declare Obj=
mesh{
triangle{-x*.5,y,x*.5 texture{Tex}}
triangle{-z*.5,y,z*.5 texture{Tex}}
}

object{Obj}
object{Obj translate x}
object{Obj translate -x}

Post a reply to this message

Margus Ramst wrote:
> 
> The problem persists in my version of UVPov (5.4)
> The following scene exhibits the problem in both UVPov and official 3.1g (and
> causes the malloc error in the Superpatch).

Actually, it's not the same problem...  similar... it's actually a new bug
that was introduced by my fix.

The problem is this:  Textures are shared by all instances of a mesh object.
If you comment out the 3rd instance, you'll see that the texture is
transformed to the right.  All of the transforms are composed.  oops.

The solution is to move the Textures outside of the "Data" struct in the mesh
object.  The "Data" struct is shared by all instances of the object, and
it is not good to share textures if you want them to be transformed for
each object.

Ok... it's fixed on my computer now.  It will be fixed in the next release
of UVPov.

-Nathan

Post a reply to this message