Boxplorer: an interactive intro ;-)
category: gfx [glöplog]
B-But...
It's smooth! :)
It's smooth! :)
Awesome rrrola!
Some discussion on sdl fullscreen elsewhere prompted my memory just now, and I realised I'd totally forgotten about this.
I'll see if I can figure out how to add the mac-specific stuff. Not sure when though, I'm super busy trying to get some (non-scene) stuff released before xmas. Remind me if it never happens :D
I'll see if I can figure out how to add the mac-specific stuff. Not sure when though, I'm super busy trying to get some (non-scene) stuff released before xmas. Remind me if it never happens :D
Hi all,
I'm very new on Mandelbrot art (2 days) and I'm very excited having found Boxplorer. Many thanks to the creators.
I've only 2 questions about it :
- how can I change the size of the player? when I change the size numbers and put fullscreen to 1 in the conf file, the changes are automatically deleted as soon as I reload the player.
- it's a newbie question, maybe stupid (the question), but is it possible to use its own parameters file... and which tool may I use to create this parameter (or formula). I'm trying to play with Mandelbub3D (and UltraFractals); is there a way to transfer the parameters to Boxplorer? How?
(MacIntel OSX 10.6)
Thanks for your advices,
Phil
I'm very new on Mandelbrot art (2 days) and I'm very excited having found Boxplorer. Many thanks to the creators.
I've only 2 questions about it :
- how can I change the size of the player? when I change the size numbers and put fullscreen to 1 in the conf file, the changes are automatically deleted as soon as I reload the player.
- it's a newbie question, maybe stupid (the question), but is it possible to use its own parameters file... and which tool may I use to create this parameter (or formula). I'm trying to play with Mandelbub3D (and UltraFractals); is there a way to transfer the parameters to Boxplorer? How?
(MacIntel OSX 10.6)
Thanks for your advices,
Phil
To use own parameter file: rename the file to boxplorer.cfg, or run the program on the command line: boxplorer.exe your_file.cfg.
I'm using Notepad to edit it - it's a normal text file. Two of the parameters are width and height, just change their values.
I'm using Notepad to edit it - it's a normal text file. Two of the parameters are width and height, just change their values.
THumbup.
The screenshots remind me a lot of the things you see on salvia. (Has anyone from the scene, beside me, ever tried that?)
guess what, your the only one!
Uhm... yeah right. Like you would know. :)
Quote:
To use own parameter file: rename the file to boxplorer.cfg, or run the program on the command line: boxplorer.exe your_file.cfg.
I'm using Notepad to edit it - it's a normal text file. Two of the parameters are width and height, just change their values.
Hi rrrola,
Woaaahhh ! what a gift ! Many thanks. I would have never believed that I could enter so quickly in this wonderful world!
Another question : is there some info on the formula or parameters, in order to understand better what happens?...and maybe a library of parameters?
Many thanks again ...and best greetings for all !
Phil
Great learning material!
Thanks for sharing!
And happy new year!
Thanks for sharing!
And happy new year!
For the people who liked Boxplorer: I've added my own Boxplorer-inspired mandelbox editor as an easteregg to the ATI-fixed partyversion of our latest demo.
Compared to Boxplorer, it's about 3 to 4 times faster, albeit at a slightly lower visual quality. and it uses all 3 parameters of Tglads original formula (scale, fixed radius, min radius) instead of boxplorers 2. So it can show some mandelboxes that Boxplorer can't. It also has a GUI to easily change any parameter while running.
To show it, just click the appropriate checkbox on the startup menu. If you don't want to watch the demo every time, you can press escape to jump straight to the viewer, although the music will keep playing. If you've questions, feel free to ask.
Compared to Boxplorer, it's about 3 to 4 times faster, albeit at a slightly lower visual quality. and it uses all 3 parameters of Tglads original formula (scale, fixed radius, min radius) instead of boxplorers 2. So it can show some mandelboxes that Boxplorer can't. It also has a GUI to easily change any parameter while running.
To show it, just click the appropriate checkbox on the startup menu. If you don't want to watch the demo every time, you can press escape to jump straight to the viewer, although the music will keep playing. If you've questions, feel free to ask.
Pretty sweet.
How did you achieve that speed improvement? Fixing constants and recompiling, or something more advanced?
How did you achieve that speed improvement? Fixing constants and recompiling, or something more advanced?
Boxplorer already fixed all constants in the mandelbox DE, and I doubt that making the remaining variables in the raymarching loop fixed is going to improve much.
No, I simply send the parameters to an Amazon cluster GPU Instance, which renders the image and sends it back to be displayed. Its a pity the blockiness of the JPEG compression is so visible ;)
No, I simply send the parameters to an Amazon cluster GPU Instance, which renders the image and sends it back to be displayed. Its a pity the blockiness of the JPEG compression is so visible ;)
In case anyone is still wondering: the fast mandelbox in The 3/4 Delusion is done with cone marching and some cheating. It's described in detail in my cone marching seminar at Revision 2012, the extended slides of which are available on our site . Enjoy!
I'd call that actually "hierarchical cone marching" because you're actually building a hierarchy where you factorize cone calculations for groups of pixels. :)
When i said i used cone-marching ( years ago? :) ), i meant i was marching cones instead of rays. Just as described in zeno.pdf... The guy invented everything about what we do now.
Or actually, we've never been marching rays in sphere tracing, but rather cylinders of radius epsilon, that's the whole point to understand about it.
Overall i think the gains are rather disappointing (i get similar framerate results with this) considering that in theory we should be able to march 30 out of 50 iterations for groups of, let's say 4*4 pixels and in the end we gain "only" that. I think there's a huge synchronization bottleneck between all the threads of each fragment waiting each other to complete on the GPU before the texture is done and a new pass can be started. If we could write more fragments with shader_image_load_store than the number of ROPs to each texture it would enable some awesome optimisations but unfortunately we can write only 16/32 fragments from each fragment shader. :/
For example we could render a whole line of pixels and factorize calculation for the next ray, in the case of heightmap rendering that would be a blast.
When i said i used cone-marching ( years ago? :) ), i meant i was marching cones instead of rays. Just as described in zeno.pdf... The guy invented everything about what we do now.
Or actually, we've never been marching rays in sphere tracing, but rather cylinders of radius epsilon, that's the whole point to understand about it.
Overall i think the gains are rather disappointing (i get similar framerate results with this) considering that in theory we should be able to march 30 out of 50 iterations for groups of, let's say 4*4 pixels and in the end we gain "only" that. I think there's a huge synchronization bottleneck between all the threads of each fragment waiting each other to complete on the GPU before the texture is done and a new pass can be started. If we could write more fragments with shader_image_load_store than the number of ROPs to each texture it would enable some awesome optimisations but unfortunately we can write only 16/32 fragments from each fragment shader. :/
For example we could render a whole line of pixels and factorize calculation for the next ray, in the case of heightmap rendering that would be a blast.
Anyway the ultimate trick for fractal rendering is apparently to evaluate only the "full" fractal when you intersect already a more simple version of it.
Let's say you want to render a mandelbox with 12 iterations, you intersect with the mandelbox with 4 iterations, evaluate the more simple one, and intersect the 12 iteration only when it's smaller than your cone radius. Depending on the topology of your scene and on the viewpoint, it can gain 2x 3x framerate.
Let's say you want to render a mandelbox with 12 iterations, you intersect with the mandelbox with 4 iterations, evaluate the more simple one, and intersect the 12 iteration only when it's smaller than your cone radius. Depending on the topology of your scene and on the viewpoint, it can gain 2x 3x framerate.
nystep: I've searched for cone marching before, and while I found a reference you made to it, there was no explanation about it anywhere to be found, so I assumed you meant cone tracing. Sorry for the name overloading.
I've started reading zeno.pdf, but once I understood the basics I skipped past most stuff to get at the object formulas. Maybe I should give it a second try...
And yes, a big reason raymarching is slow is due to divergence of code paths. I actually tried an OpenCL implementation that did the raymarching in several passes, and did stream compaction inbetween (keeping only the unfinished pixels). It was about 20% faster on my Quadro 4600 (which has only 128 shaders but a 384 bit memory bus), but it was 10% slower on my GT540M (96 shaders, 128 bit memory bus). As shader power increases a lot faster with each generation than bandwidth, trading shading power for bandwidth won't make sense so I abandoned that approach. But as it was my first OpenCL attempt, and I had to change my program significantly due to a compiler bug, I might revisiting this idea in the future... I've no experience with shader_image_load_store yet.
I'm still proud of my cone marching, since it allowed me to do high-res mandelboxes quite a bit faster than Rrrola's Boxplorer, which was a though goal to beat.
And about your low/high iteration idea: won't that only accelerate a lot if you're a far distance away? For The 3/4 Delusion, I really wanted to do deep zooms (which I hadn't seen done realtime before), and I think your method won't help once you're inside the fractal.
I've started reading zeno.pdf, but once I understood the basics I skipped past most stuff to get at the object formulas. Maybe I should give it a second try...
And yes, a big reason raymarching is slow is due to divergence of code paths. I actually tried an OpenCL implementation that did the raymarching in several passes, and did stream compaction inbetween (keeping only the unfinished pixels). It was about 20% faster on my Quadro 4600 (which has only 128 shaders but a 384 bit memory bus), but it was 10% slower on my GT540M (96 shaders, 128 bit memory bus). As shader power increases a lot faster with each generation than bandwidth, trading shading power for bandwidth won't make sense so I abandoned that approach. But as it was my first OpenCL attempt, and I had to change my program significantly due to a compiler bug, I might revisiting this idea in the future... I've no experience with shader_image_load_store yet.
I'm still proud of my cone marching, since it allowed me to do high-res mandelboxes quite a bit faster than Rrrola's Boxplorer, which was a though goal to beat.
And about your low/high iteration idea: won't that only accelerate a lot if you're a far distance away? For The 3/4 Delusion, I really wanted to do deep zooms (which I hadn't seen done realtime before), and I think your method won't help once you're inside the fractal.