Welcome to Fractal Forums

Here is Fragmentarium code to generate limit set of 4D hyperbolic reflection groups.

4D hyperbolic reflection group is generated by reflection in a set of hyperplanes in
4D hyperbolic space (H4). In order to form a group, dihedral angles of hyperplanes intersections
have to be integer fraction of pi (pi/n). 

H4 space can be modeled in 4D euclidean space as half space bounded by
3D euclidean hyperplane ("the plane at infinity").
Hyperbolic planes in that model are represented as euclidean 4D hyperspheres
and hyperplanes which orthogonal to the plane at infinity.
This plane at infinity is our usual flat euclidean 3D space. Intersections of 4D hyperplanes
with this plane at infinity are usual 3D euclidean planes and spheres.
We can model the 4D reflection group staying all the time in convenient
3D euclidean space.

"The Limit Set" of reflection group are points of accumulation of action
of the elements of the group at some arbitrary initial point. If we take an initial point
and apply a to it all possible sequence of reflection (infinite set) we
will get a infinite set of points in 3D. Some of the images of the initial
points will be isolated points. But there will be points, which have other points in
arbitrary small neighborhood. Such points can be reached only after applying
an infinite number of reflection.

We are hunting for the set of such points - "The Limit Set".
The code is actually very simple.

The Limits Sets exhibit wide range of varieties.
Just place few lanes and spheres in space and you have new fractal shape.
A example rendering is attached.

Vladimir Bulatov
http://bulatov.org

Thanks for sharing Vladimir!

Looks great, but you need some powerful hardware to run it. On my laptop rendering a single frame takes ~16 seconds. So I'd recommend turning down the preview factor to x4 or something before running it.

I had to downgrade the script from the GLSL version #430, in order to run it - I've attached the modified script, if anyone else with older hardware would like to give it a try.

Btw, Vladimir, is it okay if I distribute your script together with Fragmentarium? I'll of course keep the attribution header at top of the script.

Regards, Mikael.

  That's pretty awesome (math/images).

  Also had this gem in the code:


  :D

Thank you Mikael for optimizing the code. Thank you for your excellent Fragmentariun :-)
I've got NVIDIA GTX670 as a birthday preset from my son, and I was
suffering from 1 fps rendering speed. Now it renders at descent 17 fps.
How can you render for 16 seconds? My Win7 just crashes the Fragmentarium
after 2 seconds.
Yes, it is OK to distribute the script.

Vladimir
http://bulatov.org

The code used to render the handles attached to the previous post.

Thanks. I have a GTX570 at work, will try that!

The two second limit is a GPU watchdog limit imposed by Windows. It is possible to change the time-out using the registry: http://blog.hvidtfeldts.net/index.php/2011/12/fragmentarium-faq/

Best regards, Mikael.

Hi vb2012,
  your description at the start sounds interesting, I would like to understand it some more, maybe you could do some diagrams to show how the 'dihedral angles of hyperplanes intersections have to be integer fraction of pi' and other parts work to help us visualise. It might be easier to remove a dimension for explanation.
 O0

 :wow: :thanks1:

MY GOD!!! Thanks so much for this beautiful present we love you :love: :love: :love:

BTW! I'm obtaining a huge speed up while locking the variables (especially the checkboxes)

You are right! By locking the checkboxes in the 'limitset' tab, I suddenly get 5fps per second with the standard raytracer.

Removing variables in GLSL has always been a mystery to me. Sometimes you see radical changes, but most often not much happens.

Here is a render using the path-tracer I'm working on:

(http://blog.hvidtfeldts.net/media/vb.jpg)

Fantastic render!

Been playing with this on an nVidia GT 680M (some 1300 CUDA cores). Wow.

@Syntopia: I want that path tracer!  :D
I think that the driver gives up optimizing the uniform branches when the code reaches a certain "complexity" level.
The lesson here is that one can not simply transpose a code, intended to be run on CPU, directly to GPU. Shader languages make it possible but sometimes with a big performance penalty.
I also think that this script can be made even faster if the array of inversion spheres is sent as uniforms. This would be because not only we will save some computation (that are repeated for each pixel) but also because we will save registers. Minimizing register usage in a shader will (may) allow more threads to be launched which usually means a better GPU's computation capacity usage. With, a little scripting language (in order to setup the uniforms) fragmentarium would become a terribly powerful tool (it's already awesome ;)).

I asked about a scripting engine (a long time ago) too since that is the piece that would make Fragmentarium AWESOME but if Syntopia doesn't want to go down that path how about allowing a dynamic DLL or some other method to be called between frames and it can ONLY update parameters. Then we could write that piece. Maybe its just as easy to add a prebuilt scripting engine tho:)

Well, scripting is a possibility. In Structure Synth I added a JavaScript interpreter, which could be used to script animations (there is a builtin JavaScript compiler in Qt) - but I don't think it the best way to do it. It would be nice to have a scripting language with the same syntax as GLSL (vec3, matrices, etc.). You could probably do something clever with Clang and the GLM library, but it is a lot of work.

Also remember that it is possible to do calculations in the vertex shader, and pass them to the pixel shader. (Though the performance gain is not always great - I guess the few (four) vertice calculations are not enough to hide the GPU latencies. It might, however, reduce the register pressure in the aubsequent pixel shader).

But... first I need to do some work on the keyframe interpolations :-)

Well, no pressure intended!  :)

I'm eager to see the next relase of fragmentarium. Good luck and thank you.

Yeah after thinking about this the vertex solution seemed much simpler - maybe you could make a #providesVertexInit (if there isn't one already) and allow the user to write out the varying variables once rather than rewriting the whole vertex shader and then copying the varying definitions to the fragment shader. Its a great program now so don't think of this as badgering :)
One thing I noticed is I couldn't send as many varying floats as uniform floats - don't know why they have different limits.

It's already implemented. See for example Doyle spirals script or this: http://www.fractalforums.com/ifs-iterated-function-systems/another-3d-kleinian/  :dink:
It is perfect when there is not too much variables to initialize. This is the most common case but a client side script IS the perfect solution for complicated cases.

Bulatov.frag, limit_set.frag don't runs on Intel HD4600  :-\ Both scripts compiles without errors or warnings, but I see just green background  :'(

Well, software compatibility of different platforms is pain.  :)
Currently I am working on ShapeJS - javascript based 3d modeling environment with server side GPU renderer.
https://shapejs.shapeways.com/creator/?li=devhome_main (https://shapejs.shapeways.com/creator/?li=devhome_main)
Big development advantage - it runs on known hardware.
There is build in support for fractals generated via reflection groups.

Updated link to current real time version ShapeJS 
https://shapejs.shapeways.com/v2/examples (https://shapejs.shapeways.com/v2/examples)

Thanks for link!
So, tried to do something with Bulatov.frag... it's most resource-intensive fragment I ever used  :headbatting:
Why so hard? No ways to make it easy?  :sad1:

(http://orig12.deviantart.net/dd1b/f/2016/320/d/8/bulatov_by_crist_jroger-daoocmz.jpg)

I've been just learning the pixel shaders when I wrote it.
I didn't know what I was doing.  :embarrass:

Do not worry sir Bulatov we are glad you share your knowledge with us :beer: