Logo by Trifox - Contribute your own Logo!

END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

it was a great time but no longer maintainable by c.Kleinhuis contact him for any data retrieval,
thanks and see you perhaps in 10 years again

this forum will stay online for reference
News: Support us via Flattr FLATTR Link
 
*
Welcome, Guest. Please login or register. March 19, 2024, 10:08:43 AM


Login with username, password and session length


The All New FractalForums is now in Public Beta Testing! Visit FractalForums.org and check it out!


Pages: 1 ... 34 35 [36] 37   Go Down
  Print  
Share this topic on DiggShare this topic on FacebookShare this topic on GoogleShare this topic on RedditShare this topic on StumbleUponShare this topic on Twitter
Author Topic: True 3D mandelbrot type fractal  (Read 601642 times)
0 Members and 5 Guests are viewing this topic.
LionHeart
Explorer
****
Posts: 46



« Reply #525 on: November 19, 2009, 03:23:56 AM »

I must have a play with some of these equations and if I can figure it out, add them to my program ManpWIN.

Thanks to everyone who contributed to this most interesting thread.

Paul the LionHeart
Logged

Paul the LionHeart
ZsquaredplusC
Guest
« Reply #526 on: November 19, 2009, 04:48:30 AM »

Hello all.  Very interesting progress so far.

Twinbee...  any chance of you extending your article so it has a page 3 titled "for coders" or something similar?  ie, a pseudo code structure for someone wanting to try these formulas out who is more programming inclined rather than mathematically inclined.

Assuming that the reader has a basic raytracer or raymarcher coded up and have the ability to have a ray starting from the "camera" and know the "direction" the ray is going, then you step a certain amount along the ray and repeatedly try the mandelbulb formula to see if the point is inside or outside the set and plot the point in 3D space accordingly.

The basic code would be along the lines of

for y=1 to bitmapheight do
begin
      for x=1 to bitmapwidth do
      begin
             <calculate vector of ray direction from camera to pixel location in 3d space>
             <now we have the starting point in XYZ coords (this would be the bitmap XY coordinate converted to XYZ space in 3d)>
             <feed the point XYZ into distance estimator>
             <test point returned from distance estimator by iterating it through the iteration loops>
             if ((x^2+y^2+z^2)>4) or (iterations>256) then giveup  else XYZ is a valid point so raytrace the point
     end
end


Questions...  huh?
1. The z triplet and c triplet both have 3 xyz parameters
2. So Z starts as (1,0,0) and C starts as (X,Y,Z) when iterating the formula?
3. Does the distance estimator calc happen while the iteration happens?
4. Am I on the right track?

It would also be nice to have a series of "DistanceEstimatorNylander" "IterateNylander", "DistanceEstimatorMakin" "IterateMakin" snippets of code depending on who first came up with the idea.  Looking back over this thread shows many attempts that may not be the true 3d mandelbrot type, but never the less result in interesting results.  It would be great to have some info along the lines of "the above picture uses the following formula by whoever" and have the relevant snippet/change in code for distance estimation and iteration.

Or even a basic sample code for distance estimation and iteration of the now classic ^8 result.  Enough to get the basic framework going and have a play with these sort of images.

Keep going regardless guys.  There is some great results in this thread so far.
Logged
s31415
Conqueror
*******
Posts: 110



WWW
« Reply #527 on: November 19, 2009, 05:34:08 AM »

Hi,

