POV-Ray : Newsgroups : povray.binaries.images : isosurfaces problems Server Time
13 May 2024 17:54:17 EDT (-0400)
  isosurfaces problems (Message 1 to 6 of 6)  
From: MichaelJF
Subject: isosurfaces problems
Date: 9 Nov 2015 15:05:02
Message: <web.5640fc5483741fd416a9e0e50@news.povray.org>
Here is an Image, taken with the characteristic function (0 or 1) of the
mandelbulb. I can see no flaws with this isosurface.

Best regards,
Michael


Post a reply to this message


Attachments:
Download 'tok_mjf04_02_02.png' (1621 KB)

Preview of image 'tok_mjf04_02_02.png'
tok_mjf04_02_02.png


 

From: MichaelJF
Subject: Re: isosurfaces problems
Date: 9 Nov 2015 15:35:00
Message: <web.564102bb125f4bcb16a9e0e50@news.povray.org>
"MichaelJF" <mi-### [at] t-onlinede> wrote:
> Here is an Image, taken with the characteristic function (0 or 1) of the
> mandelbulb. I can see no flaws with this isosurface.
>
> Best regards,
> Michael

I posted this Image as an example to the discussion at

http://news.povray.org/povray.advanced-users/message/%3Cweb.5640e6d31758bc6a16a9e0e50%40news.povray.org%3E/#%3Cweb.5640
e6d31758bc6a16a9e0e50%40news.povray.org%3E

Best regards,
Michael


Post a reply to this message

From: MichaelJF
Subject: Re: isosurfaces problems
Date: 13 Nov 2015 12:30:01
Message: <web.56461dda125f4bcb36d0bf360@news.povray.org>
Here is the first of two technical images,  the third can be ruled out. As I
first studied the discussion between Waggy and Tor Olav I misunderstood the
given explanations there. See

http://news.povray.org/povray.binaries.scene-files/thread/%3C4b2c7b3f%40news.povray.org%3E/

Tor Olav states there that his distance estimation function has to be improved
likely. And Waggy explained the idea behind this functions but I was to stupid
to comprehend this at first reading. In fact the original code of Tor Olav
rendered 31 minutes, but yielded a very smooth superset of the mandelbulb only.

There exists a lot of alternative formulas to generate mandelbulb like
structures. One of them is the use of the inbuild functions f_th and f_ph from
functions.inc, which return polar coordinates. Tor Olav uses this approach but
it is different from the mandelbulb first posted ever. I changed this in his
code to the original formula.

Despite the claim within the POV-docs that atan2(A,B) can handle the value B=0
("Returns appropriate value even if B is Zero") I get range violations in this
case and the render fails. So I had to use a work around. Simple, but may the
one or other can use it (see code below).

I still kept Tor Olav's wonderful technique to turn a recursive function into an
iterative one since recursive function calls are not supported by POV
officially. In most cases they work, but it is not guaranteed.

Here is the image using the distance estimation function proposed by Scott. I
still observe some problems (there seems to be some kind of bridges at the
right). To the left is an visualisation of the mandelbulb function as a pigment
function taken at the middle of the container object. It uses
   color_map {
      [0 Red ]
      [0.5 Yellow ]
      [1 Cyan ]
   }
I rendered this to get a better understanding of the distance estimation
function (orange to red here). Note that Cyan indicates negative values close to
zero here (and not close to one).

Rendering time was 18 h 28 m. I think Scott's GPU approach will be a little bit
faster then POV.

Best regards,
Michael



/**************************************************************/
Code for the image:
/**************************************************************/
#version 3.7;

#include "colors.inc"
#include "functions.inc" // For f_r(), f_ph() and f_th()
#include "rad_def.inc"

global_settings { max_trace_level 256 radiosity {
Rad_Settings(Radiosity_OutdoorLQ,no,no) } }

#declare Atan2 = function(u,v){
   select ( v,
            select(u,atan2(u/v,1)-pi,atan2(u/v,1)+pi),// v<0
            select(u,-pi/2,0,pi/2),// v=0
            atan2(u/v,1)// v>0
          )
}


