Welcome to Fractal Forums

Fractal Math, Chaos Theory & Research => Sierpinski Gasket => Topic started by: mclarekin on November 14, 2016, 01:44:39 AM

Title: Implementing MixPinski
Post by: mclarekin on November 14, 2016, 01:44:39 AM

first attempt at darkbeams mixPinski, which I now know is another cross menger type (sierpinski-rotate-menger4D)

Title: Implementing MixPinski
Post by: mclarekin on November 14, 2016, 06:05:58 AM

Another way of looking at what is happening with the function is by graphing. This image shows the five folds that are in some amazing surf UI,s graphed at default values (generally 1.0).

the horiz. axis is x entering the function ,and the vert. axis is the output value x, (the value it has been mapped to). This graph is difficult to read, but it shows the areas of similarity between these different folds.

The peaks and valleys in the graph are related to the fold/limit/offset/shift value, in this case mostly happening at 1.0 and -1.0. What we can then do is insert types of curves into the peaks and valley and make the folding operation smooth ( i have yet to try this).

Title: Implementing MixPinski
Post by: DarkBeam on November 14, 2016, 09:35:34 AM

From what I remember I think MP is more symmetric :D
Nice render though! :beer: thanks for implementing

Title: Implementing MixPinski
Post by: Crist-JRoger on November 14, 2016, 10:37:53 AM

mclarekin, thanks again! Not really sure, added foldings, strange construction :-X ;D

(http://img00.deviantart.net/6614/i/2016/319/3/3/cm_fold_1_by_crist_jroger-daohdt2.jpg) (http://orig04.deviantart.net/c38b/f/2016/319/9/d/cm_fold_1_by_crist_jroger-daohdt2.jpg)

Title: Implementing MixPinski
Post by: mclarekin on November 14, 2016, 11:19:54 AM

@crist, WOW , cool image. A limitless world to explore when mixing all of of these linear type fractals. Is the MixPinski in a .frag? if not I can try and make one.

@DarkBeam

I quickly coded it (minus the rotation yet), and I have still to understand the menger and DE maths.

Anyhow first impressions is that is a brilliant tool for making a very large infinity of shapes and patterns and then, when I starting exploring, it just got better and better :embarrass: :beer: O0

It is fast and hybridizable, It finally gives me a second 4D linear to test the existing 4D transforms with and a reason to make some more.

So far, the analytical DE is better than I was expecting, and in some settings it is excellent.

Title: Implementing MixPinski
Post by: Crist-JRoger on November 14, 2016, 11:47:42 AM

Quote from: mclarekin on November 14, 2016, 11:19:54 AM

@crist, WOW , cool image. A limitless world to explore when mixing all of of these linear type fractals. Is the MixPinski in a .frag? if not I can try and make one.

Thank you!
I guess no. (Just googled now what is MixPinski :D ) More .frags! :dink:

upd.: another one render on Intel GPU. Classic DE-Raytracer.frag :)

(http://img04.deviantart.net/f3ea/i/2016/319/4/b/cm_fold_3_by_crist_jroger-daohpeg.jpg) (http://orig05.deviantart.net/5ca7/f/2016/319/e/f/cm_fold_3_by_crist_jroger-daohpeg.jpg)

Title: Implementing MixPinski
Post by: mclarekin on November 15, 2016, 07:42:11 AM

@ crist. This is an example of converting one of DarkBeams M3D.m3f. I have still got a lot to do to finish coding it properly ( I have also lost some symmetry in c++ version),. This is a walk_through of the steps I take when attempting to convert a .m3f to .fract

// DarkBeams MixPinski4.m3f

1) GET INFORMATION FROM FIRST SECTION
[OPTIONS]
.Version = 6
.DEscale = 0.2      DE step, fudge factor??
.ADEscale = 2      ??
.DEoption = 6      would be good to know what DE method this equates to in Fragmentarium
.RStop = 1024      bailout
.SIpower = 2      ??
.Double Scale = 2    make default settings. uniform float scaleM; slider[0.0,2.0,20.]
.Double CScale X = 1   make default settings. uniform vec4; slider[(-5.0,1.0,5.0),(-5.0,1.0,5.0),(-5.0,0.5,5.0),(-5.0,0.5,5.0)]
.Double CScale Y = 1
.Double CScale Z = 0.5
.Double CScale W = 0.5
.6SingleAngles Rotation = 0      4D six_angle rotation

558BEC53565789C38B75088B7E30DD41
08DD01DD02DD0390D9E0D8D1DFE0D0EC
7202D9C9D8D2DFE0D0EC7202D9CAD9E0
D9C9D9E0D8D2DFE0D0EC7202D9CAD9E0
D9C990D9E0D8D3DFE0D0EC7202D9CBD9
E0D9C9D9E0D8D3DFE0D0EC7202D9CBD9
E0D9C9D9CAD9E0D8D3DFE0D0EC7202D9
CBD9E0D9CA9083EF28D9C0D84FF4D9C2
D84FF0DEC1D9C3D84FECDEC1D9C4D84F
E8DEC1DD1BD9C0D84FE4D9C2D84FE0DE
C1D9C3D84FDCDEC1D9C4D84FD8DEC1DD
1AD9C0D84FD4D9C2D84FD0DEC1D9C3D8
4FCCDEC1D9C4D84FC8DEC1DD19D84FC4
D9C9D84FC0DEC1D9C9D84FBCDEC1D9C9
D84FB8DEC183C728DD47F0DCC9D9E8DE
E9DC4FD0DEE9DD5908DD01DD02DD03DD
47F0DD86E8000000D8C9DD9EE8000000
9090DCCADCC9D9C0D9E8DEE9D9C0D9C0
DC4FE8DEEDDC4FE0DEEBD8F1DC4FD8DC
ECD9CCD9E1DEECDECBDD1ADD1BDD1990
909089D85F5E5B5DC20800

2) THEN WE EVALUATE THE INFO IN DESCRIPTION (This can be very important)
Description:

NOTE: If the formula does not render correctly together with 3D formulas check "Disable analytical DE".

A strange but intriguing fractal, that mixes Sierpinski and Menger folds. The amazing thing is that in 3D it does not work so well!

3) SET UP INITIAL CONDITIONS
uniform float scaleM; slider[0.0,2.0,20.]
uniform vec4 scaleC; slider[(-5.0,1.0,5.0),(-5.0,1.0,5.0),(-5.0,0.5,5.0),(-5.0,0.5,5.0)]

// offset useful for testing purposes, but will also keep in final UI
uniform vec4 offsetM; slider[(-5.0,0.0,5.0),(-5.0,0.0,5.0),(-5.0,0.0,5.0),(-5.0,0.0,5.0)]

// to give an intial w value
uniform float w; slider[0.0, 0.0, 5.0]

uniform int MI; slider[0.0, 10.0, 250.0] // maximum iterations

uniform float bailout; slider[0.0, 1024.0, 1024.0]

uniform float DE = 1.0; // not sure if you need this

uniform vec4 z = (pos, w); // not sure how to do this in Frag.(p.x,p.y, p.z, w)

//MixPinski4(x,y,z,w){
// r=x*x+y*y+z*z;

float DE(vec4 z)
{
   float r = (z.x * z.x + z.y * z.y + z.z * z.z); // for bailout. Mandelbulber includes "+ z.w * z.w); "
// but i suspect it may not be necessary

4) THEN THE ITERATION LOOP
4a)The Sierpinski part is a cut and paste. No editing required. :)

   for(i=0;i<MI && r<bailout;i++){

   if(z.x+z.y<0.0) z.xy = -z.yx;
   if(z.x+z.z<0.0) z.xz = -z.zx;
   if(z.y+z.z<0.0) z.zy = -z.yz;
   if(z.x+z.w<0.0) z.xw = -z.wx;
   if(z.y+z.w<0.0) z.yw = -z.wy;
   if(z.z+z.w<0.0) z.zw = -z.wz;

4b) z += offsetM; // I add in offset for testing

   //rotate4D(x,y,z,w); 4D rotation TODO, could try using a 3D rot for now

4c) 4D Menger Sponge part, I did a Find and Replace

   z.x= scaleM *z.x-scaleC.x*( scaleM -1);
   z.y= scaleM *z.y-scaleC.y*( scaleM -1);
   z.w= scaleM *z.w-scaleC.w*( scaleM -1);
   z.z-=0.5*scaleC.z*( scaleM -1)/ scaleM ;
   z.z=-abs(-z.z);
   z.z+=0.5*scaleC.z*( scaleM -1)/ scaleM ;
   z.z= scaleM *z.z;

   // original code
   /* x=scale*x-CX*(scale-1);
   y=scale*y-CY*(scale-1);
   w=scale*w-CW*(scale-1);
   z-=0.5*CZ*(scale-1)/scale;
   z=-abs(-z);
   z+=0.5*CZ*(scale-1)/scale;
   z=scale*z;*/

   //r=x*x+y*y+z*z;
   r = (z.x * z.x + z.y * z.y + z.z * z.z);

   DE *= scaleM; // I added this because i do not understand the original DE, but I will eventually add the original DE to the Mandelbulber DE section and test it out
   }

5) I GET CONFUSED WITH DE
   //return sqrt(x*x+y*y+z*z)*scale^(-i); // original code, completely new to me
   return (r - 2.0) / DE); // I used this, but I could try "return r/DE;" and maybe a generic "return (r - offsetD)/DE.
I// have a lot to learn about DE calculation.

I cannot guarantee this will make a workable .fract, but hopefully it may be OK.

Title: Implementing MixPinski
Post by: DarkBeam on November 15, 2016, 08:08:52 AM

Please note that mb3d auto handles de so idk :)
:beer:

Title: Implementing MixPinski
Post by: mclarekin on November 15, 2016, 09:39:20 AM

@ DarkBeam. I am now working my way though the code, and have some questions for you.

a) does w come into the loop as a default of 0.0?

b) line: z=-abs(-z);
abs of neg z, is this different to abs of pos z in programming language?

c) With the use of Cscale.
I am guessing the terms (scale-1) and (scale-1)/scale is from how the maths is constructed.

But I am thinking that when implementing the code:

x=scale*x-CX*(scale-1);
y=scale*y-CY*(scale-1);
w=scale*w-CW*(scale-1);
z-=0.5*CZ*(scale-1)/scale;
z=-abs(-z);
z+=0.5*CZ*(scale-1)/scale;
z=scale*z;

could ithet be removed and shortened to this:
(i.e the user input CX value can be considered to include the result of the "scale" maths (unless I missed something))

x=scale*x-CX;
y=scale*y-CY;
w=scale*w-CW;
z-= CZ;
z=-abs(-z);
z+=CZ;
z=scale*z;

d) DELETED. I have looked at the DE maths:

return sqrt(x*x+y*y+z*z)*scale^(-i);

and I figured out that it looks like the linear "return distance = r/DE" sort of thing, because DE is a function of scale and iterations. With this sort of DE I visualize a graph of DE value over iteration_count, and in that respect this equation would appear to make sense. I will check it out once I have implemented the 4D rotation, but it would be interestingly cool if the "scale^(-i)" maths produced some difference.

Title: Implementing MixPinski
Post by: mclarekin on November 15, 2016, 11:12:02 AM

Symmetry issue resolved, my first image was not aligned to a symmetric axis, there are all sorts of 45 degree rotations you can view it from. It is a strange but intriguing fractal before you even start changing parameters. :beer:

These images are at default parameters.

Title: Implementing MixPinski
Post by: DarkBeam on November 15, 2016, 03:37:56 PM

Yes to all questions except you should not touch the cx scaling because it is derived from the holy Knighty formulas that I will never understand ... but are untouchable O0
Lastly I think your latest renders are okay but I am used to see it from the unrotated view. And I was amazed too from the very 1st render of the formula that I made only for fun I did not expect to discover a real fractal!

Title: Implementing MixPinski
Post by: Crist-JRoger on November 15, 2016, 05:59:38 PM

don't works :-\ end no errors :hmh: Where return function need to be?

Code:

#include "DE-Raytracer.frag"

uniform float scaleM; slider[0,.2,.2]
uniform vec4 scaleC; slider[(-5,-5,-5,-5),(1.,1.,.5,.5),(5.,5.,5.,5.)]
uniform vec4 offsetM; slider[(-5,-5,-5,-5),(0.,0.,0.,0.),(5.,5.,5.,5.)]
uniform float w; slider[0,0,5.]
uniform int MI; slider[0,10,250]
//uniform float bailout; slider[0,1024,1024]

float DE(vec3 p)
{
	vec4 z=vec4(p,w);
	float r=0.;
	//float r=(z.x*z.x+z.y*z.y+z.z*z.z);
	//float r=z.x*z.x+z.y*z.y+z.z*z.z+z.w*z.w;
	//for(int i=0; i<MI && r<bailout; i++){	
	for(int i=0; i<MI; i++){	
	if(z.x+z.y<0.0) z.xy = -z.yx;
    if(z.x+z.z<0.0) z.xz = -z.zx;
    if(z.y+z.z<0.0) z.zy = -z.yz;
    if(z.x+z.w<0.0) z.xw = -z.wx;
    if(z.y+z.w<0.0) z.yw = -z.wy;
    if(z.z+z.w<0.0) z.zw = -z.wz;

	z+=offsetM;

	z.x= scaleM *z.x-scaleC.x*( scaleM -1);
    z.y= scaleM *z.y-scaleC.y*( scaleM -1);
    z.w= scaleM *z.w-scaleC.w*( scaleM -1);
    z.z-=0.5*scaleC.z*( scaleM -1)/ scaleM ;
    z.z=-abs(-z.z);
    z.z+=0.5*scaleC.z*( scaleM -1)/ scaleM ;
    z.z= scaleM *z.z;
	
	r=z.x*z.x+z.y*z.y+z.z*z.z+z.w*z.w;
	return r;
	}
//return r;
}

