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: Visit the official fractalforums.com Youtube Channel
 
*
Welcome, Guest. Please login or register. March 28, 2024, 04:45:47 PM


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 [4] 5 6 ... 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 25700 times)
0 Members and 1 Guest are viewing this topic.
Kali
Fractal Supremo
*****
Posts: 1138


« Reply #45 on: November 10, 2012, 09:59:23 PM »

Wow! excellent shader syntopia. I never expected it would work so well. Thank you!

I agree, excelent tool indeed. Despite it's limitations, it works very well. Using this tracer I managed to make the best renders so far of the 3D Kaliset formula:



I used exponential smoothing calculation and a bailout value of 1 (the formula is all-inside)
Logged

richardrosenman
Conqueror
*******
Posts: 104



WWW
« Reply #46 on: November 11, 2012, 08:07:46 AM »

Thanks, Knighty, Kali & Syntopia.

I downloaded the latest build and it works great! Lighting and spec is working as it should. Color cycling doesn't but I have a feeling it never did. I also went out today and picked up an EVGA GeForce 650 TI and words can't describe how blazingly fast the rendering is compared to before. Of course, the first thing I did was render a high resolution tile image and you can imagine my surprise when I realized the lighting doesn't work for tile rendering when using Brute-Raytracer! Argh! wink

