Title: Implementing ABoxModKaliEiffie Post by: mclarekin on November 22, 2016, 05:02:19 AM This is the reference, http://www.fractalforums.com/new-theories-and-research/aboxmodkali-the-2d-version/ plus M3D versions.
Title: Re: Implementing ABoxModKaliEiffie Post by: mclarekin on November 22, 2016, 10:28:16 AM Here is an untested attempt. I will test it and the openCL version when next in WindosOS
Code: // aBoxModKaliEiffie Title: Re: Implementing ABoxModKaliEiffie Post by: Sabine on November 22, 2016, 10:52:46 AM For you all to have a laugh ;D, but this is what I came up with, and it sort of generates.. something... rather faulty...
This is supposed to be a very basic ABoxKali from mb3d... I'd be really grateful if someone could tell me if I am at least on the right track as it's my very first attempt? Or if I am heading nowhere ;D P.S. Stole the DE from mixpinski cause I have no clue about it! Code: #include "DE-Raytracer.frag" And a better preset maybe: Code: #preset 1 Title: Re: Implementing ABoxModKaliEiffie Post by: mclarekin on November 22, 2016, 11:27:28 AM You can try
put offset defaults to (0.5,0.5,0.5) the bailout rr for bailout check is taken form the middle of the iteration, that can make a difference I think. And if it works you save on having to recalculate rr at the end of the loop. Try all the ways and see. I dont understand the maths but with surf&box types the Dd calc adjustment looks like this Dd = Dd * abs(m) + 1.0f; when you make your first modification version of Kali's formula replace "sqrt(Min_R)" with "Min_R". Title: Re: Implementing ABoxModKaliEiffie Post by: mclarekin on November 22, 2016, 11:52:07 AM and scale at 1.5 default :)
Title: Re: Implementing ABoxModKaliEiffie Post by: Sabine on November 22, 2016, 01:45:54 PM Thank you for that, mclarekin! Forgot to check with Luca's initial settings in mb3d :embarrass:
The bailout I yet have to test in another place. The DE: Can't find a box to sneak a peak at your DE-suggestion. What is the f you refer to? ...and 1.0*f=f, I'd think in my innocence? If I just chop off the 1.0*f, I already get a much better DE, though Title: Re: Implementing ABoxModKaliEiffie Post by: Sabine on November 22, 2016, 02:40:39 PM Looks almost like the real thing... But initial view with Julia=off is empty :no:
Also made another mistake in the first attempt, if-statement within if-statement read as two seperate if-statements :embarrass: Title: Re: Implementing ABoxModKaliEiffie Post by: Crist-JRoger on November 22, 2016, 03:21:11 PM http://www.fractalforums.com/fragmentarium-b210/coloring-add-on-t14522/
Do you want create this fractal? Title: Re: Implementing ABoxModKaliEiffie Post by: Sabine on November 22, 2016, 07:39:19 PM @mclarekin I think it's coming along nicely now, at least that's how it looks :} Still no clue about the illusive 1.0f, but I stole it from your frag and it seems to work.
Fixed some more errors I only found when trying to understand what is actually happening... On conditional Julia I had no else, for instance rofl2 That's why nothing happened as soon as I switched off Julia. Also did some optimalisation... I think ;) Played with bailout location, not yet found a better place, but will investigate some more. I know this is only a simple exercise on my side and all can be done much better, I am sure, and definitely more elegant, and of course does not by far compare to anything you are doing (I really am utterly impressed by what you can set up so quickly!), but that I should have built a frag from looking at Luca's formula in mb3d and with your help on the DE should get something that does Anything at all, to me is a small miracle :yes: :dink: Thanks again and if you have more tips or see things that are not done right, please, by all means! Title: Re: Implementing ABoxModKaliEiffie Post by: mclarekin on November 22, 2016, 11:29:10 PM @sarbine 1.0f just means 1.0float. It is a coding style, I guess to show it is a float not a double. DE = DE *Scale + 1.0; the offset is set at 1.0 (I assume for some maths reason).
Now if we replace this with a generic simple DE adjustment DE = (DE * Scale * DE tweak) + DE offset, we can test the DE calc on a new formula, and we sometimes find the "+ DE offset" has no apparent effect in some situations. :hmh: I still have a lot learn about DE. Title: Re: Implementing ABoxModKaliEiffie Post by: Sabine on November 22, 2016, 11:46:15 PM Thanks you, mclarakin! :)
I still have a lot learn about DE. ...and I even more ;D Title: Re: Implementing ABoxModKaliEiffie Post by: mclarekin on November 23, 2016, 12:14:19 AM Sarbine so now you have a working Aboxkali
z = xyzAdd - abs(z); // you can add Tglad fold and other fold options to make other box types, you can even do different fold types on each axis. but as a general rule , the more you deviate away from the original formulas the greater the chance of having bad DE. Quote if (rr < sqrt(MinR)) {m = Scale/sqrt(MinR); } else if (rr < 1) {m = Scale/rr;} else { m = Scale; }; if (Julia) {z = z * m + Julia_C; } else {z = z * m;}; When you look at the posts of how all the surf& box types evolved you notice the optimisations that were not present in the original formulas This we can rewrite Initial Conditions: float MinR2; slider float Scale; slider float m = Scale; float minF = m/MinR2 In The Loop if (rr <MinR2)) {m = minF); } else if (rr < 1.0) {m = m/rr;} // else { m = Scale; }; not needed z *= m; if (Julia) {z += Julia_C; } Title: Re: Implementing ABoxModKaliEiffie Post by: mclarekin on November 23, 2016, 02:17:18 AM Lets look at the KaliBox (re - Crist's post yesterday.) The formula has evolved, the sqrt(minR) has been removed, And the spherical fold has been recoded. We have a rot at the beginning and the "AbsScaleRaisedTo1mIters" stuff (that I yet to implement in some formulas). Quote float absScalem1 = abs(Scale - 1.0); float AbsScaleRaisedTo1mIters = pow(abs(Scale), float(1-Iterations)); vec4 scale = vec4(Scale, Scale, Scale, abs(Scale)) / MinRad2; float DE(vec3 pos) { vec4 p = vec4(pos,1); for (int i=0; i<Iterations; i++) { p.xyz*=rot; p.xyz=abs(p.xyz)+Trans; float r2 = dot(p.xyz, p.xyz); p *= clamp(max(MinRad2/r2, MinRad2), 0.0, 1.0); p = p*scale + vec4(Julia,0); } return (length(p.xyz) - absScalem1) / p.w - AbsScaleRaisedTo1mIters; // (here the DE calc stuff is p.w of the vect4 p, which is a cool way of doing it in 3D) //which is the same a return (r - absScalem1) / Dd - AbsScaleRaisedTo1mIters; (so we haven’t got and Dd = Dd * scale + 1.0 in this code :)) } So any surf box type can be made this way. Box Fold, Spherical Fold, Scale, add constant(s), then add in a Rotation (or two) R, B, R, Sph, S, R, Julia-C, R, addCpixel, R and then you can swap some of not_rotations tranforms around and add more same or different transforms to the mix ( "you can mix and add, until the DE goes bad"). Then you can start modifying parameter values over iteration-count, and or implement late start/ early finish iteration controls for the separate transforms within the formula. Infinity upon infinity. Title: Re: Implementing ABoxModKaliEiffie Post by: mclarekin on November 23, 2016, 02:59:24 AM When we look at the AboxModKaliEiffie we see it is a standard sort of ABox with a swizzle and a conditional swizzle added.
if (swapXZ == 1)// default ON { z = (float3){z.z, z.y, z.x}; // X & Z swizzle every iteration. Note, if this is ON you // cannot make offset.z 0 and get an ASurf type } if (z.y > z.x) z = (float3){z.y, z.x, z.z}; // X &Y swizzle when Y > X, IN OpenCL Code: // aBoxModKaliEiffie Code: // aBoxModKaliEiffie I randomly place the Rotation in the loop, you can try relocating it. I forgot to make my .frag version available to me in Windows OS, but will try my frag version soon. Title: Re: Implementing ABoxModKaliEiffie Post by: Sabine on November 24, 2016, 10:22:14 PM @mclarekin Thanks a bunch for your elaborate replies!! :beer: :beer: :beer:
Won't be until the weekend that I can get some quiet time to study them in detail, but I'm already looking forward to it! Title: Re: Implementing ABoxModKaliEiffie Post by: mclarekin on November 25, 2016, 12:06:35 AM Here is a beta AboxModKaliEiffie .frag
This image was using this formula and ASurf in MandelbulberV2 http://www.fractalforums.com/index.php?action=gallery;sa=view;id=19627 I have set it up as a standard Abox type with check boxes for enabling the two eiffie swizzles. This was constructed from the Mandlebox.frag. Which is a good starting point for making these surf box types. Title: Re: Implementing ABoxModKaliEiffie Post by: mclarekin on November 25, 2016, 01:55:17 AM BTW some of my sliders are not set uo properly but the spinboxes all work
So evaluating . frag progress so far // Output generated from file: D:/fragmentarium/AboxModKaliEiffie6.frag // Created: Fri Nov 25 00:29:01 2016 #info Mandelbox Distance Estimator (Rrrola's version). #define providesInit #include "DE-Raytracer.frag" #include "MathUtils.frag" #group AboxModKaliEiffie this is the tab name that appears on the UI for the fractal parameters /* The distance estimator below was originalled devised by Buddhi. This optimized version was created by Rrrola (Jan Kadlec), http://rrrola.wz.cz/ See this thread for more info: http://www.fractalforums.com/3d-fractal-generation/a-mandelbox-distance-estimate-formula/15/ */ uniform bool swapXZ; checkbox[false] enable eiffie's XZ swizzle uniform bool swapXY; checkbox[false] enable eiffie's XY swizzle add another uniform bool foldB; checkbox[false] original KaliBox fold // Number of fractal iterations. uniform int Iterations; slider[0,17,300] hmmm ? 17 is too low . 60 should be safe uniform float Bailout; slider[0,100,1000] uniform int ColorIterations; slider[0,3,300] uniform vec3 Offset1; slider[(-5.0,-5.0,-5.0),(1.0,1.0,1.0),(5.0,5.0,5.0)] for the tglad fold uniform float MinRad2; slider[0,0.25,2.0] uniform float Scale; slider[-5.0,2.0,5.0] vec4 scale = vec4(Scale, Scale, Scale, abs(Scale)) / MinRad2; vec4!! the internal DE calc is p.w of p = vec4 (pos, DE) sort of thing uniform vec3 c3Mul; slider[(-5.0,-5.0,-5.0),(1.0,1.0,1.0),(5.0,5.0,5.0)] this is the scale factor applied to c (the original coordinates of the point being iterated, addCpixel) uniform vec3 cJ; slider[(-5.0,-5.0,-5.0),(0.0,0.0,0.0),(5.0,5.0,5.0)] julia constant or add_ an_offset. // then we have a rotate about a vector by angle, (I will add a 3D matrix rotation) uniform vec3 RotVector; slider[(0,0,0),(1,1,1),(1,1,1)] uniform float RotAngle; slider[0.00,0,180] mat3 rot; void init() { rot = rotationMatrix3(normalize(RotVector), RotAngle); } // this is part of the distance estimation, I have yet to evaluate this additional maths, but I think it may give a better render , hmmm? float absScalem1 = abs(Scale - 1.0); float AbsScaleRaisedTo1mIters = pow(abs(Scale), float(1-Iterations)); float Dd = 1.0; That is the initial conditions , next the Iteration Loop :) Title: Re: Implementing ABoxModKaliEiffie Post by: mclarekin on November 25, 2016, 04:34:02 AM This frag has two presets Default preset is Abox
It is now can make a KaliBox, Abox & AboxModKaliEiffie. Title: Re: Implementing ABoxModKaliEiffie Post by: mclarekin on November 25, 2016, 08:05:45 AM well all that vec4 stuff hiding the DE calcs, made it a bit hard to figure out. So I stripped it back to a vec3 p3 and the internal DE calc using float Dd.
float DE(vec3 pos) { float Dd = 1.0; vec3 p3 = pos; vec3 c3 = pos; float r2; for (int i=0; i<Iterations; i++) { p3 *=rot; // fold options if (KaliBox) p3 = abs(p3) + KaliBoxV; if (TgladFold) p3 = abs(p3 + TgladFoldV) - abs(p3 - TgladFoldV) - p3; // p = clamp(p, -1.0, 1.0) * 2.0 - p; // min;max;mad // tglad fold, which is faster?? // p = clamp (p, -Offset, Offset) * 2.0 - p; // = Abox tglad fold Fold?? // p = clamp (p, -Limit, Limit) * Value - p; // = Mbox Fold ?? // swizzle options, both enabled = aboxModKaliEiffie if (swapXZ) p3.xz = p3.zx; if (swapXY) if (p3.y > p3.x) p3.xy = p3.yx; float r2 = dot(p3, p3); // radius squared if (i<ColorIterations) orbitTrap = min(orbitTrap, abs(vec4(p3,r2))); // spherical fold p3 *= clamp(max(MinRad2/r2, MinRad2), 0.0, 1.0); // dp3,div,max.sat,mul Dd *= clamp(max(MinRad2/r2, MinRad2), 0.0, 1.0); // dp3,div,max.sat,mul p3 = (p3 * SdmR2) + cJulia + (c3 * c3Mul); Dd = (Dd *abs(SdmR2)) +1.0; //r2 = dot(p3, p3); if ( r2>Bailout) break; } //float r = sqrt(r2); // hmmm?? this don't work ?? float r = length(p3); return (r - absScalem1) / Dd - AbsScaleRaisedTo1mIters; } Title: Re: Implementing ABoxModKaliEiffie Post by: Crist-JRoger on November 25, 2016, 09:43:28 AM Looked at code. Why reinvent KaliBox (http://www.fractalforums.com/fragmentarium-b210/coloring-add-on-t14522/) again?
Or you want make all-in-one constructor based on ABox? Title: Re: Implementing ABoxModKaliEiffie Post by: Sabine on November 25, 2016, 09:56:36 AM @mclarekin Really great that you share your progress with it. Though that generates another job for my weekend: trying to dissect your code ;D
Already very cool to play with: Title: Re: Implementing ABoxModKaliEiffie Post by: mclarekin on November 25, 2016, 12:50:18 PM @ Crist. You can run both folds at the same time. You can run either fold with one or both the swizzles. Include stop & start iter conditions and it can become more manageable.
It is just one of the infinite possibilities. BTW since then I have changed the KaliBox fold to another one and added two more rotations. I will add in one more transform and call it finished. :) Title: Re: Implementing ABoxModKaliEiffie Post by: Crist-JRoger on November 25, 2016, 01:26:20 PM mclarekin, I wish and I hope that you will come to Apollonian and Kleinian fractals :embarrass: and implement your version to Frag 88)
Inspired this (http://www.fractalforums.com/gallery/apollonian-gasket-3d/15/)gallery Title: Re: Implementing ABoxModKaliEiffie Post by: mclarekin on November 26, 2016, 07:47:38 AM I added in a second scale, and a manipulation of addCpixel. Using my new knowledge of the sign() to keep it short, ( the new sign() got rid of about 150 lines of code from MandelbulberV2 ;D)
This transform allows c to become absolute value (or not), then applys the sign of the currentz, before it is added to currentz. This transform was coded for use with Msltoe's julia bulbs, but can work with some other fractals Code: if(absC_sym ) I found Fragmentarium is not at all difficult to use. And you dont actually have to understand or do coding, for loadExample_explore_render type fractal generation ( and it is soooo fast). It is also a perfect program for learning how to code fractals. Now I better get back to finishing mixPinski and cross Menger code. Title: Re: Implementing ABoxModKaliEiffie Post by: Crist-JRoger on November 26, 2016, 04:08:49 PM Thank you for sharing frag!
Played with KaliBox ^-^ added p.x=sin(p.x); after abs. (http://orig10.deviantart.net/772c/f/2016/331/a/b/kbox_sin_mod_2_by_crist_jroger-daprizu.jpg) (http://pre00.deviantart.net/e759/th/pre/f/2016/331/0/d/connection_by_crist_jroger-dapri2t.jpg) (http://orig14.deviantart.net/365f/f/2016/331/0/d/connection_by_crist_jroger-dapri2t.jpg) Title: Re: Implementing ABoxModKaliEiffie Post by: Sabine on November 26, 2016, 04:44:40 PM @mclarekin Finally got some time to have a look at your optimisations for 'my' aboxmodkali!
This is my original bit and below are your recommendations if (rr < sqrt(MinR)) {m = Scale/sqrt(MinR); } else if (rr < 1) {m = Scale/rr;} else { m = Scale; }; if (Julia) {z = z * m + Julia_C; } else {z = z * m;}; This we can rewrite Initial Conditions: float MinR2; slider float Scale; slider float m = Scale; float minF = m/MinR2 In The Loop if (rr <MinR2)) {m = minF); } else if (rr < 1.0) {m = m/rr;} // else { m = Scale; }; not needed z *= m; if (Julia) {z += Julia_C; } The part concerning the Julia-shortcut I actually understand! ;D Now my challenge is to remember and apply in the future! :} Above: The thing is: I cannot lose the Scale-variable, as m gets altered by every cycle. The only way (I think) I could do it your way is to put m=Scale at the start of the cycle and then go if (rr < 1) {m/=rr;}; This gives a correctly working fractal. But maybe I did miss something? Here's the whole thing now including your recommendations: Code: uniform int MI; slider[1,30,100] Title: Re: Implementing ABoxModKaliEiffie Post by: Sabine on November 26, 2016, 04:47:13 PM @Crist-JRoger: Beauties, both of them! I must test your trick;)
Title: Re: Implementing ABoxModKaliEiffie Post by: mclarekin on November 26, 2016, 08:39:04 PM @ Sarbine. This is the spherical fold on its own i.e. no scale. (with maxR2 also included)
float maxR2 slider default = 1 float minR2 slider default = 0.25 float mMR2 = maxR2 / minR2; then in the loop : // sphericalFold if (Enable.z == 1) { r2 = dot(z,z); if (r2 < minR2) {z *= mMR2; Dd *= mMR2; } else if (r2 < maxR2) {z *= maxR2 / r2; Dd *= maxR2 / r2; } } Title: Re: Implementing ABoxModKaliEiffie Post by: Sabine on November 26, 2016, 11:06:37 PM @mclarekin :confused: Now you lost me... I think! :}
You are now talking about something else right? I am embarrassed to say that I haven't really got a clue if the aboxmodkali is a spherical fold With scale... Is it? :embarrass: This is ALL really very new to me... Basically I am juggling with building blocks to begin with :dink: As I understand it now I can use what you wrote as an alternative way of folding? So, let me get this right (in the long version): if(Enable.z) { // uniform bool with checkbox for Enable.z r2=z.x*z.x+z.y*z.y+z.z*z.z // is this what r2=dot(z,z) means? if(r2<minr2) {z=z*mMR2; Dd=Dd*mMR2; } else // checks if r2 smaller than minR2 OR (bigger than minR2 AND smaller than maxR2), alters z and Dd to different values in either case. if (r2<maxR2) {z=z*maxR2/r2; Dd=Dd*maxR2/r2;} } Built it into abmk as option and now I find bulbs ;D Thank you very much for your patience! Another thing: I see you are really giving aboxmodkalieiffie a good spin, building in all kinds of transforms. So I was wondering: doing this kind of thing for every formula is a pain, especially when it is basically a bunch of standard routines (if I understand that correctly) that have to be coded into the formula in certain places. In Fragmentarium there is the wonderful #define option with which you can load extra options built into the raytracer you are using and the #include option with which you can include a raytracer, math-library and such. What if there were a possibility to enable transforms that live outside the formula and have them have their own tab on the variable editor? That would make a big difference to the amount of time needed to code something for Fragmentarium. But then that would mean a certain amount of standardizing and I am not sure (if it is at all feasable) if that would not mean a big change to the until now happy-go-lucky-oh-let's-try-this-fragmentarium-style approach... But is it at all possible? Or should i ask this question in a new thread (as I am already abusing this one enough as it is ;) ) Title: Re: Implementing ABoxModKaliEiffie Post by: mclarekin on November 27, 2016, 12:32:24 AM @ sarbine
Quote r2=z.x*z.x+z.y*z.y+z.z*z.z // is this what r2=dot(z,z) means? yep, vec z.xyz * vec z.xyzQuote if(r2<minr2) {z=z*mMR2; Dd=Dd*mMR2; } else // checks if r2 smaller than minR2 OR (bigger than minR2 AND smaller than maxR2), alters z and Dd to different values in either case. It works like :-if (r2<maxR2) {z=z*maxR2/r2; Dd=Dd*maxR2/r2;} check if(r2<minr2), if so then z=z*mMR2 if not, check if (r2<maxR2), if so then z=z*maxR2/r2 if not, then z remains unchanged. Standard transforms can be set up as subroutines or macros and then called into a formula. This seems to me the optimum way. I cannot do this easily in Mandelbulber OpenCL without learning how to build and compile that version but we did have it implemented in V2.5 & V2.6. In current MandelbulberV2 I have yet to re-implement a similar system, (too many other things to do). In MandebulberV2 we have nine formula slots so I can have nine seperate UI's loaded to work with. These can be formulas and /or transforms. With my frag code I was just messing about learning about Fragmentarium, so I just added a few extra options until the UI became cluttered. Finding the optimum UI setup is a balancing act between "not enough options" and "looks complicated with too many options." There may already be a Fragmentrarium thread dealing with possible enhancements, if not you could start one. If 3dickulus had a team of programmers helping him, then Fragmentarium could have many added enhancements. Title: Re: Implementing ABoxModKaliEiffie Post by: Sabine on November 27, 2016, 11:52:55 AM @mclarekin Thank you for the explanations! :beer: :beer: :beer: I will have to find out how the dot products and their proper notation really work, they are still a bit hazy to me as I have never heard about them till yesterday:} And maths at school has been so long ago and in a different language... :dink: Tangled/too complex UI: There's always the possibility to create a tab per transform or per group of transforms with #group, that way your main formula's tab does not get too 'cluttered'. Matt Benesi's latest .frag is an example for that http://www.fractalforums.com/fragmentarium/menger-toy-sorta-fun/msg97736/#new (http://www.fractalforums.com/fragmentarium/menger-toy-sorta-fun/msg97736/#new) I will have a look if there are threads about enhancements of Fragmentarium (re: my question about the feasibility of adding transforms in another way). I guess Mandelbulber's environment is close to Mandelbulb3D where it concerns the combinations of formulas/transforms. Maybe there would be possibilities with the Fragmentarium scripts too. But the whole idea is maybe just daydreaming ;) As you say: it would be a different story if there was a team of programmers for Fragmentarium :) |