Title: Implementing MixPinski
Post by: DarkBeam on November 15, 2016, 06:44:40 PM

Quote from: Crist-JRoger on November 15, 2016, 05:59:38 PM

Code:

#include "DE-Raytracer.frag"

uniform float scaleM; slider[0,.2,.2]
uniform vec4 scaleC; slider[(-5,-5,-5,-5),(1.,1.,.5,.5),(5.,5.,5.,5.)]
uniform vec4 offsetM; slider[(-5,-5,-5,-5),(0.,0.,0.,0.),(5.,5.,5.,5.)]
uniform float w; slider[0,0,5.]
uniform int MI; slider[0,10,250]
//uniform float bailout; slider[0,1024,1024]

float DE(vec3 p)
{
	vec4 z=vec4(p,w);
	float r=0.; //float sk=1.; 
	//float r=(z.x*z.x+z.y*z.y+z.z*z.z);
	//float r=z.x*z.x+z.y*z.y+z.z*z.z+z.w*z.w;
	//for(int i=0; i<MI && r<bailout; i++){	
	for(int i=0; i<MI; i++){	
	if(z.x+z.y<0.0) z.xy = -z.yx;
        if(z.x+z.z<0.0) z.xz = -z.zx;
        if(z.y+z.z<0.0) z.zy = -z.yz;
        if(z.x+z.w<0.0) z.xw = -z.wx;
        if(z.y+z.w<0.0) z.yw = -z.wy;
        if(z.z+z.w<0.0) z.zw = -z.wz;

	z+=offsetM;
        // why no rotate here? :(
        // sk *= scale;
	z.x= scaleM *z.x-scaleC.x*( scaleM -1);
    z.y= scaleM *z.y-scaleC.y*( scaleM -1);
    z.w= scaleM *z.w-scaleC.w*( scaleM -1);
    z.z-=0.5*scaleC.z*( scaleM -1)/ scaleM ;
    z.z=-abs(-z.z);
    z.z+=0.5*scaleC.z*( scaleM -1)/ scaleM ;
    z.z= scaleM *z.z;
	// You are returning on 1st iter! no ;)
	r=z.x*z.x+z.y*z.y+z.z*z.z+z.w*z.w;
	if (r>bailout) break; // bailout do not remove... else you get overflows break exits from a cycle.
	} // cycle ends
return sqrt(r)*pow(scale,-i); // returning a DE... exits from function. You must convert i to float btw
// or uncomment the sk related lines and use
// return sqrt(r)*sk;
}

That should work I think ;)

Title: Implementing MixPinski
Post by: mclarekin on November 15, 2016, 11:42:48 PM

Thanks DarkBeam, It looks good.

Crist, beware that converting DarkBeams formulas can become addictive ;D

Title: Implementing MixPinski
Post by: Crist-JRoger on November 16, 2016, 05:01:32 AM

DarkBeam, did you tried thos code?

fragment errors

Code:

return sqrt(r)*pow(scale,-i);

Frag says
Undeclared identifier: scale
Undeclared identifier: i
what is scale? i declared just inside the cycle.

and what is sk? :-\

mclarekin, I just began :dink:

Title: Implementing MixPinski
Post by: mclarekin on November 16, 2016, 09:15:50 AM

scale change to scaleM

Darkbeam wrote.

Quote

You must convert i to float btw

float Iter = i; // in openCL I found I didnt need to.

return sqrt(r)*pow(ScaleM,-Iter);

and make sure you have removed the // from:
//uniform float bailout; slider[0,1024,1024

Title: Implementing MixPinski
Post by: mclarekin on November 16, 2016, 09:35:20 AM

@ DarkBeam. I have booted up Windows to do some openCL testing on the DE calculations, and there appears to be some difference between the two functions. I think there is more detail in pow(scale,-1). I will have a better look in the future

Code:

DE *= scaleM;
//float Iter = i;
if (r4 > 1024.0f)  // bailout check
{
	r = sqrt(r4);// test both ways i.e. sqrt(r4 - (z4.w * z4.w));sqrt(r4);
	if( swapDE == 1) // pseudo checkBox
	{
		dist = (r - tempD) / fabs(DE);  // reducing the effect of r
	}
	else
	{
		//float Iter = i;
		dist = (r)*pow(scaleM,-i);
	} 
	out.colourIndex = colourMin ;
	break;
}

While in Windows I rendered mixPinski4 in M3D and I am almost certain I am getting a similar but different fractal == mixPinski4_mod1. I think i have less symmetry so I will take another look :)

Title: Re: Implementing MixPinski
Post by: DarkBeam on November 16, 2016, 11:17:18 AM

Whoa can you paste your code fully?
I love less symmetric versions :-*
Btw I splitted the topic as Mix is not a Menger and also I populated the empty section "Sierpinski" so now the IFS section is more readable :police: :beer:

Title: Re: Implementing MixPinski
Post by: mclarekin on November 16, 2016, 11:42:29 AM

@crist I am finding that the default max iterations should be more like 50

@ DarkBeam. I am just finishing of the openCL version at the moment, ( this version is set up for my DE testing).

Title: Re: Implementing MixPinski
Post by: Sabine on November 16, 2016, 11:43:56 AM

Still the int to float cast I am struggling with too!

When I tried to redeclare i as float as it says in the code (mclarekin also gave this tip) I get the same error, but now for this new line (i is not defined) :}
I have no idea how valuables behave in glsl, it's not like good old days with public and private ones:} Does it get lost on the way? Because i is defined in the for-loop as int, we shouldn't get this error? If i was still 'existing' we would get an error about faulty data type or when trying to convert, a conversion error?

Sorry, very new to this!

Title: Re: Implementing MixPinski
Post by: Crist-JRoger on November 16, 2016, 11:45:48 AM

Please return topic to Fragmentarium section

Title: Re: Implementing MixPinski
Post by: mclarekin on November 16, 2016, 01:10:28 PM

here is the current openCL version of MixPinski4D_mod1, which is very similar to ,frag. fabs = abs, float4 = vect4.

There are some stop/start iteration controls included. And a temporary 3D Rotation

My recent exploring indicates that the pow(scale,-i) is actually inferior to r/DE but it might be location & settings specific.

Mandelbulber V1.21OpenCL has one file for Initial Conditions and another for what goes inside of the Iteration Loop.

Code:

// This file has all commands which are executed once before iteration loop.
// It can be used to initialize all variables and do some preliminary calculations
// all available variables are defined in mandelbulber_cl_data.h
// MixPinski4D_mod1
// INITIAL CONDITIONS
// DarkBeam & Knighty maths fractalforums.com
// 16/11/16

// TODO reorientate

// DE testing
int swapDE = consts->fractal.mandelbox.fixedRadius;// strange names because I am using some
float offsetD = consts->fractal.mandelbox.minRadius; // some existing parameters boxed


float scaleM = consts->fractal.mandelbox.scale; // default 2.0

int startO = consts->fractal.custom[0]; //start default 0
int stopO = consts->fractal.custom[1];  // stop default 250
float4 offsetM = (float4){consts->fractal.custom[2], consts->fractal.custom[3], consts->fractal.custom[4], consts->fractal.custom[5] };
 // default 0,0,0,0
int startS = consts->fractal.custom[6];
int stopS = consts->fractal.custom[7];
float4 scaleC = (float4){consts->fractal.custom[8], consts->fractal.custom[9], consts->fractal.custom[10], consts->fractal.custom[11] };
// Defaults (1,1,0.5,0.5);
int startR = consts->fractal.custom[12];
int stopR = consts->fractal.custom[13];

float w = consts->fractal.custom[14];
float4 z4 = (float4)(z.x, z.y, z.z, w); //make the vector4

float temp = 0.0f;

//this variable is used to calculate surface colour
colourMin = 0.0f;

// initial condition for DE
float DE = 1.0f;

Code:

// MixPinski4D_mod1   beta beta beta
// ITERATION LOOP
// DarkBeam & Knighty maths fractalforums.com
// 16/11/16
if( startS <= i && i <  stopS)
{

	if(z4.x+z4.y<0.0) z4.xy = -z4.yx;

	if(z4.x+z4.z<0.0) z4.xz = -z4.zx;

	if(z4.y+z4.z<0.0) z4.zy = -z4.yz;

	if(z4.x+z4.w<0.0) z4.xw = -z4.wx;

	if(z4.y+z4.w<0.0) z4.yw = -z4.wy;

	if(z4.z+z4.w<0.0) z4.zw = -z4.wz;
}
if( startO <= i && i <  stopO)
{

	z4+=offsetM;

}        
if( startR <= i && i <  stopR)
{	
	//tempoary 3D rotation
	float3 z3 = (float3)( z4.x, z4.y, z4.z );
	z3 = Matrix33MulFloat3(consts->fractal.mandelbox.mainRot, z3);
	z4 = (float4)( z3, z4.w);
}

// 4D menger sponge
z4.x = scaleM * z4.x-scaleC.x *( scaleM - 1);

z4.y = scaleM * z4.y-scaleC.y *( scaleM - 1);

z4.w = scaleM * z4.w-scaleC.w *( scaleM - 1);

z4.z -= 0.5*scaleC.z*( scaleM - 1)/ scaleM ;

z4.z = -fabs(-z4.z);// abs in frag    
z4.z += 0.5*scaleC.z*( scaleM - 1)/ scaleM ;

z4.z = scaleM *z4.z;

float r4 = z4.x*z4.x + z4.y*z4.y + z4.z*z4.z + z4.w*z4.w;

if (r4 > colourMin) colourMin = r4;

DE *= scaleM;
if (r4 > 1024.0f)  // bailout check
{
	r = sqrt(r4);// test both ways i.e. sqrt(r4 - (z4.w * z4.w));sqrt(r4);
	if( swapDE == 1) // pseudo checkBox
	{
		dist = (r - offsetD) / fabs(DE); 
	}
	else
	{
		//float Iter = i;
		dist = (r)*pow(scaleM,-i);
	} 
	out.colourIndex = colourMin ;
	break;
}

Title: Re: Implementing MixPinski
Post by: mclarekin on November 16, 2016, 01:49:46 PM

@Sarbine62. Sorry but I do not know enough about that stuff, but hopefully we will have a working .frag soon.

These images have on the left, the pow(scale,-i) DE looking finer detailed. But when I later zoomed in, I was in a location where the r/DE function was excellent and the pow function terrible. So maybe having more than one DE option available to choose from could be a good idea. More research required. :)

Title: Re: Implementing MixPinski
Post by: Sabine on November 16, 2016, 05:02:09 PM

@mclarekin Thanks a lot! I cant for the life of me imagine why this won't work. Maybe Crist-JRoger can solve it...

And DE-options: the more the merrier;)

Title: Re: Implementing MixPinski
Post by: Crist-JRoger on November 16, 2016, 06:03:17 PM

This don't works.

Code:

#include "DE-Raytracer.frag"

uniform float scaleM; slider[0,.2,.2]
uniform vec4 scaleC; slider[(-5,-5,-5,-5),(1.,1.,.5,.5),(5.,5.,5.,5.)]
uniform vec4 offsetM; slider[(-5,-5,-5,-5),(0.,0.,0.,0.),(5.,5.,5.,5.)]
uniform float w; slider[0,0,5.]
uniform int MI; slider[0,10,250]
uniform float bailout; slider[0,1024,1024]

float DE(vec3 p)
{
	vec4 z=vec4(p,w);
	float r=0.;
	//float r=(z.x*z.x+z.y*z.y+z.z*z.z);
	//float r=z.x*z.x+z.y*z.y+z.z*z.z+z.w*z.w;
	for(int i=0; i<MI && r<bailout; i++){	
	//for(int i=0; i<MI; i++){	
	if(z.x+z.y<0.0) z.xy = -z.yx;
    if(z.x+z.z<0.0) z.xz = -z.zx;
    if(z.y+z.z<0.0) z.zy = -z.yz;
    if(z.x+z.w<0.0) z.xw = -z.wx;
    if(z.y+z.w<0.0) z.yw = -z.wy;
    if(z.z+z.w<0.0) z.zw = -z.wz;

	z+=offsetM;

	z.x= scaleM *z.x-scaleC.x*( scaleM -1.);
    z.y= scaleM *z.y-scaleC.y*( scaleM -1.);
    z.w= scaleM *z.w-scaleC.w*( scaleM -1.);
    z.z-=0.5*scaleC.z*( scaleM -1.)/ scaleM ;
    z.z=-abs(-z.z);
    z.z+=0.5*scaleC.z*( scaleM -1.)/ scaleM ;
    z.z= scaleM *z.z;
	
	r=z.x*z.x+z.y*z.y+z.z*z.z+z.w*z.w;
	
	}
//float Iter = i;
//return sqrt(r);
return sqrt(r)*pow(scaleM,-50.);
//return r;
}

Why? Because I'm not a programmer ;D

Title: Re: Implementing MixPinski
Post by: Sabine on November 16, 2016, 06:48:40 PM

YesYes it does work

Code:

#include "DE-Raytracer.frag"

uniform float scaleM; slider[-2,0,2]
uniform vec4 scaleC; slider[(-5,-5,-5,-5),(0,0,0,0),(5.,5.,5.,5.)]
uniform vec4 offsetM; slider[(-5,-5,-5,-5),(0.,0.,0.,0.),(5.,5.,5.,5.)]
uniform float w; slider[0,1,5]
uniform int MI; slider[0,10,250]
uniform float bailout; slider[0,16,1024]

