POV-Ray : Newsgroups : povray.programming : Parametric object fix : Parametric object fix Server Time
27 Jul 2024 22:23:10 EDT (-0400)
  Parametric object fix  
From: Wolfgang Wieser
Date: 3 Jul 2004 14:38:50
Message: <40e6fd38@news.povray.org>
As already mentioned in the previous thread, I have come up with a 
"solution" for the parametric object bug (crash) as reported by me 
(on 20 Jun 2003 21:49:03 in p.programming)

There are two problems: 
(1) When accuracy is made too small, an internal fixed-size array overflows. 
(2) Unless using no_shadow, the parametric object may be completely black. 

This (completely black object) can be seen e.g. using: 

------------------------------------------
#include "functions.inc"

global_settings { assumed_gamma 2.2 }
light_source { <-0.4,0.2,-0.3>*20, rgb <2,2,2>/2 }
light_source { <0.2,1,-0.8>*20, rgb <2,2,2>/1.7 }

#declare m=3;
parametric {










}


--------------------------------------------

Let's come to the black object (2) first:
-----------------------------------------

Somebody (I do not know who) supposed a patch for this which was 
as follows (IMO): 

We need DEPTH_TOLERANCE again...




...and insert the two lines indicated with "+" below: 

---------------<fpmetric.cpp around line 220>------------------













-------------------------------------------------------------

This will make the above code render a nice green parametric object. 

I must admit that I do not completely understand why this works and 
it was not me who suggested it. I recall that some of my tests made 
the object have no self-shadow, so here comes a modified test scene which 
was used to verify that shadow and self-shadow work correctly for 
accuracies 0.01 and 1e-9: (NOTE! This needs the patch for (1) applied, 
see below.)

I do not know if we should apply this. Somebody with more clue about 
the code should comment on that. This change may have side effects 
which I am not aware of. But it seems, this solution is at least better 
than the current one. 

------------------------------
#include "functions.inc"

global_settings { assumed_gamma 2.2 }
light_source { <0.2,0.3,-0.3>*20*5, rgb <2,2,2>/1.7 }

#declare m=3;
parametric {










}

plane { y,-15 pigment { rgb x }}

------------------------------

Solution for (1)
----------------

This is what I verified to work with a test scene (the one above with 
different accuracy values in range 1e-3 to <1e-10): 

First of all, we should get rid of the fixed array sizes 32 for internal 
solver sectors: 

Around line 120, replacing 

-static DBL Intervals_Low[2][32], Intervals_Hi[2][32]; // GLOBAL VARIABLE
-static int SectorNum[32]; // GLOBAL VARIABLE

+static DBL Intervals_Low[2][SECT_DIM], Intervals_Hi[2][SECT_DIM];
+static int SectorNum[SECT_DIM]; // GLOBAL VARIABLE

should do the trick. This will use fixed-size SECT_DIM=48. It showed, that 
using more does not make sense given double precision. Actually, the old 
value 32 would also suffice for most tasks but no disortion appears with 
accuracies which need 48 or even 64 sectors. (One could use 64 to be on 
an even safer side.)

Around line 408, the solver bailout test reads: 

--------------------------------





















--------------------------------

The best thing we can probably do is to also bail out if the number 
of available sectors is insufficient. This means that the accuracy will 
no longer be guaranteed but OTOH dynamically increasing the 
number of sectors without any limit may IMHO trap us in an endless 
(or neraly endless) loop when fed with pathological functions. 
Hence, I suggest to do the following: 

--------------------------------






--------------------------------

I verified that this works as expected with the test scene with different 
accuracy settings and with different values for SECT_DIM (16..64). 

Somebody with more clue about the code could please comment on 
that. At least my solution should be better than the current behaviour. 

Furthermore, there is an uneccessary test: 

Around line 350: 

------------

------------

There is IMO no way how SectorNum could get zero or negative. The second 
test can be left away for the Z component (it is actually BOT present for X 
and Y). 

Hence, 

------------

------------

should work just fine. At least no problem showed up in my tests. 


Regards,
Wolfgang


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.