Just some questions and comments, which may already have been discussed, I didn't have the courage to go through the 36 pages of comments.
I looked into the squaring formula described there:
http://www.fractalforums.com/3d-fractal-generation/true-3d-mandlebrot-type-fractal/msg4109/#msg4109
I think that up to basic trigonometric identities and a parity transformation (multiply every coordinates by -1), it boils down to:
newx = r^2 * cos(2*yang) * cos(2*zang);
newy = r^2 * cos(2*yang) * sin(2*zang);
newz = r^2 * sin(2*yang);
What basically says that you square the radius and multiply both spherical coordinates by 2. So first question:
- Is the inversion necessary? What happens if you drop it and use the formulas above instead?
With both the formulas above and the original ones, the complex plane is embedded as the plane slicing the sphere through the equator, so we recover the standard M-set there. Note that (also in both cases) a neighborhood of the north pole is mapped to a thin band close to the equator, so this transformation is not continuous (unlike complex square operation in 2d). I think you can see the hallmark of this fact in some images.
Now let us look at a meridian circle (ie zang = constant or constant + pi, and take the constant to be zero to keep things simple) and the behaviour of the points living there. A point at yang = 0 will stay there, so the points in the complex plane stay there, that's a good thing. A point with non-zero yang will be mapped to a point with 2*yang until you reach yang = pi/4, which is mapped to the north pole of the sphere. Now something strange happens when you go on increasing yang: the point comes backwards with a value of yang equal to pi - 2*oldyang (because sin(x) = sin(pi-x) ). Intuitively, I would like it to continue past the north pole... So you would need a condition so that when yang is larger than pi/4, zang is switched to zang + pi. So second question:
- Did anybody try this, and if so what are the results?

Keep these impressive images coming! 

Best,

Sam
 
Logged

iq
Guest
« Reply #528 on: November 19, 2009, 08:55:56 AM »

Spy, I think the change of sign was an fix they made to correct the wrong cartesian2polar change of coordinates they were making (same for all those +PI/2 etc you see in the beginning of the thread). I believe most of the latest images in the thread are created with the """correct""" formula (in whatever xyz, xzy system). At leas I'm using the correct version (for the "standard" academic xyz coordinate system). I'm not going to re-post it here, it's just a few pages before this one.
Logged
iq
Guest
« Reply #529 on: November 19, 2009, 08:58:11 AM »

good work JColyer. I can definitely see the effect of the orbit trap, although I guess you can still tune it a bit more indeed. I like the feeling of your rendering, it's different.
Logged
lycium
Fractal Supremo
*****
Posts: 1158



WWW
« Reply #530 on: November 19, 2009, 09:59:38 AM »

oh man, word of this thing has spread so far... it's really incredible (and to think i have a picture of a quadratic 3d mandelbrot on a mug from april last year!). even my (usually uninteresting) google alerts for "ray tracing" are turning up things related to this, it looks like there are a lot of people doing gpu ray tracing of this thing: http://frictionalgames.blogspot.com/2009/11/fractional-fun.html

i'm interested to hear from the experiences of others on implementing this on the gpu. personally i'm seeing less-than-ideal numerical results from the gpu (need a reference cpu implementation), especially in the finite difference normal estimate, and the polynomial versions are also WAY faster than the ones using trig.
Logged

iq
Guest
« Reply #531 on: November 19, 2009, 11:21:10 AM »

cool, the guy links to my site smiley

thing is GPU programming is so simple, and it's so convenient for raytracing and raymarching (few examples here http://www.iquilezles.org/www/material/nvscene2008/rwwtt.pdf, but I know of other 30 works that have been released since them). Basically, you write your code in GLSL which is 90% equal to C, but with already built-in vector types and geometric functions. I usually port my code (like the Z8+C M-set of this thread) back and forth to CPU and GPU in a matter of five minutes, since it's so similar (I´m trying to avoid the word "identical") to regular C monothread programming. As for the numerical precision, for most practical applications the 32 bit floating point arithmetic is enough. You can of course want to zoom deeper in a fractal, but well, you ALWAYS can want to go deeper and that doesn't necessarily make the experience more interesting. Anyway, GPU coding is easy for anybody already using any programing language as C, UltraFractal, Basic, whatever. All this is true for regular simple to medium type of applications (like rendering fractals). More complex things can get a bit more difficult, but not that much really.
Logged
lycium
Fractal Supremo
*****
Posts: 1158



WWW
« Reply #532 on: November 19, 2009, 11:24:26 AM »

to be more specific about the gpu precision issues, they don't support denorms yet and i'm sure this makes a difference for finite difference normal estimation since the subtracted values should necessarily be very close.