float DE(vec3 p)
{
	vec4 z=vec4(p,w);
	float r=0.;
	//float r=(z.x*z.x+z.y*z.y+z.z*z.z);
	//float r=z.x*z.x+z.y*z.y+z.z*z.z+z.w*z.w;
	for(int i=0; i<MI && r<bailout; i++){	
	//for(int i=0; i<MI; i++){	
	if(z.x+z.y<0.0) z.xy = -z.yx;
    if(z.x+z.z<0.0) z.xz = -z.zx;
    if(z.y+z.z<0.0) z.zy = -z.yz;
    if(z.x+z.w<0.0) z.xw = -z.wx;
    if(z.y+z.w<0.0) z.yw = -z.wy;
    if(z.z+z.w<0.0) z.zw = -z.wz;

	z+=offsetM;

	z.x= scaleM *z.x-scaleC.x*( scaleM -1.);
    z.y= scaleM *z.y-scaleC.y*( scaleM -1.);
    z.w= scaleM *z.w-scaleC.w*( scaleM -1.);
    z.z-=0.5*scaleC.z*( scaleM -1.)/ scaleM ;
    z.z=-abs(-z.z);
    z.z+=0.5*scaleC.z*( scaleM -1.)/ scaleM ;
    z.z= scaleM *z.z;
	
	r=z.x*z.x+z.y*z.y+z.z*z.z+z.w*z.w;
	
	}
//float Iter = i;
//return sqrt(r);
return sqrt(r)*pow(scaleM,-50.);
//return r;
} 



#preset default
FOV = 0.4
Eye = 0,0,-8
Target = -1e-07,0,2
Up = -0.7512803,0.6599832,0
EquiRectangular = false
AutoFocus = false
FocalPlane = 1
Aperture = 0
Gamma = 2
ToneMapping = 4
Exposure = 1
Brightness = 1
Contrast = 1
Saturation = 1
GaussianWeight = 1
AntiAliasScale = 2
DepthToAlpha = false
ShowDepth = false
DepthMagnitude = 1
Detail = -2.3
DetailAO = -0.5
FudgeFactor = 1
MaxDistance = 1000
MaxRaySteps = 56
Dither = 0.5
NormalBackStep = 1
AO = 0,0,0,0.7
Specular = 0.4
SpecularExp = 16
SpecularMax = 10
SpotLight = 1,0.09019608,0.02745098,0.4
SpotLightDir = 0.1,0.1
CamLight = 1,0.04313725,0.01176471,1
CamLightMin = 0
Glow = 1,1,1,0
GlowMax = 20
Fog = 0
HardShadow = 0
ShadowSoft = 2
QualityShadows = false
Reflection = 0
DebugSun = false
BaseColor = 1,1,1
OrbitStrength = 0
X = 0.5,0.6,0.6,0.7
Y = 1,0.6,0,0.4
Z = 0.8,0.78,1,0.5
R = 0.4,0.7,1,0.12
BackgroundColor = 0.6,0.6,0.45
GradientBackground = 0.3
CycleColors = false
Cycles = 1.1
EnableFloor = false
FloorNormal = 0,0,1
FloorHeight = 0
FloorColor = 1,1,1
scaleC = -0.2559727,1,0.5,0.5
offsetM = 0,0,0,0
w = 0
MI = 10
bailout = 1024
scaleM = 1.066059
#endpreset

And then you get this rofl2
Sorry, just had to post, it was the first thing that appeared on my screen after I got an image and 'slid a slider'!

(PS I can't get it to work 'really' either, no programmer ;D)

Title: Re: Implementing MixPinski
Post by: Crist-JRoger on November 16, 2016, 06:56:36 PM

Just what is needed!
And the code is simple :laugh:

upd.:
Okay, think ir's really work. Remove z.w*z.w from r=z.x*z.x+z.y*z.y+z.z*z.z; and replace
return to

Code:

float Iter = MI;
return sqrt(r)*pow(scaleM,-Iter);

Preset

Code:

FOV = 0.4
Eye = -31.7535,62.7664,-16.2701
Target = -27.2308,54.1588,-13.9345
Up = 0.357063,-0.0647625,-0.93009
EquiRectangular = false
FocalPlane = 1
Aperture = 0
Gamma = 2
ToneMapping = 4
Exposure = 1
Brightness = 1
Contrast = 1
Saturation = 1
GaussianWeight = 1
AntiAliasScale = 2
DepthToAlpha = false
ShowDepth = false
DepthMagnitude = 1
Detail = -3
DetailAO = -0.5
FudgeFactor = 0.3
MaxDistance = 1000
MaxRaySteps = 739
Dither = 0.5
NormalBackStep = 1
AO = 0,0,0,0.7
Specular = 0.4
SpecularExp = 16
SpecularMax = 10
SpotLight = 1,0.631373,0.482353,1
SpotLightDir = -0.36842,0.1
CamLight = 0.709804,0.866667,1,0.65626
CamLightMin = 0.30769
Glow = 1,1,1,0
GlowMax = 20
Fog = 0
HardShadow = 1 NotLocked
ShadowSoft = 20
QualityShadows = false
Reflection = 0
DebugSun = false
BaseColor = 1,1,1
OrbitStrength = 0
X = 0.5,0.6,0.6,0.7
Y = 1,0.6,0,0.4
Z = 0.8,0.78,1,0.5
R = 0.4,0.7,1,0.12
BackgroundColor = 0.6,0.6,0.45
GradientBackground = 0.3
CycleColors = false
Cycles = 1.1
EnableFloor = false
FloorNormal = 0,0,1
FloorHeight = 0
FloorColor = 1,1,1
scaleC = -2.5728,-5,-5,-4.2233
offsetM = -0.8763,-1.1856,2.6289,3.7629
w = 0
MI = 59
bailout = 24371.2
scaleM = 1.04684

So, what shape should get? 88)

Title: Re: Implementing MixPinski
Post by: Sabine on November 16, 2016, 07:28:32 PM

I got this (best shot with same code)
Will try yours asap!

Title: Re: Implementing MixPinski
Post by: mclarekin on November 16, 2016, 08:14:09 PM

@ crist Did you change default MI. I guessed at 10 for default but now that I have tested it 50 was better. I think in most cases bailout terminates the loop, so in Mandebulber the general default for all fractals is 250.l

My latest posted images is what I get at default setting. (But Mandelbulber V1.21 has the z axis upside down, so you need to mentally flip it vertically)

I was using a DE step (fudge factor) of 0.5.

Title: Re: Implementing MixPinski
Post by: Crist-JRoger on November 16, 2016, 08:21:58 PM

mclarekin, run Fragmentarium and test )
Me and Sabine posted preset settings. Fragment not optimized (FudgeDactor<0.3 ... 0.2) maybe not adapted for DE-raytracer, maybe need different math. Somebody who programmed for Frag can answer.

Title: Re: Implementing MixPinski
Post by: Sabine on November 16, 2016, 08:32:15 PM

Great job, Crist-JRoger! :beer: Great solution of using MI and nice shapes possible! :beer:

@mclarekin As it looks now, I think maxiter at around 60-80 gives nice solid shapes with detail detail. Go higher 160+ and the whole thing dissolves :}
Here a preset to load into frag (see image below)

Code:

#preset 5
FOV = 0.3854626
Eye = -50,9.111111,-50
Target = -7.336343,1.918736,-1.467269
Up = 0.3304061,0.0735456,-0.3194292
EquiRectangular = false
AutoFocus = false
FocalPlane = 9.184845
Aperture = 0
Gamma = 1.501706
ToneMapping = 5
Exposure = 1
Brightness = 1
Contrast = 1
Saturation = 1
GaussianWeight = 1
AntiAliasScale = 2
DepthToAlpha = false
ShowDepth = false
DepthMagnitude = 0
Detail = -3
DetailAO = -0.5
FudgeFactor = 0.3
MaxDistance = 1000
MaxRaySteps = 739
Dither = 0.5
NormalBackStep = 1 NotLocked
AO = 0,0,0,0.1557093
Specular = 0.2233677
SpecularExp = 8.185054
SpecularMax = 10
SpotLight = 1,1,1,0.083632
SpotLightDir = 0.2816901,0.5
CamLight = 1,1,1,0.6372315
CamLightMin = 0.12121
Glow = 1,1,1,0.2305006
GlowMax = 41
Fog = 0
HardShadow = 0.5474795 NotLocked
ShadowSoft = 0.2588235
QualityShadows = true
Reflection = 0 NotLocked
DebugSun = false NotLocked
BaseColor = 0.3098039,0.3098039,0.3098039
OrbitStrength = 0.14286
X = 0.427451,0.09411765,1,1
Y = 0.345098,0.666667,0,0.02912
Z = 1,0.666667,0,1
R = 0.0784314,1,0.941176,-0.0194
BackgroundColor = 0.8196078,0.8666667,0.8117647
GradientBackground = 1.401925
CycleColors = false
Cycles = 4.04901
EnableFloor = false NotLocked
FloorNormal = 0,0,1
FloorHeight = 0
FloorColor = 1,1,1
scaleM = 1.029613
scaleC = -2.5728,3.737201,4.055745,1.211604
offsetM = -0.4753723,-1.357388,-1.013746,3.7629
w = 3.007726
MI = 73
bailout = 1024
#endpreset

As it is now, moving up to close dissolves the shape too...
And I think Crist-JRoger has a point about the DE, as I can only get good solids at DE<0,3

Title: Re: Implementing MixPinski
Post by: mclarekin on November 16, 2016, 08:43:18 PM

@ sabine62 Your image looks interesting,

@ crist & sabine62, if you like ,could you post your latest versions of the code & I will add both DE methods to them. It would be good to have us all evaluating them rather than just my opinions :)

I have yet to learn how to use fragmentarium so I can not test your .frags. But I think we are getting close to getting it working.

another thought .......#include "DE-Raytracer.frag" I am not sure about the various options , it should be the one used for menger sponge and/or mandelbox.

Title: Re: Implementing MixPinski
Post by: Sabine on November 16, 2016, 08:52:39 PM

The mandelbox uses DE-Raytracer, just checked.

If you unpack the zip, open fragmentarium and choose the 6.frag ;D

But if you prefer to stay away from Fragmentarium

Code:

// 
#include "DE-Raytracer.frag"

uniform float scaleM; slider[-2,0,2]
uniform vec4 scaleC; slider[(-5,-5,-5,-5),(0,0,0,0),(5,5,5,5)]
uniform vec4 offsetM; slider[(-5,-5,-5,-5),(0,0,0,0),(5,5,5,5)]
uniform float w; slider[0,1,5]
uniform int MI; slider[0,10,250]
uniform float bailout; slider[0,16,1024]

float DE(vec3 p)
{
	vec4 z=vec4(p,w);
	float r=0.;
	//float r=(z.x*z.x+z.y*z.y+z.z*z.z);
	//float r=z.x*z.x+z.y*z.y+z.z*z.z+z.w*z.w;
	for(int i=0; i<MI && r<bailout; i++){	
	//for(int i=0; i<MI; i++){	
	if(z.x+z.y<0.0) z.xy = -z.yx;
    if(z.x+z.z<0.0) z.xz = -z.zx;
    if(z.y+z.z<0.0) z.zy = -z.yz;
    if(z.x+z.w<0.0) z.xw = -z.wx;
    if(z.y+z.w<0.0) z.yw = -z.wy;
    if(z.z+z.w<0.0) z.zw = -z.wz;

	z+=offsetM;

	z.x= scaleM *z.x-scaleC.x*( scaleM -1.);
    z.y= scaleM *z.y-scaleC.y*( scaleM -1.);
    z.w= scaleM *z.w-scaleC.w*( scaleM -1.);
    z.z-=0.5*scaleC.z*( scaleM -1.)/ scaleM ;
    z.z=-abs(-z.z);
    z.z+=0.5*scaleC.z*( scaleM -1.)/ scaleM ;
    z.z= scaleM *z.z;
	
	r=z.x*z.x+z.y*z.y+z.z*z.z;
	
	}
//return sqrt(r);
float Iter = MI;
return sqrt(r)*pow(scaleM,-Iter);
//return r;
}

Title: Re: Implementing MixPinski
Post by: Crist-JRoger on November 16, 2016, 09:11:46 PM

Quote from: mclarekin on November 16, 2016, 08:43:18 PM

I have yet to learn how to use fragmentarium so I can not test your .frags. But I think we are getting close to getting it working.

another thought .......#include "DE-Raytracer.frag" I am not sure about the various options , it should be the one used for menger sponge and/or mandelbox.

Do not be afraid, he does not bite :D
Open Fragmentarium -> Ctlr+N and paste my code to editor, press F5.
What could be easier? 88)

DarkBeam, again, please return this topic to Frag section... :now:

Title: Re: Implementing MixPinski
Post by: mclarekin on November 16, 2016, 09:16:20 PM

@sabine62 You are missing the bailout termination code so it is running only on maxiter termination

Refer darkbeams post

Quote

z= scaleM *z.z;

   r=z.x*z.x+z.y*z.y+z.z*z.z+z.w*z.w;
   if (r>bailout) break; // bailout do not remove... else you get overflows break exits from a cycle.
   } // cycle ends
return sqrt(r)*pow(scale,-i); // returning a DE... exits from function. You must convert i to float btw
// or uncomment the sk related lines and use
// return sqrt(r)*sk;
}

