Welcome to Fractal Forums

does orbit trap is possible in M3D like FractalScience Kit for example ?
Thx
ERIC
chaospros is "old" but look sphere tesselation+kleinian group

Cool thing, I never tought, it can be done there. Could you explain, how did you do it in Chaos Pro. Maybe you should explain in Chaos pro section.

not really relevant to m3d but check this out (http://www.iquilezles.org/www/articles/orbittraps3d/orbittraps3d.htm).

orbit trap is the base for KLeinian group see arXiv.org
in Chaoos pro a new paro do this seen's 2 or 2 days
in 3d it s impossible for the moment but on day ! do you see the like with M3d
for more expication see  http://arxiv.org/pdf/1206.0087.pdf 
or http://arxiv.org/pdf/0707.2427v3.pdf
the 2nd is the most  important
ericr

they suck at writing abstracts. not reading it :fiery:

I am french and not vrey god at englih but I do it because ist important
inside is the solution of kleinian group 3d
To be easy orbit  trap = set limit =attractor like lorenz's on

Maybe not all suggestions belong to m3d, but if so you have to consider that the program has to calculate distance estimates to get use of the formula, that makes many formulas not work unfortunately  :sad1:

For example the neat orbit trap pictures were rendered with a voxel-based renderer, and i think that there don't exist distance estimates for this kind of formulas, if so please correct me.  :)

Hi Jesse - it is possible to get DE estimates for solid based on orbit trap values but AFAIK it's only been done so far by fudging the values individually for each main formula and each orbit trap type.
I think Paul Nylander has rendered some and I allowed the possibility in my formula for UF - it works but is far from optimum and considerably slower than rendering to a DE surface or an iteration surface.

See:

http://makinmagic.deviantart.com/art/Beating-Mandelbrot-125142130
http://makinmagic.deviantart.com/art/Orbit-Trap-Heightfield-128850151
http://makinmagic.deviantart.com/art/Orbit-Trap-Height-Detail-128912127
http://makinmagic.deviantart.com/art/3D-Pickover-Stalks-test-142906488

The first and last rendered relatively quickly so in fact doing this as "normal" 3D fractals is better/easier than doing it in heightfield form - also the only variation from standard DE is essentially to replace the DE calculation with the orbit trap calculation.

Hi David,


 :embarrass:   it is often more easy than i thought of, lol.

Thanks again, looks like a good additional option to play with...

 It is possible   to do that ?, it would be great !
ericr

The tricky part is that AFAIK there is no algebraic method to get a true distance estimate for general orbit traps - and every single type (formula+trap) is quite likely to require different fudging to get an approximately linear distance estimate.

Ok, so its not really that easy and my first tests were also not that promising as i thought of... was not able to get a really working DE from scratch for a standard bulb and the resulting structures were also somewhat disappointing.
Must read a little more on the math to get the points...

If it helps I didn't check up on any math basically as I didn't think there'd be anything relevant (at least not below phd level) so I rendered using the brute force method - extremely small steps but only a small image (640*480) and had the program store information relating to the change in orbit trap distance values - from that info I worked out the fudge, it worked quite well for the image and animation I posted but the error in estimation is around a magnitude larger than for standard DE so obviously step sizes have to be reduced accordingly - e.g. with analytical DE one can get away with say 0.75*DE on each step, with Buddhi's method around 0.5*DE but to render orbits accurately needs around 0.1*estimate or smaller.

As for structures being disappointing - don't use a simple point trap that will be fairly mundane - try say a trap to line...

or menger sponge )

and now ?

On 3D Kleinian groups see http://www.josleys.com/show_gallery.php?galid=346 (http://www.josleys.com/show_gallery.php?galid=346) and this article (in French!)  http://images.math.cnrs.fr/Les-ensembles-limites-de-groupes.html (http://images.math.cnrs.fr/Les-ensembles-limites-de-groupes.html).

I have not been able to come up with a way of drawing these things using a DE. What I need to do is calculate the positions of the centers, and the radii of thousands of spheres.

now something completely different  :dink:

Orbit trap did not worked as expected, to bad.

But volumetric light should be also a good option for more variety in images, but this is also much work...

does anyone know a replacement for the trigonometric polar coordinate mapping for the volumetric lightmap?

Because this is for CPU the current bottleneck as it seems, for every little step a arctan2 and arccos calculation slows it very much down  :-\

So i thought there might be an alternative mapping technic to transform a fullsphere vector into a 2d map, the reverse transformation can be more time consuming because it is only performed once for each pixel.
Hmm, for partly maps (lightsource is in far distance), the function becomes more flat anyways...

Maybe cube mapping?

http://en.wikipedia.org/wiki/Cubemap

What about simply using lookup-tables for the acos and atan?

You could also precalculate two 2D textures, indexed the x and y component of a (normalized) ray direction. Since the z-component only is determined up to a sign, you would need two maps, one for positive z, and one for negative z. But I'm not sure how distorted this transformation is.


Also a good suggestion, since they probably introduce less distortion. I just checked, and you don't need trigonometry to lookup in these - there is a nice example of (CPU) cubemaps here: http://www.codermind.com/articles/Raytracer-in-C++-Part-III-Textures.html

Yes, cube mapping looks nice..

i think the optimal solution would be to calculate the needed viewing frustrum for the lightsource into the scene and compute a rotation matrix to center it to one side of the cube.
In case the frustrum is below 90 degrees this cubes side could be stretched by a factor, and in case bigger 90 degrees you could calculate the needed fractions of the surrounding cube sides, so you dont have to calculate more than needed.

you want to do things for rendering fractal as Incendia EX  for example ?
that is it.
ericr


MC render is SUBLIME

there is very simple atan approximation (Pi / 2) * x / (1 + abs(x)) - fast but nowhere near precise. for something more precise, check this out:

Thank you, i might find some use for it.
Since the memory usage for the map, a lookup table as Syntopia mentioned would have done it here also, the speedup for a arccos LUT was very good as i tested it...
already changed to cubemap now.

Just a small point relating to the Kleinians - it struck me quite awhile ago that one way to at least create something similar using DE is to use escape-time IFS - one needs something that produces circles or spheres (e.g. z^2+0) plus appropriate linear transforms.
So far I've only tried it in 2D and did this very simple example:

(http://fc04.deviantart.net/fs44/f/2009/145/5/7/Pure_Julia_IFS_by_MakinMagic.jpg)

http://makinmagic.deviantart.com/art/Pure-Julia-IFS-123685891 (http://makinmagic.deviantart.com/art/Pure-Julia-IFS-123685891)

Thinking about it one could of course also use the base object + IFS method (as per Dragon trees) to get the same result if you just want spheres ;) As in:

(http://nocache-nocookies.digitalgott.com/gallery/13/141_25_01_13_2_07_57.jpeg)

http://www.fractalforums.com/index.php?action=gallery;sa=view;id=13260 (http://www.fractalforums.com/index.php?action=gallery;sa=view;id=13260)

But with spheres instead of cylinders.

I realise there are no spirals in the above but that just needs the addition of some rotations ;)

only on example Chaospro 4.0
very simple to do with it