Research Footprints

To perform texturing, three primary decisions must be made

1. texture target (GL_TEXTURE_2D, GL_TEXTURE_RECTANGLE_ARB and so forth)
2. texture format (GL_LUMINANCE, GL_RGBA and so on)
3. internal format (NV_FLOAT_BUFFER, ARB_TEXTURE_FLOAT etc)

Just links that helped me get out of tight spots.

1.Using rectangle textures on the GPU (Cg specifically)
http://www.mathematik.uni-dortmund.de/~goeddeke/gpgpu/tutorial.html#arrays3

2.The Official GPGPU FAQ
http://www.gpgpu.org/wiki/FAQ#Why_do_I_get_all_zeros_.28black.29.3F

This is intended to be a list of the most annoying (as in "I'm-about-to-throw-the-phone-at-the-monitor annoying") errors and how to get around them.

1. Error Using GLUI
I used glui and zlib together and got this:
'char' followed by 'char' is illegal (in the zconf.h)
Hack: include glui.h after everything else

2. GLUT conflict with exit() in Visual Studio 2005 and .NET 2003
Using GLUT in .net2003 or Visual Studio 2005, gives the error
C:\Program Files\Microsoft Visual Studio 8\VC\include\stdlib.h(406) : error C2381: 'exit' : redefinition; __declspec(noreturn) differs
Hack: To fix the error, right click on the project name in the Solution Explorer tab and select Properties -> C/C++ -> Preprocessor -> Preprocessor definitions and append GLUT_BUILDING_LIB to the existing definitions, seperated by semicolons.

-Ray Tracer (Intersection)
The imprecise intersection remains a problem for the GPU terrain renderer. One possibility for this is using a 32 bpp TGA image instead of currently the PPM image. Other option (and/or) is to use quadratic interpolation instead of using a piecewise linear one for the heightfield.
The intersection routine itself is not perfect. alternatives - binary search planes, exhaustive intersection and PCA, wavelet compression, storing large precomputed data.

-Bounding Volume
It is possible to create a progression of bounding volumes starting from AABB to k-Dops to convex hull.

This has tormented me now for quite a while. I dont know what it is, the counter-intuitive specs or the complicated API but I have now been using the Vertex buffer Object extension for a few months and every time it takes me a while before I get it right. Lets put to rest the issues.

- Building the VBOs

This is done using

glGenBuffersARB( 1, &vertexVBO );
glBindBufferARB( GL_ARRAY_BUFFER_ARB, vertexVBO );
glBufferDataARB( GL_ARRAY_BUFFER_ARB, num_points*3*sizeof(GLfloat), (GLfloat*)&P[0], GL_STATIC_DRAW_ARB );
glVertexPointer( 3,GL_FLOAT,0,0);

these are fairly straightforward but the caveat is that you cant pass objects of user-defined types into the glBufferDataARB. For example, I had a list of points I had to store in the VBO. The list of points was stored as a vector of "GLPoint" type objects where GLPoint is a class I had written. But this didnt work (or as a professor of mine taught me to say "I couldnt get it to work"). The strangest thing would happen and I must describe it here. I was simply trying to render the bunny with points but if I used my vector of "GLPoint" objects, it would draw extraneous points, there would be four bunnies each one with some missing points. And one bunny would be the correct one, the other three being projections on to the coordinate planes. you dont get a word of this, well see for yourself at...http://photos1.blogger.com/blogger/1592/970/1600/weirdbunnies1.jpg

!!! ... so I read up all kinds of stuff about VBOs and glDrawRangeElements. Finally, I copied the array into a vector of GLfloats and then created the VBO with that and it worked fine. If anyone can throw light on this please email me ... mail dot saifali at gmail dot com


- Using the VBOs
Drawing the VBO with glDrawRangeElements is also fairly straightforward. But the parameters might be confusing at first use.
void glDrawRangeElements
( GLenum mode
, GLuint start
, GLuint end
, GLsizei count
, GLenum type
, const GLvoid *indices
);

