Back to the 13 june 2000, Peter J. Holzer draws my attention to
a strange behavior of the orthographic camera with the superellipsoid object.

In fact, this bug is not limited to the orthographic camera, it
just manifest itself more easily with it!

Images of the various aspect are going to be posted in p.b.i
(as png, not jpeg) (their scripts in p.t.s-f)


first image (super.png) illustrates the "missing" picture of one
superellipsoid, when looked under the correct angle
 (who need the no_image patch with such a bug ?)
There is really four superellipsoid on each row, and three by column!

Rending with or without AA does not change the problem.

second image (super2.png) illustrates the same aspect of the bug
with a default camera. please notice the single pixel at the
very center of the picture: it is the background !!!

Rending with AA does reduce the problem.

third and fourth images (super3.png and super4.png) illustrate another aspect of
the bug
when a rotation is added to a superellipsoid with small parameter values:
the camera sometimes see the inside, sometime the outside (well for the
illumination 
at least).

Rending with or without AA does not change the problem.


I have the solution:

in super.c, at the end of the intersect_box(...) function, 
before the last statement ( "return (TRUE);" ), there is
two lines outside any if block:

*dmin = tmin;
*dmax = tmax;

The correction is simple: remove these two lines.


Any volonteer to post a message to povray.bugreports ?

Post a reply to this message

J. Grimbert <jgr### [at] atos-groupcom> wrote:
: second image (super2.png) illustrates the same aspect of the bug
: with a default camera. please notice the single pixel at the
: very center of the picture: it is the background !!!

  This looks like at that point there's a mathematically undefined point
(exactly like trying to render the function 1/x: it will have this kind of
discontinuity at x=0).

: *dmin = tmin;
: *dmax = tmax;

: The correction is simple: remove these two lines.

  Are you sure this will not break anything?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp wrote:
> 
> J. Grimbert <jgr### [at] atos-groupcom> wrote:
> : second image (super2.png) illustrates the same aspect of the bug
> : with a default camera. please notice the single pixel at the
> : very center of the picture: it is the background !!!
> 
>   This looks like at that point there's a mathematically undefined point
> (exactly like trying to render the function 1/x: it will have this kind of
> discontinuity at x=0).
> 

