Welcome to Fractal Forums

Fractal Math, Chaos Theory & Research => (new) Theories & Research => Topic started by: M Benesi on January 09, 2016, 07:41:24 AM




Title: Quantized Space for DE and easier (mathematical) object manipulation
Post by: M Benesi on January 09, 2016, 07:41:24 AM
  I'm thinking about setting up a multidimensional array to hold orbitTrap information and distance estimates.  Rough idea follows.

Code:
vec4   is a 4 dimensional vector

pixel_resolution_3d =  pixel resolution of 3d array;
   //if pixel_resolution_3d=.05      (-.71,.18,.23) =  (-.70,.20,.25)

arrayElements = elements of x,y, and z in the array;  //set odd because of origin

arrayBoundingCubeEdgeLength =  pixel_resolution_3d * (arrayElements-1);

// outside of the array bounding cube, distance is calculated the old way

x_int, y_int, z_int = integer value of pixels with range of  [1 to arrayElements]

  if  (arrayElements==513)  
     x_int, y_int, and z_int    range from 1 to 513  

     (0.,0.,0.) = (x_int=257, y_int=257, z_int=257)

  halfBCEL= arrayBoundingCubeEdgeLength/2;   //half the bounding cube edge length

     (-halfBCEL, -halfBCEL, -halfBCEL) = (x_int=1, y_int=1, z_int=1)    =  (1,1,1)  
     ( halfBCEL,  halfBCEL,  halfBCEL) = (x_int=513, y_int=513, z_int=513)   =  (513,513,513)


  At every (x_int, y_int, z_int)  store orbitTrap and DE information for each iteration
(or application) of formulas so that we can use the data if we want to start recalculating
 from a slightly earlier iteration:

vec4   pointData [x_int][y_int][z_int][iteration] =  
    vec4 (x_orbit [iteration], y_orbit [iteration], z_orbit[iteration], DE [iteration])

   //note we can recover our running derivative, dr (or whatever you call it), from our DE using
the x,y,and z orbit values for the last iteration, so we have ALL of the information available to
us to us in the above 4-dimensional array of a 4 dimensional vector

pointData [1][1][1][8]  would be the point data for the 8th iteration of formulas
applied at the point (-halfBCEL, -halfBCEL, -halfBCEL)


  Why do this?

Code:
  1)  Streamline (reduce compute cost of) fractal calculation (ray paths cross the same areas over and over, although not one of them follows the EXACT same path).  

    condition a:  we take our initial DE, DEi, of point (x,y,z) and the fractal is much greater distance away than pixel_resolution_3d, so we assign DE to many points in the area:

         -assign DE (DEi) or an average DE to all points within  (x +/- [DEi * sqrt (3/8)] , y +/- [DEi * sqrt(3/8)] , z +/- [DEi *sqrt(3/8)])

                  - average DE, ADEi, of point DEi, using the center of 6 faces of a cube, and its center:  

                 ADEi=  [DE  (x+DEi*sqrt(3/8), y, z)  +  DE  (x - DEi *sqrt(3/8), y, z) + DE (x, y+ DEi *sqrt(3/8) +... DE (x, y, z - DEi * sqrt(3/8) +  DEi] / 7;
        
  We don't have to recalculate DE for every point in every ray- we check to see what point we are closest to and see if it has DE assigned or not- if not, we calculate DE for it, and assign DE to points in the vicinity that do not already have DE assigned.  Because our space is quantized, more than one ray will go through the same point too:

  At resolution_3d= .05, a ray going through  (-.71,.18,.23) will use the DE for (-.70,.20,.25), as will a ray going through (-.69,.21,.26)


  2)  If we apply additional transforms or skews to the fractal, we don't have to recalculate everything, we just apply the transforms to the existing data.  

  The main reason is to increase our ability to manipulate mathematical objects.  Currently, the fractal spray gun implementation requires a complete recalculation for every single thing we do.  This adds up- we have an interior loop in the frag, which we have to check through for each DE calculation. 


Title: Re: Quantized Space for DE and easier (mathematical) object manipulation
Post by: M Benesi on January 12, 2016, 03:14:50 AM
   Working on it.. 

(https://lh3.googleusercontent.com/-corOFBhZQ9E/VpRgbHCR_DI/AAAAAAAAEoY/nCKQoBPPQ1M/s400-Ic42/test-2.jpg)(https://lh3.googleusercontent.com/-D1J2Y7g7s0c/VpRgbDlMX-I/AAAAAAAAEoc/Vt9dZTBDFpU/s400-Ic42/test-3.jpg)


  First step, setup quantization code in raytracer (haha.. looked up Aexion's code because I thought someone had done something similar... and I was right!). 

Code:
 // Outside of trace(...) function:

#group Quantization
uniform float CubeCircumsphereRadius;slider[0.01,2.,4.]
uniform int CubePixelsPerRadiusPower2;slider[5,6,10]
float CubePixelsPerRadius=pow(2.,float(CubePixelsPerRadiusPower2));
float resolution3d=CubeCircumsphereRadius/(CubePixelsPerRadius);
float inverseResolution3d=1./resolution3d;

vec3 quantize (vec3 point) {
point*=inverseResolution3d;
 //round is not in version 120!!! is version 130!!!!
         //floor is good enough, although round would be better...  
point = vec3 (floor(point.x),floor(point.y),floor(point.z));
point *= resolution3d;

return point;
}

//Inside of trace(..) function's DE check loop:

vec3 p = from + totalDist * direction;
p=quantize(p);
dist = DE(p);


  DE could be quantized (in the array) as multiples of 2^n * sqrt(3)- although I'm not sure that it's necessary.
  We'll check points at our minimum resolution first (probably around 1/4 so):

  an array at resolution 1/4 will have points at:

  (1.75,0,0) =(7,0,0)    (2,.25,.5)= (8,1,2)   etc.            it's quantized DE could be sqrt(3)/4, or something along those lines         


   If its DE is much greater than resolution_3d, then we'll copy the DE into adjacent points at its resolution (after testing a bit- might want some average distance or something).  So maybe point (2,.25,.25) will have the same DE as (2,0,0) or (1.75,.25,0).  We'll check lower resolution points first, maybe set a minimum resolution that we first check. to grab our initial DE from (instead of recalculating a bunch of times). 


  anyway..