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: Check out the originating "3d Mandelbulb" thread here
 
*
Welcome, Guest. Please login or register. July 16, 2018, 06:49:07 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] 2 3 ... 8   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: Rendering 3D fractals without distance estimators  (Read 11713 times)
0 Members and 1 Guest are viewing this topic.
Syntopia
Fractal Molossus
**
Posts: 681



syntopiadk
WWW
« on: September 28, 2012, 05:52:36 PM »

It is not always easy to come with a distance estimator for a 3D fractal. I've seen quite a few requests for drawing fractals, where the defining function only tells you whether you are inside or not for a given point, e.g. functions defined by:

bool inside(vec3 point);

I decided to try out some simple brute-force methods to see how they would compare to the DE methods. Contrary to my expectations, it turned out that you can actually get reasonable results without a DE.

The method I used was to just simply sample random points along the camera ray for each pixel. Whenever a hit is found on the camera ray, the sampling wil proceed on only the interval between the camera and the hit point (since we are only interested in finding the closest pixels). This way you end up with a depth map, like:



In order to improve the quality, I then calculated surface normals from the depth buffer and pixel positions, and used this to do a standard Phong shading. I also applied a simple screen space ambient occlusion (and glow) pass to improve depth queuing. This results in:



You can do this at interactive frame rates in Fragmentarium, and I further improved responsiveness by using progressive rendering: do a number of samples, then storing the best found solution (closest pixel) in a depth buffer (I use the alpha channel), render the frame and repeat.

I'll add the brute-force tracer to the Fragmentarium repository, as soon as the script is cleaned up a bit.

Logged
eiffie
Guest
« Reply #1 on: September 28, 2012, 06:27:22 PM »

Thanks for all your work! This will be great for trying new functions. I remember my first renderer was brute force but not nearly with these results. Glad you gave it another look.
Logged
hobold
Fractal Bachius
*
Posts: 573


« Reply #2 on: September 29, 2012, 01:23:20 AM »

Wow, this works much better than I would have expected. Great find! Hmm ... I wonder if some statistical techniques could be used here? I.e. controlling the randomness a bit, to speed up convergence towards the "exact" solution ...?
Logged
Kali
Fractal Supremo
*****
Posts: 1138


« Reply #3 on: September 29, 2012, 05:08:07 AM »

Great!

Currently I'm using accumulative fixed-step raymarching for trying out weird 3D formulas without using a DE, like in this "3D-rotated Julia" :



But I always wanted a solid shader for formulas without DE, and I was thinking of modifying your fragmentarium default raytracer to do this (or at least trying to).

I'm glad you already did it, and that it works so good! Can't wait to try it.


Logged

|</\|_|
░░░░░░░

http://fractkali.deviantart.com/
M Benesi
Fractal Schemer
****
Posts: 1075



WWW
« Reply #4 on: September 29, 2012, 05:38:31 AM »

The method I used was to just simply sample random points along the camera ray for each pixel. Whenever a hit is found on the camera ray, the sampling wil proceed on only the interval between the camera and the hit point (since we are only interested in finding the closest pixels).

  This sounds similar to what ChaosPro does.  There are a couple cool ideas here in the documentation  (click for documentation).  Read the "Resolution", "Start Scan", and "Precision" parts.  

  It makes ChaosPro an excellent piece of software to quickly whip up a new 3d formula, without having to do the extra math to whip up a DE, especially with some of these crazy formulas.... smiley
Logged

Syntopia
Fractal Molossus
**
Posts: 681



syntopiadk
WWW
« Reply #5 on: September 29, 2012, 09:06:19 AM »

Wow, this works much better than I would have expected. Great find! Hmm ... I wonder if some statistical techniques could be used here? I.e. controlling the randomness a bit, to speed up convergence towards the "exact" solution ...?

I think it could.  I already found that a stratified approach, where the camera ray segment is divided into equal pieces and a sample is choosen from each part reduces noise. You could also probably gain speed by sampling closer to the found solution. Since I use  double buffered progressive rendering approach, at the start of each frame, I could actually read the adjacent pixel depth and sample closer to these. On the other hand, if you bias the search you are probably more like to miss subtle details closer to the camera.

Also the function I use for random numbers:
Code:
float rand(vec2 co){
// implementation found at: lumina.sourceforge.net/Tutorials/Noise.html
return fract(sin(dot(co.xy ,vec2(12.9898,78.233))) * 43758.5453);
}

is quite primitive, and will show visible artifacts. There is no easy solution in GLSL here: I probably should use a precalculated texture with random values (I do have a floating point texture loader), but I'm too lazy.

Currently I'm using accumulative fixed-step raymarching for trying out weird 3D formulas without using a DE, like in this "3D-rotated Julia" :

I know :-) Actually I decided to try this, because I saw that you were able to succesfully use brute-force fixed step rendering on your great volumetric renders. The worst part about these brute-force solids, is that you need to rely on screen space lighting - this introduces artifacts: e.g. when you do tile rendering you get visually transitions near the border of the tiles.

  This sounds similar to what ChaosPro does.

Yes, it seems to the same approach - I just don't choose a fixed step size, so there no bounds to the resolution: the image will converge towards the true set.

Just to make it clear: brute force ray tracing is not a novel idea - it was indeed the simplest method I could think of. What is perhaps surprising, is that it is fast enough to achieve interactive frame rates on a GPU.
Logged
subblue
Conqueror
*******
Posts: 116



WWW
« Reply #6 on: September 29, 2012, 11:40:30 AM »

Very interesting. I'm curious how the number of steps for the brute force approach differs from the DE method?
Logged

