I posted an image in p.b.i. under  the title of "Lines on isosurfaces."
I asked for help about a trivial problem and discovered a more serious
one.  I am using essentially a step function in an isosurface.  I find
that mega refuses to give me any diffuse reflection for this object.

I was using the cells function, I found a similar problem with my
homemade version using ceiling and noise3d.

#declare celly=function{pigment{cells}}
#declare fnoise=16;//40;

isosurface{
                function{y/160-
                celly((x+1000)/fnoise,y/fnoise,(z+1000)/fnoise)
                }
       accuracy 0.01
        threshold  0.0  //  .03
        contained_by {sphere{0,600}
        pigment{SeaGreen}         normal{bumps}
        finish{ambient 0.2}
        }

Post a reply to this message

In article <39c4295a@news.povray.org>, "Greg M. Johnson" 
<"gregj;-)56590\""@aol.c;-)om> wrote:

> I posted an image in p.b.i. under  the title of "Lines on isosurfaces."
> I asked for help about a trivial problem and discovered a more serious
> one.  I am using essentially a step function in an isosurface.  I find
> that mega refuses to give me any diffuse reflection for this object.

I think the most likely explanation is that it can't compute the correct 
normal for those surfaces.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

The irony, Chris, is that it fails where the normal calculation is a
no-brainer: you've got a straight edge there.  The "top" surface is AOK; the
edges for these step functions have diffuse=0.

Chris Huff wrote:

> In article <39c4295a@news.povray.org>, "Greg M. Johnson"
> <"gregj;-)56590\""@aol.c;-)om> wrote:
>
> > I posted an image in p.b.i. under  the title of "Lines on isosurfaces."
> > I asked for help about a trivial problem and discovered a more serious
> > one.  I am using essentially a step function in an isosurface.  I find
> > that mega refuses to give me any diffuse reflection for this object.
>
> I think the most likely explanation is that it can't compute the correct
> normal for those surfaces.
>
> --
> Christopher James Huff
> Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
> TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
>
> <><

Post a reply to this message

In article <39C600D1.36F21F0B@my-dejanews.com>, 
gre### [at] my-dejanewscom wrote:

> The irony, Chris, is that it fails where the normal calculation is a 
> no-brainer: you've got a straight edge there. 

A no-brainer for you, but the computer doesn't know it is a surface, it 
only knows about a point on a ray and differences in a density function.
If the normal is the main problem, tracing three rays could help 
calculate the correct normal. Of course, the normal calculation would be 
1/3rd as fast...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote:

> If the normal is the main problem, tracing three rays could help
> calculate the correct normal. Of course, the normal calculation would be
> 1/3rd as fast...

What is the code for that?  I vaguely remember some kind of code that said
max trace 2 or something

____________
Greg
codes at home.

Post a reply to this message

In article <39C617C3.E9180E3A@my-dejanews.com>, 
gre### [at] my-dejanewscom wrote:

> What is the code for that?  I vaguely remember some kind of code that said
> max trace 2 or something

It hasn't been written yet. :-)
I was thinking of a possible way to fix the problem, sacrificing speed 
to get good normals where they were previously impossible.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote:
> 
> In article <39C617C3.E9180E3A@my-dejanews.com>,
> gre### [at] my-dejanewscom wrote:
> 
> > What is the code for that?  I vaguely remember some kind of code that said
> > max trace 2 or something
> 
> It hasn't been written yet. :-)
	Are you sure? I thought I saw something in the doc about there being
two methods for computing normals in isosurfaces and isoblobs and one of
them looks a lot like what you described...


-- 

* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde...                  * http://www.enst.fr/~jberger
*******************************

Post a reply to this message

<Jer### [at] enstfr> wrote:

> 	Are you sure? I thought I saw something in the doc about there being
> two methods for computing normals in isosurfaces and isoblobs and one of
> them looks a lot like what you described...

That would be the "normal on|off" feature...I don't know the details of 
the different methods, but "normal on" is supposed to be more accurate, 
though it can't be used with functions using noise3d() or atan2().

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote:
> 

> <Jer### [at] enstfr> wrote:
> 
> >       Are you sure? I thought I saw something in the doc about there being
> > two methods for computing normals in isosurfaces and isoblobs and one of
> > them looks a lot like what you described...
> 
> That would be the "normal on|off" feature...I don't know the details of
> the different methods, but "normal on" is supposed to be more accurate,
> though it can't be used with functions using noise3d() or atan2().
> 
	Yes, that's it. I think that "normal off" is less accurate precisely
because it relies on a sampling method. OTOH it works in all cases
whereas "normal on" requires more definitions (in POV's source code, not
in your file) that don't exist for all functions (and maybe can't exist
for some) and therefore is less general.



PS: note that I haven't looked in detail at this part of the code so I
could be completely wrong...
-- 

* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde...                  * http://www.enst.fr/~jberger
*******************************

Post a reply to this message

<Jer### [at] enstfr> wrote:

> Yes, that's it. I think that "normal off" is less accurate precisely 
> because it relies on a sampling method. OTOH it works in all cases 
> whereas "normal on" requires more definitions (in POV's source code, 
> not in your file) that don't exist for all functions (and maybe can't 
> exist for some) and therefore is less general.

But what about the speed? "normal on" is slightly *slower* than the 
original method...and I don't think tracing 3 jittered isosurface rays 
would be very fast.
I had the impression the original method used several (7?) samples of 
the function to determine the normal(sort of like the way MegaPOV 
calculates the normals for patterns, and the way my displace warp 
works). Sampling the *difference in density* in each direction from the 
point, which is much faster than tracing rays.
I could be completely wrong though...I haven't even looked at this code.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message