In playing around with isosurfaces, I had included a
mostly-transparent box to help figure out where the edges of the
isosurface were. I just ran into a very odd situation where if that
box is there, my isosurface shows up, but as soon as I take it away,
the isosurface mostly disappears, leaving only the bottom fifth or so.


I tried, just to see if it would change anything, making the display
box completely clear (I thought maybe something strange was happening
with pigments) but that doesn't alter the results. Commenting out the
box removes the majority of the isosurface. Putting the box back in
brings it back. Isosurface by Acme.

Here's the (somewhat bizarre, too) code, using a freshly downloaded
MP0.7 for Windows. I used both versions of FStone, tried switching
sign, accuracy, method, and even the contained_by, and both included
and excluded the explicit F(x,y,z) parameters. I'm out of ideas.
Anyone? Anyone? [Something-D-O-O, Anyone?]


//#declare FStone=function { "Pillow" <1> } 
#declare FStone=function { (x^2-1) & (y^2-1) & (z^2-1) }

#declare FBozo=function {
  pigment {
    bozo
    color_map {
      [0.0 White*0.5]
     
      [1.0 Black]
      } // end cmap 
    scale .5
    }
  }

#declare ChippedGranite=function { noise3d(x*30, y*10, z*80)*0.7 } 

//box { -1.5, 1.5 pigment { Clear } }


isosurface {
  function { FStone(x,y,z)+0 - FBozo(x,y,z) + ChippedGranite(x,y,z) }
  sign 1
  accuracy 0.001
  method 2
  eval
  contained_by { box { -8, 8 } }
  pigment { rgb <.9, .9, 0> }
  finish { specular .6 roughness 1 brilliance .5 }
  }

Post a reply to this message

It seems to be an accuracy-problem for me. Sometimes you have to go really
low with this value (something like 0.000001). Your contained_by{}-box is
way to big and you get better results if it's fits better. And it will be
faster. (Throw that unnecessary '+0' out of the function, it slows down the
iso, too - well a little bit :-))

I get a shape that way (using MegaPov 0.6a), but I'm not sure if it's the
right one.

If that does not help, try setting max_gradient by hand and make it quite
high. Eval don't get everything and you have quite high gradients in that
shape. Everything will get really slow then, though.

I think, the iso appears with the transparent box, 'cause the rays get
shorter and the precision gets higher that way. I may be wrong, though..

Hope that helps,

Marc-Hendrik

Post a reply to this message

On Thu, 15 Mar 2001 19:40:16 +0100, "Marc-Hendrik Bremer"
<Mar### [at] t-onlinede> wrote:

>It seems to be an accuracy-problem for me. Sometimes you have to go really
>low with this value (something like 0.000001). Your contained_by{}-box is
>way to big and you get better results if it's fits better. And it will be
>faster. (Throw that unnecessary '+0' out of the function, it slows down the
>iso, too - well a little bit :-))

Hmm, I had the +0 in there because I stole that formula from a web
page, but I'll happily discard it if it'll speed things up :). Turns
out it was the contained_by box; thanks for pointing that out. I had
changed it earlier to increase it since I had thought maybe it was
getting cut off but I didn't try decreasing the size, which is what
did the trick.

I still don't really know what I'm doing with these things, so I'm
rarely sure why things work the way they do. I think I need to learn
more math.

Post a reply to this message

Tina S. schrieb in Nachricht <3ab10eed.32032954@news.povray.org>...
>On Thu, 15 Mar 2001 19:40:16 +0100, "Marc-Hendrik Bremer"
><Mar### [at] t-onlinede> wrote:
>
>>It seems to be an accuracy-problem for me. Sometimes you have to go really
>>low with this value (something like 0.000001). Your contained_by{}-box is
>>way to big and you get better results if it's fits better. And it will be
>>faster. (Throw that unnecessary '+0' out of the function, it slows down
the
>>iso, too - well a little bit :-))
>
>Hmm, I had the +0 in there because I stole that formula from a web
>page, but I'll happily discard it if it'll speed things up :).

Well, it is reall yjust a little speed up, something like 4:36 to 4:38 in my
testrender. But I have found out that it is good to precompute as much as
you can if it comes to isosurfaces. If you can't calculate the value with
the same precision as Pov does, use a variable, which is as not much slower
than a constant value. The function has to be evaluated over and over while
the iso is rendered, so make the computation as short as possible.
BTW x*x is faster than x^2.

>Turns out it was the contained_by box; thanks for pointing that out. I had
>changed it earlier to increase it since I had thought maybe it was
>getting cut off but I didn't try decreasing the size, which is what
>did the trick.

I don't know why it makes such a difference, since there isn't something
like samples, which are distributed over the container. But it's a good idea
to make it as small as possible for speed reasons.

>I still don't really know what I'm doing with these things, so I'm
>rarely sure why things work the way they do. I think I need to learn
>more math.

Math is useful for isos, but it does not take that much, if you don't want
to make those amazing shapes Tor Olav Kristensen, you will be lucky with
some easy shapes and an idea how to combine them.
Do you know the isosurface manual of the Smellenberghs already? If not, look
at http://users.skynet.be/smellenbergh/. It's a good source and a good
reference.

Marc-Hendrik

Post a reply to this message

"Tina S." wrote:

> In playing around with isosurfaces, I had included a
> mostly-transparent box to help figure out where the edges of the
> isosurface were. I just ran into a very odd situation where if that
> box is there, my isosurface shows up, but as soon as I take it away,
> the isosurface mostly disappears, leaving only the bottom fifth or so.
>

This is very probably a max_gradient problem. It has driven many people
mad before (including me). The trick is to give a proper max_gradient
value instead of relying on eval. A detailed explanation can be found here
:
http://www.econym.demon.co.uk/isotut/keywords.htm

G.

--

**********************
http://www.oyonale.com
**********************
Graphic experiments
Pov-ray gallery

Post a reply to this message

Gilles Tran, the IRTC God, wrote:
>This is very probably a max_gradient problem. It has driven many people
>mad before (including me). The trick is to give a proper max_gradient
>value instead of relying on eval.

I feel a lot better knowing that it drove someone I /know/ has more skill
than me nuts. :)

Thanks to you and Marc. I have started both including max_gradient based
on a prior render with eval and tweaking its value to get slightly
different results, with a lovely increase in speed that gives me hope for
actually being able to finish the ultimate image these tests are meant to
eventually lead to. Between isosurfaces, media, and an intent to use
radiosity, I envision the render time on the ultimate image to be rather
long...

Still saving up for that 1Ghz machine,

Tina

Post a reply to this message