www.subblue.com - a blog exploring mathematical and generative graphics
KRAFTWERK
Global Moderator
Fractal Senior
******
Posts: 1439


Virtual Surreality


WWW
« Reply #7 on: September 29, 2012, 01:31:27 PM »

Wow! I've always wanted to test brute force renders of the mandelbulb "to see what it REALLY looks like".
The mandelbulb you rendered have such beautiful details Syntopia.
Got to try out fragmentarium again!
Logged

Syntopia
Fractal Molossus
**
Posts: 681



syntopiadk
WWW
« Reply #8 on: September 30, 2012, 09:21:44 AM »

Very interesting. I'm curious how the number of steps for the brute force approach differs from the DE method?

There are no steps as such - you just choose a number of samples on the ray for each camera ray. A fractal such as the Mandelbulb becomes recognizable/navigatable at about 50 samples, and has a good resolution at ~500-1000 samples.

Wow! I've always wanted to test brute force renders of the mandelbulb "to see what it REALLY looks like".
The mandelbulb you rendered have such beautiful details Syntopia.
Got to try out fragmentarium again!

Thanks Kraftwerk. There is still no guarantee that you won't miss detail, though - subtle and thin structures may be overlooked in the sampling process. So it is still just an approximation.

Btw, here is another test with Aexions MandelDodecahedron:

Logged
hobold
Fractal Bachius
*
Posts: 573


« Reply #9 on: September 30, 2012, 02:04:59 PM »

And shouldn't this randomized brute force method be effective for robust computation of inside views? It wouldn't be as fast, of course, since most samples iterate to the limit, but perhaps still fast enough.
Logged
Syntopia
Fractal Molossus
**
Posts: 681



syntopiadk
WWW
« Reply #10 on: September 30, 2012, 10:03:52 PM »

I've written a blog post with some more information and links to code:
http://blog.hvidtfeldts.net/index.php/2012/09/rendering-3d-fractals-without-a-distance-estimator/

And shouldn't this randomized brute force method be effective for robust computation of inside views? It wouldn't be as fast, of course, since most samples iterate to the limit, but perhaps still fast enough.

Yes, just tried it, and it works nicely. Just invert the 'inside' function. As you say, it is a lot slower (~3-4x), since all pixels tested are inside.
Logged
cKleinhuis
Administrator
Fractal Senior
*******
Posts: 7044


formerly known as 'Trifox'


WWW
« Reply #11 on: October 01, 2012, 12:38:02 AM »

nice, i like it very much, this way it is far more easier to try out hillarious new functions, thx for keeping the program in steady development!
Logged

---

divide and conquer - iterate and rule - chaos is No random!
hobold
Fractal Bachius
*
Posts: 573


« Reply #12 on: October 01, 2012, 02:08:56 AM »

About quick and dirty random number generation ... can't we use a chaotic iterated function for that? Like Feigenbaum's logistic map at parameter value 4, or something like that. Quick to compute, and guaranteed to be chaotic. That might be good enough.
Logged
Kali
Fractal Supremo
*****
Posts: 1138


« Reply #13 on: October 01, 2012, 04:03:29 AM »

About quick and dirty random number generation ... can't we use a chaotic iterated function for that? Like Feigenbaum's logistic map at parameter value 4, or something like that. Quick to compute, and guaranteed to be chaotic. That might be good enough.

Back in my early programming experiences, I developed a random number generator based on irrational numbers... I'll try to remember how it worked, but I think the single precision limitation could be a problem.
Logged

|</\|_|
░░░░░░░

http://fractkali.deviantart.com/
Kali
Fractal Supremo
*****
Posts: 1138


« Reply #14 on: October 01, 2012, 07:04:16 AM »

Ok, I just tested the raytracer with my "rotjulia" formula, and I'm very excited with the result:




This is the "inside" function for using with the tracer:   (requires complex.frag and mathutils.frag)

Code:
bool inside(vec3 z) {
mat3 rot=rotationMatrix3(normalize(RotVector),RotAngle);
int i=0;
float r;
while (i<Iterations) {
z.xy=cMul(z.xy,z.xy);
z*=rot;
z+=JuliaC;
r=length(z);
i++;
             if ( r>Bailout) {
return false;
}
}
return true;
}

This algorithm takes x and y coordinates as a complex number, squares it, does a 3D rotation and adds julia constants.



Too bad the lighting doesn't work well with tiled large renders, but it's an awesome tool for exploring new formulas and ideas...

Thanks Mikael, good job!!



« Last Edit: October 01, 2012, 07:41:58 AM by Kali » Logged

|</\|_|
░░░░░░░

http://fractkali.deviantart.com/
Pages: [1] 2 3 ... 8   Go Down
  Print  
 
Jump to:  

Related Topics
Subject Started by Replies Views Last post
Distance Estimators Comparison 3D Fractal Generation David Makin 0 1347 Last post October 24, 2009, 10:02:58 PM
by David Makin
Dual numbers for creating distance estimators (new) Theories & Research Syntopia 2 1087 Last post December 14, 2011, 08:19:02 PM
by eiffie
Mandelbrot Set Distance Estimator Rendering Problem UltraFractal aleph0 5 1154 Last post April 30, 2014, 01:08:45 AM
by aleph0
Wooscripter noisy distance estimators 3D Fractal Generation dom767 5 1162 Last post February 14, 2015, 03:47:34 PM
by dom767
Error estimation of distance estimators (Mandelbulb improvement found!) (new) Theories & Research mermelada 6 444 Last post July 28, 2017, 09:52:19 AM
by mclarekin

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.309 seconds with 28 queries. (Pretty URLs adds 0.015s, 2q)