of course, ideal would be to get analytic normals; it would be nice if you could post your jacobian matrix for the z8 smiley
Logged

bib
Global Moderator
Fractal Senior
******
Posts: 2070


At the borders...


100008697663777 @bib993
WWW
« Reply #533 on: November 19, 2009, 11:47:47 AM »

Mandelbulb 18th order
Logged

Between order and disorder reigns a delicious moment. (Paul Valéry)
bib
Global Moderator
Fractal Senior
******
Posts: 2070


At the borders...


100008697663777 @bib993
WWW
« Reply #534 on: November 19, 2009, 01:36:17 PM »

<a href="http://www.youtube.com/v/afa7lU_yHy8&rel=1&fs=1&hd=1" target="_blank">http://www.youtube.com/v/afa7lU_yHy8&rel=1&fs=1&hd=1</a>
Logged

Between order and disorder reigns a delicious moment. (Paul Valéry)
JosLeys
Strange Attractor
***
Posts: 258


WWW
« Reply #535 on: November 19, 2009, 01:48:02 PM »

Quote
Now something strange happens when you go on increasing yang: the point comes backwards with a value of yang equal to pi - 2*oldyang (because sin(x) = sin(pi-x) ). Intuitively, I would like it to continue past the north pole... So you would need a condition so that when yang is larger than pi/4, zang is switched to zang + pi. So second question:
- Did anybody try this, and if so what are the results?

I did try this some time ago. The results are not dramatically different.
See these images (low res quick renders) of the degree 8.  
The only difference appears to be that if the point being iterated is allowed to go across the poles, then the bulbs are aligned (see the second image below) instead of staggered..


* 4D_test_niet_over_kop_8.jpg (72.68 KB, 500x500 - viewed 1772 times.)

* 4D_test_over_kop_8.jpg (73.8 KB, 500x500 - viewed 1833 times.)
Logged
flok
Guest
« Reply #536 on: November 19, 2009, 03:36:37 PM »

I calculated the 3d mandelbrot and exported it as a povray-script. Then added a hollow green box around it with some lights. Texture is glass. The results are not by far as stunning as some others i've seen here though.

Logged
JosLeys
Strange Attractor
***
Posts: 258


WWW
« Reply #537 on: November 19, 2009, 04:05:14 PM »

How about four dimensions?

I wondered what we would get on a 3-dimensional sphere. (Note that a normal sphere is two-dimensional : you need just two numbers to pinpoint your position, longitude and latitude)

So for a 3-sphere, we need three angles, like this :

sx=R^(@pow/2)*cos(@pow*mu)+csx
sy=R^(@pow/2)*cos(@pow*ph)*sin(@pow*th)*sin(@pow*mu)+csy
sz=R^(@pow/2)*sin(@pow*ph)*sin(@pow*th)*sin(@pow*mu)+csz
sw=R^(@pow/2)*cos(@pow*th)*sin(@pow*mu)+csw
R=sx*sx+sy*sy+sz*sz+sw*sw
RR=sqrt(R)
mu=acos(sx/RR)
ph=atan2(sy+i*sz)
th=acos(sw/(RR*sin(mu)))

Unless I did something wrong,the results are disappointing. There is a lot less elegant detail to be found. Seems the more we go away from two dimensions, the less interesting. See below the power two and power 8 Mandelbrot sets.
The pictures are orthogonal projections (just omitting the fourth coordinate)


* 4D_test_102b.jpg (55.02 KB, 500x500 - viewed 2167 times.)

* 4D_test_102c.jpg (77.58 KB, 500x500 - viewed 2382 times.)
Logged
fractalrebel
Fractal Lover
**
Posts: 211



WWW
« Reply #538 on: November 19, 2009, 07:37:53 PM »

For those of you interested in rendering the Mandelbulbs and corresponding Juliabulbs in UltraFractal 5, I have just updated the UF database with my latest changes to 3DFractalRaytrace and the plugins for the Mandelbulb and the Juliabulb. I have gotten my gradient function working correctly for the two plugins, which really involved gettiang the correct derivative functions.
Logged

