FRGMENTARIUM 3DICKULUS - Catmull-Rom spline paths ! camera/parameter keyframes !

[vinz]

Hahahaha Excellent ... for sure this is a usefull mod 

[3dickulus]

What I've got so far re object occlusion...

1 is just rendered over the quad with no depth test

2 is rendered over the quad with the following code at the end of successful hit in the DErt

Code:

          gl_FragDepth =  gl_FragCoord.z / gl_FragCoord.w;
	}
	else {
		hitColor = backColor;
		hitColor +=Glow.xyz*stepFactor* Glow.w*(1.0-shadowStrength);
          gl_FragDepth = 1.0;
	
	}

the FragDepth lines are the ones I've added, object = calc-depth,  background = farthest
obviously not right but getting there

[marius]

Code:

          gl_FragDepth =  gl_FragCoord.z / gl_FragCoord.w;
	}
	else {
		hitColor = backColor;
		hitColor +=Glow.xyz*stepFactor* Glow.w*(1.0-shadowStrength);
          gl_FragDepth = 1.0;
	
	}

the FragDepth lines are the ones I've added, object = calc-depth,  background = farthest
obviously not right but getting there

I have been Z-buffer drawing opengl camera path lines on top (and behind) fractals for a while w/ http://code.google.com/p/boxplorer2,
for example https://lh4.googleusercontent.com/-zg_rHyqR4ME/Tf6ByIWh61I/AAAAAAAATaM/aCoJpV_CpkM/20110619_160710.jpg.

Key is to put compatible values in the Z-buffer. Which requires a notion of near and far plane distances and field of view.

See for instance https://code.google.com/p/boxplorer2/source/browse/trunk/cfgs/rrrola/fragment.glsl#291.
And https://code.google.com/p/boxplorer2/source/browse/trunk/boxplorer.cc#367.

'speed' is actually the DE at the camera location, btw.
Which I have run-time in both shader and C++ by compiling (some part of some version of) the shader code also as C++.

When you start drawing w/ opengl primitives in a double precision fractal you'll also quickly hit precision problems if you do not make the camera be the origin as far as the opengl primitives are concerned.

Camera flight path visualization quickly breaks down in combination with time-morphed fractals, of course 

-marius

[3dickulus]

thanks for the input marius, very helpful,
I'll have to start digging into the GLSL side a little, no "speed" variable in this rt, but I'll spend some time studying the code and see if I can make the leap.

[eiffie]

If you are using OpenGL calls to draw the path (and relying on the depth buffer to occlude for you) then for sure you need marius' code. It helped me out too! If you are just simply drawing lines with qt or determining the occlusion yourself then simply set gl_FragDepth=totalDist/MaxDistance and check that against distToPath/MaxDistance. (distToPath=distance from camera to path and MaxDistance=100.0 in DE-Raytracer.frag)

wooops just read your note in the other thread so you are drawing with OpenGL - use marius' code which looks something like this...

Code:

float zNear = 0.001;
float adt = MaxDistance / (MaxDistance - zNear);
float bdt = MaxDistance * zNear / (zNear - MaxDistance);
gl_FragDepth = (adt + bdt / clamp(totalDist/length(dir), zNear, MaxDistance));

[3dickulus]

The infos I have to go on is..
linear Z buffer = ( Z - nearZ ) / ( farZ - nearZ )
non-linear Z buffer = ( 1/Z - 1/nearZ ) / ( 1/farZ - 1/nearZ )
GL uses non-linear afaik
in GLcoords... coord.w = 1/coord.z so the above would be zb = ( coord.w - 1/0.001 ) / ( 1/100.0 - 1/0.001 ) using the near/far values used in frag and GL code

my spline paths work, they are in the right place in 3D space so in my mind the depth buffer should be accurate and GL should be able to do the occlusion the same way it does for any 3D object it renders

in Fragmentarium source in the drawFragmentProgram routine

Code:

glDisable( GL_DEPTH_TEST ); // disables testing but not writing

so I have wrapped the glRectF like this

Code:

glDepthMask(GL_FALSE); // disables writing to depth buffer but not testing
				glRectf(-1,-1,1,1);
glDepthMask(GL_TRUE); // we don't want the rect to obscure anything in the depth buffer

so automatic testing and writing are off, correct me if I'm wrong but this allows the fragment code to write to the depthbuffer manually
and prevents GL from changing it so I should be able to turn testing back on to draw the splines after the frag populates the Zbuffer

gl_FragDepth = 0.0 for a hit and gl_FragDepth = 1.0 for everything else should give me at least a masking occlusion effect

[marius]

in Fragmentarium source in the drawFragmentProgram routine

Code:

glDisable( GL_DEPTH_TEST ); // disables testing but not writing

so I have wrapped the glRectF like this

Code:

glDepthMask(GL_FALSE); // disables writing to depth buffer but not testing
				glRectf(-1,-1,1,1);
glDepthMask(GL_TRUE); // we don't want the rect to obscure anything in the depth buffer

so automatic testing and writing are off, correct me if I'm wrong but this allows the fragment code to write to the depthbuffer manually
and prevents GL from changing it so I should be able to turn testing back on to draw the splines after the frag populates the Zbuffer

gl_FragDepth = 0.0 for a hit and gl_FragDepth = 1.0 for everything else should give me at least a masking occlusion effect

Known to work for me:

    glEnable(GL_DEPTH_TEST);
    glDepthFunc(GL_ALWAYS);

then call fractal shader that writes every pixel's Z (but there is not filtering test due to GL_ALWAYS).

then

     glDepthFunc(GL_LESS);

then draw GL_LINES or any GL primitives and get per pixel occlusion against the fractal.

I don't call glDepthMask() anywhere.

[3dickulus]

indeed that is the simplicity I had in mind and started with some time ago, so I will go over my changes again and see where I went wrong.

thanks marius

[3dickulus]

I'm not a mathematician or professional coder,  my best guess leads me back to a matrix issue, off by some degrees?scale?
the method described by marius above is essentially where I started with my attempts at occlusion, seemed a logical assumption based on my GL experience,
the draw commands in the spline object, spline->drawSplinePoints() and spline->drawControlPoints() expect the GL context and rendering matrix to be setup by the GL calling object, all they do is draw, I don't use any matrix maths or translations to place or scale the points as they are generated with respect to current camera and perspective settings are as the caller sets them.
lines and points all seem to be in the right locations, perspective and scale but not in the zbuffer?

[marius]

I'm not a mathematician or professional coder,  my best guess leads me back to a matrix issue, off by some degrees?scale?
the method described by marius above is essentially where I started with my attempts at occlusion, seemed a logical assumption based on my GL experience,
the draw commands in the spline object, spline->drawSplinePoints() and spline->drawControlPoints() expect the GL context and rendering matrix to be setup by the GL calling object, all they do is draw, I don't use any matrix maths or translations to place or scale the points as they are generated with respect to current camera and perspective settings are as the caller sets them.
lines and points all seem to be in the right locations, perspective and scale but not in the zbuffer?

So on screen lines look like where you want them to be but just not occluded where you expect them to be? Might be hard to judge.

Does your glFrustum() call have the same zNear, zFar and field of view as the fractal shader?

Does the fractal shader do something like:
  float a = zFar / (zFar - zNear);
  float b = zFar * zNear / (zNear - zFar);
  gl_FragDepth = (a + b / clamp(totalD/length(raydir), zNear, zFar));

You know the difference between glMatrixMode(GL_MODELVIEW) and glMatrixMode(GL_PROJECTION)?
Is the GL_MODELVIEW for the fractal shader the same as for opengl primitives?
Or does the fractal shader assume eye at (0,0,0)?

Is the depth buffer set up correctly and filled by the fractal shader at all?
Try read it out and dump to file as a first test. Perhaps there is no depth buffer properly attached at all?

What does glError() say during all this? Anything but GL_NO_ERROR is bad news.

If it is any consolidation, it took a fair amount of explicatives before I had the various projections and Z buffer values in agreement

