This is wierd.  Somehow the normal of the
plane is being rotated by the clear spheres.
Must be some sort of bug. =(

The effect goes away if you remove the
normal from the plane.

Try this as a replacement...

#local cpig = pigment{checker Red*1.7 White*1.7 scale 0.05};
#local bpig = pigment{Black};
plane {y, 0 texture{pigment{bozo pigment_map{[0 cpig][1 bpig]}}}}

Post a reply to this message

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> "gadoid" <hansen at tkgate.org> wrote:
> ....
>
> I may have narrowed the problem down for you.  It appears to be affected
> ultimately by the size of the normals of the plane behind the spheres.
>
> Try removing the plane normal or making it smaller and see what happens.  It
> doesn't matter what normal type you have on the spheres, so it's not related
> to the crackle pattern.  Whatever is causing it, the normals on the plane
> appear to be getting reversed by the spheres.  For example try rendering
> with "bozo 4" normal on the plane and then "bozo -4" and compare.
>
> Hope this can help someone track down the reason or bug causing it.
>
> -tgq

I did notice the problem only happens when the surface beyond has a normal.
You are right that it may be reversing the normal, I at first thought it was
just shifting it.  I'm beginning to think that this must be a POV-Ray bug,
but if it is, I need to find a work-around for my scene.  I can't get rid
of the "normal" on the surface behind the object, because that is water and
I am using the normal to generate the waves.  I have hundreds of the
"electron" objects in the scene.  The only thing I can think of is to
#declare a different object for every orientation I need since the
unrotated objects seem to render fine.

Post a reply to this message

gadoid nous apporta ses lumieres en ce 2007/09/06 22:23:
> "Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
>> "gadoid" <hansen at tkgate.org> wrote:
>> ....
>>
>> I may have narrowed the problem down for you.  It appears to be affected
>> ultimately by the size of the normals of the plane behind the spheres.
>>
>> Try removing the plane normal or making it smaller and see what happens.  It
>> doesn't matter what normal type you have on the spheres, so it's not related
>> to the crackle pattern.  Whatever is causing it, the normals on the plane
>> appear to be getting reversed by the spheres.  For example try rendering
>> with "bozo 4" normal on the plane and then "bozo -4" and compare.
>>
>> Hope this can help someone track down the reason or bug causing it.
>>
>> -tgq
> 
> I did notice the problem only happens when the surface beyond has a normal.
> You are right that it may be reversing the normal, I at first thought it was
> just shifting it.  I'm beginning to think that this must be a POV-Ray bug,
> but if it is, I need to find a work-around for my scene.  I can't get rid
> of the "normal" on the surface behind the object, because that is water and
> I am using the normal to generate the waves.  I have hundreds of the
> "electron" objects in the scene.  The only thing I can think of is to
> #declare a different object for every orientation I need since the
> unrotated objects seem to render fine.
> 
> 
> 
> 
> 
> 
> 
Don't rotate the texture! Instead, create the objects at the origin, rotate the 
objects, thanslate them to the final position. As you are using spheres, 
rotating the object or the texture will wave the same final aspect, minus the 
normal alteration.

In my tests, the effect depends on the axis of rotation relative to the 
camera-object vector. An object with a z rotation just in front of the default 
camera show no effect, while the same object shifted up/down or lateraly will 
exibit the effect.

-- 
Alain
-------------------------------------------------
When you don’t know what to do, walk fast and look worried.

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:
> gadoid nous apporta ses lumieres en ce 2007/09/06 22:23:
> > "Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> >> "gadoid" <hansen at tkgate.org> wrote:
> >> ....
> >>
> >> I may have narrowed the problem down for you.  It appears to be affected
> >> ultimately by the size of the normals of the plane behind the spheres.
> >>
> >> Try removing the plane normal or making it smaller and see what happens.  It
> >> doesn't matter what normal type you have on the spheres, so it's not related
> >> to the crackle pattern.  Whatever is causing it, the normals on the plane
> >> appear to be getting reversed by the spheres.  For example try rendering
> >> with "bozo 4" normal on the plane and then "bozo -4" and compare.
> >>
> >> Hope this can help someone track down the reason or bug causing it.
> >>
> >> -tgq
> >
> > I did notice the problem only happens when the surface beyond has a normal.
> > You are right that it may be reversing the normal, I at first thought it was
> > just shifting it.  I'm beginning to think that this must be a POV-Ray bug,
> > but if it is, I need to find a work-around for my scene.  I can't get rid
> > of the "normal" on the surface behind the object, because that is water and
> > I am using the normal to generate the waves.  I have hundreds of the
> > "electron" objects in the scene.  The only thing I can think of is to
> > #declare a different object for every orientation I need since the
> > unrotated objects seem to render fine.
> >
> >
> >
> >
> >
> >
> >
> Don't rotate the texture! Instead, create the objects at the origin, rotate the
> objects, thanslate them to the final position. As you are using spheres,
> rotating the object or the texture will wave the same final aspect, minus the
> normal alteration.
>
> In my tests, the effect depends on the axis of rotation relative to the
> camera-object vector. An object with a z rotation just in front of the default
> camera show no effect, while the same object shifted up/down or lateraly will
> exibit the effect.
>
> --
> Alain
> -------------------------------------------------
> When you don’t know what to do, walk fast and look worried.

Unfortunately, I still get the problem when I rotate the object and not the
texture.  I was rotating the texture because in an earlier scene, I was
using a gradient with turbulence to get rings of lightning, and I wanted
them to have different orientations for the different instances of the
object.  Ultimately, the sphere will have legs and thus will not be truly
symmetrical.  I've since decided to use crackle to get lightning so I don't
really need to rotate the texture anymore, but rotating the object still has
the same problem.

I'm not seeing any difference in the effect irregardless of where I put the
camera.  The unrotated sphere at <-0.5,1,0> is invisible no matter where I
put the location and look_at.  How are you getting it to appear?

Post a reply to this message

if you use that
#declare T_Electron =
  pigment {
    crackle
    pigment_map {
        [0.00   Clear]
        [1.00  Clear ]
    }
  };

the problem goes away ...


hence it seems that the texture_map which creates your problem ...




web.46e05e106d67f0f14e9a00c00@news.povray.org...
> The code below generates five spheres which should be invisible, yet three
> of them are visible from their interaction with the environment.  The
> spheres become visible when you apply a rotation to a texture that uses a
> texture_map  containing clear (rgbt <1,1,1,1>) components as in the
> T_Electron texture below.  If the texture is not rotated, then the sphere
> remains invisible.  Rotation applied to a clear texture not part of a
> texture_map also remains invisible.
>
> It also seems to be the case that the surface behind the spheres must have
a
> "normal" for the effect to occur.  The effect goes away if you remove the
> "normal" block in the texture of the  "floor".
>
> I realize the T_Electron texture as written below is pretty pointless, but
> in the actual scene I am trying to create, not all of the texture map is
> clear. The intent was to create a spherical shell of lightning with parts
> of the texture_map representing the lightning, and the rest clear.  The
> problem I am having is the the clear portions affecting the appearance of
> objects behind it.  I removed the "lightning" portion for this example.
>
> I am using povray 3.6
>
> #include "colors.inc"
>
> #declare T_Clear = texture {pigment { Clear }}
>
> #declare T_Electron =
>   texture {
>     crackle
>     texture_map {
>         [0.00   T_Clear]
>         [1.00   T_Clear]
>     }
>   }
>
> //
> // Three of these spheres are visible (those at x positions -1,
> // 0 and 1).
> //
> sphere { <-1,1,0>,   0.2 hollow texture { T_Electron rotate 90*y }}
> sphere { <-0.5,1,0>, 0.2 hollow texture { T_Electron rotate 0*y }}
> sphere { <0,1,0>,    0.2 hollow texture { T_Electron rotate 90*y }}
> sphere { <0.5,1,0>,  0.2 hollow texture { T_Clear rotate 90*y }}
> sphere { <1,1,0>,    0.2 hollow texture { T_Electron rotate 90*y }}
>
>
> plane { y, 0
>   texture {
>     pigment {
>       checker
>       Red
>       White
>       scale 0.05
>     }
>     normal { bozo 4}
>   }
> }
>
> light_source {
>   <-8.0,   6,   -10>
>   color rgb 2
> }
>
> camera {
>   //
>   // New Main view
>   //
>   look_at <0,1,0>
>   location <0,1.5,-2>
>
>   up <0,1,0>
> }
>
>
>
>
>

Post a reply to this message

"gadoid" <hansen at tkgate.org> wrote in message 
news:web.46e0b422c3c9512797e3bb420@news.povray.org...
>  I have hundreds of the
> "electron" objects in the scene.  The only thing I can think of is to
> #declare a different object for every orientation I need since the
> unrotated objects seem to render fine.
>

I think the easier workaround is to apply the crackle just to the pigment. 
You can still apply the finish to the texture afterwards.
Below is an example that makes the problem dissapear with an adaptation of 
your Electric Blue Lightning texture.
Regards,
Chris B.


#declare P_ElectricBlue = pigment {
  color  rgb <0.178, 0.122, 1>
}

