Help?

[DarkBeam]

Nice job and np for hijacking since I do it all the times 

[Crist-JRoger]

smooth menger rendered with global illumination

[M Benesi]

Can we pronounce it "Shmenger"?  Because that would be awesome. 


  Nice renders. 

[M Benesi]

this is how I used (modified) your fold function...

 If you could, I'd comment before bscale and boffset like the following (I also changed the default values and the total range):

Code:

// keep scale values the same for each variable, for a more orderly fractal
uniform vec3 bscale; slider[(-5,-5,-5),(2,2,2),(5,5,5)]
//only use x component, for a more orderly fractal
uniform vec3 boffset; slider[(-5,-5,-5),(2,0,0),(5,5,5)]

  In Fragmentarium, if you hover over a slider or box, it does a pop up of the comment that is directly above the variable declaration.  So if you hover over boffset, with the above code, it would pop up "only use x component, for a more orderly fractal".

 And then for the Pine part, introduce a pixel scaling part, with the y and z pixels normally set to 0, so it is more smooth.  In fact, if you set it up so the y and z parts only get added in every 4-5 iterations... way cooler.

  UPDATE:  mistake in formula below... due to optimizations (elimination of temp variables).  You have to calculate b.z before b.y, because you use b.y to calculate b.z.  I kept them in original order to let people know that I switched y and z in the calculation, but... really... seriously.  I'll comment in the formula.  

Code:

// just use x pixel, for most orderly fractal... I like order.  Don't ever alter this ever, or the fractal will
// come to life, seek out fluffy bunnies, and explode.  So if you face the Rabbit of Caerbannog.. well.
// this fractal can help, if you don't have the HHGoA.  
uniform vec3 PixelMult;slider[(-2,-2,-2),(1,0,0),(2,2,2)]

  //I'd multiply the pixel outside of the loop or function call, so you don't have to do it a bunch of times... so do it here:
Cx=Cx*PixelMult.x;
Cy=Cy*PixelMult.y;
Cz=Cz*PixelMult.z;

void BenesiPine(inout vec3 b) {
// STEP2: "Benesi pinetree"
float xt = b.x*b.x; float yt = b.y*b.y; float zt = b.z*b.z;
float t = 2.0*b.x/sqrt(yt+zt);
b.x = xt-yt-zt+Cx;
b.y = 2.0*t*b.y*b.z+Cz;  //  was b.z = t*(yt-zt)+Cy;      had to switch these because b.z is used in this.. so cannot
b.z = t*(yt-zt)+Cy;  //   was   b.y = 2.0*t*b.y*b.z+Cz;    change before it is calculated.  y and z are still switched
}                                                  // mathematically... just not in the formula    so I'd leave a comment so people know

I will add a Benensi folder to the Examples collection for these frags if that's ok with you  

 Implicitly.  Although I would totally not mind if you spelled my name correctly, like you did in the formulas, instead of like you did above.  Unless you insist on spelling it incorrectly.  Which would also probably be all right, but slightly confusing.  

  If it's all right with you, before they go all official, could I give them a once over?  Just to see if there are any optimization errors.  Funny- I made the EXACT same error when I was re-writing the frag yesterday....  because I used temp variables in the old version, and it just didn't work right.  I was like "WTF is going on??" until I looked...  

[mclarekin]

Bensei is right up there with transfrom and origional,  as my current most common typos

Code:

float Cx = 0.816496580927726;
float Cy = 0.5773502691896258;
float Cz = 0.7071067811865475;

did you change to your mag constants to something like this so not to be confused with pixel component Cx, Cy Cz

float Cmagx = 0.816496580927726;
float Cmagy = 0.5773502691896258;
float Cmagz = 0.7071067811865475;

[mclarekin]

//I'd multiply the pixel outside of the loop or function call, so you don't have to do it a bunch of times... so do it here:
Cx=Cx*PixelMult.x;
Cy=Cy*PixelMult.y;
Cz=Cz*PixelMult.z;

That is  a good idea. I have yet to set up Initial Conditions transforms in Mandelbulber, but when I may add  the PixelMult option, cool.

SO I re-arranged the BenesiFastPwr2PineTree, for easy later removal.

 

Code:

CVector3 temp = z;
    z *= z;
    double t = 2 * temp.x/sqrt(z.y + z.z);
    c *= benesiFastPwr2PineTree.constantMultiplierVect;  // possibly move to IC
    z.x = (z.x - z.y - z.z) + c.x ;
    z.z = (t * (z.y - z.z)) + c.y ;
    z.y = (2 * t * temp.y * temp.z) + c.z;

[3dickulus]

If you could, I'd comment before bscale and boffset like the following (I also changed the default values and the total range):
...
 Implicitly.  Although I would totally not mind if you spelled my name correctly
