Welcome to Fractal Forums

Fractal Math, Chaos Theory & Research => (new) Theories & Research => Topic started by: M Benesi on July 26, 2015, 01:58:55 AM



Title: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on July 26, 2015, 01:58:55 AM
  I was thinking about attempting to program a couple of non-DE formulas for the following 2 types of closely related fractals:

(https://lh3.googleusercontent.com/-GHs7jJN9vQA/VYuAnbdaYEI/AAAAAAAAC_8/_jLeIUF_IgU/s640-Ic42/mescaline%252520molecule%252520bluewhite.jpg)

and this one:
(https://lh3.googleusercontent.com/-NrJF8IWKZ88/VXjQpbxxuGI/AAAAAAAAC3o/mv4BG1AyGn0/s640-Ic42/basilica.jpg)
(https://lh3.googleusercontent.com/-_4VhN-pi4jU/VXkhoVgooMI/AAAAAAAAC1k/0d3wNRG-6Pk/s512-Ic42/nice%252520hole.jpg)

 For the top image type, one alternates between formula 1 (below) and the pine tree Mandelbulb formula.  For the second image type, every few iterations one substitutes formula 2 (instead of formula 1) in between the pine tree Mandelbulb formulas.  Initialize the formula with pixel values, and then only add in the x pixel component each iteration, otherwise it isn't as pretty, although it still is the best z^2 type out there.

  Formula 1:
Code:
temp_x=start_x*sqrt(2/3)-start_z*sqrt(1/3);
new_z=start_x*sqrt(1/3) + start_z*sqrt(2/3);   	
new_x=temp_x*sqrt(1/2)-start_y*sqrt(1/2);          
new_y=temp_x*sqrt(1/2)+start_y*sqrt(1/2);

new_x=abs(new_x);  	
new_y=abs(new_y);  	
new_z=abs(new_z);  	
			
temp_x=new_x*sqrt(1/2)+new_y*sqrt(1/2);
new_y=-new_x*sqrt(1/2)+new_y*sqrt(1/2); 
new_x=temp_x*sqrt(2/3)+new_z*sqrt(1/3);
new_z=-temp_x*sqrt(1/3)+new_z*sqrt(2/3);	

new_x=scale*new_x-offset;  //scale =2    offset=2       
new_y=scale*new_y;
new_z=scale*new_z;


Formula 2.  Do it every few iterations, switching with the above formula.  Or by itself.
Code:
temp_x=start_x*sqrt(2/3)-start_z*sqrt(1/3);
temp_z=start_x*sqrt(1/3) + start_z*sqrt(2/3);   	
new_x=temp_x*sqrt(1/2)-start_y*sqrt(1/2);          
temp_y=temp_x*sqrt(1/2)+start_y*sqrt(1/2);
temp_x=new_x;

new_x=abs(sqrt(temp_y^2+temp_z^2)-offset2)*scale2 ;  // scale2 ~1.9    mess around with these...
new_y=abs(sqrt(temp_x^2+temp_z^2)-offset2)*scale2 ;  // offset2 ~1.9     
new_z=abs(sqrt(temp_x^2+temp_y^2)-offset2)*scale2 ;
						
temp_x=new_x*sqrt(1/2)+new_y*sqrt(1/2);
new_y=-new_x*sqrt(1/2)+new_y*sqrt(1/2); 
new_x=temp_x*sqrt(2/3)+new_z*sqrt(1/3);
new_z=-temp_x*sqrt(1/3)+new_z*sqrt(2/3);

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: DarkBeam on September 27, 2015, 07:36:10 PM
Hello Matthew glad to cya around again :)
You just need the bare formula in mb3d the proggie does the rest all alone.
Btw it takes a bit of assembly to code it properly. No time I fear.

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: DarkBeam on October 02, 2015, 05:10:34 PM
By the way please provide a name - Benesi4? Does it exist ;)
Also are you sure the formula is ok? ... it contains sqrt of something but usually power 2 formulas have plain x2+y2 no sqrt.
I cannot start so I wait for notice :snore:

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: M Benesi on October 09, 2015, 05:12:32 AM
:)  Glad you're still bouncing around too.  Found an assembler that might work here: http://flatassembler.net/  so maybe I'll try it out.  If you've got a bit of pre-made code to play with???  :D


  Names?  I thought the top one (blue and white) looked a bit like it had lots of little peyote cacti growing out of it...  but it's based off of another old formula.  The other one was me playing around with a torus formula, and going off on a tangent that ended up being sort of nice.  

  I honestly can't think of names...  if you like:

  Peyote Button for the blue and white one?
  Maybe Honeycomb for this one:  

(https://lh3.googleusercontent.com/-Bfn5I9Yya-0/VXjQlO_jGtI/AAAAAAAAC1k/VKgR0wal3RY/s640-Ic42/basilica%252520TR16%252520TM3%252520torinotfirst.jpg)

  Although I do like having formulas named after me.   :o  So Benesi4 and Benesi5 would be cool too.  :D  

  The square roots are for a rotation from the x-axis to the "mag" axis, and are essential to the formula.  The formulas are not very interesting by themselves- they work well with the pine tree version of the Mandelbulb formula.

  You switch back and forth between them and the pine tree Mandelbulb formula  (1 of them, Mandelbulb, 1 of them, Mandelbulb.....).

 Posting the code for the pine tree Mandelbulb below, so you know which Mandelbulb formula works best.

  The coolest thing about this formula is that you can rotate individual sections of it:

https://www.youtube.com/watch?v=SXx36wiDpN0 (https://www.youtube.com/watch?v=SXx36wiDpN0)

Code:
//  z^2 pine tree Mandelbulb, for speed, just elementary math, no trig functions

				x_temp=start_x^2;
		y_temp=start_y^2;			
				z_temp=start_z^2;

				new_x= x_temp - y_temp - z_temp;

				temp=2.*(start_x)/sqrt(temp_y+temp_z);				

		new_z=temp*(temp_y-temp_z);            //y and z variables are switched to add symmetry 
		new_y=temp*2.*start_y*start_z;	




//regular formula with trig stuff, different variable names,
// don't want to change the variable names since you probably have a version of this in M3D:

					r2=(sx*sx+sy*sy+sz*sz)^(n/2);   
					r1=sqrt(sy*sy+sz*sz);     //r1 is used to calculate theta

					theta=atan2(r1+flip(sx))*n;   //flip just multiplies by i
					phi=atan2(sz+flip(sy))*n;     // this is regular atan2...

					new_x=r2*cos(theta);
					r2=r2*sin(theta);
					new_y=r2*cos(phi);
					new_z=r2*sin(phi);


  A couple images of various mixtures of the formulas are here:

  https://picasaweb.google.com/103496528720991269557/NewFractalType

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: DarkBeam on October 09, 2015, 01:03:21 PM
Yeah okay Matt. :) I will be more clear
Your z2 pine mandelbulb looks okay. Some coordinate look squared because you do X2 - Y2 - Z2

The previous formulas you wrote are not ok in my eyes... (and they are radically different)
Because a Mandelbrot squaring must contain ... a squaring :) so if you take sqrt of x2 it "returns to x" and it will not work - it should give a never escaping fractal. Different would be taking sqrt of x^4... or multiplying two of them.

Saying this because starting to code is frustrating already but a potentially wrong formula stops me :(

Or... maybe I just mistaken?... the formulas of posts 1 and 2 are just modifiers TO BE USED IN CONJUNCTION with the pine tree which is exactly the last formula you posted :beer:
In this last case all is ok... ;)

