POV-Ray

The Persistence of Vision Raytracer (POV-Ray).

This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.

Tasklist

FS#202 - Numerical oddities in Julia_Fractal

Attached to Project: POV-Ray
Opened by Sven Geier (SGeier) - Friday, 06 May 2011, 23:15 GMT
Last edited by William F Pokorny (wfpokorny) - Wednesday, 16 November 2016, 14:17 GMT
Task Type Definite Bug
Category Backend → Geometric Primitives
Status Tracked on GitHub
Assigned To No-one
Operating System Other
Severity Low
Priority Normal
Reported Version 3.70 RC3
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

I understand that some things have changed in the way certain computations in POV-Ray decide when something is “good enough” and I think this is biting me in Julia_Fractal (where, of course, the highest-resolution computations are needed).

The bug has been posted here:

http://news.povray.org/povray.bugreports/thread/%3Cweb.4dbf2e26b56a53c15b4449250%40news.povray.org%3E/

Including a short .pov file and instructions that reproduce it.

(It pops up in other configurations and view angles as well, but this one captures in in a way that makes it clear it’s a bug: the distance of the camera from the origin appears to change the shape of the rendered object).

This appeared first on a Windows Server 2003 machine, it is apparently confirmable on at least one other system as per that thread.

This task depends upon

Comment by Grimbert Jérôme (Le_Forgeron) - Saturday, 07 May 2011, 08:08 GMT

Just to have all resources here, the relevant code:
There is something about cam_distance changing from 0.7 for 0.5

#version 3.7;

#include "functions.inc"
global_settings { assumed_gamma 2.2 }

#declare cam_distance = 0.7;

camera { angle 45
  location  <10, .5, 0> * cam_distance
  look_at   <0, 0,  -.5>
  right     x*640/400
  rotate <0,-5,0>
}

light_source { 0 color rgb 1 spotlight
  translate <80, 80, -40> point_at 0 }
light_source { 0 color rgb <2,1,0> translate <-20, 40, -20> }
sky_sphere { pigment { gradient -y }}

julia_fractal{ <-1.483,0,-0.0,-0.025>
   quaternion sqr max_iteration 12 precision 500
   texture{
     pigment{ color rgb 0.7}
     finish { phong .6 reflection {.6 metallic }}
   }
   scale 3
   rotate <0,110,-45>
}
Comment by Grimbert Jérôme (Le_Forgeron) - Saturday, 07 May 2011, 09:07 GMT

Please notice: with 0.5 as cam_distance, the camera is inside the bounding box of the fractal

Min : -9.680,-9.680,-7.690
Max : 9.680,9.680,7.690

Which means the camera is probably in the object too.

Using a camera 10 time further (and an angle 10 time narrow, which is a different view) does not produce the same issue.

With original camera, and cam_distance = 0.5+clock/5, there is a visible clipping on frame 14 of 31 (+KI0 +KF1 +KFI0 +KFF30 +H400 +W640)
That's cam_distance 0.59333 , with a camera at 5.911,0.297,0.517

Comment by Christoph Lipka (clipka) - Monday, 09 May 2011, 08:46 GMT

So we probably do have a (pretty old) bug that causes unexpected clipping of fractals when the camera is inside the bounding box.

(No, the camera is not inside the "object" (i.e. part of the actual julia set); that would look much different. If you'd approximate the julia set with tori you'd most certainly not get any clipping.)

Comment by Sven Geier (SGeier) - Monday, 09 May 2011, 19:34 GMT

Yeah, if you copy the Axis_ and AxisXYZ macros from one of the the Basic_Scene_M... files and modify the POV file like this:

union { 
   julia_fractal{ <-1.483,0,-0.0,-0.025>
    ...
   }
   object{ AxisXYZ( 3.5, 3.5, 3.5, Texture_A_Dark, Texture_A_Light)}
   rotate <0,110,-45>
}

you can see that the object itself only extends to ~1.5 units in the y- and z- directions. Also the axes themselves (i.e. the cylinders that are drawn to represent them) are not clipped, only the object. (image attached)

HOWEVER this cannot really be clipping of the object by the camera plane, (at least not the way I understand clipping) since the rings *close* when you move the camera closer. I.e. there is 'clipping' when the camera is moved away from the object (larger cam_distance) but it goes away when I move the camera closer in. Moving the camera ten times farther and making the angle ten times closer does NOT resolve this.

If anything, apparently I need to move the camera even closer in to prevent this.

At cam_distance=0.4 (and angle=60) the object looks like I would expect a Julia set to look like, at cam_distance=0.5 the outer ring starts breaking up and at cam_distance=0.7 (and angle=45) it is wide open. (other image attached for comparison)

Comment by Sven Geier (SGeier) - Friday, 13 May 2011, 01:51 GMT

Here's a small animation, that shows the problem not just in the large ring, but also in the smaller ones.

The only thing that changes with clock is the camera location; I am letting it intentionally go *through* the large ring on the way "out":

#declare cam_distance = 0.6 + 0.55*cos(clock/180*pi);
#declare z_a = 5*sin(clock/180*pi);
camera { angle 60
  location  <10, .5, z_a> * cam_distance 

the rest is as posted before(clock obviously goes 1..360);

If this was an isosurface{}, I would say the max_gradient needs to be higher.

Comment by Christoph Lipka (clipka) - Thursday, 25 August 2011, 14:51 GMT

@thorsten: setting you to responsible as you claim the status is “Investigating”

Comment by Thorsten Fröhlich (thorsten) - Thursday, 25 August 2011, 16:02 GMT

That was an editing error.

Comment by William F Pokorny (wfpokorny) - Wednesday, 16 November 2016, 14:17 GMT
  • Field changed: Status (New → Tracked on GitHub)

Now tracked on github as issue #150.

Loading...