...
  If it's all right with you, before they go all official, could I give them a once over?  Just to see if there are any optimization errors.  Funny- I made the EXACT same error when I was re-writing the frag yesterday....  because I used temp variables in the old version, and it just didn't work right.  I was like "WTF is going on??" until I looked...  

Yes, comments are good.

TY! sorry 'bout the fat-fingering, I would have caught it eventually 

Not quite ready for patch v14 but soon, I've been thinking of putting the examples folder into a separate zip file for maintenance and distribution or perhaps an accessible folder on my webserver, maybe a repository that can be queried for updates? at any rate I'll try to keep current with your changes, just post'em here on FF an I'll find them.  I know... there's always one more tweak

[M Benesi]

did you change to your mag constants to something like this so not to be confused with pixel component Cx, Cy Cz

  No, it's the way 3dickulus wrote it.  I'm thinking it's maybe a bit of recycling of variables... which I've done often.  You should check out some of my private (not publicly released) code....... well, not really, because it would take me years to explain all the variables, and I'd have to figure out the math again, because I didn't use a standardized nomenclature... 

That is  a good idea. I have yet to set up Initial Conditions transforms in Mandelbulber, but when I may add  the PixelMult option, cool.

  I thought you did something similar from your code already.  Hmm..

CVector3 temp = z;
    z *= z;
    double t = 2 * temp.x/sqrt(z.y + z.z);
    c *= benesiFastPwr2PineTree.constantMultiplierVect;  // possibly move to IC
    z.x = (z.x - z.y - z.z) + c.x ;
    z.z = (t * (z.y - z.z)) + c.y ;
    z.y = (2 * t * temp.y * temp.z) + c.z;[/code]

Nice.  I do need to learn Mandelbulber, to become versed in it as well.

[M Benesi]

 

TY! sorry 'bout the fat-fingering, I would have caught it eventually 

   I was joking about my name..  hope I don't come across the wrong way.... eek...

I know... there's always one more tweak

  cool. 

[3dickulus]

Can we pronounce it "Shmenger"?  Because that would be awesome. 

"Shmenger" gets my vote +++

[Crist-JRoger]

 Ohh.. exp is mine.  Whhhooops...  I put in some options to rotate around the camera- actually screwed up the math, but it worked good enough for me, although it didn't work the way I wanted.

  And.. here is an update.  Includes transforms 3,4,5b as options.  I don't get a lot of mileage out of my ancient 8+ year old GPU (8600m... mobile.. and not the faster one)...  ahh, you know what.  I don't know how to color either...    I wrote a few scripts.. but.. meh...

  Anyway.. this has options to do the other transforms (and you can see how I set it up from within the code).. runs slower, but it has options.  If you remove a few of the if statements from the main loop, it will run faster.  I'd do that for rendering animations.

Is that possible to use "pine with options original Brute Raytracer.frag" with DE-raytracer?

[3dickulus]

Yes, well, sort of...
http://www.fractalforums.com/images-showcase-%28rate-my-fractal%29/bat/
http://www.fractalforums.com/images-showcase-%28rate-my-fractal%29/dragon-t22599/
and attached is a modified frag for testing, just the default mandelbulb DE frag with Benesi's fold and pine formulas hacked and butchered until I got some viewable results, this is probably not the "correct" implementation but fun to play with.

[M Benesi]

  Try this.  Keep in mind that I am using an old version of Fragmentarium with old raytracers.. I need to update to 3dickulus's new version.. I.. just work with the things on my desktop.

  OMG.. I'm turning into my parents..  using old things because they work good enough, and I don't feel like bothering to get something new....  For whatever reason, the fractal fades in the distance... things that are far behind one section of the fractal aren't there.

   Ohh... raysteps wasn't set high enough.  Set them higher to get the distant parts of the fractal..

  I've been using non-DE because I'm used to it.. but.. anyway.  Here you go:

[Crist-JRoger]

Thank you very much! 3dickulus and M Benesi too! I'll try... later, now computer busy.
I use frag ver. 1.0.0, because in new versions i have troubles with using - all borders of values in sliders are locked, so i often use values over the sliders. Sometimes very large 
And i don't like auto-build when you open many frags and switch them.
So, i use old software too, or not "old" - i just don't update without necessary   

[3dickulus]

@M Benesi mine is sooooo wrong, sorry for making a mess of your beautiful code and thanks for the proper DE frag

@Crist-JRoger I will try to apply the "No Auto Run" feature in preferences to the tab switching, but it should only be applying the last valid settings when returning to a tab ie: putting it where you left it so that settings from previous tab don't interfere with current tab.

all borders of values in sliders are locked, so i often use values over the sliders. Sometimes very large

can you elaborate on this a little bit?