last thing... is "pine tree" a normal Pow2 bulb?...
Just to know if I have to rewrite it from scratch or no?... 8)

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: M Benesi on October 09, 2015, 06:45:47 PM
Quote from: DarkBeam on October 09, 2015, 01:03:21 PM
Saying this because starting to code is frustrating already but a potentially wrong formula stops me :(
 Let me see if I can snip some code out of my experimental code database (which is large) and post a small, working, cleaned/organized ChaosPro version here after I finish this message.

Quote from: DarkBeam on October 09, 2015, 01:03:21 PM
Or... maybe I just mistaken?... the formulas of posts 1 and 2 are just modifiers TO BE USED IN CONJUNCTION with the pine tree which is exactly the last formula you posted :beer:
In this last case all is ok... ;)
 Yes, in my experience, they are most interesting combined with other formulas.  :beer:   You can do stuff with the plain old modifiers, I just like them the most mixed with the pine tree.  

  The 2nd formula (by itself) makes the following (I don't have an image of the first formula, don't think it was very interesting stand alone?? can't recall):

(https://lh3.googleusercontent.com/-P5qH0kHvq7Y/VWyYLFKjp3I/AAAAAAAADJI/uSZIxG71i8A/s400-Ic42/torus%252520non%252520mag%252520type%252520twisty.jpg)  

Quote from: DarkBeam on October 09, 2015, 01:03:21 PM
last thing... is "pine tree" a normal Pow2 bulb?...
Just to know if I have to rewrite it from scratch or no?... 8)
 It's slightly different then the "normal" version on wikipedia, but it might be the version you use.  If you do have to rewrite the formula, you might be able to take the old formula and just switch variables instead of writing from scratch.


  Ehh.. best explanation:  The main difference is the "normal" formula rotates [x vs. y] and [(x and y) vs. z] and the pine tree version rotates [(x vs. (y and z)] and [y vs. z].

"normal":

r=\sqrt{x^2+y^2+z^2}

\phi=\arctan(y/x)=\arg (x+yi)

\theta=\arctan(\sqrt{x^2+y^2}/z)=\arccos(z/r)

... rest of formula...  (multiply angles by n, take r^n.....)...  This one (for z^2) gives you new_x = x^2+y^2-z^2, new_y = 2(x^2-y^2)*z, new_z= 4xyz

pine tree:

r=\sqrt{x^2+y^2+z^2}

\phi=\arctan(z/y)=\arg (y+zi)

\theta=\arctan(\sqrt{y^2+z^2}/x)=\arccos(x/r)

...rest of formula.   new_x =  x^2 - y^2 -z^2 instead of x^2+y^2-z^2, new_y = whatever I posted earlier, etc..


  I need to eat breakfast, and then clean up that ChaosPro code and post it here so you can see how the formula works (and we can make sure I translated it correctly!!$!$).

  Matt

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: DarkBeam on October 09, 2015, 07:16:27 PM
Another thing I don't fully get is NY=2TYZ
When NZ=T(TY-TZ)... Z is multiplied by a 2 and it is ok.
But! T itself is already T=2X(TY+TZ)^-0.5
So Y gets multiplied by a factor of 4.
So again I reccomend you to look carefully... those anomalies may cause unwanted stretch. :)
Probably a math little mistake and also could look good as is nevertheless!!!

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: M Benesi on October 09, 2015, 08:55:23 PM
 Cleaned up some ChaosPro code for you to look at.  My code was horribly messy!  Took a few hours to clean up, and (update at 1:05pm GMT/UTC -8, a little bit more to correct one little mistake!). 
  
  To try the CP versions, take the ".txt" file extension off of these to use them with ChaosPro.  Put them in your CP formula directory (well, except for the fractal formula without a file extension- just open it in CP).

  "for luca" is the fractal parameters to load
  "Benesi Coloring.ccl" is the coloring formula I used for that fractal (looks better than other coloring schemes in CP, so I'd use it)
  "Clean ANSI edited.cfm" contains the formula, and an extra one

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: M Benesi on October 09, 2015, 09:41:04 PM
OHHH!  You were talking about the normal Mandelbulb formula.  Let me look at that, and edit this. Gimme a few minutes.

Quote from: DarkBeam on October 09, 2015, 07:16:27 PM
Another thing I don't fully get is NY=2TYZ
When NZ=T(TY-TZ)... Z is multiplied by a 2 and it is ok.
But! T itself is already T=2X(TY+TZ)^-0.5
So Y gets multiplied by a factor of 4.
So again I reccomend you to look carefully... those anomalies may cause unwanted stretch. :)
Probably a math little mistake and also could look good as is nevertheless!!!

PINE TREE:

   \left [x + i \sqrt{y^2+z^2} \right ]^2 = \ x^2 - y^2 - z^2 + \ i 2 x \sqrt{y^2+z^2}

   new_x is just the real part: x^2-y^2-z^2

       temp is     \frac {\ i 2 x \sqrt{y^2+z^2}}{y^2+z^2} = i \frac {2x}{\sqrt{y^2+z^2}}

  (we divide out the magnitude x^2+y^2, which we get when we square (y+ iz))
  since:
(y+iz)^2 = y^2-z^2 + i 2yz


      new \ z =temp (y^2-z^2) = \ \frac{2x (y^2-z^2)}{\sqrt{y^2+z^2}}        
      new \ y =temp (2yz) = \ \frac{2x *2yz}{\sqrt{y^2+z^2}}= \ \frac{4xyz}{\sqrt{y^2+z^2}}        
      new_z=temp*(y^2-z^2);            
      new_y=temp*2*y*z;   

  We've already divided out the magnitude of (y+iz)^2 in the "temp" part.  

NORMAL:   edited: the following was wrong.  :D    whooops...


   \left [\sqrt{x^2+y^2} + iz \right ]^2 = \ x^2 + y^2 - z^2 + \ i 2 \sqrt{x^2+y^2} z

   new_z is 2 \sqrt{x^2+y^2} z     ZZZZZZZZZZZZZZZZZZ

   temp \frac {x^2+y^2-z^2}{\sqrt{x^2+y^2}}

(x+iy)^2 = x^2-y^2 + i 2xy

      new \ x =temp (x^2-y^2) = \ \frac {(x^2-y^2)(x^2+y^2-z^2)}{\sqrt{x^2+y^2}}        
      new \ y =temp (2xy) = \ \frac {2xy (x^2+y^2-z^2)}{\sqrt{x^2+y^2}}        
      

Here is the fractal from the above code... so if the code works and the math doesn't, something is going on:

(https://lh3.googleusercontent.com/-5pSOMUtD4_M/VhgX8OM7cEI/AAAAAAAADLo/C_JZOJY2hcw/s640-Ic42/for%252520luca%252520original%252520size.jpg)


Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: DarkBeam on October 09, 2015, 11:11:05 PM
Perfect ;) it is a totally different concept and formula from the classic Mandelbulb squaring.

You find the original formulas here http://www.fractalforums.com/index.php?topic=742.msg7711#msg7711

No "4" pops in I correctly remembered :D

Will probably try to look tomorrow in those files
THANKS SO MUCH MATTHEW :)

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: mclarekin on October 10, 2015, 03:21:49 AM
Hi folks,

My trigonometry knowledge is in the far distance past (not like you guys)  so I just ignorantly made these changes, is this a pine tree mandelbulb? :) :) :)

Cheers

Code:
      aux.r = z.Length();
                double th0 = asin(z.x / aux.r) + mandelbulbPT.mandelbulbBetaAngleOffset;    // was z.z/aux.r
                double ph0 = atan2(z.z, z.y) + mandelbulbPT.mandelbulbAlphaAngleOffset;     // was zy, z.x
                double rp = pow(aux.r, mandelbulbPT.mandelbulbPower - 1.0);
                double th = th0 * mandelbulbPT.mandelbulbPower;
                double ph = ph0 * mandelbulbPT.mandelbulbPower;
                double cth = cos(th);
                aux.r_dz = rp * aux.r_dz * mandelbulbPT.mandelbulbPower + 1.0;
                rp *= aux.r;
                z = CVector3(cth * cos(ph), cth * sin(ph), sin(th)) * rp;

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: M Benesi on October 10, 2015, 05:10:50 AM
Hey Mclarekin, set it to power 2 to be sure (I'll recognize it), but the math looks about right. 

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: mclarekin on October 10, 2015, 08:29:03 AM
Thanks, how about this pwr 2 image?

BTW, Wow and weird., it gets bigger with pwr 2!


Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: mclarekin on October 10, 2015, 10:03:08 AM
This bit of code  is fun, ;D,  I've now got it in a loop following  a standard mandebulb trying out the different powers combinations.  :) :) :)

This fractal forums is the best place to learn, thanks you guys.


Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: DarkBeam on October 10, 2015, 10:04:50 AM
Hello there mclarekin ;) - why it is asin() instead of acos() like Matthew said? Just curious to see another render ;)

Ah... note that atan and atan2 are NEVER the same thing... so try them both :beer:

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: mclarekin on October 10, 2015, 11:10:07 AM
Hi DarkBeam,  I was telling the truth  :) :) :) :-

Quote
My trigonometry knowledge is in the far distance past (not like you guys)  so I just ignorantly made these changes

So I look at Buddhi's mandelbulb code and  think  :hmh: "This is not the same as in the post ???" What is arg??? , what is going on with  atan or atan2 and sin or cos ?? I wonder if its a different way of writing the same formula???

So I decided I would just change the x, y, z things,  and not the trig.  Render it to see I would get an image. Then ask at FF if the formula was correct  :).

I now suspect it may not be a Pine Tree. Oh well,  So I will make those changes and see what I get  :) :) :) :) Thanks  :) :) :)

Cheers

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: DarkBeam on October 10, 2015, 12:48:36 PM
That said I tried to put the non-trig pinetree but looks totally different from any image posted as I feared. It is in its pure form here.
The m3f (you can disassemble pasting the code into OllyDbg... the formula starts after the 1st FNOP and FLD QWORD PTR DS:[EBX] loads X into the stack, (...)EDX is Y, (...)ECX is Z, FADD QWORD PTR DS:[ESI+18] adds CX, ebp stuff stores temporary variables... and so on ;) );

Code:
[OPTIONS]
.Version = 2
.DEscale = 1
.SIpower = 2
[CONSTANTS]
Double = 0.816496580927726
Double = 0.5773502691896258
Double = 0.7071067811865475
Double = 2.0
[CODE]
558BEC81EC300000005356578B75088B7E308BD8D9D0DD03D8C8DD5DF8DD02D8
C8DD5DF0DD01D8C8DD5DE8DD03D8C0DD45F0DC45E8D9FADEF9DD5DE090DD45F8
DC65F0DC65E890DD45E0DD45F0DC65E8DEC990DD45E0D8C0DC09DC0A90DC4620
DD1A90DC4628DD1990DC4618DD1BD9D08BC35F5E5B89EC5DC20800
[END]


Description:

Benesi pinetree formula;

xt = x*x; yt = y*y; zt = z*z;
t = 2*x/sqrt(yt+zt);
x = xt-yt-zt+Cx;
z = t*(yt-zt)+Cy;
y = 2*t*y*z+Cz;

