Heya -- two questions have reared their ugly heads as I mess around with
MegaPOV.  Firstly, there seems to be some portability problems with
respect to isosurfaces -- namely division by zero.  Rendering the
following scene produces two completely different results under Linux
and Windows.  Under the former, the result is pure black.  The latter
spits out a while circle...

#version unofficial MegaPov 0.5;
isosurface{
  function{1/0}
  contained_by {sphere{0,1}}
  threshold .5 pigment {rgb 1}
}
global_settings{ ambient_light 10}
camera {location <2,0,0> look_at <0,0,0>}

I would hesitantly put forth that the all-black version is the "more
correct" version, as the isosurface evaluates to +infinity at every
point -- and +infinity is never equal to 0.5 (the threshold) so there
should be no "surface" at all.

The other, unrelated, quirk is that of nested macro definitions.  Why
does MegaPOV specifically complain about them, and refuse to parse
them?  Is there a workaround?  Because otherwise Chris Colefax's
wonderful spline macro file is useless in MegaPOV..
Thank ye for any enlightenment,
-Alex V.

Post a reply to this message

In article <397CEDA2.548E2CA1@tiac.net>, Alex Vandiver 
<van### [at] tiacnet> wrote:

> Heya -- two questions have reared their ugly heads as I mess around with
> MegaPOV.  Firstly, there seems to be some portability problems with
> respect to isosurfaces -- namely division by zero.  Rendering the
> following scene produces two completely different results under Linux
> and Windows.  Under the former, the result is pure black.  The latter
> spits out a while circle...
...snip...
> I would hesitantly put forth that the all-black version is the "more
> correct" version, as the isosurface evaluates to +infinity at every
> point -- and +infinity is never equal to 0.5 (the threshold) so there
> should be no "surface" at all.

It isn't a very serious problem(you shouldn't expect a surface there 
anyway), and to catch these cases might take too much overhead...I don't 
know the isosurface code very well though. It might be possible to weed 
out functions resulting in these values.
And are you sure about it evaluating to +infinity? I thought it was 
NaN...


> The other, unrelated, quirk is that of nested macro definitions.  Why
> does MegaPOV specifically complain about them, and refuse to parse
> them?  Is there a workaround?  Because otherwise Chris Colefax's
> wonderful spline macro file is useless in MegaPOV..

It could have something to do with the macro speed enhancements...
I thought nested definitions weren't allowed in the official version 
either, but I couldn't find any mention of this restriction in the 
documentation...
Does that spline include require nested macro definitions? I can't think 
of a good reason to use them...I have never used that include, but maybe 
I will download it and try to get it to work.
Couldn't you just use one of the spline patches included in MegaPOV? Or 
are there specific features in Colfax's spline macros which you need?

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Alex Vandiver <van### [at] tiacnet> wrote...
> Firstly, there seems to be some portability problems with
> respect to isosurfaces -- namely division by zero.  Rendering the
> following scene produces two completely different results under Linux
> and Windows.  Under the former, the result is pure black.  The latter
> spits out a while circle...

Yes.  I've known about this problem for a while now, but I don't know
exactly how to fix it (or even how it should be fixed exactly).

> The other, unrelated, quirk is that of nested macro definitions.  Why
> does MegaPOV specifically complain about them, and refuse to parse
> them?  Is there a workaround?  Because otherwise Chris Colefax's
> wonderful spline macro file is useless in MegaPOV..

Nested macro definitions are not necessary (and really should be avoided).
Programmers tend to think that nesting macro definitions is necessary (to
keep the "scope" of variables), but you need to remember that POV-Ray
scripting uses dynamic scoping rules, so that whether or not a variable
exists depends on when and where the code is RUN, not where it is DECLARED.
You can declare macros apart from each-other, and then just use them in a
nested way.

This...

#macro a()
  #macro b()
    // do stuff for macro b
  #end // macro b
  // do stuff for macro a
#end // macro a

...means the same thing as this...

#macro a()
  // do stuff for macro a
#end // macro a

#macro b()
  // do stuff for macro b
#end // macro b

...except that you can't do the first one in MegaPov.  You can simply
un-nest the nested macros and everything should work perfectly.

-Nathan

Post a reply to this message

Nathan Kopp wrote:

> Nested macro definitions are not necessary (and really should be avoided).

Except where "dynamic" macros are used.  Take the following snippet:

#macro a(foo)
  #if (foo)
    #macro b()
      // do one thing
    #end // macro b, first possibility
  #else
    #macro b()
      // do something else
    #end // macro b, second possibility
  #end // if statement