mode - type of primitive (GL_POINTS, GL_QUADS, GL_TRIANGLES and so on)
start - the lowest *vertex* index you will find in "indices"
end - the highest *vertex* index you will find in "indices"
(start and end are to determine what range of data the current call will require, this is good for optimization and pre-fetching)
So if "indices" contains indices of vertices right from vertex 0 to (vertexArraySize-1) then the values of start and end are 0 and (vertexArraySize-1) respectively
count - this is simply the number of elements in the "indices" array (not related to start and end)
type - the data type of the elements in the "indices" array
indices - the array containing the index data

a useful pointer from the GameDev forum ... INDEX_ARRAY has nothing to do with vertex-indexing, it is used for color indexing.

Finally, I could get it to work (http://photos1.blogger.com/blogger/1592/970/1600/weirdbunnies.0.jpg). hopefully the next time I use VBOs and glDrawRangeElements I wont have to write another treatise.

------------
But, I must keep writing still. problems persist. The above works for the bunny but not for the budhdha or dragon. Again Im getting three instead of just one. Some more research ensues.

- Invalidating the VBO

Gamedev forum says the following about invalidating a VBO,

- Bind the VBO
- Call the glBufferData() function with NULL as the data address, this informs the driver that you are done with that VBO and it is free to reclaim it as soon as it likes/can
- Call glBufferData() again with your real data (this will allocate a new buffer for the data which can be a new size).

This is required for dynamic VBO data swapping.

-relation to parallel movements
indie music/podcasts/web tv

-enthusiasm - similar to the VR movement
relates to the appropriation of a medium from the corporate to the personal realm
non-entertainment applications - pre-production, pitches, game/tool tool/game,
hypothetical situation - I want to open up an ad-film company which utilizes a game engine from the Unreal Tournament 2004. How does the company react after my profit goes through the roof ?

-taxonomy
machinima
speedrun
VJ


Research potential
powerful camera models / tools for Machinima
- depth of field
- smooth panning and tracking
- different lenses


-more and more of the game development software and tools will be exposed. How in this environment would a company maintain the innovative edge.
-propreitary software and engines would gravitate towards more centralized and portable models


Machinima promises to raise new questions in computer graphics and rendering research. The underlying goal of most real time rendering ventures is that the space of possible interations is inifinite. In practice this goal is never reacehd and game developers always constrain the space of possible interactions by a player. In Machinima however, the game state is partially or fully pre-determined. This means a lot of the action can be pre-computed. This brings up new possibilities for development of rendering algorithms. To sum up, the tools for making machinima need to be very flexible but the rendering algorithm do not. This means that research should focus on providing maximum leverage during the design and less during rendering. Thus, Machinima occupies a unique niche between fully real time applications and fully pre-rendered ones. Research focus should be on
- tools to create machinima
- algorithms to render machinima

for rendering algorithms, a difference kind of flexibility is required. The rendering should be viewable on different hardware at different resolutions seamlessly. This is typically not a consideration in present-day real time rendering research ... speed somehow occupies the central role. But with the application of real time rendering engines to Machinima, this could change.

Sources:

GPU Gems II
Ch32: Taking the Plunge into GPU Computing

SIGGRAPH 2005 Course : GPU Memory Models
http://www.gpgpu.org/s2005/slides/lefohn.MemoryModelOverview.ppt


Arithmetic Intensity:
GPU far superior in computation then in memory performance. Best performance in sequential access. GPU pipeline begins to compute next fragment in the time that memory is accessed (texture fetch). Arithmetic intensity = number of artihmetic operations interleaved with texture fetches to hide the cost.
Pixel format consideration:
Look at native GPU pixel format (RGBA, GRBA ?) ... conversion could incur overheads.
Floating point format consideration:
CPU's generally have a common floating point standard whereas GPU manufacturers implement different ones.
Address Calculation Issues:
Limited precision may introduce errors in address calculation if we are calculating indices into large 1D arrays.

Scattering on GPU - not possible directly,
solutions:
->implemented by converting the scatter into a gather operation essentially by some two-pass strategy.
->point rendering, application uses points to render, vertex program picks up the scatter address from texture (and if no vertex texture then vertex / pixel buffers) and assigns it to the point destination along with the scatter data.

Gather on GPU - straightforward


Further reading:
Buck and Purcell 2004, Sorting and Searching on the GPU
Ch: 46, GPU Gems II, Improved GPU Sorting
What Every Computer Scientist Should Know about Floating Point Arithmetic, David Goldberg, 1991, ACM Computing Surveys

About computing texture space

Right now, my base plane is just a quad in the XZ plane so the space coincides with the world space with the difference that the Z coordinate is negated. So to transform any vector from world space to texture space, we just take the negative of the z-coordinate. The vectors that we need to transform are:

1. the view vector (the viewing ray basically) compute this as the vector from the viewpoint (origin) to the current vertex in the vertex shader
2. the light vector

http://www.gameprogrammer.com/fractal.html

The Diamond Square Algorithm (Fournier, Fussel and Carpenter) - fractal based generation of complexity
(The 1D version is as follows) - Recursively (or oteratively) divide a line segment into equal halves and offset the mid-point by a random number at each step reducing the range of the random number generation.
Roughness constant = scalar that determines the roughness or the jaggedness ofthe resulting terrain

Height Maps - a 3D array with a height value attached to each 2D location. This can also be used to generate cloud texture maps when rendered as images.
Tesellation of the height map - look at http://www.javaworld.com/javaworld/jw-08-1998/jw-08-step_p.html for a much better description ofthe diamond square method of recursive subdivision.



note - wrapping behavior, if we go out of the array and dont have a diamond corner to read, wrap around the array, this ensures that the height map is seamlessly wrappable.

Terminology

Continous Level-of-Detail
Adaptive Meshes
View dependent triangulation
geometry clipmaps

The tasks move me in the general direction of expanding my codebase. They are as follows:

1. OBJ Class - load from file
2. OBJ Class - compute tangent space
3. Write simple camera class



Progress: At the end of todays session. I could manage to sort of redo and clean up the code for the OBJ class. Its not complete but more consolidated and more elegant. Couldnt get started on the camera class. Ah well. theres always tomorrow.

List of variables to be passed to shaders from application

vertex position
surface normal
tangent vector
light position


Varyings
light direction (to Vertex shader)
eye direction (to Vertex shader)


Uniforms
light position (to Vertex shader)

Attributes
the Tangent vector (to the vertex shader)


the bump mapper actually works ! :-) ... results are pathetic though. :-(

Before I go into GLSL stuff, there is one thing that needs clarification. The difference between texture space and the tangent space. The texture space dimensions are specified by the OpenGL constants GL_TEXTURE_2D, GL_TEXTURE_1D ... so if we have a normal map for polygons then it is a 2D map as it is restricted to the 2D plane of the polygon. But the tangent space is the space made up of the normal (which is a 3D vector looked up from the 2D normal map .. if that makes sense) .... and two other vectors orthogonal to the normal map. This is courtesy Søren Dreijer (http://www.blacksmith-studios.dk/projects/downloads/tangent_matrix_derivation.php) which provides a great tutorial on how to derive the tangent space.

It turns out the above mentioned tutorial had to be discarded in favor of a more conceptually enriching one available here : http://www.netsoc.tcd.ie/~nash/tangent_note/tangent_note.html
This tutorial has better explanations.

DOT3 Bump Maps - bump mapping involving a dot product between two 3D vectors.
1. The light vector or the half angle vector
2. The normal vector at that particular pixel

Both vectors must be defined in the same space. This could be
1. View Space
2. World space
3. Model Space

Texture Space - definition and importance (for the nth time)

The Z-axis of this space is approximately (?) parallel to the vertex normal
The x and y axes are perpendicular to the z axis and can be arbitrarily oriented around it

The texture space is a 'surface-local' basis in which our normal maps are defined. Since the normal map is defined in Texture Space, we must also define the light vector in the texture space for the dot product to make sense.

The problem Im facing so far is that what I have in my program is a Gaussian height map which is different from a bump map. Since the goal is to write a simple bump mapper, the height map must be replaced by a bump-map and a normal map. The question - how to obtain a bump-map.

This is what a bump-map is - its a grayscale image. The lighter portions are rendered as raised and the darker areas appear as depressions.

Basic bump mapper in GLSL (from the Game Programming Wiki - http://gpwiki.org/index.php/OpenGL:Tutorials:GLSL_Bump_Mapping)

types of variables (once and for all)
uniform - passed from program to a shader, cant be changed in the middle of rendering, used for light direction (doesnt change often)
varying - passed from a vertex shader to a fragment shader, must be declared in both,
attribute - sent from the program to the vertex shader for every primitive (polygon), examples - color, normal, vertex position, values are interpolated if smooth shading is enabled by the program

Have to run home to cook.
On getting back - to pick up from reading (thats a good thing to do sometimes) ... page 235 of the Orange Book (yellow?)
The section on Stored Texture Shaders. Implement one by tonight maybe.
... so .. on to spinach and potatoes.

I have embarked on a journey to implement the arcball interface using quaternions.

so here's how it is

on mouse-left-button-down

project the point at which mouse was clicked on to the (imaginary) sphere filling up the screen
(it is (x,y,sqrt(1 - x*x - y*y)) )
calculate the vector from the center of the sphere to this point (radius vector)

then on the drag event capture the mouse coordinates, project and calculate the radius vector again

calculate the cross product of these two radius vectors

that gives us the axis

the angle between them gives us the angle

now we can form a quaternion

and hence the matrix

note: the center of the sphere must coincide ( I think) with the centroid of the object being viewed. ?

this is the algorith from http://www.fas.harvard.edu/~lib175/chapters/quat.pdf

Imagine a hemisphere sitting on top of your window. You can decide where to
center the hemisphere ˜c and how big to make it. You can display the intersection
of the hemisphere and the window by drawing the appropriate circle.
• When the user clicks on a pixel within the circle, that point is lifted up off the
screen until it hits some point ˜p0 on the imaginary hemisphere.
• Computer the vector ˜p0 − ˜c, and normalize it to obtain ˆv0
• When the user now moves the mouse to some second point, repeat these steps to
obtain ˆv1
• Imagine the arc along the hemisphere connecting ˜p0 and ˜p1. The axis of rotation
can be computed as ˆa = ˆv0׈v1. The angle  of the arc satisfies cos() = ˆv0·ˆv1
• Interpret this user interaction as a request to perform a rotation of  = 2 arond
ˆa.

now ... to code.

More complications are seen. The point here is - start small. A simple ray tracer is to be implemented - in fact just a single step - so a ray caster. no reflections, no shadows, ... simple. the confusion is how are the tasks divided - which brings up the question - what is the optimal division of tasks ? ... must we do EVERYTHING on the GPU ... or divide them in such a way that they work seamlessly and overall efficiency is maximised ? - just a thought.

Application (CPU)
provides scene geometry and acceleration data structure (as textures)

Shaders (GPU)
acceleration structure traversal
intersection tests
shading

textures

1. ray origins
2. ray directions ( do we need this one ? possible to generate ray directions on the fly? )


important distinction: ray tracing a height map is a problem with different complications than ray tracing geometry. how are they different ?
... ray tracing a height map typically should not require an acceleration data structure. it should be based on texture lookup (looking up the height map in the pixel shader)

plan: code a bump mapper - to see how texture memory and the like can be used.

Ok .. future plan for coding.
Writing the shaders. Before that - what work will be done in the vertex shader, what in the pixel shader. What uniforms, attributes and varyings?

viewing direction
displacement map
TBN matrix (the inverse actually) to transform the eye/view vector to texture space

division of tasks ...


Vertex Shader
project vertex to get coordinates in clip space
calculate view vector ? (it will be interpolated in the fragment shader - varying variable)
texture coordinates


Fragment Shader
get view vector for current pixel
transform to texture space
compute sampling points along ray
at these points, look up texture to get height
see if the sampling point is above the height map or below (using 'z' coordinate?)
find the point where there is a change in sign (above to below / below to above)
use binary search to find point of intersection (within error threshhold ?)
lookup the texture to find the color at that point - thats the final color for the fragment - write it out to the frame buffer


this is all I got. I havent slept enough and Im struggling with the ray cast volume rendering.