(http://nocache-nocookies.digitalgott.com/gallery/18/4162_10_10_15_12_55_06.png)[/code]

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: DarkBeam on October 10, 2015, 06:57:23 PM
YEAH!!! It works, I added it to the database! BenesiPine1 (2 is in preparation :tease: ) :beer: :beer: :beer:
Just, it needed the fold before to work okay...

(http://nocache-nocookies.digitalgott.com/gallery/18/4162_10_10_15_6_56_26.png)

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: M Benesi on October 10, 2015, 07:20:22 PM
You're good Luca.   If you rotate the image 90° clockwise, what does it look like?  

(https://lh3.googleusercontent.com/-dlch5tmA2UM/VhlF0rDOknI/AAAAAAAADMA/fD9gt19Tn-c/s400-Ic42/pine%252520forest.jpg)

  Seriously though: you got it right.  You don't recognize it because we switched the y and z components, but this is it here (from my ChaosPro code):

(https://lh3.googleusercontent.com/-H7Q6C0NYKck/VhlISo_R5EI/AAAAAAAADMU/u2Q_rnOCqQQ/s476-Ic42/cppinetree.jpg)

  The viewing angle I use for the render is a bit more narrow, but it's definitely the same formula.  

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: M Benesi on October 10, 2015, 07:21:05 PM
Quote from: DarkBeam on October 10, 2015, 06:57:23 PM
YEAH!!! It works, I added it to the database! BenesiPine1 (2 is in preparation :tease: ) :beer: :beer: :beer:
Just, it needed the fold before to work okay...

  You are awesome Lucal!@$!@$  :D  Nice job!

  I forgot to tell you about the initialization!!!   You need to treat the fractal like a Julia, sending the pixel value into the formula first!  

  After every Mandelbulb iteration, you ONLY add in the x pixel component, which makes it much more smooth.  You do not add in any pixel component after the other formulas: they are basically pure Julias, using the offsets as the Julia component.

  Adding only the x pixel component is the key to a completely smoothly evolving fractal: it will be much more symmetric! 
 
  If you add in the whole pixel component (x, y, and z) after the Mandelbulb part, the fractal is not as nice looking, although it is still cool.

x pixel only,  full pixel
(https://lh3.googleusercontent.com/-WvarzGwEWPc/VhlN1Fw1H8I/AAAAAAAADM4/5zSAHGxKb0U/s400-Ic42/first%252520only%252520x%252520pixel.jpg)   (https://lh3.googleusercontent.com/-YoiXP2ThKx8/VhlN1lBzWJI/AAAAAAAADNA/_zfRHx4c4vE/s400-Ic42/first%252520full%252520pixel.jpg)

second formula x pixel only,  full pixel:

(https://lh3.googleusercontent.com/-Myc3eNyK5pY/VhlN2hriMQI/AAAAAAAADNQ/a5JYMLVodPQ/s400-Ic42/xpixel%252520only.jpg)  (https://lh3.googleusercontent.com/-RnvzzgRk-Mo/VhlN2JJ3wEI/AAAAAAAADNM/7iL2p6g_6wo/s400-Ic42/tor%252520first%252520full%252520pixel.jpg)


  So you really only want the x pixel added in, to make a nice symmetric fractal, otherwise you get more stretchy sections.

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: DarkBeam on October 10, 2015, 07:33:49 PM
A question;
Which symmetry is that? Tetrahedral, icosa, etc... and can it be made to other platonic solids?...

I know it may become a brain torture :hurt: :hurt: :hurt:

Quote from: M Benesi on October 10, 2015, 07:21:05 PM

  I forgot to tell you about the initialization!!!   You need to treat the fractal like a Julia, sending the pixel value into the formula first! 

  After every Mandelbulb iteration, you ONLY add in the x pixel component, which makes it much more smooth.  You do not add in any pixel component after the other formulas: they are basically pure Julias, using the offsets as the Julia component.

 
  If you add in the whole pixel component (x, y, and z) after the Mandelbulb part, the fractal is not as nice looking, although it is still cool.

Do not worry... It is enough cool :) - Initializations may bug the code and not adding all C components is not a good idea because Julia sets would be "forced" to have only infinite^1 variants and not ^3! ;D

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: M Benesi on October 10, 2015, 07:48:35 PM
  Look in the post above yours.  :D  If you're on Facebook, send me a friend request so we can open a chat window.

Be back in a bit...  I need breakfast!  Almost 11am here... did it again.  Time to eat.  

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: mclarekin on October 10, 2015, 10:04:24 PM
I am beginning to understand all of this much better :)

1) there is a whole family of mandelbulbs to explore simply by changing the trig functions. Hmmmmm?  So I could code a basic mandelbulb formula with enable checkboxes to vary the trig functions

2) and you  use  formulas 1 and 2 as modifiers  produces  these amazing fractals.  :) :)

3)  and i know now why it is called pine tree ;D

The infinite possibilities has just increased again for me.

Thanks guys

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: DarkBeam on October 10, 2015, 11:46:42 PM
Quote from: mclarekin on October 10, 2015, 10:04:24 PM
I am beginning to understand all of this much better :)

1) there is a whole family of mandelbulbs to explore simply by changing the trig functions. Hmmmmm?  So I could code a basic mandelbulb formula with enable checkboxes to vary the trig functions

2) and you  use  formulas 1 and 2 as modifiers  produces  these amazing fractals.  :) :)

3)  and i know now why it is called pine tree ;D

The infinite possibilities has just increased again for me.

Thanks guys
Yeah you should do it! Variations include asin acos atan and atan2.
For each possible coupling of angles... x y z ... etc
I made it in Mandelbulb years ago :)
Plus! Another topic you should look at ...
http://www.fractalforums.com/the-3d-mandelbulb/iterating-c/

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: M Benesi on October 11, 2015, 12:19:49 AM
Quote from: mclarekin on October 10, 2015, 10:04:24 PM
3)  and i know now why it is called pine tree ;D
  Because you can hang it from your rear view mirror and it makes your car smell fresh?

  I think Bugman named it Pine Tree, lemme find his website for you, it has a bunch of the formulas written out.   I've found the Pine Tree one produces the smoothest fractals with the various mods above...

  http://bugman123.com/Hypercomplex/

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: M Benesi on October 11, 2015, 01:17:34 AM
Quote from: DarkBeam on October 10, 2015, 12:48:36 PM
That said I tried to put the non-trig pinetree but looks totally different from any image posted as I feared. It is in its pure form here.
The m3f (you can disassemble pasting the code into OllyDbg... the formula starts after the 1st FNOP and FLD QWORD PTR DS:[EBX] loads X into the stack, (...)EDX is Y, (...)ECX is Z, FADD QWORD PTR DS:[ESI+18] adds CX, ebp stuff stores temporary variables... and so on ;) );

Code:
[OPTIONS]
.Version = 2
.DEscale = 1
.SIpower = 2
[CONSTANTS]
Double = 0.816496580927726
Double = 0.5773502691896258
Double = 0.7071067811865475
Double = 2.0
[CODE]
558BEC81EC300000005356578B75088B7E308BD8D9D0DD03D8C8DD5DF8DD02D8
C8DD5DF0DD01D8C8DD5DE8DD03D8C0DD45F0DC45E8D9FADEF9DD5DE090DD45F8
DC65F0DC65E890DD45E0DD45F0DC65E8DEC990DD45E0D8C0DC09DC0A90DC4620
DD1A90DC4628DD1990DC4618DD1BD9D08BC35F5E5B89EC5DC20800
[END]

  Question, where do you drop the code into OllyDbg, or do I need to grab the binary???  [/code]

Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: mclarekin on October 11, 2015, 01:45:13 AM
@DarkBeam Thanks for showing me that post.  The simplifications and workarounds blow my mind.   :o :hmh: :o ;D ;D ;D
@Benesi Thanks for that interesting VIBRANT site.

There is so much to learn BUT :

my status early June 2015 (when i was asking Buddhi  to take a gamble and help me play with his source code.)
Quote
Status
I have no real experience in programming, the only code I have ever looked at is Mandelbulber, the only coding I have ever done is openCL custom formulas in Mandelbulber (using Notepad), and the only coding I understand is most of the formula code. So I know nothing about terminology and how a trained programmer would do things.

And now just a few months later I  can write transforms in C++ with QT designer and compile & run,  and every day I am learning more ;D

FractalForums has grown so big that it really helps a lot when you guys who have been "around a while" can direct us to relevant old posts.

The possibilities of all the infinities  are ridiculously huge :D

Thanks again





Title: Re: Do M3D formula have to be Distance Estimation formulas?
Post by: DarkBeam on October 11, 2015, 07:45:41 AM
Code:
[quote author=M Benesi link=topic=22123.msg87695#msg87695 date=1444519054]
  Question, where do you drop the code into OllyDbg, or do I need to grab the binary??? 
[/quote]
Open OllyDbg.
Open an exe file ... I use twunk32.exe :D
Go to the end of file it is all full of 00000....
Binary paste
You will see the source :D

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: DarkBeam on October 14, 2015, 12:42:00 PM
I get horrible results replacing the fold 1 with the fold 2 :fiery: :'(

Matthew please can you clarify your statement...
How many times - how it is meant to be used :)
Quote
For the top image type, one alternates between formula 1 (below) and the pine tree Mandelbulb formula.  For the second image type, every few iterations one substitutes formula 2 (instead of formula 1) in between the pine tree Mandelbulb formulas.  Initialize the formula with pixel values, and then only add in the x pixel component each iteration, otherwise it isn't as pretty, although it still is the best z^2 type out there.

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on October 14, 2015, 09:41:12 PM
   PT: Pine Tree   F1: formula 1   F2: formula 2

  F1, PT;  F1, PT;  F1, PT;  F1, PT;  F1, PT;

5 combination iterations, or 10 total iterations:

x pixel only,  full pixel
(https://lh3.googleusercontent.com/-WvarzGwEWPc/VhlN1Fw1H8I/AAAAAAAADM4/5zSAHGxKb0U/s400-Ic42/first%252520only%252520x%252520pixel.jpg)   (https://lh3.googleusercontent.com/-YoiXP2ThKx8/VhlN1lBzWJI/AAAAAAAADNA/_zfRHx4c4vE/s400-Ic42/first%252520full%252520pixel.jpg)

 PT: Pine Tree   F1: formula 1   F2: formula 2

  F1, PT;  F1, PT;  F1, PT;  F2, PT;  F1, PT;

with second formula for the "7th" iteration, or beginning part of the 4th combination iteration

x pixel only,  full pixel:
(https://lh3.googleusercontent.com/-Myc3eNyK5pY/VhlN2hriMQI/AAAAAAAADNQ/a5JYMLVodPQ/s400-Ic42/xpixel%252520only.jpg)  (https://lh3.googleusercontent.com/-RnvzzgRk-Mo/VhlN2JJ3wEI/AAAAAAAADNM/7iL2p6g_6wo/s400-Ic42/tor%252520first%252520full%252520pixel.jpg)

  PT: Pine Tree   F1: formula 1   F2: formula 2

  F1, PT;  F1, PT;  F1, PT;  F2, PT;  F1, PT;


  Settings for F2 are ~1.9 and ~1.9.  For F1: they are around 2.  PT is the z^2 version, with only x pixel component added in (do a Julia for experimentation if you want).  


  Formula 2 introduces details to the formula 1 modified PT.  If you start out with F2, you get something more like the following (only 2 or 3 iterations!  it gets chaotic if you apply F2 too often):

(https://lh3.googleusercontent.com/-f-GYq6Y-2NI/VWgCrO7YL8I/AAAAAAAAC1k/0i6iu16PqhI/s512-Ic42/new%252520type%252520good%252520pixel%252520color%252520change.jpg)

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: DarkBeam on October 14, 2015, 09:53:08 PM
Oh yeah will try again :D but now with those images I suspect I got it right ;)
Tomorrow :thumbsup1:

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on October 14, 2015, 10:07:03 PM
k.  Special request---   I'm trying to learn to modify this stuff, so I can do more with M3D.

  What do you use to assemble the code (FASM, MASM32, something else)? 

  Could I look at your non compiled code for the above formulas (maybe even commented code) so I have a better idea of how to change the code? 

 :D
 

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: DarkBeam on October 14, 2015, 11:28:05 PM
Matt there is no source really...
I write it directly in assembly using OllyDbg so your formula was really coded manually.
Well I had to change it using less temporary stuff and shortening it...
If formulas are enough simple I do that directly.
Else I use flatasm but mainly for difs shapes because layout is ready :)

Do you like to have a layout for formulas? ... but you need to hand code them after brutal reduction...

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on October 15, 2015, 04:51:02 AM
  Thanks Luca, 

Layout would be nice.   Something to look at... although if it doesn't have commentary.  :eek:


Title: Re: Benesi "pinetree" (fold+bulb)
Post by: DarkBeam on October 15, 2015, 12:42:25 PM
Lol... For now see if the formula looks right? ;)
This is three iters of normal fold+pinetree, then one newfold+pinetree. 5+1 gives no difference  :snore:
(In certain areas, the stretch is strong and a lower raystep would be needed but it is a preview right :tease: )