#declare P_Lightning = pigment {P_ElectricBlue}
#declare P_Clear = pigment { color rgbt 1 }

#declare F_Lightning = finish {
  ambient 5
  brilliance 100.0
}

#declare T_Electron = texture {
   pigment {
     crackle
     turbulence .3
     pigment_map {
       [0.000 P_Lightning ]
       [0.0400 P_Lightning ]
       [0.0800 P_Lightning ]
       [0.00 P_Clear ]
       [1.00 P_Clear ]

     }
   }
   finish {F_Lightning}
   scale 0.1
 }


sphere { <0,1,0>, 0.2 texture { T_Electron} rotate (10+350*clock)*y}

Post a reply to this message

"Chris B" <c_b### [at] btconnectcomnospam> wrote:
> "gadoid" <hansen at tkgate.org> wrote in message
> news:web.46e0b422c3c9512797e3bb420@news.povray.org...
> >  I have hundreds of the
> > "electron" objects in the scene.  The only thing I can think of is to
> > #declare a different object for every orientation I need since the
> > unrotated objects seem to render fine.
> >
>
> I think the easier workaround is to apply the crackle just to the pigment.
> You can still apply the finish to the texture afterwards.
> Below is an example that makes the problem dissapear with an adaptation of
> your Electric Blue Lightning texture.
> Regards,
> Chris B.
>
>
> #declare P_ElectricBlue = pigment {
>   color  rgb <0.178, 0.122, 1>
> }
>
> #declare P_Lightning = pigment {P_ElectricBlue}
> #declare P_Clear = pigment { color rgbt 1 }
>
> #declare F_Lightning = finish {
>   ambient 5
>   brilliance 100.0
> }
>
> #declare T_Electron = texture {
>    pigment {
>      crackle
>      turbulence .3
>      pigment_map {
>        [0.000 P_Lightning ]
>        [0.0400 P_Lightning ]
>        [0.0800 P_Lightning ]
>        [0.00 P_Clear ]
>        [1.00 P_Clear ]
>
>      }
>    }
>    finish {F_Lightning}
>    scale 0.1
>  }
>
>
> sphere { <0,1,0>, 0.2 texture { T_Electron} rotate (10+350*clock)*y}