Syntopia is there any plans to fix this (if it's even fixable?) I think Kali mentioned something about this before and now I understand what he was talking about.

I hope it's fixable - the Brute-Raytracer produces such realistic renders it would be a shame not to be able to take advantage of it.

In the meantime, I have plenty more to play with my new video card but I figured it doesn't hurt to mention it in case it's fixable. wink

Amazing, the speeds I'm getting... wow.

-Rich
Logged

Syntopia
Fractal Molossus
**
Posts: 681



syntopiadk
WWW
« Reply #47 on: November 11, 2012, 12:14:06 PM »

Great image, Kali!

Of course, the first thing I did was render a high resolution tile image and you can imagine my surprise when I realized the lighting doesn't work for tile rendering when using Brute-Raytracer! Argh! wink

Syntopia is there any plans to fix this (if it's even fixable?) I think Kali mentioned something about this before and now I understand what he was talking about.

Yes, the tile-rendering will introduce artifacts near the tile borders, because of the screen space ambient occlusion. There may be some ways to work around this, and I plan to do something about it, but I can't promise when. I'm considering the following approaches:

- Simply use a larger GPU buffer than the visible buffer. This is the simplest approach, but rendering output will be limited by the memory on the GPU. As of now, the standard Fragmentarium "buffer swap" setup uses two HDR-buffers and one output buffer, which means each pixel use 36 bytes, so it should be possible to do quite large renders. There may be other (OpenGL) limits, though. One annoyance is that the GPU operations are likely to time out on such large buffers, and you need to disable the GPU watchdog timer.

- When doing tile renders, I could "pad" the tiles, and only use the center portion. The disadvantage of this is that some systems (Game of Life, Reaction-Diffusion, Video Feedback) rely on having access to the full buffer, and won't work.

Quote
I hope it's fixable - the Brute-Raytracer produces such realistic renders it would be a shame not to be able to take advantage of it.

The Brute-Raytracer is far the worst of the Raytracers in Fragmentarium :-) It is only meant for the case, when a proper Distance Estimator can not be found. For instance, things like soft shadows and depth-of-field won't work.

If possible, go for one of the other raytracers - they will provide much better quality and be faster as well.
Logged
Alef
Fractal Supremo
*****
Posts: 1174



WWW
« Reply #48 on: November 11, 2012, 05:43:17 PM »

p.s.
Maybe this formula should have its way into Fragmentarium?
http://www.fractalforums.com/theory/an-old-formula-revised/msg53970/


I'm alsou a little bit egoistic. I could code it by myself, but at first for that I would need younger PC:
https://sites.google.com/site/3dfractals/baguabox
posiytive version:
https://sites.google.com/site/3dfractals/baguabox/baguaboxvariations
good pics (just not secure and secure):
https://sites.google.com/site/3dfractals/baguabox/baguaboxvariations/baguabox-animation
« Last Edit: November 11, 2012, 08:42:59 PM by Asdam » Logged

fractal catalisator
richardrosenman
Conqueror
*******
Posts: 104



WWW
« Reply #49 on: November 12, 2012, 02:01:56 AM »

Thanks for the info, Syntopia.

I have to say that for something titled as the worst raytracer in Fragmentarium, it produces much more realistic and detailed renders than those of DE. At least for me. Edges are beautifully beveled with specular highlights whereas DE seems to produce 3D structures that don't make sense when you follow them with your eye. I understand about the lighting limitations using the screenspace ambient occlusion. It seems the specular also suffers: every tile seems to render the lighting in it's own relative space so rendering 3x3 tiles results in 9 of them with the light placed in the same position for each. I know this is just for discussion's sake but seeing as this is a brute-force renderer, why not try a brute-force true global illumination system? I know... easier said than done.

I will play around more the DE now that I see brute-raytracer's limitations. I have one last question for Kali and Syntopia: In playing with the Brute-Raytracer and Kali's example, I still can't reach the refinement in quality that Kali has in his image, no matter how long I let mine progressively render (it could be overnight). Did anything change in this version vs. the one Kali is using? My renders result in aliased speculars, and other pixilated artefacts, no matter how far I push the settings or how long I let the image converge. I could probably post an example but is there anything I could be missing? I tried almost everything but nothing comes close to the detail and aliasing of his renders.

Thanks again!
-Rich
Logged

M Benesi
Fractal Schemer
****
Posts: 1075



WWW
« Reply #50 on: November 12, 2012, 04:32:03 AM »

  I'm not sure of the syntax- having problems getting the following to work with the non-DE method (just wrote over a copy of tutorial #26). 

  Help with syntax please (maybe a link??).  This is a simple version of a power 2 bulb that works nicely.

Code:
void powN2(inout vec3 z, float zr0) {
float sr23=sqrt(2/3);
float sr13=sqrt(1/3);
float nx=z.x*sr23-z.z*sr13;
float sz=z.x*sr13 + z.z*sr23;
float sx=nx;
float sr12=sqrt(.5);
nx=sx*sr12-z.y*sr12;                 // tried with declaring float again, and not...
float sy=sx*sr12+z.y*sr12;
sx=nx*nx;
sy=sy*sy;
sz=sz*sz;
float r=sx+sy+sz;
while (r>0 || r<0) {                                              //not sure of != syntax ???
nx=(sx+r)*(9*sx-sy-sz)/(9*sx+sy+sz)-.5;       
float ny=(sy+r)*(9*sy-sx-sz)/(9*sy+sx+sz)-.5;
sz=(sz+r)*(9*sz-sx-sy)/(9*sz+sx+sy)-.5;
}
sx=nx;
sy=ny;
nx=sx*sr12+sy*sr12;
sy=-sx*sr12+sy*sr12;     // can I start out with a - sign??
sx=nx;
nx=sx*sr23+sz*sr13;
sz=-sx*sr13+sz*sr23;
float sx2=sx*sx;
float sy2=sy*sy;         //  does variable^2 work instead??
float sz2=sz*sz;
nx=sx2-sy2-sz2;
float r3=2*|sx|/sqrt(sy2+sz2);     
nz=r3*(sy2-sz2);
ny=r3*2*sy*sz;
z= vec3(nx,ny,nz);


}


bool inside(vec3 pos) {
vec3 z=pos;
float r;
int i=0;
r=length(z);
while(r<Bailout && (i<Iterations)) {
powN2(z,r);
if (pos.x>0) {                          // can I do this???
z+=vec3(pos.x*.5,0,0);
} else {
z+=vec3(pos.x,0,0);
}

r=length(z);
i++;
}
return (r<Bailout);

}
Logged

Syntopia
Fractal Molossus
**
Posts: 681



syntopiadk
WWW
« Reply #51 on: November 12, 2012, 05:15:14 PM »

Hi M Benesi,

There are some issues with your formula:

1) First, all floating point literals should be marked with a period, i.e. 'sqrt(1./3.)' instead of 'sqrt(1/3)'. Otherwise you will get integer division, and other errors. (sqrt(1/3) is zero)
2) != syntax is fine.
3) ^ for power exponentiation can not be used.
4) Use abs(sx) instead of |sx|
5) It is okay to start out with a minus sign (it is an unary minus).

After doing this, I ended up with:
Code:
#define providesInside
#define providesColor

#include "Brute-Raytracer.frag"
#group Mandelbulb
//#define IterationsBetweenRedraws 5

// Number of fractal iterations.
uniform int Iterations;  slider[0,9,100]
// Bailout radius
uniform float Bailout; slider[0,5,30]


vec3 color(vec3 p) {
return abs(vec3(p));
}
void powN2(inout vec3 z, float zr0) {
float sr23=sqrt(2./3.);
float sr13=sqrt(1./3.);
float nx=z.x*sr23-z.z*sr13;
float sz=z.x*sr13 + z.z*sr23;
float sx=nx;
float sr12=sqrt(.5);
nx=sx*sr12-z.y*sr12;             
float sy=sx*sr12+z.y*sr12;
sx=nx*nx;
sy=sy*sy;
sz=sz*sz;
float r=sx+sy+sz;
while (r>0. || r<0.) {                                       
nx=(sx+r)*(9.*sx-sy-sz)/(9.*sx+sy+sz)-.5;
float ny=(sy+r)*(9.*sy-sx-sz)/(9.*sy+sx+sz)-.5;
sz=(sz+r)*(9.*sz-sx-sy)/(9.*sz+sx+sy)-.5;
}
sx=nx;
sy=ny;
nx=sx*sr12+sy*sr12;
sy=-sx*sr12+sy*sr12;
sx=nx;
nx=sx*sr23+sz*sr13;
sz=-sx*sr13+sz*sr23;
float sx2=sx*sx;
float sy2=sy*sy;       
float sz2=sz*sz;
nx=sx2-sy2-sz2;
float r3=2.*abs(sx)/sqrt(sy2+sz2);
float nz=r3*(sy2-sz2);
  float ny=r3*2*sy*sz;
z= vec3(nx,ny,nz);
}


bool inside(vec3 pos) {
vec3 z=pos;
float r;
int i=0;
r=length(z);
while(r<Bailout && (i<Iterations)) {
powN2(z,r);
if (pos.x>0.) {                          // can I do this???
z+=vec3(pos.x*.5,0.,0.);
} else {
z+=vec3(pos.x,0.,0.);
}
r=length(z);
i++;
}
return (r<Bailout);
}

But there are still errors: you use the value of 'ny' before declaring and assigning to it.

Be careful of the warnings in the console when you compile the fragments. They should guide you towards the answer.
And if you want the syntax, click the 'GLSL Specification' link in the Help menu.

Feel free to post your code again - but please post all the code - this makes it easier for me to try out.
Logged
M Benesi
Fractal Schemer
****
Posts: 1075



WWW
« Reply #52 on: November 12, 2012, 08:56:14 PM »

  Thanks!   I've got a few things to do this afternoon (EST), then I'll get around to editing and reposting the full code sometime tonight- hopefully it'll be working. 


  About the incomplete code-  I cheated more than a little bit and used your tutorial #26 (downloaded from your github page).  I simply changed 2 portions that are in the above post (PowN2 and bool inside sections), and left out the majority of the unchanged code.   
Logged

richardrosenman
Conqueror
*******
Posts: 104



WWW
« Reply #53 on: November 13, 2012, 01:15:24 AM »

Ok, this is killing me. Surely, I must be doing something wrong here.  fiery

This is kali's rotjuliatestff fragment after 24 hours of progressive rendering (over 420,000 subframes!). You can see the aliased and oversized jagged pixels that never refine. Compare this to his image posted earlier in this thread and there is a world of difference. I wonder if this has anything to do with the pixelsize bug that was there before? After all, it appears as if many of the pixels here are oversized / undersampled:

http://www.richardrosenman.com/storage/poor_sampling.jpg

I'd love to try this script on an earlier Fragmentarium compile to compare but I can't find any.

Syntopia, does this look like correct output to you after 24 hours of rendering? Especially when compared to Kali's: https://dl.dropbox.com/s/xdikkc2zx16qr53/rotjuliatestff.jpg

Thanks,
-Rich
« Last Edit: November 13, 2012, 01:18:11 AM by richardrosenman » Logged

M Benesi
Fractal Schemer
****
Posts: 1075



WWW
« Reply #54 on: November 13, 2012, 04:38:21 AM »

But there are still errors: you use the value of 'ny' before declaring and assigning to it.