(http://i60.tinypic.com/29bouwn.png)

To me it looks identical :banana: :banana: :banana: - it is already downloadable :)

As for the layout please wait! :hurt:

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: KRAFTWERK on October 16, 2015, 11:38:24 AM


Can't wait to try it out guys!   :beer: O0

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: mclarekin on October 16, 2015, 12:13:16 PM
Quote
Yeah you should do it! Variations include asin acos atan and atan2.
For each possible coupling of angles... x y z ... etc

I have done a few now, maybe I have 6 so far that are not just reflections/rotations of others.  Some look the same but then you find they are subtly different.  Anyhow it is a strain on my brain, so I let myself get distracted and started testing them as hybrids in a single loop. I have found some combinations have reasonable DE ;D     But generally the DE is a worse than a  standard MBulb. :sad1: But then I have only tested a small sample.  :) :) :)


Title: Re: Benesi "pinetree" (fold+bulb)
Post by: DarkBeam on October 16, 2015, 05:21:56 PM
Why you don't let the users decide which one to pick like I did... the combinations are really too many to be explored by hand - just a thought :)
And Johan - where is the pretty image :horsie: :mandel:

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on October 16, 2015, 09:47:56 PM
 :toast:   Wise...   

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: thargor6 on October 17, 2015, 12:31:38 AM
Quote from: DarkBeam on October 14, 2015, 11:28:05 PM
Matt there is no source really...
I write it directly in assembly using OllyDbg so your formula was really coded manually.
Hey Luca, as I plan to play with a solution with an integrated compiler, would you mind to provide me the original formula in order to have a (fresh) example to compare results?

Best regards,
Andreas

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: mclarekin on October 17, 2015, 12:45:05 AM
Quote
Why you don't let the users decide which one to pick like I did... the combinations are really too many to be explored by hand - just a thought

yep I will eventually.  Definitely preferable to let the user figure out what is a unique fractal or just a rotation/reflection of another fractal.  I had come to the realisation that trying to figure it all out myself first was never going to happen ;D

I guess if I re-learnt my trig  :hmh:  i could eventually work it out.   :tongue1:). Be cool to have it tabulated (which I had started to do.). I thought for a while that looking at the pwr2 versions would quickly let me work it out but found later that some combinations "appeared"  to have the same pwr2 but at pwr 9 they were slightly different. 


An alas I am so easily distracted, like a MandelBee I "flit from fractal to fractal" LOL

Cheers

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on October 17, 2015, 11:17:05 PM
Quote from: thargor6 on October 17, 2015, 12:31:38 AM
Hey Luca, as I plan to play with a solution with an integrated compiler, would you mind to provide me the original formula in order to have a (fresh) example to compare results?

Best regards,
Andreas

  Do you just want the math, or are you looking for Luca's source? 



Title: Re: Benesi "pinetree" (fold+bulb)
Post by: DarkBeam on October 18, 2015, 12:05:36 AM
Quote from: M Benesi on October 17, 2015, 11:17:05 PM
  Do you just want the math, or are you looking for Luca's source? 
Andreas I totally missed your message!!! Please reply? :)

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: thargor6 on October 18, 2015, 12:10:47 AM
Quote from: M Benesi on October 17, 2015, 11:17:05 PM
  Do you just want the math, or are you looking for Luca's source? 
Hi,
I mean the math, but in terms which make it easy for me to translate it into MB3D's environment (in order to avoid errors while translating it).
Not sure, how it is currently done, but I was hoping there is something between the pure math and the compiled/optimized ASM-stuff.

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: thargor6 on October 18, 2015, 02:01:15 AM
Quote from: DarkBeam on October 18, 2015, 12:05:36 AM
Andreas I totally missed your message!!! Please reply? :)
Hi, I was hoping to have some fresh example to play with my proof-of-concept. (Still dreaming of some on-the-fly compiler where people who know the math can just enter their formulas and can play with them (like in Fragmentarium). Will never be that fast as your ASM-code, but cool to try new stuff)

Best for my purpose would be the formula in pascal or C or whatever "highlevel"-language, but not ASM :D