#end // macro a

..which unfortunatly can't be unrolled in the way you describe.  The above
method has the useful effect, because of the dynamic scoping rules you mention,
of making macro b() defined after macro a() ends, and available to the rest of
the program -- but with differing effects based on the value of foo!  Things
like the spline include use this to dynamically declare what a "segment" of the
spline is made of, so that the later call which actually creates the spilne is
oblivious to the type of spline it is creating.
-Alex V.

Post a reply to this message

Chris Huff wrote:

> And are you sure about it evaluating to +infinity? I thought it was
> NaN...

No, I'm not at all sure. It's quite possible that it's NaN.

> It could have something to do with the macro speed enhancements...
> I thought nested definitions weren't allowed in the official version
> either, but I couldn't find any mention of this restriction in the
> documentation...

Nested definitions are apparently perfectly happy in the official version.

> Does that spline include require nested macro definitions? I can't think
> of a good reason to use them...

See my reply to Nathan in this thread, about "dynamic" macros.

> Couldn't you just use one of the spline patches included in MegaPOV? Or
> are there specific features in Colfax's spline macros which you need?

Partially.  the spline macros allow for such interesting beasts as blob
splines, as well as several very handy tweaking parameters.  However, if the
"no nested macros" rule is set in stone, it would probably be possible to
re-write it in terms of "keyword" splines.  Just wondering if there was any
great reason that I did not know of that was swaying the decision either way..

-Alex V.

Post a reply to this message

>It isn't a very serious problem(you shouldn't expect a surface there
>anyway), and to catch these cases might take too much overhead...I don't
>know the isosurface code very well though. It might be possible to weed
>out functions resulting in these values.
>And are you sure about it evaluating to +infinity? I thought it was
>NaN...
>
>

Depends. If you play with the mathematics it can be proved that
x/0 = infinity where x!= 0 and that 0/0 can equal any number.

Generally however division by zero is undefined.

Gail
********************************************************************
* gsh### [at] monotixcoza              * Reality.dat not found         *
* http://www.rucus.ru.ac.za/~gail/ * Attempting to reboot universe *
********************************************************************
* The best way to accelerate Windows NT is at 9.8 m/s^2      *
********************************************************************

Post a reply to this message

In article <397D11B1.18DE50F5@tiac.net> , Alex Vandiver <van### [at] tiacnet>
wrote:

> #macro a(foo)
>   #if (foo)
>     #macro b()
>       // do one thing
>     #end // macro b, first possibility
>   #else
>     #macro b()
>       // do something else
>     #end // macro b, second possibility
>   #end // if statement
> #end // macro a
>
> ..which unfortunatly can't be unrolled in the way you describe.

Yes it can:

#macro b_version1()
  // do one thing
#end // macro b, first possibility

#macro b_version2()
  // do something else
#end // macro b, second possibility

#macro a(foo)
  #if (foo)
    // call b_version1
  #else
    // call b_version2
  #end // if statement
#end // macro a

Post a reply to this message

Alex Vandiver <van### [at] tiacnet> wrote:
: Firstly, there seems to be some portability problems with
: respect to isosurfaces -- namely division by zero.  Rendering the
: following scene produces two completely different results under Linux
: and Windows.

  Actually it's not a portability problem. As far as I know, the C standard
says that if a division by 0 occurs, the compiler is free to do whatever
it wants. It can return some value, it can terminate the program with an
error, it can draw a nude woman on your screen... whatever it wants.
  So you can't expect anything if you make a division by 0.

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

Nathan Kopp <Nat### [at] koppcom> wrote:
: Yes.  I've known about this problem for a while now, but I don't know
: exactly how to fix it (or even how it should be fixed exactly).

  I don't think there's any portable way of detecting whether the FPU (or
the CPU for that matter) made a division by 0 or not.
  Since we are handling real numbers here (the set or real numbers does not
have +infinity nor -infinity), a division by 0 is undefined, so there's no
"correct" behaviour if it happens.
  Even if we had +infinity and -infinity, the value of 1/x when x is 0 is
undefined. You can't actually say whether it's +infinity or -infinity since
it depends on which side of the y-axis you are looking from (ie. if x
approaches 0 from the positive values, the result will approach +infinity,
but if it approaches from negative values it will be -infinity).

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

Gail Shaw <gsh### [at] monotixcoza> wrote:
: Depends. If you play with the mathematics it can be proved that
: x/0 = infinity where x!= 0

  Nope:

-1/0 = -infinity

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