#macro MandelBulbFunction(R_Pwr, R_BO, Ph_Pwr, Ph_Phase, Th_Pwr, Max_Iter)

  #local ln_R_BO = ln(R_BO);
  #local ln_R_Pwr = ln(R_Pwr);
  #local J = Max_Iter - 1;
  #local MB_Fns = array[Max_Iter][2]
  #local I = Max_Iter;
  #while (I > 0)
    #local I = I - 1;
    #local MB_Fns[I][1] =
      function(x, y, z, _r, _rp, _ph, _th, _dr) {
        #if (I = J)
          0.5*ln(_r)*_r/_dr//0
        #else
          select(
            _r - R_BO,
            MB_Fns[I+1][0](
              x,
              y,
              z,
/*********************************************  TOK
              x + _rp*cos(_ph)*cos(_th),
              y + _rp*sin(_ph),
              z + _rp*cos(_ph)*sin(_th),
*********************************************/
              x + _rp*sin(_th)*cos(_ph),
              y + _rp*sin(_th)*sin(_ph),
              z + _rp*cos(_th),
              _dr*_rp/_r*R_Pwr+1
            ),
            // 1/(I - ln(ln(_r)/ln_R_BO)/ln_R_Pwr) // TOK
            0.5*ln(_r)*_r/_dr
          )
        #end // if
      }
    #local MB_Fns[I][0] =
      function(x, y, z, _ix, _iy, _iz,_dr) {
        MB_Fns[I][1](
          x,
          y,
          z,
          f_r(_ix, _iy, _iz),
          pow(f_r(_ix, _iy, _iz), R_Pwr),
/************************************************ TOK
          Ph_Pwr*(f_ph(_ix, _iy, _iz) + Ph_Phase),
          Th_Pwr*f_th(_ix, _iy, _iz),
*************************************************/
          Ph_Pwr*Atan2(_iy,_ix),
          Th_Pwr*Atan2(sqrt(_ix*_ix+_iy*_iy),_iz),
          _dr
        )
      }
  #end // while

  function { MB_Fns[0][0](x, y, z, x, y, z, 1) }

#end // macro MandelBulbFunction


#declare CamPos=<0,0,-3>;

#declare Power_Radius = 8;// TOK: 8;
#declare Power_Phi = 8; // TOK: 8;
#declare Power_Theta = 8; // TOK: 8;

#declare Bailout_Radius = 2; // TOK: 3.0;
#declare Phase_Phi = 0; //TOK: pi/2;
#declare Max_Iterations = 64; // TOK: 5;


#declare Pigm=pigment {
  MandelBulbFunction(
    Power_Radius,
    Bailout_Radius,
    Power_Phi,
    Phase_Phi,
    Power_Theta,
    Max_Iterations
  )
   color_map {
      [0 Red ]
      [0.5 Yellow ]
      [1 Cyan ]
   }
}



difference {
   sphere { 0,1.2 }
   box { <-2,-2,-2>,<2,2,0> }
   pigment { Pigm }
   translate <-1.3,0,0>
}

#declare MandelBulb=isosurface {
  MandelBulbFunction(
    Power_Radius,
    Bailout_Radius,
    Power_Phi,
    Phase_Phi,
    Power_Theta,
    Max_Iterations
  )
  threshold 0
  max_gradient 1000 // TOK: 20 // This value should probably be increased
  accuracy 0.001
  contained_by { sphere { <0, 0, 0>, 1.2 } }
  texture {
    pigment { color Cyan }
  }
}
object { MandelBulb
  translate <1.3,0,0>
}


light_source {
  <2, 2, 2>*100
  color White
}

light_source {
  <2, -2, -2>*100
  color White
}

light_source {
  CamPos+0.25*x
  color White
}


camera {
  location CamPos
  up y
  right image_width/image_height*x
  look_at <0, 0, 0>
}

background { color Gray40 + Blue }


Post a reply to this message


Attachments:
Download 'test_scott.png' (599 KB)

Preview of image 'test_scott.png'
test_scott.png


 

From: scott
Subject: Re: isosurfaces problems
Date: 16 Nov 2015 03:21:08
Message: <564991f4$1@news.povray.org>
> Tor Olav states there that his distance estimation function has to be improved
> likely. And Waggy explained the idea behind this functions but I was to stupid
> to comprehend this at first reading. In fact the original code of Tor Olav
> rendered 31 minutes, but yielded a very smooth superset of the mandelbulb only.