(My current idea is to extend the current formulas (which have pre-compiled code inside the CODE-section) by another (optional) section, maybe DELPHI-CODE, which may contain the Delphi-code of the formula and is compiled when loading the formula)

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on October 18, 2015, 02:18:03 AM
Quote from: thargor6 on October 18, 2015, 12:10:47 AM
Hi,
I mean the math, but in terms which make it easy for me to translate it into MB3D's environment (in order to avoid errors while translating it).
Not sure, how it is currently done, but I was hoping there is something between the pure math and the compiled/optimized ASM-stuff.

  Hey Andreas,

  The math for formula 1 and 2 is in the first post of this thread.  The math for the "Pine Tree" version of the Mandelbulb is described in post 8.  If you want further explanations, ask away.


  Something I forgot to tell Luca before he started coding:

  Only add in the x pixel component after the Pine Tree Mandelbulb portion for maximum symmetry.

  I'd do all 3 (pine tree, mod 1, and mod 2) formulas stand alone, so they can be alternated with one another.

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: thargor6 on October 19, 2015, 12:15:24 AM
Hi,
I think I succeeded with including Formula 1 in my experimental MB3D-solution (i. e., I entered just the text, but in Pascal-syntax).
I have combined a classic mandelbulb (i. e. IntPower) with this formula and got the following cool result:
(http://pre03.deviantart.net/65d9/th/pre/f/2015/291/0/f/experimental_tree_by_thargor6-d9dkyho.jpg)
The solution is not really usable now (one cant even save params), but I think it is the way to go.

Best regards,
Andreas

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on October 19, 2015, 01:18:10 AM
  Looks like the tree I was trimming a few minutes ago.    :beer:

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on October 22, 2015, 05:29:39 AM
So, I split the formulas into the transforms, and the pine tree portions.  Made a pine tree with only the x-pixel component as well.

I've yet to figure out how to do something like:

 T1, PTx, T1, PTx, T1, PTxyz, PTx, T2, PTx, T1

  T1: transform 1   
  T2: ...  Ahhnolldd  ...
  PTx:  Pine tree with x-pixel component only
  PTxyz: pine tree with x,y, and z pixel components
 
  Here is a mix of T1 and PTx...
(https://lh3.googleusercontent.com/-RuRXmWtw_SI/VihXBl5d9rI/AAAAAAAADPY/4I59pw2RbHw/s0-Ic42/first%252520try.jpg)


All the code for the split formulas...  with them attached below.  Also code for pine tree 1, with no y and z, and pine tree 2 with no y and z...  maybe next post.  Can't attach any more.... :D
Code:
[OPTIONS]
.Version = 2
.DEscale = 1
.SIpower = 2
.Double Scale = 2.0
.Double xOff = 2.0
[CONSTANTS]
Double = 0.816496580927726      
Double = 0.5773502691896258
Double = 0.7071067811865475
[CODE]
558BEC81EC300000005356578B75088B7E308BD8D9D0DD03DC0FDD01DC4F08D9
E0DEC1DC4F10DD5DF8DD03DC4F08DD01DC0FDEC1D9E190DD45F8DD02DC4F10D9
E0DEC1D9E190DD45F8DD02DC4F10DEC1D9E190DD1ADD1BDD1990DD03DC02DC4F
10DD5DF890DD03D9E0DC02DC4F1090DD45F8DC0FDD01DC4F08DEC190DD45F8DC
4F08D9E0DD01DC0FDEC190DD19DD1BDD1A90DD03DC4FF0DC67E8DD1BDD02DC4F
F0DD1ADD01DC4FF0DD1990D9D08BC35F5E5B89EC5DC20800
[END]


Description:

Cool??  :D  absolute value xyz transform;

// STEP1: "Benesi transform 1"
tx=(x*sqrt(2/3)-z*sqrt(1/3))*sqrt(1/2);
z=abs(x*sqrt(1/3) + z*sqrt(2/3));   	
x=abs(tx-y*sqrt(1/2));          
y=abs(tx+y*sqrt(1/2));
			
tx=x*sqrt(1/2)+y*sqrt(1/2);
y=-x*sqrt(1/2)+y*sqrt(1/2); 
x=tx*sqrt(2/3)+z*sqrt(1/3);
z=-tx*sqrt(1/3)+z*sqrt(2/3);	

x=scale*x-offset;  //scale =2    offset=2       
y=scale*y;
z=scale*z;



................................................................Transform 2...,,,,.,,,,.

[OPTIONS]
.Version = 2
.DEscale = 1
.SIpower = 2
.Double Scale = 2.0
.Double xOff = 2.0
[CONSTANTS]
Double = 0.816496580927726
Double = 0.5773502691896258
Double = 0.7071067811865475
[CODE]
558BEC81EC300000005356578B75088B7E308BD8D9D0DD03DC0FDD01DC4F08D9
E0DEC1DC4F10DD5DF8DD02DC4F10DD1A90DD03DC4F08DD01DC0FDEC190DD45F8
DC2290DD45F8DC0290D8C8DD5DF0D8C8DD5DF8D8C8DD19D9D0DD45F0DC01D9FA
DC67E8D9E1DC4FF0DC4F10DD1B90DD45F8DC01D9FADC67E8D9E1DC4FF0DC4F10
DD1A90DD45F8DC45F0D9FADC67E8D9E1DC4FF0DD1990DD02DC03DD02DC23DD1A
DD5DF890DD45F8DC0FDD01DC4F08DEC1DD45F8DC4F08D9E0DD01DC0F90DEC1DD
19DD1B90D9D08BC35F5E5B89EC5DC20800
[END]


Description:

The cool Benesi pinetree formula. Use in conjunction with normal
 BenesiPine1 or it is messy!
Or any other formula :)
(Three iters of pine1 + one of pine2)

// STEP1: "Benesi fold 2"
tx=(x*sqrt(2/3)-z*sqrt(1/3))*sqrt(1/2);
y=y*sqrt(1/2);
z=(x*sqrt(1/3) + z*sqrt(2/3))^2;   	
tx=(tx-y)^2;          
ty=(tx+y)^2;

x=abs(sqrt(ty+z)-offset2)*scale2*sqrt(1/2) ;
y=abs(sqrt(tx+z)-offset2)*scale2*sqrt(1/2) ;   
z=abs(sqrt(tx+ty)-offset2)*scale2 ;

tx=y+x; y=y-x; 
x=z*sqrt(1/3)+x*sqrt(2/3);
z=z*sqrt(2/3)-x*sqrt(1/3);


..................................Pine Tree X pixel Only!@$...................................
[OPTIONS]
.Version = 2
.DEscale = 1
.SIpower = 2
[CONSTANTS]

[CODE]
558BEC81EC300000005356578B75088B7E308BD8D9D0DD03D8C8DD5DF8DD02D8C8DD5DF0DD01D8C8DD5DE8
DD03D8C0DD45F0DC45E8D9FADEF9DD5DE090DD45F8DC65F0DC65E890DD45E0DD
45F0DC65E8DEC990DD45E0D8C0DC09DC0A90DD1A90DD1990DC46
18DD1BD9D08BC35F5E5B89EC5DC20800
[END]


Description:


//"Benesi pinetree X pixel"
xt = x*x; yt = y*y; zt = z*z;
t = 2*x/sqrt(yt+zt);
x = xt-yt-zt+Cx;
z = t*(yt-zt);
y = 2*t*y*z;


...................................................Pine Tree with xyz pixel......................
[OPTIONS]
.Version = 2
.DEscale = 1
.SIpower = 2
[CONSTANTS]

[CODE]
558BEC81EC300000005356578B75088B7E308BD8D9D0DD03D8C8DD5DF8DD02D8C8DD5DF0DD01D8C8DD5DE8
DD03D8C0DD45F0DC45E8D9FADEF9DD5DE090DD45F8DC65F0DC65E890DD45E0DD
45F0DC65E8DEC990DD45E0D8C0DC09DC0A90DC4620DD1A90DC4628DD1990DC46
18DD1BD9D08BC35F5E5B89EC5DC20800
[END]


Description:


//"Benesi pinetree XYZ pixel"
xt = x*x; yt = y*y; zt = z*z;
t = 2*x/sqrt(yt+zt);
x = xt-yt-zt+Cx;
z = t*(yt-zt);
y = 2*t*y*z;

[/code][/code][/code][/code]

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: thargor6 on October 22, 2015, 11:46:18 PM
Edit, I finally succeeded by translating the first non-trivial formula (your initial formula 1 +2), so that it runs on the experimental embedded formula compiler and leads to the same result.

Using this system, this formula can be written like this:
Code:
[OPTIONS]
.Version = 2
.DEscale = 1
.SIpower = 2
[SOURCE]
procedure BenesiPineTree(var x, y, z, w: Double; PIteration3D: TPIteration3D);
var
  scale, offset: Double;
  sqrt_1_2, sqrt_1_3, sqrt_2_3: Double;
  start_x, start_y, start_z: Double;
  temp_x, temp_y, temp_z, temp: Double;  
  new_x, new_y, new_z: Double;
  x_temp, y_temp, z_temp: Double;

begin
  scale := 2.0;
  offset := 2.0;

  sqrt_1_2 := sqrt(1.0/2.0);
  sqrt_1_3 := sqrt(1.0/3.0);
  sqrt_2_3 := sqrt(2.0/3.0);

  start_x := x; start_y := y; start_z := z;
  temp_x := start_x*sqrt_2_3-start_z*sqrt_1_3;
  new_z := start_x*sqrt_1_3 + start_z*sqrt_2_3; 
  new_x := temp_x*sqrt_1_2-start_y*sqrt_1_2; 
  new_y := temp_x*sqrt_1_2+start_y*sqrt_1_2;

  new_x := abs(new_x); 
  new_y := abs(new_y); 
  new_z := abs(new_z); 

  temp_x := new_x*sqrt_1_2+new_y*sqrt_1_2;
  new_y := -new_x*sqrt_1_2+new_y*sqrt_1_2; 
  new_x := temp_x*sqrt_2_3+new_z*sqrt_1_3;
  new_z := -temp_x*sqrt_1_3+new_z*sqrt_2_3; 

  start_x:=scale*new_x-offset; //scale =2 offset=2 
  start_y:=scale*new_y;
  start_z:=scale*new_z;

  x_temp:=start_x*start_x;
  y_temp:=start_y*start_y; 
  z_temp:=start_z*start_z;
  temp:=2.0*start_x/sqrt(y_temp+z_temp); 


  new_x:= x_temp - y_temp - z_temp;
  new_z:=temp*(y_temp-z_temp); //y and z variables are switched to add symmetry 
  new_y:=temp*2.0*start_y*start_z;

  x := new_x + PIteration3D^.J1; 
  y := new_y + PIteration3D^.J2; 
  z := new_z + PIteration3D^.J3;

end;
[END]

Description:
...

To compare speed, I rendered the example you provided at 960x720 once with the ASM-formula, once with the on-the-fly compiled formula:

Hand-coded ASM: 14 seconds
On-the-fly compiled : 42 seconds


Title: Re: Benesi "pinetree" (fold+bulb)
Post by: lycium on October 23, 2015, 02:26:48 AM
Maybe it's failing to optimise those sqrt(1/3) etc. Could try replacing with the result, i.e. 0.57735026918962576450914878050196

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: thargor6 on October 23, 2015, 03:09:11 AM
Quote from: lycium on October 23, 2015, 02:26:48 AM
Maybe it's failing to optimise those sqrt(1/3) etc. Could try replacing with the result, i.e. 0.57735026918962576450914878050196
You are right, of course, thanks for the heads up!
When I use those constants, the render takes 28 seconds (compared to 14 seconds for handcoded ASM), probably there is some more room for improvement.

Cheers!

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on October 23, 2015, 04:16:58 AM
Can we compare the binary (or hex) the compiler generates with the ASM hex/binary?


  and.. it's a bit off topic, but is there a way to select each formula you want to use for each iteration in M3D?

Iteration   Formula
1      Transform 1
2      Pine Tree_x only
3      Transform 1
4      Pine Tree
5      Transform 2
n...  ...

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: lycium on October 23, 2015, 04:59:55 AM
I find it a bit odd that JIT compiled code is (so much!) slower than the normal static code.

As a point of comparison, Chaotica's new render engine (and all transforms) is written in our functional language Winter, and even doing CPU vs CPU comparisons (there is an OpenCL backend for GPUs) the MSVC compiled code gets spanked by LLVM-backed JIT code. This is largely because many things are known at render-time that are not at compile-time, but also because LLVM makes highly optimised code using the latest CPU extensions (such as AVX2, AVX-512) on CPUs which support it.

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on October 23, 2015, 07:13:55 AM
Quote from: thargor6 on October 22, 2015, 11:46:18 PM
Edit, I finally succeeded by translating the first non-trivial formula (your initial formula 1 +2), so that it runs on the experimental embedded formula compiler and leads to the same result.

:D

Ok, after doing Lycium's suggestion with the square roots, some questions.

Do you have to assign the variables every iteration?

Doesn't using fewer variables for the calculation mean fewer stack (memory) movements?  Does the compiler automatically eliminate extra variables?   Maybe test the code I make with fewer variables...

  Commenting/changing your code below.   Doing another revision below the following code because I'm not sure about your compiler- whether it's cool to use the x,y, and z variables as part of the iteration.  Second code eliminates more variables by using x,y, and z in the iteration.  SECOND CODE LOOKS BETTER>>>>... but the compiler might already streamline variables, ehh?  So... I don't know.  I can't test it.  I'd recommend second code if it works.
Code:
[OPTIONS]
.Version = 2
.DEscale = 1
.SIpower = 2
[SOURCE]
procedure BenesiPineTree(var x, y, z, w: Double; PIteration3D: TPIteration3D);
var
  scale, offset: Double;
  sqrt_1_2, sqrt_1_3, sqrt_2_3: Double;
 //     start_x, start_y, start_z: Double;   // eliminate these variables.....
//  temp_x, temp_y, temp_z, temp: Double;   // how about these too???  
  new_x, new_y, new_z: Double;
  x_temp, y_temp, z_temp, temp: Double;   //gotta add a new temp variable because we took out the others...

begin
  scale := 2.0;     // can you take all these variable assignments, and do them outside of the iteration???
  offset := 2.0;

  sqrt_1_2 := 0.7071067811865475;
  sqrt_1_3 :=  0.5773502691896258;
  sqrt_2_3 := 0.816496580927726;   // to here...

   //   start_x := x; start_y := y; start_z := z; 

    //  can you eliminate the start_x, start_y, and start_z variables???

  x_temp := x*sqrt_2_3 - z*sqrt_1_3;
  new_z :=  x*sqrt_1_3 + z*sqrt_2_3; 
  new_x := x_temp*sqrt_1_2-y*sqrt_1_2; 
  new_y := x_temp*sqrt_1_2+y*sqrt_1_2;

  new_x := abs(new_x); 
  new_y := abs(new_y); 
  new_z := abs(new_z); 

  x_temp := new_x*sqrt_1_2+new_y*sqrt_1_2;
  new_y := -new_x*sqrt_1_2+new_y*sqrt_1_2; 
  new_x := x_temp*sqrt_2_3+new_z*sqrt_1_3;
  new_z := -x_temp*sqrt_1_3+new_z*sqrt_2_3; 

  new_x:=scale*new_x-offset; //scale =2 offset=2 
  new_y:=scale*new_y;
  new_z:=scale*new_z;

  x_temp:=new_x*new_x;
  y_temp:=new_y*new_y; 
  z_temp:=new_z*new_z;
  temp:=2.0*new_x/sqrt(y_temp+z_temp); 


  new_x:= x_temp - y_temp - z_temp;
  new_y:=temp*2.0*new_y*new_z;  //  put this above the next one, so I could eliminate variables....
  new_z:=temp*(y_temp-z_temp);   //math for y and z variables is switched from regular bulb formula to add symmetry 
 
 x := new_x + PIteration3D^.J1;    // come on... don't add the next pixel components in.  come on... :D  :p   do what ya want.
y := new_y;                             // y := new_y + PIteration3D^.J2; 
z := new_z;                           // z := new_z + PIteration3D^.J3;

end;
[END]

Description:
...

With x,y, and z used for variables...

Code:
[OPTIONS]
.Version = 2
.DEscale = 1
.SIpower = 2
[SOURCE]
procedure BenesiPineTree(var x, y, z, w: Double; PIteration3D: TPIteration3D);
var
  scale, offset: Double;
  sqrt_1_2, sqrt_1_3, sqrt_2_3: Double;
 //     start_x, start_y, start_z: Double;   // eliminate these variables.....
//  temp_x, temp_y, temp_z, temp: Double;   // how about these too???  
 // new_x, new_y, new_z: Double;    // for this one, these get eliminated too....
  x_temp, y_temp, z_temp, temp: Double;   //gotta add a new temp variable because we took out the others...

begin
  scale := 2.0;     // can you take all these variable assignments, and do them outside of the iteration???
  offset := 2.0;

  sqrt_1_2 := 0.7071067811865475;
  sqrt_1_3 :=  0.5773502691896258;
  sqrt_2_3 := 0.816496580927726;   //   up to here, if you can eliminate these variable assignments.. if it's necessary?

   
  x_temp := x*sqrt_2_3 - z*sqrt_1_3;
  z :=  x*sqrt_1_3 + z*sqrt_2_3; 
  x := x_temp*sqrt_1_2-y*sqrt_1_2; 
  y := x_temp*sqrt_1_2+y*sqrt_1_2;

  x := abs(x);   // can you do this above?  I don't know how tight the compiler is
  y := abs(y);   // so if it's moving the stack and registers around before it does these commands
  z := abs(z);   // it might be faster to do the abs()  command up above, instead of here 

  x_temp := x*sqrt_1_2 + y*sqrt_1_2;
  y := -x*sqrt_1_2 + y*sqrt_1_2; 
  x := x_temp*sqrt_2_3 + z*sqrt_1_3;
  z := -x_temp*sqrt_1_3 + z*sqrt_2_3; 

  x:=scale*x-offset; //scale =2 offset=2 
  y:=scale*y;
  z:=scale*z;

  x_temp:=x*x;
  y_temp:=y*y; 
  z_temp:=z*z;
  temp:=2.0*x/sqrt(y_temp+z_temp); 


  x:= x_temp - y_temp - z_temp + PIteration3D^.J1;   // moved the pixel component up here....
  y:=temp*2.0*y*z;  //    I didn't add in the y or z pixel components because... it is more awesome that way... @!@$!@$
  z:=temp*(y_temp-z_temp);   //math for y and z variables is switched from regular bulb formula to add symmetry 
 
// x := new_x + PIteration3D^.J1;    // come on... don't add the next pixel components in.  come on... :D  :p   do what ya want.
// y := new_y;                             // y := new_y + PIteration3D^.J2; 
// z := new_z;                           // z := new_z + PIteration3D^.J3;

end;
[END]

Description:
...

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: DarkBeam on October 23, 2015, 10:08:01 AM
My handcoded uses just one temp for the fold and three for the transform. I did other reductions and stuff. By the way. Can you try to enable SSE2? Jesse did many formulas with it and it could help :)
I can surely predict that ppl will not use slow formulas, as all slow ones I did stay unused.

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: lycium on October 23, 2015, 10:44:13 AM
Re-using variables is very bad for code readability/clarity, and doesn't result in fewer registers being used or anything like that.