float Iter = MI; This has to be Iter = i

   z.z= scaleM *z.z;
   DE *= scaleM; ................ add this in
   r=z.x*z.x+z.y*z.y+z.z*z.z;

   }
return sqrt(r)/ DE; // .............................alternative DE return function
}

I will be back later and have a proper look

Next time I am in Windows OS I will download Fragmentarium

Title: Re: Implementing MixPinski
Post by: mclarekin on November 17, 2016, 04:51:34 AM

Attached is my latest attempt at writing the frag, using Sabine62's code.

I note I was using a step multiplier of 0.1 in MBulberV2 c++ (for this fractal. I seldom go below that for fractals, but I have noticed that 0.1 is essential for some difficult fractals)

Reviewing Sabine62 code, based on how my openCL code is behaving.
I have studied a lot of fractal code here at the forum, that is the extent of my programming knowledge. I would have to follow a tutorial to make "hello world".
So I am limited to how much I can help.

Sabine62s Initial Conditions:

uniform float scaleM; slider[-2,0,2]
uniform vec4 scaleC; slider[(-5,-5,-5,-5),(0,0,0,0),(5,5,5,5)]
uniform vec4 offsetM; slider[(-5,-5,-5,-5),(0,0,0,0),(5,5,5,5)]
uniform float w; slider[0,1,5]
uniform int MI; slider[0,10,250]
uniform float bailout; slider[0,16,1024]

ScaleM not sure if negative scale is usable. BTW if using a negative scale, then return sqrt(r)/ abs(DE) is required, I think.
ScaleM default should be 2.0, so I would try (0.0, 2.0, 4.0)

vect4 -5 & 5 are guesses, for offsetM I was working with 0.1 and 0.2 size parameters when I tested it yesterday.

float w I have at default 0.0 , (-5, 0, 5) would be my initial guess forann initial range.
in this case w enter the loop as 0.0, then it gets given a non-zero value as it runs though the iterations. So to get the "default" image this must be set at 0.0.

MI both in c++ and openCL is set a default of 250 with no problems. This suggests that the fractal function is not terminating on Maxiter (this is normal for most std fractals). ( my guess at 50 was because I saw I had suggested 10 in my earlier frag post (standard menger sponges usually terminate in less than 10 iterations) and I thought i I better increase it just in case). In fact I just had a look in MandelbulberV2 c++, and the first image I posted had an average of 4.8 and maximum of 8 iterations.

Bailout. I am running with 1024 in OpenCL (i hard code this value into openCL versions, but a slider would be nice, but MandelbulberV1.21 has only 15 empty parameter input boxes so I have to choose my parameters wisely.) BUT in MbulberV2 c++ i have a bailout set at only 10 and it is working OK. NOTE I still need to test out this formula for normal working ranges for the parameters.

I cannot quite remember but there might be a third criteria for stopping termination based on z' - z < small number. So stops when when iterating is not significantly changing the value of z.

The first few pages of this try to explain how bailout, maxiter and DE work in Mandelbulber:

http://cdn.mandelbulber.org/doc/Mandelbulber_Manual_v091.pdf (translated from some form of archaic Polish language)

Added float Dd, for the DE inside the loop as I have set this up with the common type of linear DE calc
Added in a float offsetD for manipulating the DE calc. return (r - offsetD)/ abs(DE). Normally this should be set at 0.0 and increased to improve DE and will lose detail. If the DE is already good then apply ing a small negative number can give more details it seems??).
The final part of the loop I have changed to
................
z.z= scaleM *z.z;
   Dd *= scaleM; // for DE calc
   r2=z.x*z.x+z.y*z.y+z.z*z.z + z.w * z.w; // bailout criteia, and I added in the z.w part to see if it necessary
   }

float r = sqrt(r2);

return (r - offsetD) / fabs(Dd); // offsetD has a default of 0.0 which is the std case. The offsetD results are similar or maybe the same as adjusting Detail Level( Quality)
// float Iter = i; // this DE works also in openCL so it might be something to with "i" in Fragmentarium
//return sqrt(r)*pow(scaleM,-Iter);

?? ooops I need to remove this from my frag
} urn sqrt(r)*pow(scaleM,-Iter);
//return r;
}

Title: Re: Implementing MixPinski
Post by: Crist-JRoger on November 17, 2016, 05:53:36 AM

Sabine, mclarekin try Subblue-Raytracer.frag. It looks much more better! :joy:
#include "Subblue-Raytracer.frag"

Title: Re: Implementing MixPinski
Post by: mclarekin on November 17, 2016, 10:06:02 AM

well down team. ;D It is cool that we have managed to almost properly convert the MixPinski4.

Now I would add in separate start/stop iteration controls for the sierpinksi, offset, rotation and, possibly, menger4D transforms and explore different start/stop settings mixed with the other parameters. (as I have implemented in openCL)
A 3D rotation works good for now and is an integral part of the total formula, it maybe a while before i get back to finishing that

My latest guess about the missing symmetry is that it may be an orientation thingy between the Sierpinski and Menger. The sierpinski might have axis at 45 degrees to the menger sponge hmmm. Otherwise I have created some typos.

Sequence Sierp, rot(45,45,45), menger for the first iteration, then alternating sierp & meneger until termination, may produce a symmetrical fractal

Title: Re: Implementing MixPinski
Post by: Crist-JRoger on November 17, 2016, 10:46:16 AM

mclarekin, can you play with last .frag in Fragmentarium? To see what we got and maybe change something...
At least - set variable parameters to state when MixPinski looks as default shape

Title: Re: Implementing MixPinski
Post by: mclarekin on November 17, 2016, 12:42:44 PM

This is mandelbulberV2 dev version, looking straight down the y axis. scale default 2, offsets 0, menger scaleC 1, 1, 0.5, 0.5.
The image DE quality looks better then the statistics data displays. Rotate camera -45 degrees around z axis and the camera is looking at the main symmetry, i think.

About test.frag

float Dd = 1.0 must be outside the loop. It needs to come into the loop as value 1.0, then be modified each iteration until termination conditions are met. This is how the DE is updated with every iteration

Did you need to move it to get Subblues Raytracer to work?

Title: Re: Implementing MixPinski
Post by: Sabine on November 17, 2016, 01:59:26 PM

Sorry, am lagging behind a bit...

@Crist-JRoger: Can't use Subblue's raytracer as it gives me strange errors, won't work :'(
Update Had to define bool DepthFlag-uniform in raytracer, and all is well, great raytacer!!! :yes: Thanks for the tip!

@mclarekin: First of all, and I am really late with this: Thank you for taking all this trouble to code the Mixpinski! :beer: :beer: :beer: Without people like you who know what they are doing in fractal-land I'd be missing all the fun!

All those slider limits: They are arbitrary, I just used them this way to see how they work for this formula. There are fractals that can give nice results with negative scale (amazingboxes f.i.), and Menger really needs the scale=3 to get the perfect mengershape (at least, in mandelbulb3D). They can always be set to the best working ranges later when we know where fine steps are needed and where big ones ;)
I got your own .frag to work also (Crist-JRoger doing the same work ;D) The missing bailout-break (Luca's) you mentioned: I don't really need to add it since it's in the condition of the loop already?

Had a look at Luca's .m3f and set the values in the .frag according, looks pretty standard to me?

Title: Re: Implementing MixPinski
Post by: Crist-JRoger on November 17, 2016, 03:24:09 PM

Sabine, orbittrap coloring works too

Code:

uniform int ColorIterations; slider[0,10,250]

Code:

if (i<ColorIterations) orbitTrap = min(orbitTrap, abs(vec4(z.x,z.y,z.z,z.w)));

So there is intel mobile gpu with subblue-raytracer render (goodbye subframes!!! ;D ) 7200x4050 88)

(http://img07.deviantart.net/fca7/i/2016/322/e/4/sub_pinski3_by_crist_jroger-daot2zn.jpg) (http://orig02.deviantart.net/a992/f/2016/322/e/4/sub_pinski3_by_crist_jroger-daot2zn.jpg)

Title: Re: Implementing MixPinski
Post by: DarkBeam on November 17, 2016, 04:10:38 PM

Awesome works :D congrats to everyone :beer:
mp goes well with the reciprocals so try some :)

Title: Re: Implementing MixPinski
Post by: Sabine on November 17, 2016, 07:53:20 PM

@Crist-JRoger ColorIterations up and running;) Thanks for that! Does not work wel in subblue-RT, but like a charm in DE_raytracer and DE-Kn2cr11!
And what do you mean by intel mobile gpu? :} What am I missing?! :}
Beautiful image of a beautiful formula! :yes:

@mclarekin Seems I was a bit off when coming to dimensions, zeroG-sh ;) The frag and image that I posted that look like the standard: it's upside down. Also I have checked and a maxiter of 16 is really better than 13, clearer forms and stable from there on. See attachment for the new and improved version;) Also I am not so sure about OffsetD (and that's very probably because I do not know what it is supposed to do!) : at low values its influence is negligible, at high values it leads to fuzz/discontinuities when walking in/out?

@dark-beam Don't you agree that mclarekin should have his own folder in the Examples by now, Luca? :yes:
Ohh and one question: Have not yet had time to really look at the reciprocals, but now I am braindead with flu the moment has come:} In the .m3f you write:
x' = sign(x)(1/Lim1 + 1/lim2 - 1/(abs(m1 * x)+ Lim ) - 1/(m2 * x*x+ Lim2 ) )
The third Lim... it should have been a Lim1?

(http://orig07.deviantart.net/f1d1/f/2016/322/f/9/12_by_sabine62-daotqn0.png)

Title: Re: Implementing MixPinski
Post by: Crist-JRoger on November 17, 2016, 08:13:30 PM

Cool render!!! Bravo :o

So here 1st rotated version. I delete bailout, think it's no needs here. Pre-post rotations with start iteration position for more random ;D
Added some presets quickly.

intel mobile gpu - that's my only Frag-platform on my job :D Enough for tests and simple renders.

Title: Re: Implementing MixPinski
Post by: DarkBeam on November 17, 2016, 08:33:12 PM

Sabine I don't fail to write a one line formula ;D
It is another parameter. It has different effects :dink: try!

Title: Re: Implementing MixPinski
Post by: Sabine on November 17, 2016, 09:02:55 PM

@Crist-JRoger: already thought you'd found the free-to-use renderfarm for us all;)
Will check on your rotations after I have solved the reciprocal mystery;) (OR when I know I have failed miserably ;} )

@Dark-beam: Nono, we have only two limiters (and two muls)!
But in your formula you use 3 limiters?? Lim1, Lim2 and Lim? ;D

First results has the right forms, vaguely... very very vaguely :laugh:

Title: Re: Implementing MixPinski
Post by: Crist-JRoger on November 17, 2016, 09:08:49 PM

renderfarm yeah ))
De-Kn based with M Benesi palette: :dink:

(http://orig13.deviantart.net/57d8/f/2016/322/e/4/2016_11_17_230238_by_crist_jroger-daotyx8.jpg)

Title: Re: Implementing MixPinski
Post by: Sabine on November 17, 2016, 11:38:16 PM

@Crist-JRoger: Have looked at your rotations: Very nice!! I Must try and understand how they work though, especially the RotStart, which is iteration-dependent??

Something else, and I am not at all sure about it: This is a 4D-fractal, but you have only rotations for xyz, not w?
Do we Need the w-rotation?

(also a question for

@Dark-beam and
@mclarekin

)

And I think we cannot solve it like this?

Code:

uniform int PreRotStart; slider[0,1,15] 
uniform vec4 PreRotVector; slider[(0,0,0,0),(1,1,1,1),(1,1,1,1)]
uniform float PreRotAngle; slider[0.00,0,180]
uniform int RotStart; slider[0,1,15] 
uniform vec4 RotVector; slider[(0,0,0,0),(1,1,1,1),(1,1,1,1)]
uniform float RotAngle; slider[0.00,0,180]
mat3 fracRotation1;
mat3 fracRotation2;
void init() {
	fracRotation1 = rotationMatrix3(normalize(PreRotVector), PreRotAngle);
	fracRotation2 = rotationMatrix3(normalize(RotVector), RotAngle);
}

The fourth slider Does rotate err.. something... ;D And nothing like the other three sliders rotate. Sorry, I Really am new to this:}
But if we do it like the mb3d-formula we need the whole thing: yz, xz, xy, xw, yw, zw

Ohh and forgot @Crist-JRogers: Great render! :beer:

Title: Re: Implementing MixPinski
Post by: DarkBeam on November 18, 2016, 12:42:09 AM

x' = sign(x)(1/Lim1 + 1/lim2 - 1/(abs(m1 * x)+ Lim ) - 1/(m2 * x*x+ Lim2 ) )

Yeah that lim should be Lim1 :'( but I no longer remember really

Title: Re: Implementing MixPinski
Post by: mclarekin on November 18, 2016, 12:49:10 AM

We all can make same default now, O0 O0