The Max_Iterations limit will control how smooth or detailed the surface 
is. 64 is really a bit OTT for a render that shows the entire 
mandelbulb, I primarily put it that high so that when you zoomed right 
in there was still a lot of detail. You might try reducing it to speed 
things up.

> Here is the image using the distance estimation function proposed by Scott. I
> still observe some problems (there seems to be some kind of bridges at the
> right). To the left is an visualisation of the mandelbulb function as a pigment
> function taken at the middle of the container object. It uses
>     color_map {
>        [0 Red ]
>        [0.5 Yellow ]
>        [1 Cyan ]
>     }
> I rendered this to get a better understanding of the distance estimation
> function (orange to red here). Note that Cyan indicates negative values close to
> zero here (and not close to one).

That's a good idea, I hadn't thought of that - it's interesting to see 
what the range of values actually is.

> Rendering time was 18 h 28 m. I think Scott's GPU approach will be a little bit
> faster then POV.

Well mine (obviously) depends on the GPU you have available, if you have 
a card older than a year or so then it's highly probably it will take an 
infinite amount of time to complete :-) On a modern nVidia 970 it can 
manage of the order of 10fps, which means after 5-10 seconds you've got 
a nice anti-aliased image (once you stop moving the camera it 
continually averages the new frames together).


Post a reply to this message

From: MichaelJF
Subject: Re: isosurfaces problems
Date: 16 Nov 2015 11:30:01
Message: <web.564a03e2125f4bcbb6de0e0c0@news.povray.org>
Changing only three lines in the code given above one yields a somewhat similiar
but in detail very different image. The three changes are (1) returning 0 in
case of assumed boundedness, (2) returning 1 in case of (assumed) divergence and
(3) raising the isosurface threshold from 0 to 0.5. This results in a
dichotomous function representing the isosurface. In consequence to the left one
has only the values 1 (Cyan) and 0 (Red). I see more details but stronger
artifacts on the other side.

Under comparable conditions the rendering time was a bit shorter now: 7 h 48 m.

That is less than a half of the time the approach with the distance estimation
function needed which was intended to accelerate the solver originally. Since I
have no idea what solver POV uses to compute the surface of an isosurface (and I
have not the wits to work through the POV sources for it) I would be happy if
someone of the more involved can name the algorithm used by POV to solve this
unexpected riddle.

If someone finds a flaw in my modification of Tor Olav's code I would be happy
as well since four eyes see more then two.

Best regards,
Michael

A short note: Originally I wrote this post after the image was rendered while
watching a game of soccer between France and Germany at the late evening of
Friday 13/11/2015. During the game it became more and more clear that Paris got
under attack by IS terrorists. I was not in the mood to post something about
mandelbulbs while innocent people were killed at Paris.


Post a reply to this message


Attachments:
Download 'test_dicho.png' (534 KB)

Preview of image 'test_dicho.png'
test_dicho.png


 

From: scott
Subject: Re: isosurfaces problems
Date: 17 Nov 2015 03:41:07
Message: <564ae823$1@news.povray.org>
> That is less than a half of the time the approach with the distance estimation
> function needed which was intended to accelerate the solver originally. Since I
> have no idea what solver POV uses to compute the surface of an isosurface (and I
> have not the wits to work through the POV sources for it) I would be happy if
> someone of the more involved can name the algorithm used by POV to solve this
> unexpected riddle.

One name for it is "sphere tracing". So called because at each point 
along the ray POV determines the largest sphere that doesn't intersect 
the surface. It then moves the radius of this sphere along the ray and 
repeats. The radius of the "largest sphere" is determined by the 
function value at that point divided by the "max_gradient".

The fact it takes longer with the D.E. function might be because you 
have not optimised "max_gradient" in the isosurface. "max_gradient" 
needs to be chosen specifically for each function you use in an 
isosurface. In your D.E. version I was able to reduce it from 1000 to 
0.5 without any obvious impact on the image (you will probably need to 
experiment a bit to determine the optimum value). Max_Iterations 
probably doesn't need to be as high as 64 for a wide-angle shot of the 
entire mandelbulb.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.