> 
> 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

> >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.
>

Has anybody already the corrected and translated windows source code?
I would be very glad if I can get it.

Dieter

Post a reply to this message

On Thu, 10 Aug 2000 12:04:07 +0200, J. Grimbert wrote:
>Any volonteer to post a message to povray.bugreports ?

I just posted a summary of your analysis and a patch to
povray.bugreports.

	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

On Sun, 13 Aug 2000 12:26:02 +0200, Peter J. Holzer wrote:
>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).

And it wouldn't have compiled on every possible machine.  This is C, not
C++.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

On 20 Aug 2000 23:47:55 -0400, Ron Parker wrote:
>On Sun, 13 Aug 2000 12:26:02 +0200, Peter J. Holzer wrote:
>>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).
>
>And it wouldn't have compiled on every possible machine.  This is C, not
>C++.

In C you can declare variables at the start of every block. I don't know if
this has always been the case, but I am reasonably sure it was already
in K&R I 1978 (it's in the German translation of that book, which was
published 5 years later).

	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