Ok. here's the situation:
I have a scene file ( attached ) that contains a height_field.
If you place the smooth keyword in the height_field def as normal, it
works..

however, if, perchance, you should place it when noted in the comments (the
second place).. Pov-Ray 3.1 for windows crashes.
it is reproducible (at least on my system.... )

-
Twyst
============================================================
for pov-ray news, reviews, and tutorials
http://twysted.net
e-mail: twy### [at] twystednet
============================================================

Post a reply to this message

Attachments:
Download 'background.pov.txt' (2 KB)

On Thu, 3 Dec 1998 02:49:35 -0700, Twyst <twy### [at] twystednet> wrote:
>Ok. here's the situation:
>I have a scene file ( attached ) that contains a height_field.
>If you place the smooth keyword in the height_field def as normal, it
>works..
>
>however, if, perchance, you should place it when noted in the comments (the
>second place).. Pov-Ray 3.1 for windows crashes.
>it is reproducible (at least on my system.... )

I have verified it, and it is a problem.  Please submit it to the POV-Team
via the usual bug-reporting address. You may quote this message, if you think
it will help.

The short version of the problem:

+----------------------------------
| object {
|   height_field { tga "image.tga" }
|   smooth
| }
+----------------------------------

crashes with an access violation while rendering.

This also crashes, for the same reason:

+----------------------------------
| #declare MyHF=height_field { tga "image.tga" }
| object { MyHF smooth }
+----------------------------------

The reason:

"smooth" is parsed by Parse_Object_Mods.  If an object is "smoothable" as
indicated by the SMOOTH_OK_OBJECT flag, the presence of the "smooth" keyword 
sets SMOOTHED_FLAG to indicate that the object should be smoothed.  After 
calling Parse_Object_Mods, Parse_HField calls Compute_HField.  Among other 
things, Compute_HField allocates and fills an array of vertex normals, but 
only if SMOOTHED_FLAG is set.  Finally, while rendering, POV computes the 
local normal by using that array, again only if SMOOTHED_FLAG is set.  This
sets the stage for disaster:  consider what happens if SMOOTHED_FLAG
gets set after Compute_HField is called, but before rendering.  The 
array doesn't get allocated, but it does get used.  BOOM!  This is in fact
what happens, as Parse_Object calls Parse_Object_Mods and sets SMOOTHED_FLAG
without calling Compute_HField (which has already been called by then.)

A solution: 

Compute_HField should clear the SMOOTH_OK_OBJECT flag before it returns.  
Then 'smooth' wouldn't be valid for this object outside the scope of the 
original height_field declaration and you'd get a parse error.  (I haven't 
tried this myself yet, but it should work.)

Post a reply to this message