On Sat, 11 May 2002 18:58:23 +0200 peter wrote:

>attached heightfield makes RC4 win binary crash on my intel pentium machine.
>only happens when I use smooth option
>

  Oh, gosh... Thanks for the report, but the next time could you post
the binary to the p.beta-test.binaries group? You've also omitted
important system specs, which are requested here:

Message-ID <3B94E1CF.7498B010@pacbell.net>, in this group.

-- 
Alan
ako### [at] povrayorg
a k o n g <at> p o v r a y <dot> o r g

Post a reply to this message

peter wrote:
> attached heightfield makes RC4 win binary crash on my intel pentium
> machine. only happens when I use smooth option

Maybe it would be a great idea to supply some code which can't only be 
executed on your own system.
-- 
Felix Wiemann

Post a reply to this message

In article <3cdd6463@news.povray.org> , Felix Wiemann <Fel### [at] gmxnet>
wrote:

> peter wrote:
>> attached heightfield makes RC4 win binary crash on my intel pentium
>> machine. only happens when I use smooth option
>
> Maybe it would be a great idea to supply some code which can't only be
> executed on your own system.

All the include files were unnecessary :-(

I have been able track this down to a very odd way of parsing height_fields.
Even more interesting, even the docs showed this odd way.  A check in the
sample scenes showed no use of the odd "feature" so it will be gone in the
next beta as will be the problem:

Essentially the "smooth" is not supposed to be outside the height_field.  In
the scene it was in the object block, which was what caused the problem.  So
next time the parser will catch it as an error.  Moving the smooth into the
height_field block solves the problem.

Oh, and did I mention that this bug has been around at least since 3.1?  Well,
it actually has been around since smooth height_fields were introduced as far
as I can tell.  Anybody remember when they were introduced?


    Thorsten


BTW, the original post with its big attachment has been removed.

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:

>Oh, and did I mention that this bug has been around at least since 3.1?
>Well, it actually has been around since smooth height_fields were
>introduced as far as I can tell.  Anybody remember when they were
>introduced?

Well, since you're asking...
That must have been the legendary version 2.0 back in 1993.
Remember..., when clock was introduced? And automatic bounding slabs?
Getting quite melancholic here.

Good luck,
Jan Maarten van der Valk

Post a reply to this message

jmvdvalk <jm.### [at] hccnetnl> wrote:
> That must have been the legendary version 2.0 back in 1993.
> Remember..., when clock was introduced? And automatic bounding slabs?
> Getting quite melancholic here.

  Wasn't automatic bounding introduced in 3.0?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:
>   Wasn't automatic bounding introduced in 3.0?

Yes.

-- 
Ken Tyler

Post a reply to this message

Ken wrote:
>
>
>Warp wrote:
>>   Wasn't automatic bounding introduced in 3.0?
>
>Yes.

No, in 2.0. (You challenged me into checking the docs ;-)

JM

Post a reply to this message

jmvdvalk <jm.### [at] hccnetnl> wrote:
>>>   Wasn't automatic bounding introduced in 3.0?
>>
>>Yes.

> No, in 2.0. (You challenged me into checking the docs ;-)

  I quite clearly remember that in 2.2 you had to bound objects by hand
if you wanted speed, but in 3.0 POV-Ray started to remove those user-specified
bounding objects (because it thought it could do better than me).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message news:3ce3a478@news.povray.org...
>
> > No, in 2.0. (You challenged me into checking the docs ;-)
>
>   I quite clearly remember that in 2.2 you had to bound objects by hand
> if you wanted speed, but in 3.0 POV-Ray started to remove those user-specified
> bounding objects (because it thought it could do better than me).
>

Which doesn't nec. mean that 2.2 didn't have auto-bounding, but it would
indicate that it was a) a bit crap and b) the developers knew that.

Post a reply to this message

Warp wrote:
> 
> jmvdvalk <jm.### [at] hccnetnl> wrote:
> >>>   Wasn't automatic bounding introduced in 3.0?
> >>
> >>Yes.
> 
> > No, in 2.0. (You challenged me into checking the docs ;-)
> 
>   I quite clearly remember that in 2.2 you had to bound objects by hand
> if you wanted speed, but in 3.0 POV-Ray started to remove those user-specified
> bounding objects (because it thought it could do better than me).

From the POV-Ray v2.2 docs --

3.3.12 BOUNDING SLABS CONTROL
      -MB         Turn off bounding slabs
      +MBnnn      Use bounding slabs if more than nnn objects in scene.
New in POV-Ray 2.0 is a spatial sub-division system called bounding slabs.
It compartmentalizes all of the objects in a scene into rectangular slabs
and computes which slabs a particular ray hits before testing the objects
within the slab.  This can greatly improve rendering speed.  However for
scenes with only a few objects the overhead of using slabs is not worth the
effort.  The +MB switch sets the minimum number of objects before slabs are
used.  The default is +MB25.  The -MB switch turns off slabs completely.

I too thought they were introduced in 3.0 but it appears we both were wrong. 

-- 
Ken Tyler

Post a reply to this message