I thought I had everything working in my POV-Ray v3.1g port for OpenVMS
UNTIL I tried the radiosity demo scene.

It would parse the image and then go into an infinite loop rendering
line #1.

A quick look showed me that the ot_point_in_node() test called in
ot_index_box() is always FALSE so the loop there is infinite (
while(!done) ).
It takes quite a bit of CPU actually doing not too much. The

  return(point[X] >= lox && point[X] < hix &&
         point[Y] >= loy && point[Y] < hiy &&
         point[Z] >= loz && point[Z] < hiz);

is mainly translated into things such as

  -11.800113 >= -10000000.000000 && -11.800113 < -10000000.000000
   -2.364801 >= -10000000.000000 &&  -2.364801 < -10000000.000000
    5.109679 >= -10000000.000000 &&   5.109679 < -10000000.000000

The main reason for that is that the funcky union does not seem to do
what was intended (whatever that is). The conversion sized = (DBL)
size.f;
always leads to 0.0 and consequently, minx = miny = minx = - OT_BIAS
and lox = hix = loy = hiy = loz = hiz = - OT_BIAS as well.
                                                                      
BTW : (DBL) size.f; is bound to lead to 0.0 because the TRACER already
complains that size.f is an illegal float (i.e. goes beyong a float).
There
is no way to get the above test pass in such conditions.

This way of playing with union of float and double is highly
unrecommended.
 
I got around the problem and by doing the folowing

	- In octree.c line 547 you change

  	  sized = (DBL) size.f;
 		to
  	  sized = size.l;

I have no clue if that was the intent but this allows the program to get
unstuck and does appear to work and the radiosity demo scene comes out
properly.

So I'm asking what the intent here was and if what I've done breaks
anything or would cause any other problems.

-- 

 +--------------------------+----------------------------------------+
 | Robert Alan Byer         | "I don't want to take over the world,  |
 | bye### [at] mailourserversnet |  just my own little part of it."       |
 | Phone: (317)357-2724     | http://www.ourservers.net/~byer        |
 +--------------------------+----------------------------------------+
 | Send an E-mail request to obtain my PGP key.        ICQ #65926579 |
 +-------------------------------------------------------------------+

Post a reply to this message

I don't understand. How can you have all these problems with the core
source of povray in VMS when nobody else has the same problems? It looks like
you don't have the same source codes as anyone else has.

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

Post a reply to this message

The comments for ot_index_box() in octree.c contain the following text:

*   PORTABILITY WARNING:  this function REQUIRES IEEE single precision
floating
*   point format to work.  This is true of most common systems except VAXen,
*   Crays, and Alpha AXP in VAX compatibility mode.  Local "float" variables
*   can NOT be made double precision "double" or "DBL".

-Nathan

Robert Alan Byer <bye### [at] mailourserversnet> wrote...
> I thought I had everything working in my POV-Ray v3.1g port for OpenVMS
> UNTIL I tried the radiosity demo scene.
>

Post a reply to this message

Nathan Kopp <Nat### [at] koppcom> wrote:
: *   PORTABILITY WARNING:  this function REQUIRES IEEE single precision
: floating
: *   point format to work.

  Why?

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

Post a reply to this message

> 
>   I don't understand. How can you have all these problems with the core
> source of povray in VMS when nobody else has the same problems? It looks like
> you don't have the same source codes as anyone else has.
>

I'm using the stock "povuni_s.tgz" from the Unix Download page at the
POV-Ray site.

Plus the fact that I'm NOT Unix or Linux of any kind, I'm porting
the Unix code over to OpenVMS which is slightly different.
 
-- 

 +--------------------------+----------------------------------------+
 | Robert Alan Byer         | "I don't want to take over the world,  |
 | bye### [at] mailourserversnet |  just my own little part of it."       |
 | Phone: (317)357-2724     | http://www.ourservers.net/~byer        |
 +--------------------------+----------------------------------------+
 | Send an E-mail request to obtain my PGP key.        ICQ #65926579 |
 +-------------------------------------------------------------------+

Post a reply to this message

> 
> The comments for ot_index_box() in octree.c contain the following text:
> 
> *   PORTABILITY WARNING:  this function REQUIRES IEEE single precision
> floating
> *   point format to work.  This is true of most common systems except VAXen,
> *   Crays, and Alpha AXP in VAX compatibility mode.  Local "float" variables
> *   can NOT be made double precision "double" or "DBL".
> 
> -Nathan

(Doing best Homer Simpson impersonation)  DOOOOOOHHHHHH

Might help if I actually read :}~

-- 

 +--------------------------+----------------------------------------+
 | Robert Alan Byer         | "I don't want to take over the world,  |
 | bye### [at] mailourserversnet |  just my own little part of it."       |
 | Phone: (317)357-2724     | http://www.ourservers.net/~byer        |
 +--------------------------+----------------------------------------+
 | Send an E-mail request to obtain my PGP key.        ICQ #65926579 |
 +-------------------------------------------------------------------+

Post a reply to this message

Nieminen Juha <war### [at] sarakerttunencstutfi> wrote...
> Nathan Kopp <Nat### [at] koppcom> wrote:
> : *   PORTABILITY WARNING:  this function REQUIRES IEEE single precision
> : floating
> : *   point format to work.
>
>   Why?

Later in the code you'll run across these two cryptic operations and
comments that describe them.

First,

  /*
   * This hex operation does a floor to next lower power of 2, by clearing
   * all of the mantissa bits.  Works only on IEEE single precision floats
   */
  convert.f = maxdel;
  convert.l &= 0xff800000;
  bsized = (DBL) convert.f;

And later,
  /*
   * This magic hex operation extracts the exponent, which gives us an
   * integer number suitable for labelling a range of a power of 2.  In IEEE
   * format, value = pow(2,exponent-127). Therefore, if our index is, say,
   * 129, then the item has a maximum extent of (2 to the (129-127)), or
   * about 4 space units.
   */
  convert.f = (float) bsized;
  base_id.Size = (convert.l & 0x7f800000) >> 23;


The variable "convert" is defined as follows:
  union
  {
    float f;
    long l;
  }
  convert;


A portable version of these operations could be written, using logrithms and
fractional powers, but it would be significantly slower.  I suggest #ifdef
blocks so that VAX and other non-IEEE-compliant systems will be able to run
this code, even if it does have to run slowly.

-Nathan

Post a reply to this message

>
> fractional powers, but it would be significantly slower.  I suggest #ifdef
> blocks so that VAX and other non-IEEE-compliant systems will be able to run
> this code, even if it does have to run slowly.
>

This is what so far has been done to keep compatibility.  I'm looking
into this
more as I have been told that the newer compiler has a IEEE float
compliant
setting.

-- 

 +--------------------------+----------------------------------------+
 | Robert Alan Byer         | "I don't want to take over the world,  |
 | bye### [at] mailourserversnet |  just my own little part of it."       |
 | Phone: (317)357-2724     | http://www.ourservers.net/~byer        |
 +--------------------------+----------------------------------------+
 | Send an E-mail request to obtain my PGP key.        ICQ #65926579 |
 +-------------------------------------------------------------------+

Post a reply to this message

Eeew, what a horrid way to treat floats.

Post a reply to this message

Nathan Kopp <Nat### [at] koppcom> wrote:
: A portable version of these operations could be written, using logrithms and
: fractional powers, but it would be significantly slower.  I suggest #ifdef
: blocks so that VAX and other non-IEEE-compliant systems will be able to run
: this code, even if it does have to run slowly.

  I definitely agree. Optimizations are ok, but there should always be the
possibility of compiling it in any system.

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

Post a reply to this message