Unfortunately, this didn't work for me.  It fixed the problem with the clear
texture reversing the normals, but the pigment map which is really:

pigment_map {
  [0 P_Lightning]
  [0.04 P_Lightning]
  [0.08 P_Clear]
  [1 P_Clear]
}

has a transition from the lightning texture to the clear texture to give it
a soft edge.  When the full finish is applied to this transition region, it
looks terrible.  I have found another possible workaround though.  I tried
replacing my sphere:

sphere { <0,0,0>, R texture { T_Electron}}

with

difference {
  sphere { <0,0,0>, R }
  sphere { <0,0,0>, R-0.001 }
  texture { T_Electron }
}

and this seems to look OK (in fact I suspect it constrains the problem to
the region between R-0.001 and R) which is too small to notice.  The
primary problem is that it increases the rendering time by about a factor
of 3.  Here is what I get before
(http://www.tkgate.org/povray/electrons.png) and after
(http://www.tkgate.org/povray/fixed-electrons.png) using the "difference".
I tried adding an "interior_texture { T_Clear }" to the difference to see if
that would speed up the rendering.  While it does speed up the rendering, it
causes the strange artifact to return.

Post a reply to this message

gadoid nous apporta ses lumieres en ce 2007/09/06 23:44:
> Alain <ele### [at] netscapenet> wrote:
>> gadoid nous apporta ses lumieres en ce 2007/09/06 22:23:
>>> "Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
>>>> "gadoid" <hansen at tkgate.org> wrote:
>>>> ....
>>>>
>>>> I may have narrowed the problem down for you.  It appears to be affected
>>>> ultimately by the size of the normals of the plane behind the spheres.
>>>>
>>>> Try removing the plane normal or making it smaller and see what happens.  It
>>>> doesn't matter what normal type you have on the spheres, so it's not related
>>>> to the crackle pattern.  Whatever is causing it, the normals on the plane
>>>> appear to be getting reversed by the spheres.  For example try rendering
>>>> with "bozo 4" normal on the plane and then "bozo -4" and compare.
>>>>
>>>> Hope this can help someone track down the reason or bug causing it.
>>>>
>>>> -tgq
>>> I did notice the problem only happens when the surface beyond has a normal.
>>> You are right that it may be reversing the normal, I at first thought it was
>>> just shifting it.  I'm beginning to think that this must be a POV-Ray bug,
>>> but if it is, I need to find a work-around for my scene.  I can't get rid
>>> of the "normal" on the surface behind the object, because that is water and
>>> I am using the normal to generate the waves.  I have hundreds of the
>>> "electron" objects in the scene.  The only thing I can think of is to
>>> #declare a different object for every orientation I need since the
>>> unrotated objects seem to render fine.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> Don't rotate the texture! Instead, create the objects at the origin, rotate the
>> objects, thanslate them to the final position. As you are using spheres,
>> rotating the object or the texture will wave the same final aspect, minus the
>> normal alteration.
>>
>> In my tests, the effect depends on the axis of rotation relative to the
>> camera-object vector. An object with a z rotation just in front of the default
>> camera show no effect, while the same object shifted up/down or lateraly will
>> exibit the effect.
>>
>> --
>> Alain
>> -------------------------------------------------
>> When you don’t know what to do, walk fast and look worried.
> 
> Unfortunately, I still get the problem when I rotate the object and not the
> texture.  I was rotating the texture because in an earlier scene, I was
> using a gradient with turbulence to get rings of lightning, and I wanted
> them to have different orientations for the different instances of the
> object.  Ultimately, the sphere will have legs and thus will not be truly
> symmetrical.  I've since decided to use crackle to get lightning so I don't
> really need to rotate the texture anymore, but rotating the object still has
> the same problem.
> 
> I'm not seeing any difference in the effect irregardless of where I put the
> camera.  The unrotated sphere at <-0.5,1,0> is invisible no matter where I
> put the location and look_at.  How are you getting it to appear?
> 
> 
If you don't rotate the sphere, it's placement is irrevelent. IF you rotate the 
texture, THEN the location DOES have an effect. If the axis of rotation is 
parallel to the camera-object axis, then you don't have the problem.

-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when you've convinced your boss that 
raytracing is really an integral part of your job title (and you really don't 
work in a position that requires it).
Quietly Watching

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:
> gadoid nous apporta ses lumieres en ce 2007/09/06 23:44:
> > Alain <ele### [at] netscapenet> wrote:
> >> gadoid nous apporta ses lumieres en ce 2007/09/06 22:23:
> >>> "Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> >>>> "gadoid" <hansen at tkgate.org> wrote:
> >>>> ....
> >>>>
> >>>> I may have narrowed the problem down for you.  It appears to be affected
> >>>> ultimately by the size of the normals of the plane behind the spheres.
> >>>>
> >>>> Try removing the plane normal or making it smaller and see what happens.  It
> >>>> doesn't matter what normal type you have on the spheres, so it's not related
> >>>> to the crackle pattern.  Whatever is causing it, the normals on the plane
> >>>> appear to be getting reversed by the spheres.  For example try rendering
> >>>> with "bozo 4" normal on the plane and then "bozo -4" and compare.
> >>>>
> >>>> Hope this can help someone track down the reason or bug causing it.
> >>>>
> >>>> -tgq
> >>> I did notice the problem only happens when the surface beyond has a normal.
> >>> You are right that it may be reversing the normal, I at first thought it was
> >>> just shifting it.  I'm beginning to think that this must be a POV-Ray bug,
> >>> but if it is, I need to find a work-around for my scene.  I can't get rid
> >>> of the "normal" on the surface behind the object, because that is water and
> >>> I am using the normal to generate the waves.  I have hundreds of the
> >>> "electron" objects in the scene.  The only thing I can think of is to
> >>> #declare a different object for every orientation I need since the
> >>> unrotated objects seem to render fine.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >> Don't rotate the texture! Instead, create the objects at the origin, rotate the
> >> objects, thanslate them to the final position. As you are using spheres,
> >> rotating the object or the texture will wave the same final aspect, minus the
> >> normal alteration.
> >>
> >> In my tests, the effect depends on the axis of rotation relative to the
> >> camera-object vector. An object with a z rotation just in front of the default
> >> camera show no effect, while the same object shifted up/down or lateraly will
> >> exibit the effect.
> >>
> >> --
> >> Alain
> >> -------------------------------------------------
> >> When you don’t know what to do, walk fast and look worried.
> >
> > Unfortunately, I still get the problem when I rotate the object and not the
> > texture.  I was rotating the texture because in an earlier scene, I was
> > using a gradient with turbulence to get rings of lightning, and I wanted
> > them to have different orientations for the different instances of the
> > object.  Ultimately, the sphere will have legs and thus will not be truly
> > symmetrical.  I've since decided to use crackle to get lightning so I don't
> > really need to rotate the texture anymore, but rotating the object still has
> > the same problem.
> >
> > I'm not seeing any difference in the effect irregardless of where I put the
> > camera.  The unrotated sphere at <-0.5,1,0> is invisible no matter where I
> > put the location and look_at.  How are you getting it to appear?
> >
> >
> If you don't rotate the sphere, it's placement is irrevelent. IF you rotate the
> texture, THEN the location DOES have an effect. If the axis of rotation is
> parallel to the camera-object axis, then you don't have the problem.
>

I see said the blind man.  I didn't try that, or at least I wasn't paying
close attention to the rotated spheres while looking at the non-rotated
one.

Post a reply to this message

"gadoid" <hansen at tkgate.org> wrote:
>... it may be reversing the normal, I at first thought it was
> just shifting it.  I'm beginning to think that this must be a POV-Ray bug,


Seems to be more complicated than reversing the normal. Here is a test scene
that creates several "invisible" discs with varying rotations of a texture.
Note how some of the bumps are lit sideways.   (I've uploaded an image to
povray.binaries.images)

This does look like a bug where, given a sufficiently complicated (semi or
fully) transparent texture on one object, and a 2nd object with a normal
pattern behind it, somehow leftover transformations from dealing with the
first object "stick" in some data structure when calculating lighting on
the 2nd one.  I looked at the source code, but the flaw isn't obvious;
perhaps someone with more recent experience hacking normal.cpp or
lighting.cpp can spot it.

Sorry, no good general workaround i can find yet.  An awkward workaround is
to put behind each object using a rotated transparent texture like your
T_Electron, an invisible object using a purely invisible texture (rgbt
<1,1,1,1>, no patterns) but rotating oppositely.  These invisible
compensator objects going between the real objects and the background would
have to match in shape as seen from the camera. Yeeks, good luck with that!


/// funnynormal.pov
/// render with:  povray +D +P +X -ifunnynormal.pov  +w800 +h600
plane {z, 0
 pigment {color rgb 1}
 finish {diffuse 1  ambient  0}
 normal { leopard 1  sine_wave    scale .2}
}

#declare ClearTex=   texture {
   pigment { color rgbt <.8, 1, 1, 1>}
   finish { ambient 0  diffuse 0}
}

#declare IndirectClearTex = texture {
  bozo  texture_map { [0 ClearTex] }
}

#declare ix=-3;
#while (ix <=3)
 disc {<ix*2, 2,-5>, z,.8 texture{        ClearTex rotate 45*ix*y}}
 disc {<ix*2, 0,-5>, z,.8 texture{IndirectClearTex rotate 45*ix*y}}
 disc {<ix*2,-2,-5>, z,.8 texture{IndirectClearTex rotate 45*ix*z}}
 #declare ix=ix+1;
#end

light_source { <100, 0, -10> rgb <.8,.8,1>*2 }
light_source { <0, 100, -30> rgb <.2, .2, 0> }
camera {
 orthographic
 location <0,0,-100>
 right <15,0,0>
 up <0,10,0>
 direction <0,0,1>*10
}

Post a reply to this message