Having to declare variables ahead of time is awful to read and to write, and gets in the way of making variables as locally scoped as possible and declared constant. Compilers make short work of functions which don't modify any global state and just do a bunch of arithmetic on const variables. Const const const const :)

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: DarkBeam on October 23, 2015, 12:17:58 PM
An assembly formula is never readable nor reusable ;)

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: thargor6 on October 23, 2015, 12:30:02 PM
Quote from: M Benesi on October 23, 2015, 07:13:55 AM
Commenting/changing your code below.   Doing another revision below the following code because I'm not sure about your compiler...
Hi, thanks for the comment, but please note, that for me performance at this step of development was not important (except for those obvious things like precalculating constants), the main achievement was to make this formula to work at all... and getting the same result :D There was a lot of guessing involved, because there are so many versions of those formulas around and some of them use variables in a cryptic way, making it not clear, if it is a typo or intended (e.g. using tx and xt as temporary variables, and using them both ;-)). So, it was hard to guess, if the formula is wrong or the compiler did not work right (because there where also problems with compiler, e.g. when using code with a const-section it seems to overwrite internal stuff causing crashes or weird results).

A test-version will be available soon to people who are interested (no public release at the current state)


Best regards


Title: Re: Benesi "pinetree" (fold+bulb)
Post by: DarkBeam on October 23, 2015, 12:47:42 PM
Quote from: thargor6 on October 23, 2015, 12:30:02 PM
... (e.g. using tx and xt as temporary variables, and using them both ;-))...
:yes: :rotfl: :crazyeyes:

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: mclarekin on October 23, 2015, 03:01:28 PM
My attempt at a modified pinetree, hmmm :hmh:  Will have to try harder :sad1:

Code:
//benesiPineTree transform 3D
void benesiPineTreeTransform3D(const sTransformBenesiPineTree &benesiPineTree, CVector3 &z, CVector3 &c,int i, sExtendedAux &aux)
{
  if (benesiPineTree.control.enabled && i >= benesiPineTree.control.startIterations && i < benesiPineTree.control.stopIterations)
  {
    CVector3 temp = z;
    CVector3 start = z;
    CVector3 tempV1;
    CVector3 newZ;
    CVector3 tempV2;
    tempV1.x = start.x * 0.81649658092772603273242802490196 - start.z * 0.57735026918962576450914878050196;
    newZ.z = start.x * 0.57735026918962576450914878050196  +  start.z * 0.81649658092772603273242802490196;
    newZ.x = tempV1.x * 0.70710678118654752440084436210485 - start.y * 0.70710678118654752440084436210485;
    newZ.y = tempV1.x * 0.70710678118654752440084436210485 + start.y * 0.70710678118654752440084436210485;
    newZ.x = fabs(newZ.x);
    newZ.y = fabs(newZ.y);
    newZ.z = fabs(newZ.z);
    tempV1.x = newZ.x * 0.70710678118654752440084436210485 + newZ.y * 0.70710678118654752440084436210485;
    newZ.y = -newZ.x * 0.70710678118654752440084436210485 + newZ.y * 0.70710678118654752440084436210485;
    newZ.x = tempV1.x * 0.81649658092772603273242802490196 + newZ.z * 0.57735026918962576450914878050196;
    newZ.z = -tempV1.x * 0.57735026918962576450914878050196 + newZ.z * 0.81649658092772603273242802490196;
    
    start = benesiPineTree.scale * newZ - benesiPineTree.offset; // applying six variables:-  scale.x, scale.y, scale.z,  offset.x, offset.y, offset.z
    
    
    tempV2 = start * start;
    double tempD3 = 2.0 * start.x/sqrt(tempV2.y + tempV2.z);
    newZ.x= tempV2.x  -  tempV2.y  -  tempV2.z;


    newZ.z=tempD3 * (tempV2.y - tempV2.z); //y and z variables are switched to add symmetry
    newZ.y=tempD3 * 2.0 * start.y * start.z;
    z = newZ + c * benesiPineTree.constantMultiplier;// CVector3 individual values for c.x, c.y, c.z, so can use "0" to get rid of unwanted pixel additions



Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on October 23, 2015, 07:08:03 PM
Quote from: lycium on October 23, 2015, 10:44:13 AM
Re-using variables is very bad for code readability/clarity, and doesn't result in fewer registers being used or anything like that.

  My idea is to test whether there is a problem with the compiler using unnecessary registers or stack shifts, thus the streamlined code (which is harder to read.. but so what- this is just to test the compiler). 

  In other words, if the following code runs faster than the original code, you have a problem with the compiler using extra registers or stack movement due to the extra variables.  The test is easy.  Run this code.  Run the other code.  If one is measurably faster.....

Code:
[OPTIONS]
.Version = 2
.DEscale = 1
.SIpower = 2
[SOURCE]
procedure BenesiPineTree(var x, y, z, w: Double; PIteration3D: TPIteration3D);
var
  scale, offset: Double;
  sqrt_1_2, sqrt_1_3, sqrt_2_3: Double;
  x_temp, y_temp, z_temp, temp: Double;   

begin
  scale := 2.0;     
  offset := 2.0;

  sqrt_1_2 := 0.7071067811865475;
  sqrt_1_3 :=  0.5773502691896258;
  sqrt_2_3 := 0.816496580927726;   

   
  x_temp := x*sqrt_2_3 - z*sqrt_1_3;
  z :=  x*sqrt_1_3 + z*sqrt_2_3; 
  x := x_temp*sqrt_1_2-y*sqrt_1_2; 
  y := x_temp*sqrt_1_2+y*sqrt_1_2;

  x := abs(x);   // can you do this above?  I don't know how tight the compiler is
  y := abs(y);   // so if it's moving the stack and registers around before it does these commands
  z := abs(z);   // it might be faster to do the abs()  command up above, instead of here 

  x_temp := x*sqrt_1_2 + y*sqrt_1_2;
  y := -x*sqrt_1_2 + y*sqrt_1_2; 
  x := x_temp*sqrt_2_3 + z*sqrt_1_3;
  z := -x_temp*sqrt_1_3 + z*sqrt_2_3; 

  x:=scale*x-offset; //scale =2 offset=2 
  y:=scale*y;
  z:=scale*z;

  x_temp:=x*x;
  y_temp:=y*y; 
  z_temp:=z*z;
  temp:=2.0*x/sqrt(y_temp+z_temp); 


  x:= x_temp - y_temp - z_temp + PIteration3D^.J1;   
  y:=temp*2.0*y*z;  
  z:=temp*(y_temp-z_temp); 
 
end;
[END]

Description:
...

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on October 23, 2015, 07:14:22 PM
Quote from: DarkBeam on October 23, 2015, 12:17:58 PM
An assembly formula is never readable nor reusable ;)
  lol...

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on October 23, 2015, 07:20:56 PM
Quote from: thargor6 on October 23, 2015, 12:30:02 PM
Hi, thanks for the comment, but please note, that for me performance at this step of development was not important (except for those obvious things like precalculating constants), the main achievement was to make this formula to work at all... and getting the same result :D
  Cool.  Awesome that you got it to work!

  I was thinking that maybe using the 2 different codes would show whether there is an optimization bug associated with variable usage (to be fixed later). 

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: thargor6 on October 23, 2015, 10:04:24 PM
Quote from: M Benesi on October 23, 2015, 07:08:03 PM
   In other words, if the following code runs faster than the original code, you have a problem with the compiler using extra registers or stack movement due to the extra variables.  The test is easy.  Run this code.  Run the other code.  If one is measurably faster.....
The "optimized" code runs slightly slower, but more importantly, it does not lead to the same result ;-)

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: thargor6 on October 23, 2015, 10:16:37 PM
Btw, I like this formula a lot (still using my first "slow" version):
(http://orig14.deviantart.net/c9f0/f/2015/296/e/e/benesi_reef_by_thargor6-d9e3w0l.png)

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on October 23, 2015, 11:49:39 PM
Quote from: thargor6 on October 23, 2015, 10:04:24 PM
The "optimized" code runs slightly slower, but more importantly, it does not lead to the same result ;-)