kram1032
Fractal Senior
******
Posts: 1863


« Reply #539 on: November 19, 2009, 07:58:12 PM »

@JosLeys

Spherical Coordinates are 3D. You need only two values to get to any point on the surface. But if you want to have a not-fixed radius (which is the case, here), you have your third dimension wink

Maybe, try to rotate in 4D-style? That might give some nice results...
Though, if you go for 4D, maybe you find a way to unify julia with Mandelbrot (not in the Buddhagram way^^) - that probably will lead to more interesting details, as no artifical extension way has to be done then...

Also, omitting one axis probably might not be the best way... what's about a full 4D -> 2D projection? (Or is that equivalent to dropping an axis?)


As said before, doing that direct conversion from 2D to 3D seems a bit odd...
The Mset lies inside an algebratic vector-space, where new calculation rules apply, which results in that nice shape.
Adding just another axis which does the very same as the second axis, where no correspondance is between the two axes, whill likely destroy details. (Especially on the M²-Set, as that doesn't even have radial symmetries)

In a true extension, all axes would comunicate with each other, I guess...
Quaternionic has the "problem" of 2*4D, rather than the 2*2D in Complex numbers (2* because there are the two real and the two imaginary parts)

Maybe, we could try to develop a small algebra just for that...

for instance...

x*x=-x
y*y=-y
z*z=-z
x*y=z
y*z=x
x*z=y
x*y*z=0

that would be the simplest case I can think of.... (a*b*c=0 to avoid a fourth Dimension being formed,  a, b and c are axial units like i,j and k with the quaternions)

Of course, it's very likely, that this algebra wouldn't hold under any conditions, but for a Mandelbrot-Set, it should be possible to work with smiley

x,y,z are the units from above...

(n*x+k*y+j*z)²+a*x+b*y+c*z =

j²*z^2+2*j*k*y*z+2*j*n*x*z+k^2*y^2+2*k*n*x*y+n^2*x^2*+a*x+b*y+c*z=

-j²z + 2*j*k*x + 2*j*n*y -k²y + 2*k*n*z -n²x + a*x + b*y + c*z

split into the three parts:

nx -> (-n²+2jk+a)x
ky -> (-k²+2jn+b)y
jz -> (-k²+2kn+c)z

not actually toooo hard formulae... they seem to be closely related to the imaginary part of the Mandelbrot, though. If I'm unlucky, this will nearly look like the quaternion variant...

As long as no exponential or stuff is needed, which you'd first have to figure out, this algebra should hold easily...

for instance, x*x*y*z*z*z=x²*y*z³=-x*y*-z*z=-x*y*-(z²)=-x*y*z=0
xn=
x | n is an odd
-x | n is an even

scalars in front of the units simply get extended with the very same rules as always...
Logged
Pages: 1 ... 34 35 [36] 37   Go Down
  Print  
 
Jump to:  

Related Topics
Subject Started by Replies Views Last post
Implementation: 3D mandelbrot type fractal 3D Fractal Generation « 1 2 » steamraven 27 64415 Last post August 21, 2016, 12:13:13 AM
by ironfractal
Re: True 3D mandelbrot type fractal Other / General Discussion shanest 2 26277 Last post November 20, 2009, 03:24:26 AM
by fractalrebel
True 3D mandelbrot fractal (search for the holy grail continues) The 3D Mandelbulb « 1 2 ... 17 18 » illi 260 57194 Last post November 25, 2010, 12:57:55 AM
by cKleinhuis
New fractal type... latest 3d type.. a z^2 for Benoit Images Showcase (Rate My Fractal) M Benesi 0 7431 Last post October 21, 2010, 07:14:00 AM
by M Benesi
My First Mandelbrot...Okay not true. Images Showcase (Rate My Fractal) Zephitmaal 3 8246 Last post January 07, 2012, 04:30:36 PM
by Pauldelbrot

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM
Page created in 0.193 seconds with 24 queries. (Pretty URLs adds 0.011s, 2q)