Be careful of the warnings in the console when you compile the fragments. They should guide you towards the answer.
And if you want the syntax, click the 'GLSL Specification' link in the Help menu.  

  You helped out a lot.

  The current problem may lie in my archaic 8600m (yeah.. the infamous one) GPU, or maybe I'm missing something in the rewritten code: pesky while statement.  It compiles fine- but even set to "manual", I've ended up with a BSOD that tells me that my video card driver is stuck in an infinite loop.  Haven't seen a BSOD in years....   The one time I did get a partial image, it was white noise (like "snow" on an old fashioned analog CRT TV) before being kicked out to a BSOD.    


Quote
Feel free to post your code again - but please post all the code - this makes it easier for me to try out.

  Here is the "corrected", full code.   IT WORKS!!!  Having problem with orbit trap coloring though.  Would like to implement some type of palette coloring scheme, to cycle through defined palettes.  That's for the future.    Also need to implement the full version of this fractal, rather than simply the double z^2 version.

  NOTE:  Just fixed this at ~2:16am EST.  Old version had a bug.  In addition, I messed with the coloring in the brute 3d without DE file, so don't know how this will fly with the regular.  Make sure to increase lighting (I suppose I could change the presets... but it's late).
Code:

#info Mandelbulb without Distance Estimator

#define providesInside

#define providesColor

#include "Brute-Raytracer-color.frag"
#group Mandelbulb
//#define IterationsBetweenRedraws 5      // I really need to clean this code up... LATER though...

// Number of fractal iterations.
uniform int Iterations;  slider[0,4,100]

// Number of color iterations.
uniform int ColorIterations;  slider[0,3,100]

// Mandelbulb exponent (8 is standard)
//uniform float Power; slider[-10,8,10]

// Bailout radius
uniform float Bailout; slider[0,12,30]

//uniform vec3 RotVector; slider[(0,0,0),(1,1,1),(1,1,1)]

//uniform float RotAngle; slider[0.00,0,180]

uniform bool Julia; checkbox[false]
uniform vec3 JuliaC; slider[(-2,-2,-2),(0,0,0),(2,2,2)]

vec3 color(vec3 p) {
return abs(vec3(p)); // should this point to z??
}
void powN2(inout vec3 z, float zr0) {
float sr23=sqrt(2./3.);
float sr13=sqrt(1./3.);
float nx=z.x*sr23-z.z*sr13;
float sz=z.x*sr13 + z.z*sr23;
float sx=nx;
float sr12=sqrt(.5);
nx=sx*sr12-z.y*sr12;            
float sy=sx*sr12+z.y*sr12;
sx=nx*nx;
sy=sy*sy;
float ny=sy;
sz=sz*sz;
float r2=sx+sy+sz;
if (r2!=0.) {                                      
nx=(sx+r2)*(9.*sx-sy-sz)/(9.*sx+sy+sz)-.5;
ny=(sy+r2)*(9.*sy-sx-sz)/(9.*sy+sx+sz)-.5;
sz=(sz+r2)*(9.*sz-sx-sy)/(9.*sz+sx+sy)-.5;

}
sx=nx;
sy=ny;
nx=sx*sr12+sy*sr12;
sy=-sx*sr12+sy*sr12;
sx=nx;
nx=sx*sr23+sz*sr13;
sz=-sx*sr13+sz*sr23; //some things can be cleaned up
sx=nx;
float sx2=sx*sx;
float sy2=sy*sy; // will be switching code around later      
float sz2=sz*sz;
nx=sx2-sy2-sz2;
float r3=2.*abs(sx)/sqrt(sy2+sz2);
float nz=r3*(sy2-sz2);
  ny=r3*2.*sy*sz;
z= vec3(nx,ny,nz);
}


bool inside(vec3 pos) {
vec3 z=pos;
float r;
vec4 colortime=vec4(0.,0.,0.,0.);
int i=0;
r=length(z);
orbitTrap=colortime;
while(r<Bailout && (i<Iterations)) {
powN2(z,r);
if (i<ColorIterations) {
orbitTrap=orbitTrap+vec4(z.x*(z.x),z.y*(z.y),z.z*(z.z),length(z));
}
if (pos.x>0.) {                          // can I do this???
z+=vec3(pos.x*.5,0.,0.);
} else {
z+=vec3(pos.x,0.,0.);
}
r=length(z);

i++;
}
return (r<Bailout);
}


#preset Default
FOV = 0.62536
Eye = 0.633014,-0.13205,-1.83663
Target = -3.07766,0.866233,6.14854
Up = -0.87195,0.22693,-0.433562
EquiRectangular = false
Gamma = 2.5
ToneMapping = 3
Exposure = 1.34694
Brightness = 1
Contrast = 0.9901
Saturation = 1
GaussianWeight = 1
AntiAliasScale = 0
CamLight = 1,1,1,0.38462
CamLightMin = 0
Fog = 0
BaseColor = 1,1,1
OrbitStrength = 0
X = 1,1,1,1
Y = 0.345098,0.666667,0,0.02912
Z = 1,0.666667,0,1
R = 0.0784314,1,0.941176,-0.0194
BackgroundColor = 0.607843,0.866667,0.560784
GradientBackground = 0.86955
CycleColors = false
Cycles = 1.1
NormalScale = 0.00024
AOScale = 0.00631
Glow = 0.34167
AOStrength = 0.86047
Specular = 0
SpecularExp = 5.455
SpotLight = 1,0.678431,0.494118,0.78431
SpotLightDir = 1,0.78126
Iterations = 4
ColorIterations = 3
Power = 8
Bailout = 12
AlternateVersion = false
RotVector = 1,1,1
RotAngle = 0
Julia = false
JuliaC = 0,0,0
ShowDepth = true
Samples = 100
Near = 0.7368
Far = 2.45904
#endpreset


  Here is an image.. click to biggify:
« Last Edit: November 13, 2012, 08:23:04 AM by M Benesi » Logged

Syntopia
Fractal Molossus
**
Posts: 681



syntopiadk
WWW
« Reply #55 on: November 13, 2012, 09:50:00 PM »

Good to see you got it working!

It works on my machine too - after changing to the old 'Brute-raytracer.frag'. Here is an example:



If possible, you should implement the 'color' function, instead of changing the 'Brute-raytracer'. This will make the code more reusable.
Logged
Syntopia
Fractal Molossus
**
Posts: 681



syntopiadk
WWW
« Reply #56 on: November 13, 2012, 10:03:28 PM »

Ok, this is killing me. Surely, I must be doing something wrong here.  fiery

This is kali's rotjuliatestff fragment after 24 hours of progressive rendering (over 420,000 subframes!). You can see the aliased and oversized jagged pixels that never refine. Compare this to his image posted earlier in this thread and there is a world of difference. I wonder if this has anything to do with the pixelsize bug that was there before? After all, it appears as if many of the pixels here are oversized / undersampled:

http://www.richardrosenman.com/storage/poor_sampling.jpg

I'd love to try this script on an earlier Fragmentarium compile to compare but I can't find any.

Syntopia, does this look like correct output to you after 24 hours of rendering? Especially when compared to Kali's: https://dl.dropbox.com/s/xdikkc2zx16qr53/rotjuliatestff.jpg

Thanks,
-Rich

Hi Rich,

Did you see my post on the Brute-raytracer: http://blog.hvidtfeldts.net/index.php/2012/09/rendering-3d-fractals-without-a-distance-estimator/

The Brute-raytracer uses screen-space methods to calculate normals and AO. For this particular raytracer, there is no subpixel jittering and no anti-alias.
So no matter for how long you run your calculation you will have jaggies. The only way to avoid this by rendering as large as your screen permits and down-size the image (this was probably what Kali did).

The best way to deal with this would be to use the High-Resolution Render, and manually downsize the image, but as mentioned earlier in this thread, it has some issues with tiling artifacts because of the SSAO (and another error in the lighting, but this I can fix).

Finally, it should be mentioned that I changed the 'DepthBufferShader.frag' implementation to use hardware derivates (dFdx, dFdy) for the screen space normals in my later version. This may have lowered the resolution for normals, since I think most GPU's calculate these in 2x2 blocks. I will check this when I get a chance.

Logged
richardrosenman
Conqueror
*******
Posts: 104



WWW
« Reply #57 on: November 13, 2012, 10:19:29 PM »

Quote
Finally, it should be mentioned that I changed the 'DepthBufferShader.frag' implementation to use hardware derivates (dFdx, dFdy) for the screen space normals in my later version. This may have lowered the resolution for normals, since I think most GPU's calculate these in 2x2 blocks. I will check this when I get a chance.

Hi Syntopia;

