Logo by Fiery - 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. April 19, 2024, 03:51:16 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   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: Prophetic  (Read 2458 times)
0 Members and 1 Guest are viewing this topic.
Kali
Fractal Supremo
*****
Posts: 1138


« on: December 17, 2012, 06:31:32 AM »

Prophetic



http://www.fractalforums.com/index.php?action=gallery;sa=view;id=12985

Testing an experimental Fragmentarium renderer of mine, featuring positional light, and some kind of cheap/fake volumetric fog/lighting.

Logged

eiffie
Guest
« Reply #1 on: December 18, 2012, 05:48:22 PM »

Like it! Fakes are fun. Glad to see your making your own renderers - very interesting stuff.
Logged
Kali
Fractal Supremo
*****
Posts: 1138


« Reply #2 on: December 20, 2012, 02:15:46 AM »

Thanks eiffie! to be honest, I haven't wrote any own full renderer from scratch yet, I should said "a Fragmentarium raytracer mod of mine" instead, because I'm always introducing my own modifications on Syntopia's default Fragmentarium renderer, adding features and doing a lot of "experiments"  grin

I'm having fun lately, indeed, with this kind of light effects, they are very cheap because is like a fog based on the minimum distance to positional light during the raytrace. Then I add regular distance fog, and clear a bit of light fog based on the distance between the ray hit position and the light position.

Here's another image:



Now I want to make the hard shadow projections on the fog, I think I know a way for doing it easily, let's see if it could work...
« Last Edit: December 20, 2012, 05:24:30 AM by Kali » Logged

Kali
Fractal Supremo
*****
Posts: 1138


« Reply #3 on: December 20, 2012, 09:20:47 PM »

First attempts... not bad, but still have to work a lot on it. Also the script runs too slow for my taste...






A short clip with a moving light should be nice for better appreciation of the effect... I'll do some later.

Logged

M Benesi
Fractal Schemer
****
Posts: 1075



WWW
« Reply #4 on: December 20, 2012, 10:52:15 PM »

  Nice.  Next up, light paths determined by surface normals of an object.  Then we make the disco ball light sources, or diamonds (stellated cuboctahedrons would work nicely, especially if Knighty corrects my formula...).

  About script times-  For whatever reason, locking variables seems to decrease render times.  Doesn't make sense, since the compiler is the thing that should do the branch tracing.... 

  and, well... the compiler does- add multiple if statements to a formula in Fragmentarium and it increases the time to compile exponentially-compile \, time \, \times \, 2^{number \, of \, if \, statements}, I think it does it less for if else statements...
Logged

Syntopia
Fractal Molossus
**
Posts: 681



syntopiadk
WWW
« Reply #5 on: December 21, 2012, 12:06:04 AM »

Great light rays, Kali!

  About script times-  For whatever reason, locking variables seems to decrease render times.  Doesn't make sense, since the compiler is the thing that should do the branch tracing.... 
When you lock a variable in Fragmentarium, it replaces the uniform variable with a constant definition. This allows the GLSL compiler to remove dead code branches and do other optimizations. The GLSL compiler knows nothing about uniform variable values, so here it cannot optimize as much.

Quote
  and, well... the compiler does- add multiple if statements to a formula in Fragmentarium and it increases the time to compile exponentially-<Quoted Image Removed>, I think it does it less for if else statements...

The compile time does not double when you add an if-statement. This is easy to test in Fragmentarium since it always outputs the compile time. Just remember that you have to change the program before the compile - otherwise the GLSL compiler uses a cached version of the code, resulting in much faster compilation.
Logged
Kali
Fractal Supremo
*****
Posts: 1138


« Reply #6 on: December 21, 2012, 12:14:49 AM »

Thanks! at the moment I have to find manually the right adjustments to make them look good enough, it's a bit difficult and unhandy... also fog translucency is not properly done but well it's a start smiley

  Nice.  Next up, light paths determined by surface normals of an object.  Then we make the disco ball light sources, or diamonds (stellated cuboctahedrons would work nicely, especially if Knighty corrects my formula...).