lol!@#   My anti-optimization powers strike again!  :D  

  The result difference is because I took out the y and z pixel additions.  


  Cool looking image!  Organic.  nice. 

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on October 24, 2015, 01:37:58 AM
here. 

Transform 3 is sort of like transform 2, use ~1.414 scale and offset for it.  I'll post images later.  It's a bit different. 

Code:
[OPTIONS]
.Version = 2
.DEscale = 1
.SIpower = 2
.Double Scale = 1.414    //no.. it is not square root of 2.  Seriously.  I wouldn't lie to you.
.Double xOff = 1.414   //  there is no such thing as mathematical sarcasm.
[CONSTANTS]
Double = 0.816496580927726
Double = 0.5773502691896258
Double = 0.7071067811865475
[CODE]
558BEC81EC300000005356578B75088B7E308BD8D9D0DD03DC0FDD01DC4F08D9
E0DEC1DC4F10DD5DF8DD02DC4F10DD1A90DD03DC4F08DD01DC0FDEC190DD45F8
DC2290DD45F8DC0290D9E1DD5DF0D9E1DD5DF8D9E1DD19D9D0DD45F0DC01
DC67E8D9E1DC4FF0DC4F10DD1B90DD45F8DC01DC67E8D9E1DC4FF0DC4F10
DD1A90DD45F8DC45F0DC67E8D9E1DC4FF0DD1990DD02DC03DD02DC23DD1A
DD5DF890DD45F8DC0FDD01DC4F08DEC1DD45F8DC4F08D9E0DD01DC0F90DEC1DD
19DD1B90D9D08BC35F5E5B89EC5DC20800
[END]


Description:

The cool Benesi pinetree formula. Use in conjunction with normal
 BenesiPine1 or it is messy!
Or any other formula :)
(Three iters of pine1 + one of pine2)

// STEP1: "Benesi fold 3"
tx=(x*sqrt(2/3)-z*sqrt(1/3))*sqrt(1/2);
y=y*sqrt(1/2);
z=abs(x*sqrt(1/3) + z*sqrt(2/3));   	   //replace squaring with abs    D8C8 to  D9E1   done
tx=abs(tx-y);          //replace squaring with abs    D8C8 to  D9E1   done
ty=abs(tx+y);  			     //replace squaring with abs    D8C8 to  D9E1   done

x=abs(ty+z-offset2)*scale2*sqrt(1/2) ;  //remove sqrt part for these three   done
y=abs(tx+z-offset2)*scale2*sqrt(1/2) ;   //
z=abs(tx+ty-offset2)*scale2 ;    //

tx=y+x; y=y-x; 
x=z*sqrt(1/3)+tx*sqrt(2/3);    //
z=z*sqrt(2/3)-tx*sqrt(1/3);    // 


[/code]

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on October 24, 2015, 06:00:26 AM
And.. silly me.  I finally understand how to use M3D....  :embarrass: :embarrass: :embarrass:

   Finally made my first official pine tree combo in M3D!#!!!:

(https://lh3.googleusercontent.com/-0kT3i4qAr0E/Vir_CWtouII/AAAAAAAADQc/zZZafM2QEf4/s640-Ic42/doy.jpg)

Code:
Mandelbulb3Dv18{
g.....s/...c3...w....2.....qgGqbq9Jxz8k7.8K6JA2EQOmvmJrojz93xENw05CpzaOoO35E..yD
................................PQmj9H0S/.2........A./..................y.2...wD
...Uz6.....c0.../M.0/.....kf....//....E3.....2B2wllgi0oD/..........m0dkpXm1....U
./....kD12../..........wz.................................U0.....y1...sD...../..
.z1...sD2iG9ULnFTx1mfy826hJBzoHTbqMrUGoj6HQUgZVsZwXAZ3up1YKKzM5RdsAtmJpDW2C40nmY
4x1SpJd8qDDJzageHU16WRpDU.....Iy1.............sD.6....sD..G.....................
.............oAnAt1...sD....z...........................................C....k1.
.....Ksulz1.......kz.wzzz1.U..6.P....U5...EB....m....c3....F....6/...I1.....SF52
...U.qFG9yzb2zzzRYoWzz7lz16.pc..zXCc..kvrEtMc7xD6ocyFE0ujz1..........2.28.kFrA0.
.Ub96aAIVz9.1se7Umvxz0........../EU0.wzzz1...........s/...................E.2c..
zzzz.............0...................2./8.kzzzD............8....................
/EU0.wzzz1...................................2CcN/UvNPcveeWCNq0.yRiibHJJUk1f..XR
SvBmx3CcN/UvNPcvQsLsUa3.ibhVi1bTV1OK.sSq4uCly3CcN/UvNPcvMwLsUa3.ibhVinqTV1OK.sSq
4uCkz3CcN/UvNPcv..EsUa3feeWCNqGQIJ36wk8EwyLsUa3f................................
E.E..I.//3./....I....6....UEZtKNnZ4IdtKNlsqPNd3.................................
...................../.........E................................................
................................................................................
.....................2.....3....0....6INiJqQdFZQVtqQaxaQh71.....................
...............................E..........2.....................................
................................................................................
................................/....E/.........0JaPZBLOEZaPZVJKO/..gJKOY/......
..........................................2........../.................CD02.....
.UnX.1.................CD02......UnX.1..........................................
..........................................E.....I....6....UEZtKNnZ4Jm3aPnNqPmpqA
..........................................kAnAnAnAnyzAnAnAnAngzD................
................................................................................
.....................................................2.....3....0....6INiJqQd/JO
iJKAixKKO/.....................................................E..........2.....
................................................................................
................................................................}
{Titel: doy}


  Attaching a few other formulas...  BenesiPine1noYZ... has noYZ components.  You don't have to cancel them out.  If you mix it with the first one Luca wrote (after a few iterations)... it gets sort of cool.

  hahhaa... Someone needs to make an animation.  If you do a rotation between the Mandelbulb part of the formula, and the transform part, after a certain iteration, it only rotates certain things.  It's pretty cool...



Title: Re: Benesi "pinetree" (fold+bulb)
Post by: DarkBeam on October 24, 2015, 10:07:55 AM
Message to Matthew
Please please open a topic with your m3f and put them all together in there (or a mass confusion is going to begin). Thanks :) :police:

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: mclarekin on October 24, 2015, 12:44:45 PM
Quote
And.. silly me.  I finally understand how to use M3D...

Silly me. I just reread the whole post and I find I had some really mixed up ideas on the transforms :)

Well done with getting it all working, it is a relief when you finely  get your transforms working. I find it incredible how many stupid mistakes I make, and everthy takes so much longer than I expect. :)