and your images are looking good. The MinPinski4 is a bit more tricky to convert than most M3D formulas. Converting the M3D _transforms rather than the formulas is easier because in most cases we do not have to think about DE.
(
orientation of default may depend on how the main program is set up. Like Mandelbulber V1.21OpenCL version produces the image upside down compared to MandelbulberV2 T(he direction of the z axis was reversed)

rotation will be 4D when I get back to finishing off coding the 4D rotation. 3D is temporary. There could be a .frag somewhere with 4D rotation already coded ?? This is where I was before I got sidetracked.

Code:

		// 4D r0t
				/*
				 * mat4 rotationXY  ( float angle )
				{
					mat4 rot;
					rot[0] = CVector4(cos(angle), sin(angle), 0.0, 0.0);
					rot[1] = CVector4(-sin(angle), cos(angle), 0.0, 0.0);
					rot[2] = CVector4(0.0, 0.0, 1.0, 0.0);
					rot[3] = CVector4(0.0, 0.0, 0.0, 1.0);
					return rot;
				}

				mat4 rotationYZ  ( float angle )
				{
					mat4 rot;
					rot[0] = CVector4(1.0, 0.0, 0.0, 0.0);
					rot[1] = CVector4(0.0, cos(angle), sin(angle), 0.0);
					rot[2] = CVector4(0.0, -sin(angle), cos(angle), 0.0);
					rot[3] = CVector4(0.0, 0.0, 0.0, 1.0);
					return rot;
				}

				mat4 rotationXZ  ( float angle )
				{
					mat4 rot;
					rot[0] = CVector4(cos(angle), 0.0, -sin(angle), 0.0);
					rot[1] = CVector4(0.0, 1.0, 0.0, 0.0);
					rot[2] = CVector4(sin(angle), 0.0, cos(angle), 0.0);
					rot[3] = CVector4(0.0, 0.0, 0.0, 1.0);
					return rot;
				}


				mat4 rotationXW  ( float angle )
				{
					mat4 rot;
					rot[0] = CVector4(cos(angle), 0.0, 0.0, sin(angle));
					rot[1] = CVector4(0.0, 1.0, 0.0, 0.0);
					rot[2] = CVector4(0.0, 0.0, 1.0, 0.0);
					rot[3] = CVector4(-sin(angle), 0.0, 0.0, cos(angle));
					return rot;
				}

				mat4 rotationYW  ( float angle )
				{
					mat4 rot;
					rot[0] = CVector4(1.0, 0.0, 0.0, 0.0);
					rot[1] = CVector4(0.0, cos(angle), 0.0, -sin(angle));
					rot[2] = CVector4(0.0, 0.0, 1.0, 0.0);
					rot[3] = CVector4(0.0, sin(angle), 0.0, cos(angle));
					return rot;
				}

				mat4 rotationZW  ( float angle )
				{
					mat4 rot;
					rot[0] = CVector4(1.0, 0.0, 0.0, 0.0);
					rot[1] = CVector4(0.0, 1.0, 0.0, 0.0);
					rot[2] = CVector4(0.0, 0.0, cos(angle), -sin(angle));
					rot[3] = CVector4(0.0, 0.0, sin(angle), cos(angle));
					return rot;
				}

				mat4 scale  ( CVector4scale4 )
				{
					mat4 rot;
					rot[0] = CVector4(scale4.x, 0.0, 0.0, 0.0);
					rot[1] = CVector4(0.0, scale4.y, 0.0, 0.0);
					rot[2] = CVector4(0.0, 0.0, scale4.z, 0.0);
					rot[3] = CVector4(0.0, 0.0, 0.0, scale4.w);
					return rot;
				}*/

offsetD is just an experimental thing for me to investigate. Distance Esimate is an "estimate", and we can tweak the estimate to try and get it closer to the real distance. You can be removed from the .frag

This is reciprocal3 for the x axis (I have yet to get my sign(z.x) function working so this is longer than it needs to be)

Code:

float3 tempZ  = z;
if (RecX_enabled)
		tempZ.x = (1.0 / Limit.x) - 1.0 / (abs(z.x) + Limit.x); // 

		tempZ.x += abs(z.x) * Slope.x; // function slope default 0.0

		if (z.x > 0.0)
		{
			z.x = tempZ.x;
		}
		else
		{
			z.x = -tempZ.x;
		}

Title: Re: Implementing MixPinski
Post by: DarkBeam on November 18, 2016, 12:56:11 AM

For mclarekin:
If you use the standard quaternion maths, a 4d rotation should simply be a quaternonic mult by a 4d number of norm 1. Else it is a scaling plus rotating. To set norm=1 you multiply the vector by 1/sqrt(x2+y2+z2+w2) but if magnitude is 0... do nothing ;)
Too bad this is far less user friendly than the pretty angles notation ...
Plus I made many formulas that offset rotations! Very interesting results if you do this;

P = p + offset;
P = p * rotmatrix;
P = p - offset;

You will get fractals of a *new* type because this is a particular combination of things :D be careful if offset is too big the rotation can sometimes kill the fractal :(
This idea is reported in the original kifs thread in this Sierpinski forum section :alien:

Title: Re: Implementing MixPinski
Post by: mclarekin on November 18, 2016, 02:23:54 AM

Random thoughts on Fragmentarium and M3D code.

You could have a section in Fragmentarium called "M3D formulas" or better a specific one for "DrakBeam's codes", (and Knighty, Msltoe, Benesi etc). MixPinski could be the first post in the Darkbeam part. Choose some more you want to convert, and together we can do it.

It is a good feeling when you get them working ;D. Plus you learn and then start to experiment.

For example, by default I always initially install start / stop iteration controls for the individual transforms within the formula ( and then later decide what to keep). With some transforms you will learn that they can be stopped earlier than others in a formula, and hence you can save some render maths time. And every late start and/or early stop setup can produce a variation of the default fractal, they are each a separate conditional mode. But as usual the more you add and tweak the greater the chance that the DE calc will become less accurate.(but not always it can get better).

I like the .frag setup as a standard format for a formula/transform "bank" for people to view the maths.

Title: Re: Implementing MixPinski
Post by: mclarekin on November 18, 2016, 03:54:10 AM

@ DarkBeam. Thanks for maths advice.

@ Crist & sarbine
The following is a good example of how a lot of fractals work. Convert(map) p, do some maths, then map p back,. Then repeat for each iteration until termination.

P = p + offset;
P = p * rotmatrix;
P = p - offset;

Rotate folding= rotate P, do some maths, rotate back

Benesi Mag Transforms= magFold forward, do some maths, magFold back

Mbulb= Convert to polar , do some maths, covert back to Cartesian.

Title: Re: Implementing MixPinski
Post by: 3dickulus on November 18, 2016, 04:20:29 AM

Quote from: mclarekin on November 18, 2016, 02:23:54 AM

The current list of top level Examples folders...

2D Systems
Benesi
DarkBeam
eiffieGI2
Experimental
Historical 3D Fractals
Kaleidoscopic IFS
Kali's Creations
Knighty Collection
Theory
Tutorials

... contains 209 frag files
I think an online repository would be great :D

Title: Re: Implementing MixPinski
Post by: mclarekin on November 18, 2016, 04:30:32 AM

@ 3dickulus. It is already partly set-up., good O0 (i should have looked)

Probably the only main one missing is Msltoe, then we also have Makin, Aexion, Trafassel etc.

If there are no msltoe Juliabulbs then we need to code one quickly ;D

Title: Re: Implementing MixPinski
Post by: 3dickulus on November 18, 2016, 04:41:47 AM

...my personal collection, 838, contains msltoe.frag dated Jan 28 2016 Msltoes Julia Bulb Distance Estimator ?

I recall asking a few members if I could/should include their frags in the distribution but it was a mixed yes/no result at the time so I left it as is,
there is currently an Examples.zip on my website that is just the Examples folder, it would be easy to create a repo on github or sourceforge :D

Title: Re: Implementing MixPinski
Post by: mclarekin on November 18, 2016, 05:15:15 AM

I guess realistically, this will take a lot of time, what I personally would like is an easy to find location for recently converted fractal codes. So whenever we go though the process of converting ,there is a central place for this work in one format. Trawling the achieves is interesting ( for me) , but it takes a lot of time figuring things out, and you can miss important offshoot posts.

I am often guilty of posting code in random obscure places, very hard to find again. Lazy habits are hard to break. :)

Title: Re: Implementing MixPinski
Post by: Sabine on November 18, 2016, 09:36:45 AM

Just a shout in between:

Quote

Random thoughts on Fragmentarium and M3D code.

From a newbie point of view: A online repository would be wonderful!
And also: there are many little routines that are already written, there are certain standard ways f.i. to get the colorpalette.frag working, that are easy if you only know how and where to put them into the frag. Maybe in the repository we could also have a place for subroutines and their how-to-'s? Then, if we need a 4D-rotation and it's already been done we can look there instead of going through hundreds of frags on our HD?;)

@mclarekin Will have a closer look at this p-thing, thank you very much for the tip, might get back to you for a bit more info... (like what is p? :embarrass:) But I might find out on my own with some luck;)
@DarkBeam Thank you! And no wonder you forgot, you have coded so many! :)

Title: Re: Implementing MixPinski
Post by: mclarekin on November 18, 2016, 10:10:05 AM

@sabi, This is my view. vect3 p is pixel,position, or point or something like that. Maybe short for pixel positioning point. When I come across it in formula code I generally change it to z, which i have to do for MandelbulberV2 code. But p is perfect, it goes well with notation p.xyz whereas z.xyz looks confusing.

In reading posts and code you can get confused between z the vector, and z the axis. p is by far preferable.

attached image is using the sierpinski part, once at iteration #3 in a hybrid

Title: Re: Implementing MixPinski
Post by: Crist-JRoger on November 18, 2016, 04:32:00 PM

We are have similar thoughts :) Last week I began collect all my frags since 0.9.12 for sharing

upd.: 1st complete render :embarrass:

Labyrinth

(http://pre06.deviantart.net/deea/th/pre/f/2016/323/a/4/labyrinth_by_crist_jroger-daowvko.jpg) (http://orig11.deviantart.net/b01a/f/2016/323/a/4/labyrinth_by_crist_jroger-daowvko.jpg)

Title: Re: Implementing MixPinski
Post by: Crist-JRoger on November 18, 2016, 06:51:16 PM

Quote from: mclarekin on November 18, 2016, 12:49:10 AM

...
rotation will be 4D when I get back to finishing off coding the 4D rotation. 3D is temporary. There could be a .frag somewhere with 4D rotation already coded ?? This is where I was before I got sidetracked.
...

4D in frag? I think no. Not seen
Can you extend this frag 3D rotation to 4D? (see \Examples\Include\MathUtils.frag)

Code:

// Return rotation matrix for rotating around vector v by angle
mat4  rotationMatrix(vec3 v, float angle)
{
	float c = cos(radians(angle));
	float s = sin(radians(angle));
	
	return mat4(c + (1.0 - c) * v.x * v.x, (1.0 - c) * v.x * v.y - s * v.z, (1.0 - c) * v.x * v.z + s * v.y, 0.0,
		(1.0 - c) * v.x * v.y + s * v.z, c + (1.0 - c) * v.y * v.y, (1.0 - c) * v.y * v.z - s * v.x, 0.0,
		(1.0 - c) * v.x * v.z - s * v.y, (1.0 - c) * v.y * v.z + s * v.x, c + (1.0 - c) * v.z * v.z, 0.0,
		0.0, 0.0, 0.0, 1.0);
}

Title: Re: Implementing MixPinski
Post by: Crist-JRoger on November 18, 2016, 07:48:28 PM

Quote from: DarkBeam on November 18, 2016, 12:56:11 AM

...
P = p + offset;
P = p * rotmatrix;
P = p - offset;

Thank you! Added this but conversely :-\ :hmh:

Code:

for(int i=0; i<MI; i++){
	if(PreOffset) z-=offsetM;
	if(i>=PreRotStart) z.xyz*=fracRotation1;
	
	if(z.x+z.y<0.0) z.xy = -z.yx;
    	if(z.x+z.z<0.0) z.xz = -z.zx;
    	if(z.y+z.z<0.0) z.zy = -z.yz;
   	if(z.x+z.w<0.0) z.xw = -z.wx;
    	if(z.y+z.w<0.0) z.yw = -z.wy;
    	if(z.z+z.w<0.0) z.zw = -z.wz;

	z+=offsetM;
...

And really works and sometimes result looks differently
Maybe it's mathematically incorrect?

Title: Re: Implementing MixPinski
Post by: Sabine on November 18, 2016, 08:23:33 PM

@mclarekin Ohh yes, pixel... I am really Really embarrassed now because I have read so many times that p=pixel... :embarrass: And the formulas always are z=... But there you see the difference for me about reading something and Doing something. With me the theory seldom ever really sinks in until I have tried it myself. The same with distance estimation: I have read Syntopias writings many times, but it never really stuck and all stayed very much theoretical. Now I am busy with the formulas it all starts making much more sense, and the DE-bit in the Mandelbulber-Manual you recommended is excellent as a starter, much less intimidating than anything else I have read on the topic.
Also agree about calling it p makes more sense than calling it z (z is for maths people, p is for coords people;) )

BTW Had another go at your alternative DE version, now working finally!!!! As usual programming language was very unforgiving, it wanted a properly defined variable :}

Olde code:

Code:

float DE(vec3 p)
{
	vec4 z=vec4(p,w);
	float r2=0.;  //  r2 is a better term as we are using radius squared for bailout (dot(z,z) )
	float Dd = 1.0;

	for(int i=0; i<MI && r2<bailout; i++){

New code:

Code:

float DE(vec3 p)
{
	vec4 z=vec4(p,w);
	float r2=0.;  //  r2 is a better term as we are using radius squared for bailout (dot(z,z) )
	float Dd = 1.0;
	int i;
	for(i=0; i<MI && r2<bailout; i++){

Notice how the condition of the loop had to change too.

and the 'footer';) will work as you wrote:

Code:

float r = sqrt(r2);
//return (r - offsetD) / abs(Dd); // offsetD has a default of 0.0 which is the std case. The offsetD results are similar or maybe the same as adjusting Detail Level( Quality)
float Iter = i; // this DE works also in openCL so it might be something to with "i" in Fragmentarium
return sqrt(r)*pow(scaleM,-Iter);
}

@Crist-JRoger: Great Labyrinth! A real beauty :)
Can you try the code up here in your frag and test if the frag is still intact? It needs a bit adjusting on Detail and Fudgefactor...
Have also looked at 4D-formulas in fragM, haven't found any 4D-rotation, also had a look at the rotations in mathutils like you, but felt rather intimidated by all the sinusses and cosinusses :crazyeyes: :laugh:

Title: Re: Implementing MixPinski
Post by: Crist-JRoger on November 18, 2016, 08:42:32 PM

Sabine, ok I'll check it
Just for fan :D added z.w+=sin(z.w); then replace to z.w-=sin(z.w); then z.w-=sin(z.w)+cos(z.w); :hrmm: after Dd *= scaleM; in loop

(http://orig13.deviantart.net/6731/f/2016/323/4/b/2016_11_18_221537_by_crist_jroger-daoxh15.jpg)

(http://orig14.deviantart.net/2579/f/2016/323/0/5/2016_11_18_221805_by_crist_jroger-daoxh1k.jpg)

(http://orig00.deviantart.net/5b31/f/2016/323/4/a/2016_11_18_223015_by_crist_jroger-daoxh21.jpg)

Title: Re: Implementing MixPinski
Post by: Sabine on November 18, 2016, 09:32:40 PM

@Crist-JRoger: Ehmm... the upper image: Seems you found SMOOTH Mixpinski!!! ;D ;D ;D :beer:

I am still trying to get reciprocalX3b to work, but it plays merry hell with the DE (it also does next to really cool also really terrible things in mb3d, but there it is much more controleable (for me... :dink:)) :crazyeyes: It does behave better with the alternative DE-return, but still not good!

(http://orig09.deviantart.net/c2b6/f/2016/323/3/b/6_by_sabine62-daoxm6z.png)

I really am not sure now if this is the 'normal' distortion and it is only me not finding the right place for it to look good, or if there's still something amiss with the code... :suspious: Need to test more...

Title: Re: Implementing MixPinski
Post by: Crist-JRoger on November 18, 2016, 09:38:33 PM

About return func.
return r/abs(Dd); enouth because in Frag we have Detail/FudgeFactor sliders and offsetD have the same intention.
return sqrt(r)*pow(scaleM,-Iter); gives very strange results, i don't like it )

easier - it is better ©

Title: Re: Implementing MixPinski
Post by: Sabine on November 18, 2016, 10:01:02 PM

Hm, I think it is better than return r/abs(Dd) and also, Fudgefactor can be set to 1 if necessary without discontinuations... ;D
Can we agree to disagree and keep both? ;)

Title: Re: Implementing MixPinski
Post by: DarkBeam on November 18, 2016, 10:15:43 PM

Quote from: Crist-JRoger on November 18, 2016, 07:48:28 PM

Thank you! Added this but conversely :-\ :hmh:

Code:

for(int i=0; i<MI; i++){
	if(PreOffset) z-=offsetM;
	if(i>=PreRotStart) z.xyz*=fracRotation1;
	
	if(z.x+z.y<0.0) z.xy = -z.yx;
    	if(z.x+z.z<0.0) z.xz = -z.zx;
    	if(z.y+z.z<0.0) z.zy = -z.yz;
   	if(z.x+z.w<0.0) z.xw = -z.wx;
    	if(z.y+z.w<0.0) z.yw = -z.wy;
    	if(z.z+z.w<0.0) z.zw = -z.wz;

	z+=offsetM;
...

And really works and sometimes result looks differently
Maybe it's mathematically incorrect?

No idk what is correct anymore!!! Lol :hmh:
But I love the water cloudy pinsky a lot :beer:
Also Sabine's Image!

Title: Re: Implementing MixPinski
Post by: Crist-JRoger on November 18, 2016, 10:42:27 PM

Quote from: Sabine62 on November 18, 2016, 10:01:02 PM

Hm, I think it is better than return r/abs(Dd) and also, Fudgefactor can be set to 1 if necessary without discontinuations... ;D
Can we agree to disagree and keep both? ;)

Strange, very strange, because I have freezes and lags with return sqrt... But r/abs(Dd) works with Fudgefactor=1 :-\
Diffetent frags? Here my last edit

DarkBeam, thank you! Any ideas for randomize pinsky in Frag? ;D

Title: Re: Implementing MixPinski
Post by: mclarekin on November 18, 2016, 11:28:47 PM

set up
iteration 0 mixPinski
iteration 1 3D rotation
iterations 2 - termination Mixpinski

all combinations of 45,0, 45 45, 0,0 45,45,45 etc produce interesting symmetric shapes. I like 45,45,45 the best .
attached image is 45,0,0

other image is a minimalistic structure a hybrid with prismeshapeCMT

Title: Re: Implementing MixPinski
Post by: mclarekin on November 19, 2016, 12:15:53 AM

linear analytic DE my current thoughts:

In a standard situation when we graph outDist value over iteration count, and adjusting DE value by "* scale", the curve is following the equation outDist = r/DE.

This is good for "safe, robustDE" fractals, but when the Distance Estimation is not good we can try tweaking the outDist maths.

outDist = ( r- tweakOffset) / (DE * tweakScale)

Now if we are tweaking only one iteration, I can tweak to the same specific tweaked outDist value by using either manipulating the scale or offset tweaks.

But when we are tweaking more than one iteration (all iterations is the most normal case) the two tweaks work differently.

The offset is tweaking the outDist by a constant value each iteration, whereas the tweakScale is tweaking the outDist proportional to tweakScale.

Alternatively I also tweak this way

outDist = r / ((DE * tweakScale) -tweakOffset)

Title: Re: Implementing MixPinski
Post by: mclarekin on November 19, 2016, 01:29:34 AM

previous post I wrote about tweaking the outDist after termination condition has been met.

Alternatively we can tweak the outdistance by tweaking the DE at only specific iterations.

Example is when we are running an iteration loop where we add in a transform only at iteration 4 ( or say at iters 5,6,7)

The maths of this added transform may be detrimental to the distance estimation calculation.

So we try including a generic DE tweak in the transform 's code DE = (DE * tweak scale) + tweakOffset).

I find that in some cases this will help.

Many of the latest formulas and some transforms in MandelbulberV2 have some sort of DE tweak included, maybe just a DE *= tweakscale.

For me this is another area of experimentation , that I still have to figure out.

BTW Crist and Sarbi, I note that we all seem to have various knowledge that each other lacks, I have learnt new things working with you guys O0 O0

Title: Re: Implementing MixPinski
Post by: mclarekin on November 19, 2016, 02:44:56 AM

@ crist

Quote

And really works and sometimes result looks differently
Maybe it's mathematically incorrect?

if it makes a fractal that can be rendered with acceptable image quality, the maths is correct. IMHO ;D

This is how I currently view the process ;

I could make a make Mandelbox out of four transforms - boxfold, spherical fold, scale and addC.

I then can add in a rotation and an offset transforms.

I can then swap the order of all six transforms to make different fractals, then add in more copies of these six transforms. to make all possible combinations ( except note scale then rotate is the same as rotate then scale)

I then could further infinitize by adding in any other transform , z.x =sin(z), octo, fabs() prismShape, Bensi T1 etc .that work with analytical distance estimation.

I have start/stop iteration controls on every transform.

I conclude that any combinations of transforms where the maths renders a good image in a reasonable amount of time, is what I technically describe as "good maths" otherwise it is called "bad maths" and i dont like it".. ;D

But amongst all the infinite possibilities of transform sequences and parameter settings, some things work well others don't. The map forward to some maths then map back is a procedure that works well.

There is an infinite amount of combinations that can follow this rule.

example - symmetrical pattern (not tested)

magForward
* scale
+ offset1
rotForward
fasb(z+offset2)
rotBack
- offset1
* -scale
magBackwards

or a simple magForward , MBox , magBack

or +offset , ( scale, fabs, rotate, menger) , -offset

this sort of thing is often "good maths" :)

Title: Re: Implementing MixPinski
Post by: mclarekin on November 19, 2016, 04:31:13 AM

Back to the MixPinski

what we have is Mixpinski4D_mod1

the true mixPinski4 looks like this,

so TODO is 4D rotation plus figure out the difference. so we can make the true mixPinski4.

Title: Re: Implementing MixPinski
Post by: mclarekin on November 19, 2016, 07:15:22 AM

Here is a zoom at distance 4e-06, showing an area with fine detail. Step fudge 0.8.

Title: Re: Implementing MixPinski
Post by: Crist-JRoger on November 19, 2016, 09:31:55 AM

Quote from: mclarekin on November 19, 2016, 01:29:34 AM

I have learnt new things working with you guys O0 O0

Me too :dink:

Quote from: mclarekin on November 19, 2016, 02:44:56 AM

example - symmetrical pattern (not tested)

magForward
* scale
+ offset1
rotForward
fasb(z+offset2)
rotBack
- offset1
* -scale
magBackwards

or a simple magForward , MBox , magBack

or +offset , ( scale, fabs, rotate, menger) , -offset

this sort of thing is often "good maths" :)

will try handle this ;D Thank you very much!

Quote from: mclarekin on November 19, 2016, 04:31:13 AM

Back to the MixPinski
...
figure out the difference. so we can make the true mixPinski4.

In frag "default" shape with scaleC=(1,1,1,0.5). I fixed Default preset

Title: Re: Implementing MixPinski
Post by: mclarekin on November 19, 2016, 10:21:56 AM

The spherical fold seems to work well with the mixPinski. I am using 3 formula slots in MandelbulberV2. MixPinski in slots 1& 3 , and randomly trialling formulas and transforms in slot 2 :) and have been barely scratching at the surface of the mixPinski possibilities.

Title: Re: Implementing MixPinski
Post by: mclarekin on November 19, 2016, 11:26:51 AM

@ crist. The default is cool. :beer: :beer: :beer:

Title: Re: Implementing MixPinski
Post by: Sabine on November 19, 2016, 11:44:54 AM

mclarekin wrote

Quote

I have learnt new things working with you guys

You don't want to know how much I am learning from all of you ;D and it's such fun! I am quite in awe of the knowledge present here. I know I can only add very little and simple stuff, but to know how little you know seems to be the first step ;}

@Crist-JRoger: It was the bailout I forgot to delete! Agree now with you on simple DE ;D And great that you found the standard shape with the zScale=1. In mb3d it gives the standard shape with zScale=0,5 I do not know why and if that is important.

@Dark-Beam Thank you, Luca! :-* It's not yet right I think, I need to adjust all the things I know to find in mb3d: raystep multiplyer, stepwidth limiter, stepcount binary search, smooth normals, and I have no idea how/where to set them in frag! It would be so nice if everything had the same name :laugh: But really, the _reciprocals in mb3d need really fine settings to render nicely, so I cannot at this moment tell you if my efforts lead to any good result ;) The good thing it that I have not blown up Fragmentarium yet while hobbying rofl2 Thank you for challenging me;)

If anyone has any idea which settings in Fragmentarium correspond more or less with raystep multiplyer, stepwidth limiter, stepcount binary search, smooth normals, at least, if they exist at all in Fragmentarium? Would be a great help in figuring out if I am on to something or not.

Title: Re: Implementing MixPinski
Post by: Crist-JRoger on November 19, 2016, 06:44:33 PM

Some fun for MixPinski :) z.w manipulations and sphere for cut. At one's own sweet will (_{thankls to googleTranslate})
When tested has recalled Dr.Strange movie