Well, this positional light script is indeed based on normals of a DE object... Here I'm using a sphere, but could be whatever DE object, I already made some tests with fractals as lights (not the same as eiffie's emissive material, but...). The disco ball light is a great idea... do you know how to do a DE version? anyway, first I want to improve the renderer (maybe this weekend, if the world is still here  cheesy)
Logged

M Benesi
Fractal Schemer
****
Posts: 1075



WWW
« Reply #7 on: December 21, 2012, 05:32:44 AM »

  I'll see if I can do a DE type implementation of the stellated cuboctahedron.

  I mainly do escape time, which is totally sdrowkcab.  Unless you consider that it's easier to mix certain types of ET  alien formulas. 
Logged

M Benesi
Fractal Schemer
****
Posts: 1075



WWW
« Reply #8 on: December 21, 2012, 08:35:25 AM »

@Kali-  If you want to make it "rounder" (for better dispersion of light) change the r2 part of the DE return function to:   r2 = length (z) -1.;

Ok, here's a frag for the DE Stellated CubeOctohedron.  Uncheck the "stellated" boolean (in the fractal tab) to make a standard one.

  The whole frag is below, based off of Knighty's Menger formula (it was easier to start from there).  I don't understand all the options for the DE raytracer, nor do I know if I used the "best" raytracer, so modify the frag (defaults as well) to optimize it if desired.  

Just the code for the DE section:
Code:
float DE(vec3 z)
{
float r;
float r2=0.;
int n = 0;
vec3 rmin=vec3(0.);
vec3 zoff=vec3(0.);
vec3 zstore=vec3(0.);
while (n < Iterations) {
z*=rot;
z=abs(z);
zstore=z;
rmin=vec3(100.,100.,100.);
//  x part  
r=(z.x-OffSet.x);
r=r*r;
if (r<rmin.x) { rmin.x=r;zoff.x= OffSet.x;}

r=(z.x)*z.x;
if (r<rmin.x) { rmin.x=r;zoff.x= 0.;}
// y part
r=(z.y-OffSet.y);
r=r*r;
if (r<rmin.y) { rmin.y=r;zoff.y= OffSet.y;}

r=(z.y)*z.y;
if (r<rmin.y) { rmin.y=r;zoff.y= 0.;}
//z part
r=(z.z-OffSet.z); r=r*r;
if (r<rmin.z) { rmin.z=r;zoff.z= OffSet.z;}

r=(z.z)*z.z;
if (r<rmin.z) { rmin.z=r;zoff.z= 0.;}

z=Scale*z-zoff*(Scale-1.0);

if (!Stellated) { // you can take out the not Stellated part here
if (abs(zstore.x)<abs(zstore.y)) {
if (abs(zstore.x)<abs(zstore.z)) {
z.x+=zoff.x;
} else {
z.z+=zoff.z;
}
} else {
if (abs(zstore.y)<abs(zstore.z)) {
z.y+=zoff.y;
} else {
z.z+=zoff.z;
}
}
} else { //  and just use the following section
if (rmin.x<rmin.y) { // if you do, remove the zstore variable, as it is
if (rmin.x<rmin.z) { // superfluous.  hahah... superfluous....  :D
z.x+=zoff.x;
} else {
z.z+=zoff.z;
}
} else {
if (rmin.y<rmin.z) {
z.y+=zoff.y;
} else {
z.z+=zoff.z;
}
}
}
if (n<ColorIterations) orbitTrap = min(orbitTrap, (vec4(abs(z),dot(z,z))));

n++;
}

r2=(max(abs(z.x),max(abs(z.y),abs(z.z)))-1.);

return r2*pow(Scale,float(-n));
}

@ Syntopia-  Just noticed your message.  First part I get (about the GLSL compiler).  Makes sense to lock branches.

  2nd part "The compile time does not double when you add an if-statement."

  I believe (I could be wrong, can try to duplicate if you'd like) I've ended up increasing compile time exponentially with each additional if statement (of one specific variety).

  Basically, I set up an integer check (not if -- else!):
Code:

vec3 example (vec3 hrmm) {
  if (check==1) { code  }

  some code.....

  if (check==2)  { code }

 some code

  if (check==3) { code }

  some code ...   etc.

  When I did it this way, each additional if statement doubled the compile time (from 752 to 1484 to 2888 or something along those lines- I had other stuff going on).  I can probably duplicate it if you want.  Yes.  I did offer to attempt to duplicate it twice.  

* Stellate DE.frag (4.73 KB - downloaded 76 times.)
« Last Edit: December 21, 2012, 09:00:25 AM by M Benesi » Logged

Sockratease
Global Moderator
Fractal Senior
******
Posts: 3181



« Reply #9 on: December 21, 2012, 12:02:49 PM »

Ok, here's a frag for the DE Stellated CubeOctohedron.  Uncheck the "stellated" boolean (in the fractal tab) to make a standard one.

No Fair!!

I have been wanting a 3D Model of a CubeOctahedron ever since I saw the documentary "Black Whole" about Nassim Haramein's work.  His views are a bit far-fetched, but his findings about this structure are fascinating!

But...

I can't even run Fragmentarium on my hardware sad

Anybody (Darkbeam?) care to try to implement the formula in Mandelbubl3D so I can try to make an obj from a voxel stack?

Logged

Life is complex - It has real and imaginary components.

The All New Fractal Forums is now in Public Beta Testing! Visit FractalForums.org and check it out!
eiffie
Guest
« Reply #10 on: December 21, 2012, 05:42:36 PM »

Wow kali I didn't think the fog shadows would be as easy as you thought - maybe they weren't. But great job!!! Now I am scratching my head on how you did it smiley
Logged
knighty
Fractal Iambus
***
Posts: 819


« Reply #11 on: December 21, 2012, 06:04:52 PM »

@Benesi: I don't think that a stellated cubeoctahedron based fractal is achievable as a KIFS (meaning using only foldings and no "if' statement). After factoring the symmetries of the figure one needs to apply two scalings: one about the vetex of the cube and the other about the vertex of the octahedron. These two transformations are not symmetric. A recursive algorithme (which needs a stack) would be necessary... or just accept a non continuous DE.

The only advantage of KIFS over IFS is that it's possible to get a DE with an iterative algorithm. The drawback is that the obtained figures are always "very" symmetric.

@Kali: Those volumetric effects are Wow
Code:
#info Faceted sphere Distance Estimator just like Darkbeam's discoballIFS
#include "DE-Raytracer.frag"
#group discoballIFS

// Number of faces in xy and yz planes.
uniform int Nfaces;  slider[0,9,100]

vec2 fold2D(vec2 p, vec2 fp){//algorithmically this is O(n)... It could be done in O(log(n)). Gess how ;o)
vec2 ap=p+vec2(1.);
int i=0;
while(i++<20 && any(notEqual( p, ap))){
ap=p;
p.y=abs(p.y);
float t=2.*min(0.,dot(p,fp)); p-=t*fp;
}
return p;
}

float DE(vec3 p) {
#define PI 3.14159
float angle = PI/float(Nfaces);
vec2 foldingPlaneNormal=vec2(sin(angle),-cos(angle));
p.xy=fold2D(p.xy,foldingPlaneNormal);
p.xz=fold2D(p.xz,foldingPlaneNormal);
return p.x-1.;
}
Logged
M Benesi
Fractal Schemer
****
Posts: 1075



WWW
« Reply #12 on: December 22, 2012, 04:19:29 AM »

@Benesi: I don't think that a stellated cubeoctahedron based fractal is achievable as a KIFS (meaning using only foldings and no "if' statement). After factoring the symmetries of the figure one needs to apply two scalings: one about the vetex of the cube and the other about the vertex of the octahedron. These two transformations are not symmetric. A recursive algorithme (which needs a stack) would be necessary... or just accept a non continuous DE.