Here is a minor optimization ( if you have not already done it) ,  y := x_temp*sqrt_1_2+y*sqrt_1_2;    reduces to      y :=( x_temp +  y )  * sqrt_1_2;      // you  delete 4 multiplications from your transform

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on October 24, 2015, 06:16:23 PM
I'll check it... I cannibalized Luca's version of transform 2 to make transform 3, just removing 3 square root operations.

  Some of the math posted in this thread is not actually the way it is implemented in the code (some of the descriptions of the code (for the formulas!) contain errors. 

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: DarkBeam on October 24, 2015, 07:53:17 PM
Plz read my latest message above ;)

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on October 25, 2015, 02:00:47 AM
hahahaha... Done.  Next up.. well, I should put it in that thread  (a few formulas for Luca thread is here (http://www.fractalforums.com/mandelbulb-3d/a-few-formulas-%28for-luca-d%29)).

 I'm thinking about a weighted transform, that smoothly transitions between T2 and T3.  So you could be 100 T2, or 99 T2 + 1 T3, or 35 T2 + 65 T3...  you get the picture.

  This will allow smooth transitions between stuff, such as the first image (which is pure T3, with 1 or 2 full pixel add ins, which give it a bit of distortion) to the next image (which... I think is T2 and T3??? with maybe... only pixel x??):
(https://lh3.googleusercontent.com/-GX7d2FRnAVc/VisEbyw_fLI/AAAAAAAADQ0/VVgsxIglMcw/s400-Ic42/doy2.jpg) to (https://lh3.googleusercontent.com/-Zr5P8pL-WXM/VisJWAkjFwI/AAAAAAAADRo/rPFcdH5uedA/s400-Ic42/doy4.jpg)

  Then when we mix in specific rotations (after transforms on specific iterations), we can move specific portions of it:
https://www.youtube.com/watch?v=SXx36wiDpN0 (https://www.youtube.com/watch?v=SXx36wiDpN0)

  You can also distort it a bit by rotating around different axes (the video above is around the x axis after the transform).  

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: mclarekin on October 25, 2015, 02:09:13 AM
Transition look at Mandelbulber common_math.cpp.

Code:
//Smooth transition between two vectors with vector length control
template <typename T>
T SmoothCVector(const T &v1, const T &v2, double k)
{
	T result;
	double nk = 1.0 - k;

	if(k <= 0.0)
	{
		result = v1;
	}
	else if (k >= 1.0)
	{
		result = v2;
	}
	else
	{
		double length1 = v1.Length();
		double length2 = v2.Length();
		double lenInterp = length1 * nk + length2 * k;
		T vTemp = v1 * nk + v2 * k;
		double lengthTemp = vTemp.Length();
		if(lengthTemp > 0.0)
		{
			result = (vTemp / lengthTemp) * lenInterp;
		}
		else
		{
			result = v1;
		}
	}
	return result;


With it you can transition between any fractal or transform with good to average effect.  With it you can grow hybrid fractals. It is very cool for animation.

Can be used also to fine tune DE, i.e if adding a tranform into your loop that makes the DE bad, you can try reducing the weight and sometimes you still get a good effect but also your DE gets better.

With IFS you sometimes have to set it up so the weight also changes the DE calculation.

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on October 25, 2015, 02:50:30 AM
Cool.  That might work, but for some reason I don't think it will be quite as smooth (I'm often wrong... the only way to check is to test it out).  As a matter of fact, I think the major difference in the 2 images above is... one uses 4 iterations of Pine1 before the transform, the other uses 3.  See... I told you I make lots of mistakes.  :D


  The math/geometry of T2 and T3 is:  Rotate, Transform (T2 or T3), Rotate back.  My idea is to blend the transforms inside the rotation, instead of outside.  The 2 transforms are quite similar...  Luca's descriptions are in the code block below.  Just made another transform because I was thinking about it.  I'll make up an original name for this one.  Maybe... transform 4?  :D  

T4:
(https://lh3.googleusercontent.com/-D1YpOIJqqHw/Viw0ddPEveI/AAAAAAAADSc/Fzk5fLkl-xM/s640-Ic42/T4.jpg)
T4 with XYZ pixel too, like the next 2 images...
(https://lh3.googleusercontent.com/-bhHn4l8wggk/Viw4tHXoMEI/AAAAAAAADS4/7krBhikLKl0/s640-Ic42/T4%252520with%252520xyz%252520too.jpg)

  These next 3 images have an additional transform (2?? or 3???) later on.  The 2 images above this do not.  You can see that it changes the details a bit.  Question: do the transforms have a different effect if you select odd or even numbers of prior iterations?  For some reason, I think that it does. 

T4, xyz, extra transform 2 later on:

(https://lh3.googleusercontent.com/-twYl4QjIhuo/Viw7m0krDBI/AAAAAAAADTQ/4g685LUn2Wc/s640-Ic42/T4%252520with%252520xyz%252520and%252520extra%252520T2.jpg)

T2:
(https://lh3.googleusercontent.com/-BoU8gAkkrl0/VisGOluC76I/AAAAAAAADRI/_AtWoYrZKCk/s640-Ic42/doy3.jpg)

T3... This one also has full xyz pixel component added in at one point, which makes it wavier in areas... and maybe other stuff...:
(https://lh3.googleusercontent.com/-GX7d2FRnAVc/VisEbyw_fLI/AAAAAAAADQ0/VVgsxIglMcw/s640-Ic42/doy2.jpg)

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: KRAFTWERK on October 25, 2015, 04:02:39 PM
Quote from: DarkBeam on October 16, 2015, 05:21:56 PM
...And Johan - where is the pretty image :horsie: :mandel:

Too little time... :) Here is a one default setting render...


Title: Re: Benesi "pinetree" (fold+bulb)
Post by: thargor6 on October 28, 2015, 10:26:26 PM
One more play with the JIT-version of this formula:
(http://orig09.deviantart.net/b939/f/2015/301/2/4/benesi_reef_2_by_thargor6-d9ep6g8.png)

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: DarkBeam on October 29, 2015, 12:17:55 AM
Great work Johan and Andreas... :)

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on October 29, 2015, 01:27:25 AM
Very nice.  Thank you for using the formula!

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: KRAFTWERK on October 29, 2015, 04:08:00 PM
Quote from: M Benesi on October 29, 2015, 01:27:25 AM
Very nice.  Thank you for using the formula!

It's an honor!  O0 And thank you Luca!

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on October 30, 2015, 06:39:08 AM
I don't know if anyone noticed that the 0,0,0 Julia of this fractal is arranged like a stellated octahedron.  That's the next project..  aligning a stellated octahedron (maybe a pseudo-Sierpinski type) and hybridizing it with this fractal.

  I had something I thought was one... but now I'm not too sure (actually.. I don't think it is):
https://www.youtube.com/watch?v=GC8IKrIB1pA (https://www.youtube.com/watch?v=GC8IKrIB1pA)

  Luca showed me the shape's formula in M3D, but it's DIFS...

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: DarkBeam on October 30, 2015, 09:36:03 AM
Difs are calculated in one shot, so hybrids are not possible.
In other words given x, y, z they just return the distance estimation. I hope it is clear?  :beer:

on the other hand. Using difs you can create more general fractals replicating even de combinates and fractals with more than three variables like phoenix ... etc :dink:
Of course you must handle the bailout the cycle everything.
I wanted to import the script by Bulatov but it is hyper complicated...

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on October 30, 2015, 06:23:28 PM
  So Luca.. I can maybe extract what I want from the binary... and make a plain formula.  I'll have to look.  Doing other things now.  :D

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on November 02, 2015, 08:45:45 AM
Pine tree frag with lolsquares.  :D  Will add more lolsquares functionality to it later.
  Fixed DE for T3... :D   Thanks Mclarekin...

(https://lh3.googleusercontent.com/-s7voqcz7IKQ/VjcT5utbiXI/AAAAAAAADao/ljLIgoahV2k/s534-Ic42/lolsqer3.jpg) (https://lh3.googleusercontent.com/-KkRTGd8Lb6M/VjcTvL-TLUI/AAAAAAAADao/2vfWL6fdiTw/s366-Ic42/lolsquares.jpg)

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: mclarekin on November 02, 2015, 09:57:58 AM
Looking even better O0


BTW   .frag  is missing    dr*=T3Scale;

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on November 03, 2015, 07:32:54 AM
  Fixed DE yesterday, thanks!

So I need to work on getting these formulas ported to M3D.  I'm thinking the separate cube to sphere, and sphere to cube formulas, and a combo formula with Pine Tree 1, so we don't have to use a whole bunch of formula tabs to use it...

from the frag:
Code:
sr32=sqrt(3/2); //both use square root of 3/2 ...
// spheric  code
 rCyz= (z.y*z.y)/(z.z*z.z);
 rCxyz= (z.y*z.y+z.z*z.z)/(z.x*z.x);
if (rCyz<1.) {rCyz=sqrt(rCyz+1.);} else {rCyz=sqrt(1./rCyz+1.);}
if (rCxyz<1.) {rCxyz=sqrt(rCxyz+1.);} else {rCxyz=sqrt(1./rCxyz+1.);}

z.yz*=rCyz;  
z*=rCxyz/sr32;  


// unSpheric 
	
 rCyz= (z.y*z.y)/(z.z*z.z);
if (rCyz<1.) {rCyz=1./sqrt(rCyz+1.);} else {rCyz=1./sqrt(1./rCyz+1.);}
z.yz*=rCyz;

 rCxyz= (z.y*z.y+z.z*z.z)/(z.x*z.x);
if (rCxyz<1.) {rCxyz=1./sqrt(rCxyz+1.);} else {rCxyz=1./sqrt(1./rCxyz+1.);}
z*=rCxyz*sr32;
 

  That might be tomorrows work.

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: DarkBeam on November 03, 2015, 10:43:29 AM
This is what I experienced;
People tend to ignore transforms.
Also they ignore slow formulas.
Even worse transforms that must be used in conjunction!
They tend to use easy to handle formulas and to combine them in a random way.
That is why I did your formulas that way :)
More importantly there is already a tospherical/invsph transform for MB3D ;)

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on November 03, 2015, 05:18:25 PM
hahahha... Awesome.  Less work... whoops.  IT does work.. :D  Maybe not exactly how I expected it.

  Ehh... So...  I looked at them some more.  While they can transform an amazing box to a sphere, and back, they don't have the same effects.  They introduce distortions and stuff... and they don't work like the sphere transforms I wrote. 

  I'll try them on some other stuff.. but they don't seem to be working the same way.  Instead of making a "squary" pine tree, they make a brain:

(https://lh3.googleusercontent.com/-KkRTGd8Lb6M/VjcTvL-TLUI/AAAAAAAADao/2vfWL6fdiTw/s300-Ic42/lolsquares.jpg) (https://lh3.googleusercontent.com/-FIZ7vAkJg-Y/VjjnQNyYEHI/AAAAAAAADbM/ZZZE5HvnZvg/s500-Ic42/brain.jpg)

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: DarkBeam on November 03, 2015, 06:20:24 PM
Ah!!! That's because you are not using really the standard spherical coordinates! :) Because the transforms itself do their work :)
That's right. You are maybe doing a "spherization"?
Luca

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on November 03, 2015, 08:00:04 PM
 yeah!  Basically, I'm taking a cube... making it a sphere.  Then I transform it back. Or the other way around (in the case of the squary pine tree above). 

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: M Benesi on November 04, 2015, 03:28:16 AM
omg... I think Scale and Offset are reversed in all the assembly!  At least in the one I just opened to cannibalize.  I wonder... will have to compare with other stuff!

Title: Re: Benesi "pinetree" (fold+bulb)
Post by: thargor6 on December 16, 2015, 02:05:05 AM
Quote from: thargor6 on October 22, 2015, 11:46:18 PM
To compare speed, I rendered the example you provided at 960x720 once with the ASM-formula, once with the on-the-fly compiled formula:
Hand-coded ASM: 14 seconds
On-the-fly compiled : 42 seconds
In the meanwhile the solution can reach much better speed.
Using the current prototype, I created a test-render with the initial example from Luca, i. e. two formulas, one of them is the BenesiTree, resolution was 1920x1440.

Both formulas hand-coded ASM: 15 seconds
Same setting, but exchanged one formula by the JIT-variant: 25 seconds




Powered by SMF 1.1.21 | SMF © 2015, Simple Machines