the simpliest naive bruteforce code for mandelbulb

[richardrosenman]

Thanks for those tips, Jason & David!

I will be working with my code this weekend and adding your suggestions. I have already implemented the orbit trap shading and yes, it is quite a bit nicer than before. Thank you for that! I'll post an example asap.

Can I ask about your light sourcing and specularity? Any good suggestions for code examples / theory for this? I know there must be a ton on here but I'm looking for a *really* simply explanation. Do surface normals need to be calculated for specularity?

Asimes: Yours is coming along nicely too. Let's try to figure out the rotation together as this is something I also need to put in next... Nothing like a couple of newbies (one being an artist who can't think in numbers) trying to figure out computational algebra and trigonometry together...

-Rich

[David Makin]

Bailout of 4 is fine for the DE method from this thread.  Larger than 4 tends to smooth out the surface and will lose details.

That's simply incorrect unless you're not using enough iterations to actually reach a consistent DE value as the solid surface - of course if you're using a particular iteration level as the solid surface then that's a different matter but will never give the consistent detail that using the DE as the solid threshold will achieve.

[David Makin]

Can I ask about your light sourcing and specularity? Any good suggestions for code examples / theory for this? I know there must be a ton on here but I'm looking for a *really* simply explanation. Do surface normals need to be calculated for specularity?

Normals are required both for diffuse and specular if implementing such....the guy to ask about lighting is lycium:

http://www.fractalforums.com/index.php?action=profile;u=87

He's always correcting me anyway (my textbooks are a little old).

[David Makin]

That's simply incorrect unless you're not using enough iterations to actually reach a consistent DE value as the solid surface - of course if you're using a particular iteration level as the solid surface then that's a different matter but will never give the consistent detail that using the DE as the solid threshold will achieve.

Just to add that to get more detail *and* more accuracy even when using a given iteration boundary as the "solid" surface then it's still better to increase the bailout but to keep the detail you have to increase the "solid" iteration level appropriately.
This means that for z^2+c to use a bailout of 16 (for sqrt(x^2+y^2+z^2) compared to using 2 then you need to increase the surface iteration count by just 2 since 1 extra iteration is required for a bailout of 4 (==2^2), and 2 for 16 (==(2^2)^2), 3 for 64 etc. - so for the suggestion I gave (32) then increasing the surface iteration threshold by 3 would actually result in more detail *and* more accurate DE at the cost of around 3 iterations per loop.

[Syntopia]

Can I ask about your light sourcing and specularity? Any good suggestions for code examples / theory for this? I know there must be a ton on here but I'm looking for a *really* simply explanation. Do surface normals need to be calculated for specularity?

The Phong model is very common and is probably a good staring point: http://en.wikipedia.org/wiki/Phong_reflection_model

[asimes]

Softology, mixing the orbit color with the ray marcher looks great, thanks.

I'm beginning to think that my sketch is just not set up for rotation. The part of the sketch that still somewhat alien to me is the "dr" part. However, it seems to only be affected by 'z', maybe if I had it be affected by 'y' it would give me a top down point of view but I don't know about arbitrary rotation. Any suggestions?

[asimes]

I finally figured out how to view it from a 90 degree rotated angle (now it seems obvious). I just swap the 'y' and 'z' values for the Mandelbulb code as the initialization to 'ny' and 'nz' as well as when adding to them during the while loop. Still not sure about arbitrary rotations, would I need to shoot the rays separately from the 'x', 'y', 'z' triple loop or is there a clever way to include it?

Here's a result (purely ray marching, no orbit trap color):

[ker2x]

congratulation 

[David Makin]

Softology, mixing the orbit color with the ray marcher looks great, thanks.

I'm beginning to think that my sketch is just not set up for rotation. The part of the sketch that still somewhat alien to me is the "dr" part. However, it seems to only be affected by 'z', maybe if I had it be affected by 'y' it would give me a top down point of view but I don't know about arbitrary rotation. Any suggestions?

For complete implementation of rotation you need to consider a viewpoint firing rays through each pixel of the screen (a flat plane) the centre of which is a fixed distance from the viewpoint and such that the plane is perpendicular to the central ray.
Then to change views you can simply transform each "pixels" coordinate from the position in the flat (screen) plane e.g. (+/-0.5,+/-0.5) or (
+/-1,+/-1) to a coordinate in 3D space based on the location of the viewpoint and the location/orientation of the viewing plane.
For each pixel you then have the viewpoint (vx,vy,vz) and the pixel's coordinate (px,py,pz) so for that pixel you compute (px-vx,py-vy,pz-vz) and then normalise this vector which gives a unit direction vector say (dx,dy,dz) for stepping along the ray.
The start position for the ray-stepping could be the viewpoint but often a near-cutting plane is used and in such a case you simply intersect the ray that starts at (ox,oy,oz) in direction (dx,dy,dz) with this near cutting plane and use the resultant point as the start point for stepping for that pixel.
Of course the above is for perspective projection and the closer the viewing plane (screen) is to the viewpoint then the widerthe field of view (or the smaller the camera with respect to the fractal if you prefer).