The patch below should fix the problem related to the no_shadow 
and parametric objects reported in povray.general

Message-ID: <3ef375c0@news.povray.org>
From: Wolfgang Wieser <.....>
Subject: Re: Parametric object with shadow gets black
Newsgroups: povray.general
Date: Fri, 20 Jun 2003 22:59:01 +0200


HTH Massimo

--- obj/fpmetric.cpp 2003-06-21 17:56:52.000000000 +0200
+++ src/fpmetric.cpp 2003-06-21 17:08:17.000000000 +0200
@@ -447,7 +447,7 @@
   }
  }
 
- if (TResult < Depth2)
+ if (TResult < Depth2 && TResult > DEPTH_TOLERANCE)
  {
   Increase_Counter(stats[Ray_Parametric_Tests_Succeeded]);
   VScale(IPoint, Ray->Direction, TResult);

Post a reply to this message

Massimo Valentini wrote:

> The patch below should fix the problem related to the no_shadow
> and parametric objects reported in povray.general
> 
Hmm, yes and no. 

YES, the image is no longer black and there is a nice shadow 
_below_ the parametric object. 

And NO, it does not look like the object has any shadow on 
its own surface. I mean -- the high parts of the parametric 
surface should throw shadows on the low parts...
Or at least if I peak a cylinder through the object. 
I failed see such a shadow in my test-renders. 

> From: Wolfgang Wieser <.....>
>
That's me...

Wolfgang

Post a reply to this message

"Wolfgang Wieser" ha scritto 
 
: 
: YES, the image is no longer black and there is a nice shadow 
: _below_ the parametric object. 

I saw the shadow below the object, and I thought the surface 
was in full light :-(

: 
: And NO, it does not look like the object has any shadow on 
: its own surface. I mean -- the high parts of the parametric 
: surface should throw shadows on the low parts...
: Or at least if I peak a cylinder through the object. 
: I failed see such a shadow in my test-renders. 
: 

Looking at the code (All_Parametric_Intersections) it seems that 
only one intersection is pushed onto the Depth_Stack, so when 
testing for self shadows if the first intersection is the starting
point, not meaningful (and so dropped with my patch), every other
intersection is not considered. 

I just gave a fast glance to docs and code, so I cannot say whether 
this behaviour is the documented behaviour or a misbehaviour. 

I don't think a quick patch is easy, but, may be, it suffices a loop.

Massimo

Post a reply to this message

"Massimo Valentini" ha scritto 
: 
: I don't think a quick patch is easy, but, may be, it suffices a loop.
: 

Instead of a loop it is possible to set appropriately the range 
for intersections, so that the first is the correct. 

The following patch should fix the shadow problem, though not 
the accuracy one.

Massimo

--- obj/fpmetric.cpp 2003-06-23 22:10:24.000000000 +0200
+++ fpmetric.cpp 2003-06-23 22:11:30.000000000 +0200
@@ -222,6 +222,9 @@
  if (Depth1 == Depth2)
   Depth1 = 0;
 
+  if (Depth1 < DEPTH_TOLERANCE)
+    Depth1 = DEPTH_TOLERANCE;
+  
  if ((Depth1 += 4 * Par->accuracy) > Depth2)
   return false;

Post a reply to this message

Massimo Valentini wrote:
> "Massimo Valentini" ha scritto
> : I don't think a quick patch is easy, but, may be, it suffices a loop.
> 
> Instead of a loop it is possible to set appropriately the range
> for intersections, so that the first is the correct.
> 
> The following patch should fix the shadow problem, 
>
Hey, that's cool! It seems to work well. There is lots of self-shadow 
and the whole object throws shadow. AND it is no longer solid black. 

Does anybody know if there is any reason for doing 
>   if (Depth1 == Depth2)
>    Depth1 = 0;
around line 222?
Shouldn't one use 
    if(fabs(Depth1-Depth2)<=some_epsilon)  Depth=0;
instead?

> though not the accuracy one.
> 
The accuracy problem is caused by the array index overflow. 
I don't know what one should do. Of yourse, one could dynamically 
enlarge the array but before doing that one should be certain 
that the loop will ever terminate in all situations. 
I mean -- this is FP numerics and I'm not sure if we can trap 
situations where things break (no convergence...). 
I'm not sure about that (no time to study the code in depth) but 
it is possible that there is no emergency break in the code which 
makes sure that we give up numeric calculation when it comes clear 
that the desired accuracy cannot be reached? Trying to reach 
1e-20 accuracy with standard FP is simply ridiculous...

Wolfgang

> --- obj/fpmetric.cpp 2003-06-23 22:10:24.000000000 +0200
> +++ fpmetric.cpp 2003-06-23 22:11:30.000000000 +0200
> @@ -222,6 +222,9 @@
>  
> +  if (Depth1 < DEPTH_TOLERANCE)
> +    Depth1 = DEPTH_TOLERANCE;
> +
>   if ((Depth1 += 4 * Par->accuracy) > Depth2)
>    return false;

Post a reply to this message