I might as well point this out here, in hopes that it will get fixed in 3.5.
There seems to be a major bug in SOR, where it looks like the rays are
tested for intersection as if the SOR was open, but the pixels are colored
as if it was closed. This happens in 3.1g, MegaPov 0.7, and 3.5 beta 1.
(Windows 98, Athlon 700, 256MB RAM) Here's some example code that
demonstrates the problem.

camera { location <10, 15, 15> look_at <0, 1, 0> angle 15 }
light_source { <2, 15, 5> color rgb <1, 1, 1> }
plane { +y, 0 pigment { rgb <1, 1, 1> } }
sor { 4, <2, -1> <2, 0> <2, 2> <2, 3> pigment { checker } }

Read my post in .general (with the same subject) for more information and
some small pictures. In particular, see the second one, which corresponds to
the code above. (I posted this before the beta came out.)

http://news.povray.org/povray.general/17877/

Anders K.

Post a reply to this message

Weird effect. :)
  Definitely a bug.

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

I wrote this little macro to temporarily work around the bug:

#macro SorFix (P)
  #local n = dimension_size(P, 1); #local i = 0;
  intersection {
    sor { n+2 P[0] #while (i < n) P[i] #local i = i+1; #end P[n-1] }
    plane { -y, -P[1].v } plane { y, P[n-2].v }
  }
#end

camera { location <10, 15, 15> look_at <0, 1, 0> angle 15 }
light_source { <2, 15, 5> color rgb <1, 1, 1> }
plane { +y, 0 pigment { rgb <1, 1, 1> } }
// sor { 4, <2, -1> <2, 0> <2, 2> <2, 3> pigment { checker } }
object {
  SorFix ( array[4] { <2, -1>, <2, 0>, <2, 2>, <2, 3> } )
  pigment { checker }
}

Anders

P.S. Yeah, I know, it's too late for feature requests, but why do I have to
explicitly specify the number of elements in an array? Why can't I just
write something like
  array { <2, -1>, <2, 0>, <2, 2>, <2, 3> }
without worrying about counting the number of elements I put in? That would
make it much, much easier to maintain large arrays with elements being added
and deleted often.

Post a reply to this message

Anders K. <and### [at] f2scom> wrote:
: P.S. Yeah, I know, it's too late for feature requests, but why do I have to
: explicitly specify the number of elements in an array?

  I think it's because POV-Ray needs to allocate space for the array before
it can put values into it.

  Of course it could be a dynamic array (std::vector), but I think the answer
to this, as to many other things, is: POV-Ray 4.

-- 
#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 wrote:
> 
> Anders K. <and### [at] f2scom> wrote:
> : P.S. Yeah, I know, it's too late for feature requests, but why do I have to
> : explicitly specify the number of elements in an array?
> 
>   I think it's because POV-Ray needs to allocate space for the array before
> it can put values into it.
> 
>   Of course it could be a dynamic array (std::vector), but I think the answer
> to this, as to many other things, is: POV-Ray 4.

Or the code will ended like the mesh parser in 3.1 : calling realloc everytime
that the array is too short... it is not very efficient, and moreover on 
computer with limited memory, a scene may failed to parse due to the system
being unable to provide a continuous memory zone: If the structure would need
66 unit, but the parser get to the end of 64 unit and try to double that amount,
you end up needing 128 unit + 64 possible units (if the system need to copy
them,
instead of extending): total need of 192 units of memory for a scene that would 
required only 66 units! 
Whereas, if you provide the count at the start, only 66 units are needed.

Powerful computer do not care, but small one might ! 
SOR was already available in DKBTrace, 
whereas mesh was introduced later. The difference reflects the evolution
of computers and programmers.
Small was beautiful, Nowadays every program must have fancy graphics and
waste as mush as possible memory and CPU.
Who need a smart programming when brute force provide the result in
bearable time (if you have the big CPU, of course!).

Post a reply to this message

> Powerful computer do not care, but small one might !
> SOR was already available in DKBTrace,

I don't recall SOR being introduced until POV-Ray v3.0 at the same time
Lathe and Prisms were introduced.

-- 
Ken Tyler

Post a reply to this message

On Fri, 07 Sep 2001 04:29:43 -0700, Ken wrote:
>
>

>
>> Powerful computer do not care, but small one might !
>> SOR was already available in DKBTrace,
>
>I don't recall SOR being introduced until POV-Ray v3.0 at the same time
>Lathe and Prisms were introduced.

What he said.  

--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}

Post a reply to this message

> SOR was already available in DKBTrace,

Actually, I was referring to arrays, which were new in 3.1 (right?)

Anders

Post a reply to this message

Just a quick note that this bug is still here in Beta 2 (Windows 98, Athlon
700, 256 MB). If it wasn't supposed to be fixed then please ignore me. :-)

"Anders K." <and### [at] f2scom> wrote in message
news:3b978031@news.povray.org...
> I might as well point this out here, in hopes that it will get fixed in
3.5.
> There seems to be a major bug in SOR, where it looks like the rays are
> tested for intersection as if the SOR was open, but the pixels are colored
> as if it was closed. This happens in 3.1g, MegaPov 0.7, and 3.5 beta 1.
> (Windows 98, Athlon 700, 256MB RAM) Here's some example code that
> demonstrates the problem.
>
> camera { location <10, 15, 15> look_at <0, 1, 0> angle 15 }
> light_source { <2, 15, 5> color rgb <1, 1, 1> }
> plane { +y, 0 pigment { rgb <1, 1, 1> } }
> sor { 4, <2, -1> <2, 0> <2, 2> <2, 3> pigment { checker } }
>
> Read my post in .general (with the same subject) for more information and
> some small pictures. In particular, see the second one, which corresponds
to
> the code above. (I posted this before the beta came out.)
>
> http://news.povray.org/povray.general/17877/
>
> Anders K.
>
>
>

Post a reply to this message

On Thu, 6 Sep 2001 09:55:11 -0400, Anders K. wrote:
>I might as well point this out here, in hopes that it will get fixed in 3.5.
>There seems to be a major bug in SOR, where it looks like the rays are
>tested for intersection as if the SOR was open, but the pixels are colored

Well, the squeaky wheel gets the grease, as they say.  This one's fixed 
for the next beta.  Thanks for pointing it out and sticking with it.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end 
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}

Post a reply to this message