I've just noticed that the behaviour of the two operators | and & has changed again
(at least in functions). With MegaPov I could make unions between isosurfaces with
the operator |. With the last beta, I managed to accomplish the same result with &.
In beta 10 neither work. I have to use min (f1,f2). Am I the only fool who is
surprised by this?

Ok, just in case this is a known bug/feature, I have a bonus question: why do I need
to translate the iso by a little amount in order to avoid a "floating-point
exception" fatal error? Why if I translate it along the x instead of z (or y) the
trick doesn't work? Shouldn't the iso remain the same since I'm not translating it at
a 'function level'?

POV-Ray beta 10 Windows ME Athlon.

#include "functions.inc"

#declare USE_AMPERSAND = off;
#declare USE_TRANSLATE = on;

#declare f_triv = function {f_helix2
(x,y,z,0,6.8,-sin(y*pi/5.5)*0.3*(y/2-abs(y)/2)/y,0.25,0,1,0)}
#declare cilindro = function {x^2+z^2-(0.25+min(0,y/5)*0.2)^2}

#if (USE_AMPERSAND)
#declare trivella=
isosurface {
    function {cilindro(x,y,z)&f_triv(x,y,z)}
    accuracy 10^-2
    max_gradient 1.943
    contained_by {box{<-0.7,1,-0.7>,<0.7,-5,0.7>}}
    pigment {rgb 1}
   #if (USE_TRANSLATE) translate 0.0001*z #end
}

#else

#declare trivella=
isosurface {
    function {min (cilindro(x,y,z),f_triv(x,y,z))}
    accuracy 10^-2
    max_gradient 1.943
    contained_by {box{<-0.7,1,-0.7>,<0.7,-5,0.7>}}
    pigment {rgb 1}
   #if (USE_TRANSLATE) translate 0.0001*z #end
}

#end

object {trivella}

camera {
    location <0,2,-10>
    look_at 0
}

light_source {
    <50,50,-50>
    rgb 1}


--
#local j=text{ttf"arial""JRG".2,0}#local J=0;#while(J<10)#local R=0;#while
(R<2)#local G=0;#while(G<1)#if(inside(j<R,G.1>))object{j scale.025translate
<R-1G-J/20J/-40+2>pigment{rgb<9J>}}#debug"O"#else#debug" "#end#local G=G+
.025;#end#local R=R+.05;#debug"\n"#end#local J=J+1;#end// JRG

Home: http://digilander.iol.it/jrgpov  //New: Kitchen scene WIP

Post a reply to this message

JRG wrote:
> With MegaPov I could make unions between isosurfaces with the
> operator |. With the last beta, I managed to accomplish the same
> result with &. In beta 10 neither work. I have to use min (f1,f2).
> Am I the only fool who is surprised by this?

I noticed exactly the same behavior, but didn't have energy to extract
the problem. I assumed that if there were a real problem, some of you
people with more credibility would have already reported it :-).

System I am using: W2ksp2, 3.5beta10.

-- 
          /"\                           |    iki.
          \ /     ASCII Ribbon Campaign |    fi/
           X      Against HTML Mail     |    zds
          / \

Post a reply to this message

JRG <jrg### [at] hotmailcom> wrote:
: With MegaPov I could

  That's the source of your problem. POV-Ray 3.5 is not MegaPov.

  (More specifically: & and | were changed to be logical binary operators
instead of being set intersection and union operators.)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

In article <3c5b3764$1@news.povray.org> , "JRG" <jrg### [at] hotmailcom> wrote:

> I've just noticed that the behaviour of the two operators | and & has changed
> again (at least in functions). With MegaPov I could make unions between
> isosurfaces with the operator |. With the last beta, I managed to accomplish
> the same result with &. In beta 10 neither work. I have to use min (f1,f2).

Yes, "and"/"or" work the same way as everywhere else in POV-Ray now.  Before
they were nothing more than synonyms for "min"/"max".  This had been mentioned
in this group several times.  However, I am not sure if the docs are updated
in beta 10 or not.

> Ok, just in case this is a known bug/feature, I have a bonus question: why do
> I need to translate the iso by a little amount in order to avoid a
> "floating-point exception" fatal error? Why if I translate it along the x
> instead of z (or y) the trick doesn't work? Shouldn't the iso remain the same
> since I'm not translating it at a 'function level'?

Because you divide something by "y".  If "y" happens to be zero, you get the
error because, as you know, the division by zero is not defined.  Depending on
what you want to do, you have to use "select" and assign an appropriate value
to divide by if "y" is zero.  The value to use depends on your function,
starting with a very small number might be a good idea.  If it doesn't give
you good results, in some functions using one works as well.

    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" wrote:
> Yes, "and"/"or" work the same way as everywhere else in POV-Ray now.  Before
> they were nothing more than synonyms for "min"/"max".  This had been mentioned
> in this group several times.  However, I am not sure if the docs are updated
> in beta 10 or not.

Sorry, I missed that. But, yes, the present behaviour seems logical.

> Because you divide something by "y".  If "y" happens to be zero, you get the
> error because, as you know, the division by zero is not defined.  Depending on
> what you want to do, you have to use "select" and assign an appropriate value
> to divide by if "y" is zero.  The value to use depends on your function,
> starting with a very small number might be a good idea.  If it doesn't give
> you good results, in some functions using one works as well.

I did use divisions by zero many times before, and all I got was weird surfaces at
most.
Assuming that divisions by zero have to be avoided, I believed that functions in
isosurfaces were *parsed* (I know they are evaluated during the rendering) before the
transformations. I mean, the shape (thus the function) does not change if you
translate the iso anywhere you want.

--
Jonathan.

Post a reply to this message

"Warp" wrote:
>   That's the source of your problem. POV-Ray 3.5 is not MegaPov.

I know that. But in last betas it worked pretty much the same (just | and & were
inverted).

>   (More specifically: & and | were changed to be logical binary operators
> instead of being set intersection and union operators.)

Yes, now I know. Min and max work perfectly.

Post a reply to this message

In article <3c5bafb4@news.povray.org> , "JRG" <jrg### [at] hotmailcom> wrote:

> Assuming that divisions by zero have to be avoided, I
> believed that functions in isosurfaces were *parsed* (I know they are
> evaluated during the rendering) before the transformations. I mean, the shape
> (thus the function) does not change if you translate the iso anywhere you
> want.

Ah, now I see your problem.  You completely misunderstand why it sometimes
appears and why not.  Translating does not change anything but the points that
are evaluated.  With some translations you are just lucky that "y" will never
be zero when rendering with a specific resolution.  There is no way to predict
when "y" will be zero and when it will not be.

> I did use divisions by zero many times before, and all I got was weird
> surfaces at most.

You got those because for many other reasons that having nothing to do with
the division by zero.  I.e. if you are referring to MegaPOV, I think it would
crash (on Windows and Linux at least, on Macs division by zero excepts don't
cause programs to be terminated) if there really was a division by zero.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message