The only advantage of KIFS over IFS is that it's possible to get a DE with an iterative algorithm. The drawback is that the obtained figures are always "very" symmetric.

  Yeah.  There is a bit of weirdness with the stellated vs. normal (using the same DE):
Logged

Kali
Fractal Supremo
*****
Posts: 1138


« Reply #13 on: December 22, 2012, 06:01:30 AM »

@Benesi/@knighty: thanks! I'll try the codes later...

Wow kali I didn't think the fog shadows would be as easy as you thought - maybe they weren't. But great job!!! Now I am scratching my head on how you did it smiley

Thanks! Well, no fake stuff this time... I added a fixed-step volumetric tracer to test if the point is on the light path or under shadow.
This is the main cause for being slow... I'm trying with bigger fixed-steps and then jittering using progressive renderer, it works faster and still looks ok. But my goal is to achieve real-time rendering so I must find another tricks and optimizations.

A short animation: (I'm too lazy and impatient for longer ones  embarrass)

<a href="https://dl.dropbox.com/s/z6reuqxayc3f2iw/volumetric_light_test.swf" target="_blank">https://dl.dropbox.com/s/z6reuqxayc3f2iw/volumetric_light_test.swf</a>

« Last Edit: December 22, 2012, 06:05:03 AM by Kali » Logged

eiffie
Guest
« Reply #14 on: January 03, 2013, 05:49:01 PM »

So every time Knighty posts links to papers I quickly download them, start reading, hit a math formula and stop, figure I can wing it from there - and then things go bad smiley but this worked!
The idea is to place the camera in the light first and create a spherical depth texture then instead of DE checks along the ray you simply check the distance to the light against the depth texture and add fog if less than.
Code:
void main() {//first pass - render from light's perspective to get a depth texture
vec2 pt=(gl_FragCoord.xy/vec2(resolution))*PI;//map screen coords to sphere
vec3 rayDir = vec3(sin(pt.y)*cos(pt.x),cos(pt.y),sin(pt.y)*sin(pt.x));
vec3 ray = lightPosition;//place the camera at the light
float rayLen=0.0,dist=lightFallOff;
for(int iSteps=0;iSteps<MaxSteps && dist>=HitDistance && rayLen<=lightFallOff;iSteps++){
rayLen+=dist=DE(ray+rayLen*rayDir);
}//march until you hit something or the light gets too weak
rayLen=clamp(rayLen/lightFallOff,0.0,0.99);
gl_FragColor = Encode(rayLen);//for non-float textures just shove the float into bytes
gl_FragDepth = rayLen;
}
void main() {//second pass - draw the scene as usual then fill in fog
... usual rendering code here ...
... rayLen has depth of scene, ray is position of hit, color has color:)

for(float rl=0.0;rl<rayLen;rl+=fogStep){//take small steps along the ray checking depth
vec3 lightCamDir=ray+rayDir*rl-lightPosition;//get the direction FROM light
float d=length(lightCamDir);
lightCamDir=normalize(lightCamDir);
float phi=acos(lightCamDir.y);//map back to screen coords
vec2 pt=vec2(acos(lightCamDir.x/sin(phi)),phi)/3.1416;
//add fog light only if the distance to the light is less than that in texture
if(d<Decode(texture2D(tex,pt))*lightFallOff)color.rgb+=fogColor/(d*d);
}
}
You could do these two passes in Fragmentarium using the backBuffer and the backBufferCounter to flip back and forth then throw away every other frame.

<a href="http://www.youtube.com/v/AnA3s3ncL94&rel=1&fs=1&hd=1" target="_blank">http://www.youtube.com/v/AnA3s3ncL94&rel=1&fs=1&hd=1</a>
Logged
Pages: [1] 2 3   Go Down
  Print  
 
Jump to:  


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