(http://orig04.deviantart.net/e411/f/2016/324/6/d/2016_11_19_201706_by_crist_jroger-dap0vu9.jpg)

Title: Re: Implementing MixPinski
Post by: mclarekin on November 19, 2016, 11:29:46 PM

This transform i will insert into my openCL version, probably after the menger4D,
this transform uses Dd so cannot use pow(scale,-i)

Quote

uniform int foldSphStart; slider[0,250,250] ??start default 250 = transform disabled
uniform int foldSphStop; slider[0,250,250]
uniform float offsetS; slider[-5., 0.0, 5.]
//uniform float scaleS; slider[-5., 1.0, 5.] // neg scale so abs(Dd) needed

uniform float minR2; slider[-5., 0.25, 5.]
uniform float maxR2; slider[-5., 1.0, 5.]
float mMR2 = maxR2 / minR2;



if( i >= foldSphStart && i < foldSphStop)
{ // this transform uses Dd so cannot use pow(scale,-i)
   float r2 = dot(z,z);
   z += offsetS;

   //z *= scaleS; // if using pow(scale, -i) then comment out this and the next line
   //Dd = Dd * abs(scaleS) + 1.0; // beta, is the +1.0 needed in this function?

   if (r2 < minR2)
   {
      z *= mMR2;
      Dd *= mMR2;

   }
   else if (r2 < maxR2)
   {
      z *= maxR2 / r2;
      Dd *= maxR2 / r2;

   }
   z -= offsetS;

}

Title: Re: Implementing MixPinski
Post by: Sabine on November 20, 2016, 01:35:45 AM

Already had fun with your great Sity, Crist-JRoger! ;D Really great image too!

A bit of preview what maybe is or one day might be reciprocalX3b:

(http://orig00.deviantart.net/cc9c/f/2016/324/4/b/reci7a_by_sabine62-dap2ea4.png)

Title: Re: Implementing MixPinski
Post by: Crist-JRoger on November 20, 2016, 05:22:12 PM

Quote from: mclarekin on November 19, 2016, 11:29:46 PM

This transform i will insert into my openCL version...

Thank you :dink: Very interesting randomize of fractal. In standard settings i got upper half of apple with leaf ;D
So it works even after z scaling, but before z+=offsetM looks better I think

(http://orig07.deviantart.net/e813/f/2016/325/7/8/2016_11_20_190246_by_crist_jroger-dap4t7q.jpg)

Quote from: Sabine on November 20, 2016, 01:35:45 AM

A bit of preview what maybe is or one day might be reciprocalX3b:

Code not optimized? Fractal goes to infinity

Title: Re: Implementing MixPinski
Post by: Sabine on November 20, 2016, 06:03:04 PM

Quote

Code not optimized? Fractal goes to infinity

I have no idea how to optimize this code for fragm :laugh:

As I have written I haven't even got a clue if its basic is ok, I have asked Dark-beam, will wait what he says. This transform goes into some sort of almost-infinity in mb3d with Sierpnski4ex too, and it does always have DE issues if you use small limiters :suspious: Maybe you can have a look at its behaviour in mb3d with mixpinsky4ex, it looks like it is only seemingly going infinite there (big change in scale so must zoom out very much!)...

But all in all it does make nice images :tease: so might be a 'nice' error if it is one :}

Update Heard from DarkBeam: All is ok with it, this is normal behaviour for non-linears... But I have made it conditional, so you can just uncheck it;)

Title: Re: Implementing MixPinski
Post by: M Benesi on November 21, 2016, 02:22:04 AM

  So I made it 3d and mixed it with the "slice" formula (going to remove the accordion function I think, but for now it's still embedded in the slice part).

  Makes for some interesting infinitely zoomable patterns...
(http://drive.google.com/uc?export=view&id=0B0EcJQ49B_yOUUVfb0pxV1pWazg)

  Files here. The rotation technique seems applicable to both 2d and 3d fractals, and adds lots of details. More on it later... probably a name for it that educated people know. :D

https://drive.google.com/open?id=0B0EcJQ49B_yOUG1lRk5GdUk1MEk

Title: Re: Implementing MixPinski
Post by: Sabine on November 21, 2016, 11:11:53 AM

@Matt Very cool toy! ;D
I cannot get the AccCycleSplit to do anything, is there a condition that it needs to work that I am not aware of? But great fun anyhow!

Title: Re: Implementing MixPinski
Post by: M Benesi on November 21, 2016, 03:58:57 PM

lol. AccCycleSplit actually sets the cycle length for repetition along the x component. Doesn't do that much if you use it beyond the first iteration, and even then it's probably a superfluous part of the code.

Was going to remove the whole accordion part of the code anyway... right now. :D

Title: Re: Implementing MixPinski
Post by: DarkBeam on November 21, 2016, 04:18:22 PM

Hi Matt :dink:
For Crist: the fractal goes to infinity because the reciprocal transform map big numbers to zero and epsilons to infinity. This causes strong stretching but goes well with kifs :)
See the graphic of y=1/x for comparison. :)

Title: Re: Implementing MixPinski
Post by: M Benesi on November 21, 2016, 05:54:10 PM

Luca. ^-^

This is the 3d "Kaleidoscopic rotation" thing (rotates at multiple points to preserve continuity while adding movement/rotation). I uploaded the newer code with the rotations added, and accordion taken out to the link I posted above.

https://www.youtube.com/watch?v=P94WJoCtnSU&feature=youtu.be

(https://giphy.com/gifs/kaleidoscopic-rotation-W5KN3GmUmVT4k)

How do we do giphy gifs on the forums?

https://giphy.com/gifs/kaleidoscopic-rotation-W5KN3GmUmVT4k

Math guys- what is the technical term for those types of rotations? They do not introduce discontinuity as long as there are even numbers of rotations.

Title: Re: Implementing MixPinski
Post by: Sabine on November 21, 2016, 07:03:15 PM

Thank you Matt! ;D Will download your de-accordeoned version :)

The giphys can be uploaded into the gallery, no problem, just tested;)

Title: Re: Implementing MixPinski
Post by: M Benesi on November 21, 2016, 07:42:19 PM

Thanks Sabine :D. I was trying to directly link with the IMG tags... I haven't used the image gallery since.. well, the artist formerly known as TriFox said something along the lines of "hey, you're uploading too much stuff to my servers!" :D

Trying Giphy without the https in IMG tags....
(http://gph.is/2eZt4YS)

Giphy download link:
(http://i.giphy.com/l5pWLVTgr3hg4.gif)

Just plain old Youtube link:

https://www.youtube.com/watch?v=WANAUp1_lB0

Title: Re: Implementing MixPinski
Post by: Sabine on November 21, 2016, 07:58:29 PM

WOW beautiful!

Title: Re: Implementing MixPinski
Post by: cKleinhuis on November 22, 2016, 12:12:01 AM

Quote from: M Benesi on November 21, 2016, 07:42:19 PM

whoops, i said that to all of you ;) ... back in the days it was server space yes, nowadays simple 1 image per day and user is a convenience for people to not get flooded ... just to get things straight here ... muahar

Title: Re: Implementing MixPinski
Post by: mclarekin on November 22, 2016, 03:35:22 AM

@ matt, looking beautiful!!! This is what is needed in a dentist waiting-room. Do away with filthy dirty fish tanks, instead have a beautiful clean fractal formation generator (guaranteed fish free,) I want the holographic model

Title: Re: Implementing MixPinski
Post by: mclarekin on November 22, 2016, 04:35:48 AM

I had a productive day yesterday. - sign() working properly ;D. hmmm this leads to the boring work of checking all the formulas to see where i can retrofit this function :sad1:

- finally installed a temp 3D rotation in mixPinsky for MandelbulberV2. :)

- AND I fearlessly downloaded fragmentarium and it doesn’t look so scary as it did a few years ago ;D

Now I think I will implement aboxmodKaliEiffie as a fragmentarium exercise

Title: Re: Implementing MixPinski
Post by: 3dickulus on November 22, 2016, 05:19:11 AM

w00t!!!

Title: Re: Implementing MixPinski
Post by: Sabine on November 22, 2016, 09:59:44 AM

Quote from: mclarekin on November 22, 2016, 04:35:48 AM

- AND I fearlessly downloaded fragmentarium and it doesn’t look so scary as it did a few years ago ;D

I'm so proud of you! ;}

-aboxmodKaliEiffie?!!!! I only know the mb3d aboxmodKali-version: glorious fractal! Can't wait!
Will watch closely on your progress, it's a great mystery to me how to arrive at a working Fragm-version and especially at the DE, so lots for me to learn :dink:

Title: Re: Implementing MixPinski
Post by: M Benesi on November 22, 2016, 03:20:23 PM

Quote from: cKleinhuis on November 22, 2016, 12:12:01 AM

lol :D

Title: Re: Implementing MixPinski
Post by: M Benesi on November 22, 2016, 03:23:02 PM

Quote from: mclarekin on November 22, 2016, 03:35:22 AM

Seriously- it would occupy kids (and... our age kids).

Awesome that you're trying Fragmentarium. My computer is still a bit slow for Mandelbulber (it seems that way at least- 2 cores, 2 gigahertz...).

(http://i.giphy.com/LgfAvZCyDbXC8.gif)

higher res:

https://www.youtube.com/watch?v=Xfrhi6zhY2w&feature=youtu.be

Title: Re: Implementing MixPinski
Post by: DarkBeam on November 22, 2016, 08:08:24 PM

Mmm... That mix23 pineapple! You should add an apple, two pens and you get a fractal PPAP!
:music: :spgloomy: :cantor_dance:

Title: Re: Implementing MixPinski
Post by: mclarekin on November 22, 2016, 11:42:22 PM

@ matt, Seriously, I do see a market for this visualisation. (As well as L Markoya 3D supercool lenticular and GIFs). This is all coming together with the audio_fractal interface option as well. My favourite is still the T1 Pinetree for animation (in fact the T1 with anything) ;D

Title: Re: Implementing MixPinski
Post by: 3dickulus on November 23, 2016, 02:54:48 AM

https://youtu.be/XLYUPejADjI
Crinoid - Wikipedia (https://en.wikipedia.org/wiki/Crinoid)

Title: Re: Implementing MixPinski
Post by: Crist-JRoger on November 23, 2016, 11:59:08 AM

Quote from: mclarekin on November 19, 2016, 11:29:46 PM

This transform i will insert into my openCL version, probably after the menger4D,
this transform uses Dd so cannot use pow(scale,-i)

Code:

uniform int foldSphStart; slider[0,250,250]  ??start default 250 = transform disabled
uniform int foldSphStop; slider[0,250,250] 
uniform float offsetS; slider[-5., 0.0, 5.]
   
uniform float minR2; slider[-5., 0.25, 5.]
uniform float maxR2; slider[-5., 1.0, 5.]
float mMR2 = maxR2 / minR2;

if( i >= foldSphStart && i < foldSphStop)
{ // this transform uses Dd so cannot use pow(scale,-i)
   float r2 = dot(z,z);
   z += offsetS;

   if (r2 < minR2)
   {
      z *= mMR2;
      Dd *= mMR2;
   }
   else if (r2 < maxR2)
   {
      z *= maxR2 / r2;
      Dd *= maxR2 / r2;
   }
   z -= offsetS;
}

I replaced your transforms to z*= clamp(max(maxR2 /r2, minR2), 0.0, 1.0); from KaliBox. Not sure about correctness :embarrass:

(http://img09.deviantart.net/c01b/i/2016/327/1/8/mp_kboxmod_by_crist_jroger-dapdfy3.jpg) (http://orig04.deviantart.net/cadf/f/2016/327/e/c/mp_kboxmod_by_crist_jroger-dapdfy3.jpg)

Title: Re: Implementing MixPinski
Post by: M Benesi on November 23, 2016, 04:24:06 PM

Quote from: mclarekin on November 22, 2016, 11:42:22 PM

thx :D

Quote from: DarkBeam on November 22, 2016, 08:08:24 PM

Mmm... That mix23 pineapple! You should add an apple, two pens and you get a fractal PPAP!
:music: :spgloomy: :cantor_dance:

lol... I hadn't heard of PPAP before. I am so dememed by my lack of constant intertube access.

Title: Re: Implementing MixPinski
Post by: mclarekin on November 28, 2016, 05:39:21 AM

Placing a swizzle transform before mixPinski is O0 IMHO. I will add it as an option on the UI.

In MandelbulberV2 dev version, I test each combination and notice that some combinations have better DE image quality, these are the combinations I then explore further.

The code below is from MandelbulberV2, and was coded for a combo box, but each combination can simple have a checkBox

Sometime I should extend this for 4D

// swizzle order of z vector every iteration
// swizzle pos neg iteration
void TransformZvectorAxisSwapIteration(CVector3 &z, const cFractal *fractal)
{
   switch (fractal->mandelbulbMulti.orderOfxyz) // comboBox
   {
      case sFractalMandelbulbMulti::xyz:
      default: p = CVector3(p.x, p.y, p.z); break;
      case sFractalMandelbulbMulti::xzy: p = CVector3(p.x, p.z, p.y); break; // or p.yz = p.zy;
      case sFractalMandelbulbMulti::yxz: p = CVector3(p.y, p.x, p.z); break; // or p.xyz = p.yxz;
      case sFractalMandelbulbMulti::yzx: p = CVector3(p.y, p.z, p.x); break;
      case sFractalMandelbulbMulti::zxy: p = CVector3(p.z, p.x, p.y); break;
      case sFractalMandelbulbMulti::zyx: p = CVector3(p.z, p.y, p.x); break;
   }
   if (EnabledxFalse) p.x = -p.x;
   if (EnabledyFalse) p.y = -p.y;
   if (EnabledzFalse) p.z = -p.z;
}

Title: Re: Implementing MixPinski
Post by: mclarekin on November 29, 2016, 11:42:58 PM

I have been sidetracked and working backwards :) , by coding up mixPinski, sierpinski4d and then finally sierpinski3D

If we take the sierpinski code from the mixPinski4D and add in a scale of default 2, and having a negative offset at default (1,1,1,1) we have a sierpinski4D.

My mixPinski UI has been updated to include a sierpinski scale set at default = 1.

Then we can add other linear types before and after this transform.

      if (p.x + p.y < 0.0) p = p.xy = -p.yx;
      if (p.x + p.z < 0.0) p = p.xz = -p.zx;
      if (p.y + p.z < 0.0) p = p.yz = -p.zy;

      if (p.x + p.w < 0.0) p = p.xw = -p.wx;
      if (p.y + p.w < 0.0) p = p.yw = -p.wy:
      if (p.z + p.w < 0.0) p = p.zw = -p.wz;

   p = p * scale2; // scale default 2
   Dd *= scale2;

   if (i >= startIter && i < stopIter) // defaults 0 and 30?
   {
      p -= offset1111; // neg offset default ( 1,1,1,1)
   }

   //add rotation

BTW My mixPinski UI has been updated to include a sierpinski scale set at default = 1.

Title: Re: Implementing MixPinski
Post by: DarkBeam on November 29, 2016, 11:46:33 PM

Good job :alien: :)

Title: Re: Implementing MixPinski
Post by: mclarekin on November 30, 2016, 01:34:41 AM

Now for Sierpinski3D. I have included the code for Darkbeams reversed full tetra-fold as well, but I have yet to figure it out.

Sierpinski3D is fast (33 sec for this 3200x2400 render) and the DE calc quality is really good.

I have just randomly been testing combinations with other linear type transforms and it is very cool!!

BTW this is default settings looking down the MandelbulberV2 y_axis

   //Normal full tetra-fold;
   if (normalEnabled)
   {

      if (z.x - z.y < 0.0) z.xy = z.yz;
      if (z.x - z.z < 0.0) z.xz = z.zx;
      if (z.y - z.z < 0.0) z.yz = z.zy;
      if (z.x + z.y < 0.0) z.xy = -z.yx;
      if (z.x + z.z < 0.0) z.xz = -z.zx;
      if (z.y + z.z < 0.0) z.yz = -z.zy;
   }
   z = z * scale2;
   Dd *= scale2;

   if (i >= startIter && i < stopIter)
   {
      z -= offset111; // neg offset
   }

   // add rotation

   //Reversed full tetra-fold;
   /*if (z.x + z.y < 0.0) z.xy = -z.yz;
   if (z.x + z.z < 0.0) z.xz = -z.zx;
   if (z.y + z.z < 0.0) z.yz = -z.zy;
   if (z.x - z.y < 0.0) z.xy = z.yx;
   if (z.x - z.z < 0.0) z.xz = z.zx;
   if (z.y - z.z < 0.0) z.yz = z.zy;*/

Title: Re: Implementing MixPinski
Post by: Sabine on November 30, 2016, 01:40:18 AM

@mclarekin Saw your Sierpinski-image and already hoped you'd add it too! :dink: Very cool! Will try and see what I can get as soon the humble Mandelbrot releases me from its claws!

Title: Re: Implementing MixPinski
Post by: mclarekin on November 30, 2016, 04:34:09 AM

@ sarbine.

Reciprocal3b , I am about include this option in my OpenCL code.

This is the optimising (although it is not really necessary in Fragmentarium, because it is so fast)

Before the loop, we do this maths so that we do not have to do it every iteration:
double limitC = 1/Lim1 + 1/Lim2;

In the loop:
x' = sign(x)(limitC - 1/(abs(m1 * x) + Lim1 ) - 1/(m2 * x*x+ Lim2 ) )

Title: Re: Implementing MixPinski
Post by: Sabine on November 30, 2016, 01:51:10 PM

@mclarekin Ohh thank you for that, mclarekin! To be honest, I hadn't looked into optimizing it in Fragmentarium. I guess I was too much over the moon that I got it working at all ;D But optimising should get into my system as it should be done Always :)

Title: Re: Implementing MixPinski
Post by: mclarekin on December 04, 2016, 10:23:20 PM

So now I have coded the M3D Menger4, ( it is so cool!) and now I can finally see how the complete mixPinski was created. Now I will do the 4D rotation, and i will then be finished

(BTW DarkBeam suggested I code the MixPinski way back in June. Good things take time ;D)

This is the menger4D code I will use as the basis of a .frag
   float scaleM default 3.0
   vec4 offsetM default (1.0,1.0,0.5,0.5);
   vec4 opt1 = scaleM - 1.0;
   offsetM *= opt1;
   float opt2 = 0.5 * offsetM.z / scaleM;

   vec4 PreAdd default (0.0,0.0,0.0,0.0);

// iteration loop
   if (i >= StartPreAdd && i < StopPreAdd)
   {
      z4D += PreAdd_vec4_0000; // offset
   }

   z4D = abs(z4D);
   vec4 temp4;

   if ( z4D.x - z4D.y < 0.0) { temp4.x = z4D.y; z4D.y = z4D.x; z4D.x = temp4.x ;}
   if ( z4D.x - z4D.z < 0.0) { temp4.x = z4D.z; z4D.z = z4D.x; z4D.x = temp4.x ;}
   if ( z4D.y - z4D.z < 0.0) { temp4.y = z4D.z; z4D.z = z4D.y; z4D.y = temp4.y ;}
   if ( z4D.x - z4D.w < 0.0) { temp4.x = z4D.w; z4D.w = z4D.x; z4D.x = temp4.x ;}
   if ( z4D.y - z4D.w < 0.0) { temp4.x = z4D.w; z4D.w = z4D.y; z4D.y = temp4.x ;}
   if ( z4D.z - z4D.w < 0.0) { temp4.y = z4D.w; z4D.w = z4D.z; z4D.z = temp4.y ;}

   // temp3D rot

   if (rot && i >= StartRot && i < StopRot)
   {
      //Temp3D rotation
   }

   z4D.x = scaleM * z4D.x - offsetM.x;
   z4D.y = scaleM * z4D.y - offsetM.y;
   z4D.w = scaleM * z4D.w - offsetM.w;
   z4D.z -= opt2;
   z4D.z = -fabs(-z4D.z);
   z4D.z += opt2;
   z4D.z *= scaleM;
   Dd *= scaleM;

   // bailout 10
   // return sqrt(x* x + y* y + z* z)*scale^(-i);

Title: Re: Implementing MixPinski
Post by: mclarekin on December 07, 2016, 12:11:59 AM

Here is the Menger4 in a ,frag

Title: Re: Implementing MixPinski
Post by: mclarekin on December 07, 2016, 12:19:23 AM

This is what I get in OpenCL

Title: Re: Implementing MixPinski
Post by: M Benesi on December 07, 2016, 05:55:14 PM

Iteration weight code! :D

Title: Re: Implementing MixPinski
Post by: DarkBeam on December 07, 2016, 11:55:27 PM

Finally :) happy for you :D and all people.
Those 4d kids except MixP were made from a formula kindly given to me by Syntopia the genius of Fragmentarium! :)

