I'm not sure how to describe what is happening, other than that objects 
inside unions have their textures translated in odd ways by the 
Center_Trans macro.

Consider this scene:
--------------------
#include "transforms.inc"

camera {
	location -z*2
	look_at 0
}

#declare tube = union {
	cylinder {
		0, y, 1/10
		pigment {
			gradient y
			color_map {
				[0 color rgb x]
				[1 color rgb z]
			}
		}
	}
}

object {tube Center_Trans(tube, x+y+z) rotate z*90 translate y/4}
object {tube rotate z*90 translate y*0.5+x*0.5}

#declare tube2 = cylinder {
	0, y, 1/10
	pigment {
		gradient y
		color_map {
			[0 color rgb y]
			[1 color rgb 1]
		}
	}
}

object {tube2 Center_Trans(tube2, x+y+z) rotate z*90 translate -y/4}
object {tube2 rotate z*90 translate -y*0.5+x*0.5}

light_source {
	<1,1,-1>*10 color rgb 1
}
--------------------

Rendered in 3.6, both pairs of tubes are identical.

Rendered in 3.7, we can see that the upper tube's texture is translate 
wrt it's pair's texture, despite them being identical objects.  The only 
difference is that the one object is translated via Center_Trans(), 
while the other is not.

The second pair of tubes, in which the cylinder itself is the object 
(rather than being contained inside a union), does not exhibit this bug.

This leads me to believe that the problem is the combination of 
Center_Trans(), unions, and textures.  But I'm not sure why, or exactly how.

Sorry I couldn't give more detailed info, but this one was quite tricky 
for me to track down.

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Was anybody able to at least reproduce this bug on their system?

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> Was anybody able to at least reproduce this bug on their system?
>
> --
> ...Ben Chambers
> www.pacificwebguy.com

Yes, although beta 24 has now expired. I noticed a possibly similar problem last
week with patterns used in media densities appearing to be translated
incorrectly when their parent object was transformed with a Shear_Trans or
Matrix_Trans call, but I was unable to reduce it to a minimal scene.

Tom

Post a reply to this message

"Chambers" <ben### [at] pacificwebguycom> schreef in bericht 
news:47a3dcc5$1@news.povray.org...
> Was anybody able to at least reproduce this bug on their system?
>

Yes, I got the same results
(Windows XP)

Thomas

Post a reply to this message

>> Was anybody able to at least reproduce this bug on their system?
>>
>
> Yes, I got the same results
> (Windows XP)

Me too, in beta 25, and verified it works fine in 3.6.
I think it has to do with the use of transform{}. Here's
a modified scene that removes "transforms.inc" from
the minimal scene.

camera {
   location <0,1,-4>
   look_at <0,0,0>
   angle 30
}

light_source {
   <1,1,-1>*10 color rgb 1
}

// inside a union
#declare tube = union {
   cylinder {
      <0,0,0>, <0,1,0>, 0.1
      pigment {
         gradient y
         color_map {
            [0 color <1,0,0>] // red
            [1 color <0,0,1>] // blue
         }
      }
   }
};

// just a cylinder
#declare tube2 = cylinder {
   0, y, 1/10
   pigment {
      gradient y
      color_map {
         [0 color <0,1,0>] // green
         [1 color <1,1,1>] // white
      }
   }
};

// with object in union, red-blue
object {
   tube
   transform {translate <0.25,-0.5,0>}// this transform misaligns texture
}
object {
   tube
   translate <-0.25,-0.5,0>
}

// with cylinder only, green-white
object {
   tube2
   transform {translate <0.5,-0.5,0>}// this tranform works fine
}
object {
   tube2
   translate <-0.55,-0.5,0>
}

Post a reply to this message

There doesn't seem to be any way yet to feed back proposed fixes for defects
except through the newsgroups, so:

I think I've found the problem using a minor simplification of Tim's scene and
the recently released Beta 3.7 source. In csg.cpp#40, in the 3.7.beta.25b
source archive, CSG::Transform is defined as:

void CSG::Transform(TRANSFORM *tr)
{
  for(vector<ObjectPtr>::iterator Current_Sib = children.begin(); Current_Sib !=
children.end(); Current_Sib++)
    (*Current_Sib)->Transform(tr);

  Recompute_BBox(&BBox, tr);
}

This is only called when you use a transform {} block with a CSG object.
Changing

(*Current_Sib)->Transform(tr);

to

Transform_Object (*Current_Sib, tr);

seems to fix the problem, because the former only sets up the transforms on the
child geometry (a cylinder in this case) whereas Transform_Object calls the
needful transformations on the textures as well (and some other stuff). The
latter also looks more like the implementation of CSG::Translate, CSG::Rotate
and CSG::Scale (which are called to handle your transforms when you don't use a
transform block).

For reference, the final minimal scene is included below. Both the red->blue
texture and the black->white texture should appear as smooth vertical gradients
following the fix. I can't guarantee that this fix does not cause unintended
regressions.

camera {
   location <0,1,-4>
   look_at <0,0,0>
   angle 30
}

light_source {
   <1,1,-1>*10 color rgb 1
}

union {
   cylinder {
      <0,0,0>, <0,1,0>, 0.1
      pigment {
         gradient y
         color_map {
            [0 color <1,0,0>]
            [1 color <0,0,1>]
         }
      }
   }
   transform {translate <0.25,-0.5,0>}// this transform misaligns texture
}

union {
   cylinder {
      <0,0,0>, <0,1,0>, 0.1
      pigment {
         gradient y
         color_map {
            [0 color <0,0,0>]
            [1 color <1,1,1>]
         }
      }
   }
   translate <-0.25,-0.5,0>// this transform doesn't misalign texture
}

Post a reply to this message

The proposed fix also seems to address the defect mentioned by Tim and
elaborated on by Samuel Benge in the bugs list for beta 25:

http://news.povray.org/povray.beta-test/thread/%3C47a84bb1%241%40news.povray.org%3E/

The results were checked using the minimal scene provided there.

The Transform_Object routine takes care of transforming objects used in
clipped_by, so calling it would believably fix clipped_by transform {} problems
too.

Post a reply to this message