I actually got Kali's help with this and he too confirmed the newest release renders incorrectly with the Brute-Raytracer (he tried it as well and compared to his current one). He sent me most of the older .frag include files and behold - it renders it correctly. So you might want to check that - we can both confirm it does not render in brute force at the quality it previously did. Perhaps the modification you mentioned did in fact change something. I understand about downsampling and such but this is something different. Perhaps the best way for you to see what I mean is to render Kali's image with the newest and then older raytracer.

Anyway, I'm a happy camper with the old files from Kali - the results are spectacular. I can post a before and after if you want to see the difference. Just let me know.

Regarding this last image - can you explain how to use the color function for brute rendering?

Thanks Syntopia (and Kali for the help!)

-Rich
« Last Edit: November 13, 2012, 10:27:21 PM by richardrosenman » Logged

Syntopia
Fractal Molossus
**
Posts: 681



syntopiadk
WWW
« Reply #58 on: November 13, 2012, 10:36:53 PM »

Hmm, guess I have to do some debugging...

Wrt colors, I provide them manually, i.e. placed a
Code:
#define providesColor

at top of the script, and then I reused the color-cycling code:
Code:

vec3 cycle(vec3 c, float s) {
return vec3(0.5)+0.5*vec3(cos(s*Cycles+c.x),cos(s*Cycles+c.y),cos(s*Cycles+c.z));
}

vec3 color(vec3 p) {
        // We need to call 'inside' again.
orbitTrap = vec4(10000.0);
inside(p);
orbitTrap.w = sqrt(orbitTrap.w);

vec3 orbitColor;
if (CycleColors) {
orbitColor = cycle(X.xyz,orbitTrap.x)*X.w*orbitTrap.x +
cycle(Y.xyz,orbitTrap.y)*Y.w*orbitTrap.y +
cycle(Z.xyz,orbitTrap.z)*Z.w*orbitTrap.z +
cycle(R.xyz,orbitTrap.w)*R.w*orbitTrap.w;
} else {
orbitColor = X.xyz*X.w*orbitTrap.x +
Y.xyz*Y.w*orbitTrap.y +
Z.xyz*Z.w*orbitTrap.z +
R.xyz*R.w*orbitTrap.w;
}
return orbitColor;
}

Be sure to set the OrbitStrength to 1, to see the effect of the custom coloring!

In the 'inside' function I keep track of the closest points (the orbit traps):

Code:
/// inside loop
if (i>ColorIterationsMin && i<ColorIterations) {
orbitTrap=min(orbitTrap,vec4(z.x*z.x,z.y*z.y,z.z*z.z,dot(z,z)));
}

I'm not particular fond of this orbit trap/color cycling scheme, so I'm sure you can come up with something better :-)
Logged
M Benesi
Fractal Schemer
****
Posts: 1075



WWW
« Reply #59 on: November 13, 2012, 11:15:11 PM »


If possible, you should implement the 'color' function, instead of changing the 'Brute-raytracer'. This will make the code more reusable.


  Nice render.  For whatever reason, I'm having a few problems with the coloring function- you got it to do what I wanted it to do.  I'll mess around with it and take into consideration your post above this one. 

  I had a few problems with atan as well, trying to get atan2 type outputs.

  I think I might have that figured out- had to use some math trick, but am not satisfied using the math trick as the GLSL documentation site says that the atan function should output atan2 type outputs (I'll go back and retry atan(y,x) and atan (y/x) to see if they are different as the documentation seems to imply). 

  I'm assuming that GPU rendering with trigonometric functions is pretty fast smiley, even on my old beast. 
Logged

Pages: 1 2 3 [4] 5 6 ... 8   Go Down
  Print  
 
Jump to:  

Related Topics
Subject Started by Replies Views Last post
Distance Estimators Comparison 3D Fractal Generation David Makin 0 2361 Last post October 24, 2009, 10:02:58 PM
by David Makin
Dual numbers for creating distance estimators (new) Theories & Research Syntopia 2 1317 Last post December 14, 2011, 08:19:02 PM
by eiffie
Mandelbrot Set Distance Estimator Rendering Problem UltraFractal aleph0 5 10834 Last post April 30, 2014, 01:08:45 AM
by aleph0
Wooscripter noisy distance estimators 3D Fractal Generation dom767 5 2872 Last post February 14, 2015, 03:47:34 PM
by dom767
Error estimation of distance estimators (Mandelbulb improvement found!) (new) Theories & Research mermelada 6 832 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.331 seconds with 24 queries. (Pretty URLs adds 0.025s, 2q)