Title: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: David Makin on February 14, 2010, 12:15:00 AM Hi all,
When implimenting Tom Lowe's Mandelbox in my formula for Ultra Fractal I realised that it's essentially a different way of doing escape-time RIFS (that's Restricted IFS not Random IFS). In fact it's revealed the answer I was looking for in terms of how to efficiently render RIFS using the standard escape time method rather than employing Hart's method as I did in my older 3D IFS formula (which can only be used for purely affine IFS/RIFS). However to do true "correct" IFS using the method (e.g. for the Sierpinski tetrahedron) is not applicable to all IFS. When using the contractive methods for rendering IFS (chaos game or deterministic) then each transform normally consists of a contraction (scale/skew/rotate etc) followed by an attraction (translation to the transform's location) but using the escape-time methods this is reversed to being a repulsion (away from the attractors location) followed by an expansion (scale/skew/rotate etc.). When using the contractive methods the key transform that dictates if the point concerned belongs to a particular transform's area/volume is the *last* transform performed, when using the escape-time method the key transform that dictates which transform's area/volume a point belongs to is the *first* transform performed. This fact about the escape-time method can be exploited because if we determine which area a given point is in (i.e. which transform's area/volume it belongs to) then we know the next transform to perform for that point. Using the Sierpinski tetrahdron for example it's easy to find which of the 4 transforms concerned should be applied next to a given point simply by finding which of the vertices of the tetrahedron the given point is closest too and applying the associated transform to the point and iteratively repeat that procedure as normal until bailout or max iterations is reached. The drawback with this method is that if the volumes relating to each transform are not easy to separate (as is usually the case when using rotations for instance) then the method causes parts of the "correct" attractor to be missed due to choosing the wrong transform at some point during the iteration, though this of course can be used to control the results too. Also the delta DE methods give us a way of mixing affine and non-affine transforms for RIFS using the escape-time method. Am just working out a new formula addition to the options in my wip 3D formula along these lines. I realise the method is a little "chicken and egg" since you need to know the fractal shape in terms of the transform areas/volumes before you can use it to render a particular fractal, but then again yoiu could just play with the parameters until you find something you like completely ignoring whether parts of the "correct" result are missing or not ;) Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: Timeroot on February 14, 2010, 01:19:00 AM Hey, that's pretty interesting. I have a question though: you said that for the Sierpinski tetrahedron, you can determine which transform to apply simply based on the nearest vertex. Wouldn't this just give four points, in the end? Don't you need to vary the transform randomly in order to get all the details? Me is confused... ???
Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: David Makin on February 14, 2010, 01:44:21 AM Hey, that's pretty interesting. I have a question though: you said that for the Sierpinski tetrahedron, you can determine which transform to apply simply based on the nearest vertex. Wouldn't this just give four points, in the end? Don't you need to vary the transform randomly in order to get all the details? Me is confused... ??? No, you don't have to do anything random, nor compute an entire IFS tree for each point. Remember this is using the escape-time method, so we're starting with a point and saying "is this point on the fractal ?" by finding the first transform to use for the start point, which gives us a new poiint for which we again find the transform to use and so on - so every start point will have a very different iterated sequence. Each point on the attractor has a "genetic code" of the transforms used to get there using the contractive methods, what we're doing here is attempting to decode that genetic code by going in the reverse (expanding) direction, if the point is truly part of the attractor then the correct genetic sequence will repeatedly take us to other points on the attractor, if the point is not on the attractor than no matter what sequence we use eventually we'll bailout - also the further from the attractor the point is then the sooner we'll bailout. The important (and potentially problematic) part is the identification of the correct transform area/volume occupied by the point at each stage which gives us the next transform in the sequence. Two general methods are to identify the fundamental point attractors of the transforms concerned and either just use the nearest of these as a guide to the next transform, or to create cutting planes based on these to separate the areas/volumes (a bit like a BSP tree) but neither of these will work perfectly for all transforms - in particular not for those with rotations. Any ideas of how to better (and efficiently) find the correct transform volume for a given point would be appreciated (note that simply applying all transforms on each iteration and picking the result with the smallest magnitude is *not* generally much good). Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: Timeroot on February 14, 2010, 02:16:06 AM I think I get it better now. It's basically identical to iterating a general Julia Set, and seeing if it is attracted to anything, or if it stays on the Julia Set. The only thing is that you have different functions which created the Julia Set, and so it's harder to "work backwards". You have to figure out what sequence of transforms created that specific part of the Julia Set. Correct?
Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: David Makin on February 14, 2010, 03:34:19 AM I think I get it better now. It's basically identical to iterating a general Julia Set, and seeing if it is attracted to anything, or if it stays on the Julia Set. The only thing is that you have different functions which created the Julia Set, and so it's harder to "work backwards". You have to figure out what sequence of transforms created that specific part of the Julia Set. Correct? Correct - normally the "correct" Julia for a standard given IFS would be with a seed/constant of zero, changing the constant/seed would effectively be simply modifying all the translations by a set value, but you can actually apply it in the Mandelbrot form as well - in fact in the case of Tom's Mandelbox it's that form that's interesting. Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: David Makin on February 14, 2010, 10:54:12 PM Finally got around to comparing the delta DE method with Hart's method and was pleasantly surprised (I was expecting Hart's method to be both considerably faster and higher quality).
Here are two renders of part of a Sierpinski Tetrahedron: Hart's Method: (http://www.fractalforums.com/gallery/1/141_14_02_10_10_40_47.jpeg) Delta DE (Buddhi's method but using just 2 points per step) (http://www.fractalforums.com/gallery/1/141_14_02_10_10_44_23.jpeg) You can see that the edges are about the same roundness/shininess but the smallest holes are much clearer on the delta DE version. Hart's method took 1min. 3secs. Delta DE took 1min. 45secs. However I tried to adjust the bailout size and closeness on the Hart's method version to match the clarity of the delta DE version but to do this required considerable increase in the bailout size and decrease in the closeness factor and changing this in this way produces pretty much exponential increases in render times - I got a better render but it took well over 3 minutes and still wasn't as clear as the delta DE version. I should also point out the obvious - there's definitely an issue with respect to the shadowcasting, there's not enough shadow on the Hart's method version and possibly too much on the delta DE version - I will be looking into this :) I should add that this sort of holey low dimension fractal is optimum for Hart's method but worst-case for the delta DE method so for fractals that are more solid/of higher dimension the delta DE method will be relatively much better provided it can be applied to them successfully. Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: David Makin on February 21, 2010, 10:23:35 PM I decided to see if application of Tglad's location restricted based rendering (which I suppose originally should be credited to Barnsley for example with the Barnsley types in Fractint) could be used to optimise the rendering of more general IFS.
So I decided to start with the classic Heighway Dragon. Here is a render showing the Heighway Dragon coloured to separate the areas belonging to each of the primary transforms (the last if using convergent rendering, the first if using divergent rendering): (http://www.fractalforums.com/gallery/1/141_21_02_10_7_55_46.jpeg) Clearly we can't really use a simple location method to separate the areas for each of the transforms since the boundary between them is itself fractal in nature, however we could split the plane into 3 sections, an area to the left (transform 2 only), a central area (both transforms possible) and an area to the right (transform 1 only). In this case we could say that transform 1 is needed if x>-0.34 and transform 2 is needed if x<0.167. Rendering on a depth by depth basis rather than traversing the IFS tree we can use this to control which transforms are performed on each iteration and using the above figures we get this result for a bailout radius of 16: (http://www.fractalforums.com/gallery/1/141_21_02_10_9_24_58.jpeg) Clearly we are getting hard breaks in the distance estimates, this is because we have only decided which transforms to use on locations inside the fractal but our colouring is actually outside. Here is a view of the fractal with both inside and outside coloured based on areas belonging to the primary transforms: (http://www.fractalforums.com/gallery/1/141_21_02_10_9_34_53.jpeg) Clearly splitting the plane in the same way means the central area that requires both transforms to be performed is much larger. Re-rendering using the new locations corrects the DE: (http://www.fractalforums.com/gallery/1/141_21_02_10_8_15_30.jpeg) In case you're wondering why use such a large bailout value, here's the problem if you use the smallest possible bailout: (http://www.fractalforums.com/gallery/1/141_21_02_10_8_01_40.jpeg) As you can see the distance estimation is split at the iteration boundaries, this is because that although our bailout radius (here 1.36) is large enough to contain the whole fractal so inside/outside is rendered correctly the magnitude is insufficient for correct distance estimation because the second level bailout spheres overlap the primary bailout sphere and a larger bailout is required to reduce/prevent this problem. I then thought that maybe doing a limited resolution pre-render to a square of side 2*bailout radius storing the information about which point belongs to which transform may be useful (such that if pixel 1 belongs to transform 1 first then all pixels in the associated 3*3 pixels are flagged as belonging to transform 1 and the same for transform 2 i.e. so boundary pixels could use both transforms). This worked very well and is in fact by far the fastest rendering method. Here is a test UPR which includes my test formula (copy the whole lot and paste into an open fractal window in UF: Code: IFStransforms {Here is a UPR to compare the different rendering methods (needs the formula from the UPR above so paste that lot into UF first): Code: IFSde {Timings on my machine for the individual test layers in the above: Original traversal of the entire tree: 6 mins 36 secs Depth by depth complete: 4 mins 59 secs Depth by depth Location restricted: 1 min 40 secs Depth by depth Pre-render restricted: 25 secs The key thing is obviously to reduce the area that requires more than one transform/path on each iteration - this manifests itself in my test formula as the array size required to avoid errors rendering the "inside" - e.g. try reducing the array sizes on the depth by depth layers and you'll see the problem. Obviously the low-resolution pre-rendered map method is best but it does suffer from problems e.g. extremely thin/small transform areas may get missed and there would definitely be memory issues for applying it in 3D - here a 256*256 pixel pre-render is no problem but 256*256*256 is starting to get a little large :) Edit: I should add that the depth-by-depth methods are by no means fully optimised - for instance changing the array storage to a linked list method sorted by magnitude would probably help a lot :) Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: Timeroot on February 22, 2010, 02:50:03 AM Wow, this is sounds really interesting... I hope you help a noob like me understand it:
1) - What do you mean, "depth-by-depth"? 2) - I don't understand what the third image, with the irregular split, is supposed to represent. Is it some other way of splitting of the transforms? 3) - What's the difference between "Depth-by-depth complete" and "Depth-by-depth Location restricted"? For the pre-render, you mentioned that memory usage could become an issue, especially in 3D. Would it be possible to just store certain "boundary points", and then if a point in question lies on one side of the area between some boundary points, and with a small margin away, a certain transform would be used, otherwise it uses both? That is, just storing the surface instead of the entire area? :hmh: :hmh: :hmh: :hmh: Please help baffled... Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: David Makin on February 22, 2010, 04:09:57 AM Wow, this is sounds really interesting... I hope you help a noob like me understand it: 1) - What do you mean, "depth-by-depth"? 2) - I don't understand what the third image, with the irregular split, is supposed to represent. Is it some other way of splitting of the transforms? 3) - What's the difference between "Depth-by-depth complete" and "Depth-by-depth Location restricted"? For the pre-render, you mentioned that memory usage could become an issue, especially in 3D. Would it be possible to just store certain "boundary points", and then if a point in question lies on one side of the area between some boundary points, and with a small margin away, a certain transform would be used, otherwise it uses both? That is, just storing the surface instead of the entire area? :hmh: :hmh: :hmh: :hmh: Please help baffled... 1. The "usual" method of doing escape-time IFS involves traversing the entire IFS tree for each point by stepping down the tree until either bailout is reached or we get to a certain depth (or overall scale factor). If we hit bailout first then we step back up the tree by one depth and try the next transform and so on, stepping back up the tree to higher branchings each time we hit bailout and have done all transforms for that branch at that depth - obviously in this case if we hit max depth/greatest overall scale then the point is "on" the fractal. That method works quite well but doesn't lend itself to applying the location restrictions - for that we need to start with the point to test and apply all applicable transforms on the first iteration giving us up to n new poiints where n is the number of transforms, then on the second iteration we repeat the process for all the points generated from the first iteration. Obviously as soon as one of these points bails out we do not pass it on to the next iteration. The problem with this method is that if not enough points bailout and many transforms need to be applied on each iteration then our number of points can grow exponentially though of course location restriction reduces the number of required transforms for a given point on a given iteration. 2. The third image is a zoomed out map of which pioints belong to which primary transform's area including those points that are "outside" in this case the area belonging to transform 1 (on the right) is all one colour but I've coloured the area for transform 2 so that the "inside" and "outside" are different colours - the rather small area shows you the "inside" area for transform 2 (compare with the first image to get an idea of scale). When I say the "outside" area belonging to a given primary transform I mean the area where the highest iteration bailout (with the lowest bailout magnitude) had that transform as it's primary. 3. "Depth by Depth complete" applies all transforms to the current array of points for a given iteration passing all the ones that don't bailout on to the next iteration. "Depth by depth location restricted" (and pre-render resricted) restrict the number of transforms for each of the points in the current array depending on each point's location thus reducing the number of points passed on to the next iteration. Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: David Makin on February 22, 2010, 04:42:39 AM For the pre-render, you mentioned that memory usage could become an issue, especially in 3D. Would it be possible to just store certain "boundary points", and then if a point in question lies on one side of the area between some boundary points, and with a small margin away, a certain transform would be used, otherwise it uses both? That is, just storing the surface instead of the entire area? :hmh: :hmh: :hmh: :hmh: Please help baffled... You could limit the storage required in some way but the only way to do a really quick look-up test to decide the transforms to use for a given point is a complete set of flags indicating required transforms for the whole area within bailout - I can't really see a method using just boundary points that would work in a general case - consider Barnsley's ferns for instance, they usually have many areas of overlap so I think a complete area map is the only efficient generic method to use. Obviously specific cases are simpler, in fact for a Sierpinski carpet or Menger Sponge then simple coordinate testing would obviously be the optiimum method. I'm trying to develop a generic method that I can both make as "black-box" as possible and that will even work when some transforms are non-affine, though I'm considering abandoning the black-box idea in favour of making the location tests part of the actual user-parameters for the fractal i.e. a type where the user specifies location control as well as the transforms - that would be far easier from the formula author's point of view ;) Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: David Makin on February 24, 2010, 02:49:01 AM First results based on Tglad's method used for location-restricted-IFS (both a distorted Sierpinski Octahedron):
"Sierpinski Sponge" (http://fc01.deviantart.net/fs71/f/2010/054/0/1/Sierpinski_Sponge_by_MakinMagic.jpg) If no image above then look here: http://makinmagic.deviantart.com/art/Sierpinski-Sponge-155198251 (http://makinmagic.deviantart.com/art/Sierpinski-Sponge-155198251) "Sierpinski Stone" (http://fc02.deviantart.net/fs70/f/2010/054/e/6/Sierpinski_Stone_by_MakinMagic.jpg) If no image above then look here: http://makinmagic.deviantart.com/art/Sierpinski-Stone-155198492 (http://makinmagic.deviantart.com/art/Sierpinski-Stone-155198492) They were produced with a very basic addition to my wip3D formula that only allows up to 6 transforms with just translation and scaling and decides which transform to use based on the nearest translation location, I'm hoping to expand the method and release an update at the weekend though I doubt I'll be adding rotations for now. Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: kram1032 on February 24, 2010, 03:27:26 PM that first image looks a lot like a 2D-Version of some of the 1D-cellular automata :)
Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: David Makin on February 24, 2010, 09:57:53 PM Another one, still just a distorted Sierpinski Octahedron:
(http://fc06.deviantart.net/fs70/f/2010/055/4/b/The_Complex_by_MakinMagic.jpg) If no image above then look here: http://makinmagic.deviantart.com/art/The-Complex-155249983?loggedin=1 (http://makinmagic.deviantart.com/art/The-Complex-155249983?loggedin=1) Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: Timeroot on February 25, 2010, 01:17:07 AM that first image looks a lot like a 2D-Version of some of the 1D-cellular automata :) Considering that the Sierpinski triangle can be generated using 1-D cellular automata, I actually bet you could make something like that. I wonder if anyone has a program for generating the 2D-cellular automata. It would certainly look cool.... O0Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: David Makin on February 25, 2010, 04:06:03 AM Here's another test - I added analytical DE for these IFS fractals:
http://www.fractalforums.com/index.php?action=gallery;sa=view;id=1742 (http://www.fractalforums.com/index.php?action=gallery;sa=view;id=1742) Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: kram1032 on February 27, 2010, 07:27:52 PM WOW, great octahedral stuff :D
Looks nice'n smooth and stull fractal :D And @ 2D-cellular automata: Well, there are hundreds of 2D-cellular automata but I never saw one which is basically the direct extension of the 1D ones an maps time to the 3rd dimension.... Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: David Makin on March 02, 2010, 03:05:53 AM Hi all,
My wip3D5 formula for UF now includes "Simple Sierps" under the Mandelbulb/Juliabulb option (here due to the architecture of the formula). The "Simple Sierps" options allow Location Restricted escape-time IFS based on Tglad's fractal type. http://www.fractalgallery.co.uk/MMFwip3D.zip (http://www.fractalgallery.co.uk/MMFwip3D.zip) Edit: Formula updated to include better colouring options. The main formula itself now features a "Lighting + Orbits" option which allows true 3D orbit trapping plus a "genetic" based colouuring option for Tglad's Mandelbox and for the "Simple Sierps" (ifs) method. At the moment it's plain IFS with uniform scaling plus translation only but I'm working on a much more comprehensive formula incorporating most possible escape-time fractal types in one (as conditionally applied transforms). Here are some examples using the "Simple Sierps" formula option: A Menger Sponge: Code: QuickMengerSponge {Sierpinski Tetrahedron: Code: QuickSierpinskiTetrahedron {Sierpinski Octahedron featuring fogging: Code: QuickSierpinskiOctahedron {A Box Plant: Code: BoxPlant {Note that the Box Plant example shows how location restriction can be used to control the IFS - on transform #13 the "relative radius" is set to 2.75 to thin out the foliage. The "correct" value would be 1.5 but that produces a rather solid result :) Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: M Benesi on March 02, 2010, 03:45:20 AM David,
Do you mind posting the math (can't read what you posted) for your Menger Sponge algorithm? I'm hoping (from what you've said) that it's more along the lines of Msltoe's radius formulas (similar to Tglads Mandlebox formulas) instead of the standard algorithms: I've made 3d Cantor Dust, but no sponge. :( Whatever the answer, thanks for the work you put into these various formulas. Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: David Makin on March 02, 2010, 04:03:03 AM David, Do you mind posting the math (can't read what you posted) for your Menger Sponge algorithm? I'm hoping (from what you've said) that it's more along the lines of Msltoe's radius formulas (similar to Tglads Mandlebox formulas) instead of the standard algorithms: I've made 3d Cantor Dust, but no sponge. :( Whatever the answer, thanks for the work you put into these various formulas. It's actually very straightforward: We define the 20 transforms for the sponge i.e. at the centres of the relevant cubes with a uniform scale of 3 each. In the iterative loop we then check the distance of the current "z" locaton from the centre of each cube and choose the transform for which the centre is closest to z and then use the values from that transform for that iteration i.e. loop: Find nearest centre/transform compute new z = transform scale*(z - transform centre) until |z|>bailout || numiter>maxiter Actually I also add the normal "constant" value to each new z - but for the plain original sponge you need the Julia form with a constant of (0,0,0). The distance estimate is simply the final z magnitude divided by the total scale which for the Menger is simply magnitude/(3^numiter). Obviously it's pretty simple to adapt the above for more general IFS, though my implimentation sticks to uniform scaling and a translation per transform only. Adding non-uniform x/y/z scales is feasible I think but adding rotations is another matter. You should note that for the Menger Sponge using Hart's method of interesecting the transformed viewing ray with a bounding sphere and/or cube is both faster and cleaner - though this method (with the analytical DE) does appear to be faster for the Sierpinski octahedron and tetrahedron, and of course allows the possibility of mixing affine and non-affine transforms which is not possible using Hart's method. Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: M Benesi on March 02, 2010, 08:05:15 AM Thanks David,
I'm still having a problem, however. I check my 7 knockoff points (center, 6 other cubes to remove), subtract their corresponding values and end up with this pseudo-Sierpinski octahedron instead of a Menger sponge: (http://lh5.ggpht.com/_gbC_B2NkUEo/S4yyRaGXFpI/AAAAAAAAAEU/TZ6krDxNOUY/octahedron.jpg) Matt Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: David Makin on March 02, 2010, 01:04:53 PM Thanks David, I'm still having a problem, however. I check my 7 knockoff points (center, 6 other cubes to remove), subtract their corresponding values and end up with this pseudo-Sierpinski octahedron instead of a Menger sponge: Matt No - use the other 20 cubes, not the 7 empty ones - as you show using the 7 empty ones can give a Sierpinski Octahedron with a copy of itself in the centre (and in the centre of every sub-octahedron) :) (I assume you used scales of 2 instead of 3 in that render ?) Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: M Benesi on March 02, 2010, 11:59:09 PM Doyyyy <-- wish I could include a bouncing noise in the spelling of that word
Thanks! I just dropped in to see is you had answered. I'll try that out after dinner. Sheesh, and I was wondering where you got the number 20 from. Hilarious. :D Scale was 2, as you said. Just checked it. Bailout of 2, and simple bail check value of |x| + |y| + |z| (crisps it up a bit, instead of the rounded images we get with x^2+y^2+z^2), although it may be better to do a more complex check. David- I end up with a Sponge in the center of my sponge: a Beavis and Butthead tattoo scenario. Going to check my formula. Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: fractalrebel on March 03, 2010, 12:41:38 AM Dave,
Your applications of MMFWip3D are really cool! Great stuff. Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: David Makin on March 03, 2010, 02:08:33 AM David- I end up with a Sponge in the center of my sponge: a Beavis and Butthead tattoo scenario. Going to check my formula. I'm guessing you've got 21 transforms instead of 20 i.e. you've left in the central cube :) Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: David Makin on March 03, 2010, 02:10:00 AM Dave, Your applications of MMFWip3D are really cool! Great stuff. Thanks Ron. I wish I had more spare time - my class-based version is not progressing very quickly :( Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: M Benesi on March 03, 2010, 08:42:36 PM David- I end up with a Sponge in the center of my sponge: a Beavis and Butthead tattoo scenario. Going to check my formula. I'm guessing you've got 21 transforms instead of 20 i.e. you've left in the central cube :) It's 20 transforms (checked it: no central checkpoint (0,0,0), 20 transforms). I could set it up to remove the central cube (if the pixel values are within the central cube, set my bail comparison variable to max_bailout+1) but that seems like cheating (it isn't, but if you got it with the 20 transforms, I should too). Haven't found a nice bail point either. It's a whole recursive set within the set, within the set, within the set, within the set (which technically makes it something other than a Menger Sponge)... Doyyyy <bouncing sound effect added> : in mid message, I decided to check my initial radius check, which was set too low. Incidentally, if you decide you want an infinitely recursive Menger Variant, set your initial radius checkpoint low. If you haven't done it yet, setting bailout up this way (instead of magnitude bailout check) gives you a much crisper sponge: if ( |sx|>|sy| && |sx|>|sz| ) // sx, sy, and sz values are the names of my x, y, and z post-calculation values { bail=|sx|;} // I check to see which has the highest absolute value, and set bail on that else if (|sy|>|sz|) // if I haven't hit my iteration limit { bail= |sy|; } else { bail= |sz|; } // the whole concept is: if one of the values is outside of the sponge, bail out man! with your code: until bail>bailout instead of until |z| >bailout With a sponge of "pseudo-volume" of 3^3 (3 is side length), I set bail check variable to 1.5 (side length/2) for a perfect Menger sponge: (http://lh6.ggpht.com/_gbC_B2NkUEo/S467bqWhg-I/AAAAAAAAAEc/3Hdd4wV-_Hw/menger.jpg) <-- and I was all like "I M G !!!! /I M G" Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: David Makin on March 03, 2010, 08:53:01 PM David- I end up with a Sponge in the center of my sponge: a Beavis and Butthead tattoo scenario. Going to check my formula. I'm guessing you've got 21 transforms instead of 20 i.e. you've left in the central cube :) It's 20 transforms (checked it: no central checkpoint (0,0,0), 20 transforms). I could set it up to remove the central cube (if the pixel values are within the central cube, set my bail comparison variable to max_bailout+1) but that seems like cheating (it isn't, but if you got it with the 20 transforms, I should too). Haven't found a nice bail point either. It's a whole recursive set within the set, within the set, within the set, within the set (which technically makes it something other than a Menger Sponge)... Doyyyy <bouncing sound effect added> : in mid message, I decided to check my initial radius check, which was set too low. Incidentally, if you decide you want an infinitely recursive Menger Variant, set your initial radius checkpoint low. If you haven't done it yet, setting bailout up this way (instead of magnitude bailout check) gives you a much crisper sponge: if ( |sx|>|sy| && |sx|>|sz| ) { bail=|sx|;} else if (|sy|>|sz|) { bail= |sy|; } else { bail= |sz|; } <-- and I was all like "I M G!" Since I'm using distance estimation I'm not sure if using bailout to a cube would be of any help - I do have that option in my "3D IFS" formula which uses Hart's method - that's actually faster for rendering the sponge anyway. Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: M Benesi on March 03, 2010, 09:24:22 PM I've never implemented DE, nor do I know what "Hart's method" is... suppose I should find it somewhere.
ChaosPro does use a built in bisection algorithm, which seems to do a nice job, although some form of DE might be nice. Do you get the crisp cubes with the DE method or are they the slightly "bubbly" looking cubes? Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: David Makin on March 04, 2010, 02:52:27 AM I've never implemented DE, nor do I know what "Hart's method" is... suppose I should find it somewhere. ChaosPro does use a built in bisection algorithm, which seems to do a nice job, although some form of DE might be nice. Do you get the crisp cubes with the DE method or are they the slightly "bubbly" looking cubes? You get crisp renders at smaller DE thresholds - here's a render with threshold 1e-3: (http://www.fractalforums.com/gallery/1/141_04_03_10_2_50_17.jpeg) That render took 1 min 3 secs on this heap-o-junk, equivalent to around 21secs on a 2GHz core2duo. Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: M Benesi on March 06, 2010, 02:03:53 AM That DE version looks plenty 'crisp' (no different from a similar 6 iteration one I did to compare). The time to calculate appears to be pretty similar (accounting for our different cpus: I'm using a 2 gigahertz core 2 duo).
Depending on what settings I use it either takes (exactly what you said according to ChaosPro's internal timer.. weird) 21 seconds for normal background detection, down to ~11.312 seconds for extremely soft background detection (no clipping occurs for the extremely soft setting, so it can apparently be used for the Menger Sponge). Anyways, thanks for helping me with the formula. Whenever I find a good freeware compiler I might ask for help with DE, unless I figure it out simply by reading your older posts. Title: Re: Tglad's Mandelbox and using the delta DE methods for RIFS Post by: David Makin on March 12, 2010, 10:10:03 PM I have now added an extra "Lighting + Orbits" method to the colourings in the mmfwip3d formula (wip3D5). This allows full-3D based orbit trapping for any of the formula types plus the option of using "genetics" based colouring for the "Lowe's Mandelbox" and "Simple Sierps" formulas (as suggested by Tglad). Link to formula is above: http://www.fractalforums.com/3d-fractal-generation/tglad%27s-mandelbox-and-using-the-delta-de-methods-for-rifs/msg13560/#msg13560 (http://www.fractalforums.com/3d-fractal-generation/tglad%27s-mandelbox-and-using-the-delta-de-methods-for-rifs/msg13560/#msg13560) |