But there is no such discontinuity for the superellipsoid.
It is bounded by a 2 unit sized box and should not escape it;
(Let's me add, the surface of the superellipsoid is continuous,
it's not an object with holes.)

> : *dmin = tmin;
> : *dmax = tmax;
> 
> : The correction is simple: remove these two lines.
> 
>   Are you sure this will not break anything?

Short answer:

    Yes


Long answer:

   In the intersect_box() code of super.c, the aims of
the function is to compute the length from the origin
on the current ray of the two possible intersections with a
box (-1,1) and to order them correctly (hence the max and min
suffixes everywhere)

The intersect_box() itself is made of three big IF block:
one for the X axis, one for the Y axis and one for the Z axis.
For each axis, the intersection is looked for the two planes of
the axis (-1 and 1).
The reuse of tmin and tmax is a potential source of error, because in
the first IF block, tmin and tmax should rather be called xtmax and
xtmin (I guess the t is for temporary). 
As well in the second IF block, they should be ytmax and ytmin;
and in the third and last block, it should be ztmax and ztmin.
At the end of every IF block, the current lengths found (*dmin and
*dmax) are compared with the new intersection. If the intersection
is better suited, the *dmin or/and *dmax are updated.

Now, could you tell me, if I do the replacement inside each IF blocks,
which variables must be used for the two suspected lines ?
Is it xtmax, ytmax or ztmax ?
And why their values would be better than the work done by the
complex IF blocks ?

The fact is that when the code reach these two lines, 
the *dmin and *dmax are already correct, and (it become worst),
sometimes tmin and tmax have the same values (so it does not 
show as a bug), and sometimes tmin and tmax have not
good values (but the z IF block knews that, and did not use
them directly), so the bug shows its missing head !

And to make matter worst, these two lines are not always reached
(often an IF block does the return!).


Medium Answer:

  Yes, the intersect_box code is only used by the superellipoid, so other
objects do not share it. 
 Making the modification still allows to render superellipoid and does
 correct the problems shown by the previous version.
 What do you want more ?

Post a reply to this message

J. Grimbert <jgr### [at] atos-groupcom> wrote:
: But there is no such discontinuity for the superellipsoid.
: It is bounded by a 2 unit sized box and should not escape it;

  Yes, the shape shouldn't have a discontinuity. But it depends on the formula.
Do you know what function povray uses to calculate the superellipsoid.

: (Let's me add, the surface of the superellipsoid is continuous,
: it's not an object with holes.)

  Think about the function: f(x) = x^2/x

  It should be a continuous straight diagonal line. However, it has a
discontinuity, and thus a hole at x=0.
  It just depends on the function.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

> 
> J. Grimbert <jgr### [at] atos-groupcom> wrote:
> : But there is no such discontinuity for the superellipsoid.
> : It is bounded by a 2 unit sized box and should not escape it;
> 
>   Yes, the shape shouldn't have a discontinuity. But it depends on the formula.
> Do you know what function povray uses to calculate the superellipsoid.
> 
> : (Let's me add, the surface of the superellipsoid is continuous,
> : it's not an object with holes.)
> 
>   Think about the function: f(x) = x^2/x
> 
>   It should be a continuous straight diagonal line. However, it has a
> discontinuity, 

Not for mathematician but perhaps for programmer :).

>  and thus a hole at x=0.
>   It just depends on the function.
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp wrote:
> 
> J. Grimbert <jgr### [at] atos-groupcom> wrote:
> : But there is no such discontinuity for the superellipsoid.
> : It is bounded by a 2 unit sized box and should not escape it;
> 
>   Yes, the shape shouldn't have a discontinuity. But it depends on the formula.
> Do you know what function povray uses to calculate the superellipsoid.
> 

It does not matter. The bug is not in the superellipsoid formula, it
is in the 'bounding' box used before the formula (not THE pov bounding box).
It is a simple 6 sided box, and sometimes the computation of the
intersection of the ray with this box is bogus.
And the "sometimes" is limited when the two offending lines are
reach and do something (it happen, also sometime, that *dmin and *dmax
already have the value of tmin and tmax; In such lucky case, nobody
seen the bug, because these two lines do nothing!)

Post a reply to this message

First, I want to apologize for for not following up on the matter after
discovering the bug. It was just before my holidays and after my
holidays I was swamped in Real Work[TM] and forgot about it.

On Fri, 11 Aug 2000 13:21:10 +0200, J. Grimbert wrote:
>   In the intersect_box() code of super.c, the aims of
>the function is to compute the length from the origin
>on the current ray of the two possible intersections with a
>box (-1,1) and to order them correctly (hence the max and min
>suffixes everywhere)
>
>The intersect_box() itself is made of three big IF block:
>one for the X axis, one for the Y axis and one for the Z axis.
>For each axis, the intersection is looked for the two planes of
>the axis (-1 and 1).

Yup.

>The reuse of tmin and tmax is a potential source of error, because in
>the first IF block, tmin and tmax should rather be called xtmax and
>xtmin (I guess the t is for temporary). 
>As well in the second IF block, they should be ytmax and ytmin;
>and in the third and last block, it should be ztmax and ztmin.

Possibly. But tmin and tmax are always just the distance of the
currently considered planes from P, so I guess it makes sense to reuse
the variables (or at least the variable name - personally I would have
declared those variables only in the blocks where they are used).

>At the end of every IF block, the current lengths found (*dmin and
>*dmax) are compared with the new intersection. If the intersection
>is better suited, the *dmin or/and *dmax are updated.

>The fact is that when the code reach these two lines, 
>the *dmin and *dmax are already correct,

I agree with this. The two lines are indeed wrong.

This can be seen most easily in the case where I discovered the bug. If
the ray is parallel to the x axis, intersect_box enters only the first
block, computes *dmin and *dmax correctly (without using tmin and tmax)
and then overwrites the correct values with the values for tmin and
tmax, which still have their default value (0.0).

AFAICS dmin and dmax are always computed correctly. I don't know what
the last two lines are supposed to do, they just don't make sense.
Probably a leftover from an earlier restructuring of the code.

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message

Dear all,

just this weekend in this newsgroup I wanted to post for help
- with my superellipsoids.

Luckily, I see that this bug has already been discussed.

As I am not very deeply involved with POVRAY,
can anyboldy help me with my special problem?

I had rebuild a real tree with the surface of each main branch
represented by such an ellipsoid. With the intention to
create an animation with the camera turning clockwise
round the tree this resulted in some "catastrophic" photos.

The anim can be found in p.b.a. (Bugs in tree anim with superellipsoids).

What shall I do? Omitting them is one but not very good
solution giving annoying jerks.

I am using POV 3.1g (Windows). Is there in the source code
*dmin = tmin;
*dmax = tmax;
to be removed, too?

Thanks for all help!

Dieter

--
**************************************************
University of Goettingen, Faculty of Forest Sciences and Forest Ecology
Institute of Forest Biometry and Informatics
Dr. Dieter Gaffrey                              | Phone: +49 (0)551 393460
Buesgenweg 4                                    | Fax:    +49 (0)551 393465
37077 Goettingen, Germany               | http://www.uni.gaffrey.de

Post a reply to this message

>
> The anim can be found in p.b.a. (Bugs in tree anim with superellipsoids).
>

Due to problem with the upload:

 http://www.uni-forst.gwdg.de/~dgaffre/diverses/tree.avi


Dieter

Post a reply to this message

On Mon, 14 Aug 2000 10:58:11 +0200, Dieter Gaffrey wrote:
>I am using POV 3.1g (Windows). Is there in the source code
>*dmin = tmin;
>*dmax = tmax;
>to be removed, too?

Yes. I don't have the windows source code here to check, but they should
be identical in this respect.

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message