[3dickulus]

lines and points are where they should be, at least when I rotate, pan and zoom they look like they are but when looking at a static view there is no depth cue and hard to judge if the path goes through solid or empty space, that's the only reason I'm trying to get occluding to work, don't really need it for just saving keyframes as one roams around but it would be helpful.

using gluPerspective() and gluLookAt() with the values from the camera target and up pos.xyz and afaik near and far are 0.001 and 100.0

the shader does not appear to set gl_FragDepth, the only one I've seen that does is eiffieGI.frag

modelview is relative to object, projection is relative to camera

I'm not entirely sure of the inner workings of the GLSL code regarding assumptions about eye(0,0,0)

I don't pop or push a matrix or loadidentity in the spline part, it just calls draw commands on the current context/view/matrix

no, I don't think the shader is concerned at all with the GL zbuffer, at least not in an outright manner, when a vert/frag shader writes a pixel doesn't that cause GL to calculate and write the zbuffer for display purpose?

haven't specifically tested glError() or looked at a dump of zbuffer, view as an image? but that's a definite todo

so just need to get the shader populating the zbuffer with the right transform for the primitives to use, sounds simple enough

edit: when target is at 0,0,0 I see the object (bulb) center screen and eye is 2,0,0

[Syntopia]

Hi,

I've been on vacation without internet for a while, so I haven't followed this thread.

Fragmentarium does not use the ModelView matrix and Projection matrix to set up the camera. The ModelView matrix is unused, and the Projection matrix is only used to setup the tile rendering - normally it is just unity. The advantage of this is that it is possible to do more complex projections (such as equirectangular projections), but the downside is that coupling with standard OpenGL will be harder. But I guess you are already setting the OpenGL camera yourself with gluPerspective(): Start by creating some boxes/spheres at various position using both OpenGL and GLSL and check that they are aligned when moving the camera, changing the FOV and so on.

Also notice that the intermediate buffers used by Fragmentarium does indeed not create depth buffers, as Marius suggested - this can be changed though: try searching for the QGLFramebufferObject(...) constructor and make sure that QGLFramebufferObject::NoAttachment is changed to QGLFramebufferObject::Depth.

What do you write to gl_FragDepth and where do you do it?

[3dickulus]

in DErt-v0.9.10.frag trace routine I tried 0.0 for a hit and 1.0 for background and floor, just for a simple mask effect with some odd results as well as a number of different formulas found on the net and suggested by other users, no useable results yet, as far as placement and perspective go they seem good, I think there might be an issue with the way the accumulative rendering mode works, will have to let the depth buffer accumulate too or be full of holes.
With my limited math skills I could see that the internal workings are not GL-centric but my logic says "distance from eye to object factored between 0 and 1 stored in zbuffer = occlusion"  so here I am 

yes, studied marius' code and read GL docs on how QGLFramebufferObject(...) works, taking a minor detour from GL code with setting the focalplane to track the target distance, request by Vinz, only 3 or 4 lines, back to GL tomorrow? will enable the depth buffer and try the simplest no math type of test 0 or 1 hit/miss for a mask type effect and if that works out I'll proceed with trying to populate it.

[3dickulus]

hey vinz, you mean like this...

<a href="http://vimeo.com/moogaloop.swf?clip_id=70625008" target="_blank">http://vimeo.com/moogaloop.swf?clip_id=70625008</a>

easy to attach the focal plane to the target because it's already moving on a spline
and makes sense to follow target with observer focus but
Aperture and Details will need a control scheme that gets the desired effect and makes sense

hm... back to occlusion

[eiffie]

What the heck I will post it again. You need to populate the depth buffer with this...

Code:

float zNear = 0.001;
float adt = MaxDistance / (MaxDistance - zNear);
float bdt = MaxDistance * zNear / (zNear - MaxDistance);
gl_FragDepth = (adt + bdt / clamp(totalDist/length(dir), zNear, MaxDistance));

There may be other issues but you at least need to do this. It is the same as Marius' code but with Fragmentarium's variables.