Implementing MixPinski

[Crist-JRoger]

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

upd.: 1st complete render 

Labyrinth

[Crist-JRoger]

...
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);
}

[Crist-JRoger]

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

Thank you! Added this but conversely  

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?

[Sabine]

@mclarekin Ohh yes, pixel... I am really Really embarrassed now because I have read so many times that p=pixel...  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   

[Crist-JRoger]

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

[Sabine]

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

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... )) It does behave better with the alternative DE-return, but still not good!



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...  Need to test more...

[Crist-JRoger]

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 ©

[Sabine]

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

[DarkBeam]

Thank you! Added this but conversely  

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
But I love the water cloudy pinsky a lot
Also Sabine's Image!

[Crist-JRoger]

Hm, I think it is better than return r/abs(Dd) and also, Fudgefactor can be set to 1 if necessary without discontinuations... 
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? 

[mclarekin]

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

[mclarekin]

  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)

[mclarekin]

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

[mclarekin]

@ crist

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

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"..

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"

[mclarekin]

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.