Kali
|
|
« 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
|
|
« 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! 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. Amazing, the speeds I'm getting... wow. -Rich
|
|
|
Logged
|
|
|
|
Syntopia
|
|
« 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! 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. 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
|
|
« Reply #48 on: November 11, 2012, 05:43:17 PM » |
|
|
|
« Last Edit: November 11, 2012, 08:42:59 PM by Asdam »
|
Logged
|
fractal catalisator
|
|
|
richardrosenman
|
|
« 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
|
|
« 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. 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
|
|
« 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: #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
|
|
« 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
|
|
« Reply #53 on: November 13, 2012, 01:15:24 AM » |
|
Ok, this is killing me. Surely, I must be doing something wrong here. 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.jpgI'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.jpgThanks, -Rich
|
|
« Last Edit: November 13, 2012, 01:18:11 AM by richardrosenman »
|
Logged
|
|
|
|
M Benesi
|
|
« 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.
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). #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
|
|
« 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
|
|
« Reply #56 on: November 13, 2012, 10:03:28 PM » |
|
Ok, this is killing me. Surely, I must be doing something wrong here. 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.jpgI'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.jpgThanks, -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
|
|
« Reply #57 on: November 13, 2012, 10:19:29 PM » |
|
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
|
|
« 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 #define providesColor
at top of the script, and then I reused the color-cycling 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): /// 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
|
|
« 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 , even on my old beast.
|
|
|
Logged
|
|
|
|
|