Title: Re: Implementing MixPinski
Post by: mclarekin on December 08, 2016, 02:00:48 AM

@ Matt, Iteration Weight is good for Menger3 and PrismShapes.

I prefer to use Mandlebulber Curvi-Linear Algorithm Randomly Evolved Knavish Iteration Numberlisation (the MCLAREKIN), which I simply call VCL in MandlebuldberV2.10, (as shown in the attached para-graph). I have this working on Scale, MinR2 and SphericalOffset transforms. I will make a .frag including a VCL transform soon.

BTW Now that I have the Menger4 working I have been able to properly test out SphericalFold4D. I have found that under certain settings I can use three DOT modes :

/float r2=z4.x*z4.x+z4.y*z4.y; //Dot2
//float r2=z4.x*z4.x+z4.y*z4.y+z4.z*z4.z; //Dot3
//float r2=z4.x*z4.x+z4.y*z4.y+z4.z*z4.z+z4.w*z4.w; //Dot4

But it is tricky finding workable combinations of minR2 and maxR2.

@ DrakBeam. I have coded up most of the 4D matrix rotation in MandelbulberV2, ;D. I will soon be into the lengthy debugging period, :sad1:

Title: Re: Implementing MixPinski
Post by: mclarekin on December 08, 2016, 09:39:40 AM

Image of dot modes 2,3 & 4. It is kind of interesting. May be more so in another fractal?

Title: Re: Implementing MixPinski
Post by: mclarekin on December 10, 2016, 03:04:20 AM

In the wonderful world of 4D there are many more options to play with.

I have been experimenting in Fragmentarium and Mandelbulber V1.21 OpenCL. My latest Menger4 UI works like this

a) We have our Initial w to set prior to iterating. Then we iterate:-

b) We add a parabolic-iteration based function operating on z4.w.

//Menger4D VCL w
//based on Synatopia & Darkbeams Menger4

//ITERATION LOOP
//
// Iter loop :parab_w, pre_add, menger_Rot_sponge, sphericalFold

//09-12-16
   float para = 0.0;
   if (EnabledParabolic)
   {
      parabolicAddP0 = offsetP + (i * slopeP)   + (i * i * 0.001 * scaleP);
   }
   z4.w += parabolicAddP0;

c) we add to the Menger4 the option to turn off the separate z4.z function and instead scale & offset z4.z the same way as the other three axis.
// scale and offset
   z4.x = scaleM * z4.x - offsetM.x;
   z4.y = scaleM * z4.y - offsetM.y;
   z4.w = scaleM * z4.w - offsetM.w;
   if(EnableCondz == 1)
   {
      z4.z = scaleM * z4.z - offsetM.z;
   }
   else
   {
      z4.z -= opt2;
      z4.z = -fabs(-z4.z);
      z4.z += opt2;
   }
d) With the SphericalFold we add in options for various dot modes

if (EnableSphFold == 1)// 4D sphfold
   {
      r2 = z4.x*z4.x + z4.y*z4.y;

      if (Dot3 == 1)   { r2 +=    z4.z*z4.z ;}
      if (Dot4 == 1)   { r2 +=    z4.w*z4.w ;}

The attached image shows that with some settings the parabolic (i * i * scaleP) can be used to adjust the surface texture detail.

Title: Re: Implementing MixPinski
Post by: mclarekin on January 09, 2017, 05:14:52 AM

Menger 4D with 6 plane rotation

Title: Re: Implementing MixPinski
Post by: Sabine on January 09, 2017, 11:28:47 AM

(http://st.deviantart.net/emoticons/c/clap2.gif) Great work, mclarekin! :beer: :beer: :beer:

Love your setup naming the angles so it is clear right away what will be rotated. Will have a closer look at your formula soon, but for now am happily 'caleidoscoping' your preset ;)

Title: Re: Implementing MixPinski
Post by: mclarekin on January 10, 2017, 12:03:56 AM

I too spent some time happily caleidoscoping ;D

I could not remove all the code for 3D rot without crashing the program, :hmh:, so the frag is still not quite complete. I have not yet updated the MixPinski as I can not find my frag. :)

Title: Re: Implementing MixPinski
Post by: Mrz00m on January 10, 2017, 04:53:03 AM

Quote from: Crist-JRoger on November 14, 2016, 10:37:53 AM

Hey there, That's a very nice mandelbox there.

I had something similar when i tried to rewrite the mandelbox function in mandelbulber source one time, to find some new mathematics. I only changed 2-3 of the functions to arcsin/atan/ any random function that i could figure out... most of them had an infinity in them, but at some stage i found a fractal similar to the one you have above, except that the voids also contained gothic arch topology rather than mostly cubic, they went straight for a long time and at the top they had gothic arches everywhere. It was the only mandelbox var that worked nicely, i think perhaps it was arcsin added somewhere, i can't recall it. Darkbeams fractal looks very cool, it's good to not rely on sin in the mandelbox and to use periodic functions that are weird, perhaps inspired by audio synthesizer design... in synthesizers, we have frequency modulation, additive and sampling mostly as sources for complicating linear periodic functions, most simply mathematically and minimum computationally intensive.

In synthesizers, one of the best easy tricks that i know to mutate a single periodic function is "filter feedback loop" where the output of N wave iterations/periods, passes through a frequency filter which takes out some of the frequencies and changes the wave, and feed the output of that filter back into the frequency of the original oscillator using a time delay of at least one period.

That means it is self modulating it's own frequency with a delay of at least one period with a periodically semi consonant sound wave, and it's perhaps useable in fractals, i.e. copy a simple lowpass/highpass/bandpass filter code, use it to modulate the sine function through multiple iterations. That shouldn't be attempted without first trying simple additive/rectifying(abs value)/Frequency Modulation of the same wave, where the effect changes over time, as it's more difficult.

When doing Frequency modulation for example of a sine wave, Three important factors count to have very nice forms computationally cheaply and with much varietly without the sine degenerating into noise:...
A/ control of an ampltude varliabe on the amplitude of the frequency modulating sine wave into the frequency input of the main sine wave,
and then two controls to mutate the frequency modulating signal very subtly using two independent variables:

B/ in steps consonant with the period (.25/.5/2/4/8/16)
C/ in dissonant increments of 1-100th of the period of the main sine wave... it means that the signal never repeats once, and 100 periods or "recursions" later the measures of the sine wave (that makes a sphere for example in 3d) would have changed slowly from the first with a periodicity of perhaps 500 recursions.

I don't know totally how that works out in a recursion, else an ISO surface sense, because every sine function mutation used for the next recursion, would be best to not have any jagged moments caused by aperiodicity form being slightly mutated away from a normal sine. In synthesizers, the FM sine is a perfectly rounded aperiodic sine wave, i am not sure if that can even translate into a recursive function... if it is possible, it would perhaps mean that every next SIN function used in for example a mandelbox, was had it's freqency changed by another SIN of frequency .5 /.25 + 0.001, and of amplitude exponantially variable from 0.01 to 1.

I often program graphically and the fractals are higher than my normal maths level because the recursion spins me out and i didn't learn that in programming, but i believe that synthesizer periodic wave tricks can be applied to fractals. I may be completely wrong that synthesizer FM, which made a revolution in digital synths in the 80's and is still used in most synths today, can be applied to fractals, but if it can, that above ABC guide is the way to get the most out of it using very simple maths

Sorry about that synthesizers theory there, perhaps designing synthesizer wave generating central engines and writing recursive maths are not the same?!?! perhaps synthesizer wave folding (serge wave multiplier) and audio FM maths can be applied to give as much variety in fractals as they did in Yamaha's line of DX syths that changed music some time ago. FM can be very challenging mathematically to use it as advancedly as it's used in today's expensive synths because they manage to use totally random freqencies to produce unchaotic sounds using the FM index which is too complex for ordinary synth programmers and requires very advanced mathematicians.

perhaps someone else can tell me if synthesizer tricks can be used on fractal mathematics?!?
Changing the frequency of one periodic function using another atuned one is much more powerful than multiplying or adding them, and a lot more chaotic and less predictable.

https://www.youtube.com/watch?v=6zSmvNiN8hc

Title: Re: Implementing MixPinski
Post by: hgjf2 on January 14, 2017, 12:24:58 PM

Also the fractal music in Syerpinsky order can be founded and at the program AURAL.
Your clip has so music but with sounds like the trance techno music of years 2001 made by organ YAMAHA.
Cool!
:thumbsup1: :peacock: