<?xml version="1.0" encoding="utf-8"?>
<!-- If you are running a bot please visit this policy page outlining rules you must respect. http://www.livejournal.com/bots/ -->
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:lj="http://www.livejournal.com">
  <id>urn:lj:livejournal.com:atom1:saifjournal</id>
  <title>Research Footprints</title>
  <subtitle>notes, observations, confusions, questions</subtitle>
  <author>
    <name>saifjournal</name>
  </author>
  <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/"/>
  <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom"/>
  <updated>2006-11-08T23:25:59Z</updated>
  <lj:journal userid="8669603" username="saifjournal" type="personal"/>
  <link rel="service.feed" type="application/x.atom+xml" href="http://saifjournal.livejournal.com/data/atom" title="Research Footprints"/>
  <link rel="hub" href="http://pubsubhubbub.appspot.com/"/>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:5923</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/5923.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=5923"/>
    <title>GPU Textures</title>
    <published>2006-11-08T23:25:59Z</published>
    <updated>2006-11-08T23:25:59Z</updated>
    <content type="html">To perform texturing, three primary decisions must be made&lt;br /&gt;&lt;br /&gt;1. texture target (GL_TEXTURE_2D, GL_TEXTURE_RECTANGLE_ARB and so forth)&lt;br /&gt;2. texture format (GL_LUMINANCE, GL_RGBA and so on)&lt;br /&gt;3. internal format (NV_FLOAT_BUFFER, ARB_TEXTURE_FLOAT etc)</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:5840</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/5840.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=5840"/>
    <title>Useful Links</title>
    <published>2006-11-08T23:06:23Z</published>
    <updated>2006-11-08T23:06:23Z</updated>
    <content type="html">Just links that helped me get out of tight spots. &lt;br /&gt;&lt;br /&gt;1.Using rectangle textures on the GPU (Cg specifically)&lt;br /&gt;  &lt;a href="http://www.mathematik.uni-dortmund.de/~goeddeke/gpgpu/tutorial.html#arrays3"&gt;http://www.mathematik.uni-dortmund.de/~goeddeke/gpgpu/tutorial.html#arrays3&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;2.The Official GPGPU FAQ&lt;br /&gt;  &lt;a href="http://www.gpgpu.org/wiki/FAQ#Why_do_I_get_all_zeros_.28black.29.3F"&gt;http://www.gpgpu.org/wiki/FAQ#Why_do_I_get_all_zeros_.28black.29.3F&lt;/a&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:5443</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/5443.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=5443"/>
    <title>Popular Errors and Hacks</title>
    <published>2006-10-31T21:52:17Z</published>
    <updated>2006-11-08T00:31:28Z</updated>
    <content type="html">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.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;1. Error Using GLUI&lt;/b&gt;&lt;br /&gt;I used glui and zlib together and got this: &lt;br /&gt;'char' followed by 'char' is illegal (in the zconf.h)&lt;br /&gt;Hack: include glui.h after everything else&lt;br /&gt;&lt;br /&gt;&lt;b&gt;2. GLUT conflict with exit() in Visual Studio 2005 and .NET 2003&lt;/b&gt;&lt;br /&gt;Using GLUT in .net2003 or Visual Studio 2005, gives the error &lt;br /&gt;C:\Program Files\Microsoft Visual Studio 8\VC\include\stdlib.h(406) : error C2381: 'exit' : redefinition; __declspec(noreturn) differs&lt;br /&gt;Hack: To fix the error, right click on the project name in the Solution Explorer tab and select Properties -&amp;gt; C/C++ -&amp;gt; Preprocessor -&amp;gt; Preprocessor definitions and append GLUT_BUILDING_LIB to the existing definitions, seperated by semicolons. &lt;br /&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:5232</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/5232.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=5232"/>
    <title>saifjournal @ 2006-09-28T15:14:00</title>
    <published>2006-09-29T00:05:00Z</published>
    <updated>2006-09-29T00:05:00Z</updated>
    <content type="html">-Ray Tracer (Intersection)&lt;br /&gt;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. &lt;br /&gt;The intersection routine itself is not perfect. alternatives - binary search planes, exhaustive intersection and PCA, wavelet compression, storing large precomputed data. &lt;br /&gt;&lt;br /&gt;-Bounding Volume &lt;br /&gt;It is possible to create a progression of bounding volumes starting from AABB to k-Dops to convex hull.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:5056</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/5056.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=5056"/>
    <title>On using VBOs and glDrawRangeElements</title>
    <published>2006-07-17T05:10:11Z</published>
    <updated>2006-07-17T06:34:30Z</updated>
    <content type="html">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. &lt;br /&gt;&lt;br /&gt;- Building the VBOs&lt;br /&gt;&lt;br /&gt;This is done using &lt;br /&gt;&lt;br /&gt;	glGenBuffersARB( 1, &amp;vertexVBO );					&lt;br /&gt;	glBindBufferARB( GL_ARRAY_BUFFER_ARB, vertexVBO );	&lt;br /&gt;	glBufferDataARB( GL_ARRAY_BUFFER_ARB, num_points*3*sizeof(GLfloat), (GLfloat*)&amp;P[0], GL_STATIC_DRAW_ARB );&lt;br /&gt;	glVertexPointer( 3,GL_FLOAT,0,0); &lt;br /&gt;&lt;br /&gt;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...&lt;a href="http://photos1.blogger.com/blogger/1592/970/1600/weirdbunnies1.jpg"&gt;http://photos1.blogger.com/blogger/1592/970/1600/weirdbunnies1.jpg&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;!!! ... 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&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;- Using the VBOs&lt;br /&gt;Drawing the VBO with glDrawRangeElements is also fairly straightforward. But the parameters might be confusing at first use. &lt;br /&gt;void glDrawRangeElements&lt;br /&gt;              	(	GLenum mode&lt;br /&gt;              , GLuint start&lt;br /&gt;              , GLuint end&lt;br /&gt;              , GLsizei count&lt;br /&gt;              , GLenum type&lt;br /&gt;              , const GLvoid *indices&lt;br /&gt;              );&lt;br /&gt;&lt;br /&gt;mode - type of primitive (GL_POINTS, GL_QUADS, GL_TRIANGLES and so on)&lt;br /&gt;start - the lowest *vertex* index you will find in "indices" &lt;br /&gt;end - the highest *vertex* index you will find in "indices" &lt;br /&gt;(start and end are to determine what range of data the current call will require, this is good for optimization and pre-fetching)&lt;br /&gt;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&lt;br /&gt;count - this is simply the number of elements in the "indices" array (not related to start and end)&lt;br /&gt;type - the data type of the elements in the "indices" array&lt;br /&gt;indices - the array containing the index data&lt;br /&gt;&lt;br /&gt;a useful pointer from the GameDev forum ... INDEX_ARRAY has nothing to do with vertex-indexing, it is used for color indexing. &lt;br /&gt;&lt;br /&gt;Finally, I could get it to work (&lt;a href="http://photos1.blogger.com/blogger/1592/970/1600/weirdbunnies.0.jpg"&gt;http://photos1.blogger.com/blogger/1592/970/1600/weirdbunnies.0.jpg&lt;/a&gt;). hopefully the next time I use VBOs and glDrawRangeElements I wont have to write another treatise.&lt;br /&gt;&lt;br /&gt;------------&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;- Invalidating the VBO &lt;br /&gt;&lt;br /&gt;Gamedev forum says the following about invalidating a VBO, &lt;br /&gt;&lt;br /&gt;- Bind the VBO&lt;br /&gt;- 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&lt;br /&gt;- Call glBufferData() again with your real data (this will allocate a new buffer for the data which can be a new size).&lt;br /&gt;&lt;br /&gt;This is required for dynamic VBO data swapping.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:4765</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/4765.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=4765"/>
    <title>Understanding Machinima</title>
    <published>2006-04-24T12:16:40Z</published>
    <updated>2006-04-24T13:33:51Z</updated>
    <category term="machinima research ideas"/>
    <content type="html">-relation to parallel movements&lt;br /&gt;indie music/podcasts/web tv&lt;br /&gt;&lt;br /&gt;-enthusiasm - similar to the VR movement&lt;br /&gt;relates to the appropriation of a medium from the corporate to the personal realm&lt;br /&gt;non-entertainment applications - pre-production, pitches, game/tool tool/game, &lt;br /&gt;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 ?&lt;br /&gt;&lt;br /&gt;-taxonomy &lt;br /&gt;machinima&lt;br /&gt;speedrun&lt;br /&gt;VJ&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;Research potential&lt;br /&gt;powerful camera models / tools for Machinima &lt;br /&gt;  - depth of field&lt;br /&gt;  - smooth panning and tracking&lt;br /&gt;  - different lenses&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;-more and more of the game development software and tools will be exposed. How in this environment would a company maintain the innovative edge. &lt;br /&gt;-propreitary software and engines would gravitate towards more centralized and portable models&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;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 &lt;br /&gt;- tools to create machinima&lt;br /&gt;- algorithms to render machinima&lt;br /&gt;&lt;br /&gt;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.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:4535</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/4535.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=4535"/>
    <title>GPU Memory Model and Optimizations</title>
    <published>2006-04-11T03:44:18Z</published>
    <updated>2006-04-11T03:44:18Z</updated>
    <content type="html">Sources: &lt;br /&gt;&lt;br /&gt;GPU Gems II&lt;br /&gt;Ch32: Taking the Plunge into GPU Computing &lt;br /&gt;&lt;br /&gt;SIGGRAPH 2005 Course : GPU Memory Models&lt;br /&gt;&lt;a href="http://www.gpgpu.org/s2005/slides/lefohn.MemoryModelOverview.ppt"&gt;http://www.gpgpu.org/s2005/slides/lefohn.MemoryModelOverview.ppt&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;Arithmetic Intensity: &lt;br /&gt;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. &lt;br /&gt;Pixel format consideration: &lt;br /&gt;Look at native GPU pixel format (RGBA, GRBA ?) ... conversion could incur overheads. &lt;br /&gt;Floating point format consideration: &lt;br /&gt;CPU's generally have a common floating point standard whereas GPU manufacturers implement different ones. &lt;br /&gt;Address Calculation Issues:&lt;br /&gt;Limited precision may introduce errors in address calculation if we are calculating indices into large 1D arrays. &lt;br /&gt;&lt;br /&gt;Scattering on GPU - not possible directly, &lt;br /&gt;solutions: &lt;br /&gt;-&amp;gt;implemented by converting the scatter into a gather operation essentially by some two-pass strategy. &lt;br /&gt;-&amp;gt;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. &lt;br /&gt;&lt;br /&gt;Gather on GPU - straightforward&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;Further reading: &lt;br /&gt;Buck and Purcell 2004, Sorting and Searching on the GPU&lt;br /&gt;Ch: 46, GPU Gems II, Improved GPU Sorting &lt;br /&gt;What Every Computer Scientist Should Know about Floating Point Arithmetic, David Goldberg, 1991, ACM Computing Surveys</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:4326</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/4326.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=4326"/>
    <title>saifjournal @ 2006-02-25T23:11:00</title>
    <published>2006-02-26T07:15:10Z</published>
    <updated>2006-02-26T07:15:10Z</updated>
    <content type="html">About computing texture space&lt;br /&gt;&lt;br /&gt;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:&lt;br /&gt;&lt;br /&gt;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&lt;br /&gt;2. the light vector</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:3867</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/3867.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=3867"/>
    <title>Web Crawl for the terrain project</title>
    <published>2006-02-21T10:14:49Z</published>
    <updated>2006-02-21T10:14:49Z</updated>
    <content type="html">&lt;a href="http://www.gameprogrammer.com/fractal.html"&gt;http://www.gameprogrammer.com/fractal.html&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;The Diamond Square Algorithm (Fournier, Fussel and Carpenter) - fractal based generation of complexity &lt;br /&gt;(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. &lt;br /&gt;Roughness constant = scalar that determines the roughness or the jaggedness ofthe resulting terrain &lt;br /&gt;&lt;br /&gt;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. &lt;br /&gt;Tesellation of the height map - look at &lt;a href="http://www.javaworld.com/javaworld/jw-08-1998/jw-08-step_p.html"&gt;http://www.javaworld.com/javaworld/jw-08-1998/jw-08-step_p.html&lt;/a&gt; for a much better description ofthe diamond square method of recursive subdivision. &lt;br /&gt;&lt;br /&gt;&lt;img src="http://www.javaworld.com/javaworld/jw-08-1998/step/diamondSquare.gif" /&gt;&lt;br /&gt;&lt;br /&gt;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. &lt;br /&gt;&lt;br /&gt;Terminology&lt;br /&gt;&lt;br /&gt;Continous Level-of-Detail&lt;br /&gt;Adaptive Meshes&lt;br /&gt;View dependent triangulation&lt;br /&gt;geometry clipmaps</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:3772</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/3772.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=3772"/>
    <title>Expanding the Codebase</title>
    <published>2006-02-19T08:11:33Z</published>
    <updated>2006-02-19T08:11:33Z</updated>
    <content type="html">The tasks move me in the general direction of expanding my codebase. They are as follows: &lt;br /&gt;&lt;br /&gt;1. OBJ Class - load from file &lt;br /&gt;2. OBJ Class - compute tangent space&lt;br /&gt;3. Write simple camera class &lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;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.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:3387</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/3387.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=3387"/>
    <title>Putting in Together - Bump Mapping</title>
    <published>2006-02-08T07:18:55Z</published>
    <updated>2006-02-08T07:18:55Z</updated>
    <content type="html">List of variables to be passed to shaders from application&lt;br /&gt;&lt;br /&gt;vertex position&lt;br /&gt;surface normal &lt;br /&gt;tangent vector&lt;br /&gt;light position&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;Varyings &lt;br /&gt;light direction (to Vertex shader)&lt;br /&gt;eye direction (to Vertex shader)&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;Uniforms&lt;br /&gt;light position (to Vertex shader)&lt;br /&gt;&lt;br /&gt;Attributes&lt;br /&gt;the Tangent vector (to the vertex shader) &lt;br /&gt;&lt;br /&gt;&lt;br /&gt;the bump mapper actually works ! :-) ... results are pathetic though. :-(</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:3299</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/3299.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=3299"/>
    <title>Tangent Space Derivation for a Mesh</title>
    <published>2006-02-02T02:34:23Z</published>
    <updated>2006-02-02T02:34:23Z</updated>
    <content type="html">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 (&lt;a href="http://www.blacksmith-studios.dk/projects/downloads/tangent_matrix_derivation.php"&gt;http://www.blacksmith-studios.dk/projects/downloads/tangent_matrix_derivation.php&lt;/a&gt;) which provides a great tutorial on how to derive the tangent space. &lt;br /&gt;&lt;br /&gt;It turns out the above mentioned tutorial had to be discarded in favor of a more conceptually enriching one available here : &lt;a href="http://www.netsoc.tcd.ie/~nash/tangent_note/tangent_note.html"&gt;http://www.netsoc.tcd.ie/~nash/tangent_note/tangent_note.html&lt;/a&gt; &lt;br /&gt;This tutorial has better explanations.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:2963</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/2963.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=2963"/>
    <title>DOT3 Bump Maps, Texture Space</title>
    <published>2006-01-24T21:29:36Z</published>
    <updated>2006-01-24T21:29:56Z</updated>
    <content type="html">DOT3 Bump Maps - bump mapping involving a dot product between two 3D vectors.&lt;br /&gt;1. The light vector or the half angle vector&lt;br /&gt;2. The normal vector at that particular pixel &lt;br /&gt;&lt;br /&gt;Both vectors must be defined in the same space. This could be &lt;br /&gt;1. View Space&lt;br /&gt;2. World space&lt;br /&gt;3. Model Space&lt;br /&gt;&lt;br /&gt;Texture Space - definition and importance (for the nth time)&lt;br /&gt;&lt;br /&gt;The Z-axis of this space is approximately (?) parallel to the vertex normal&lt;br /&gt;The x and y axes are perpendicular to the z axis and can be arbitrarily oriented around it &lt;br /&gt;&lt;br /&gt;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. &lt;br /&gt;&lt;br /&gt;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. &lt;br /&gt;&lt;br /&gt;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.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:2623</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/2623.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=2623"/>
    <title>Bump Maps in GLSL</title>
    <published>2006-01-23T18:10:32Z</published>
    <updated>2006-01-23T18:10:32Z</updated>
    <content type="html">Basic bump mapper in GLSL  (from the Game Programming Wiki - &lt;a href="http://gpwiki.org/index.php/OpenGL:Tutorials:GLSL_Bump_Mapping"&gt;http://gpwiki.org/index.php/OpenGL:Tutorials:GLSL_Bump_Mapping&lt;/a&gt;)&lt;br /&gt;&lt;br /&gt;types of variables (once and for all)&lt;br /&gt;uniform - passed from program to a shader, cant be changed in the middle of rendering, used for light direction (doesnt change often)&lt;br /&gt;varying - passed from a vertex shader to a fragment shader, must be declared in both, &lt;br /&gt;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</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:2346</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/2346.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=2346"/>
    <title>This is a test entry to - testing LJ.net</title>
    <published>2005-12-04T08:22:28Z</published>
    <updated>2005-12-04T08:22:28Z</updated>
    <content type="html">&lt;font face="Arial" size="2"&gt;testing testing&lt;/font&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:2229</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/2229.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=2229"/>
    <title>cvbcxv</title>
    <published>2005-12-04T07:57:29Z</published>
    <updated>2005-12-04T07:57:58Z</updated>
    <content type="html">&lt;ul&gt;&lt;br /&gt;&lt;li&gt;dfgdgd&lt;/li&gt;&lt;br /&gt;&lt;li&gt;ghjgj&lt;/li&gt;&lt;br /&gt;&lt;li&gt;ghjghuj&lt;/li&gt;&lt;/ul&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:2023</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/2023.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=2023"/>
    <title>Cooking Turn</title>
    <published>2005-11-13T01:02:12Z</published>
    <updated>2005-11-13T01:02:12Z</updated>
    <content type="html">Have to run home to cook. &lt;br /&gt;On getting back - to pick up from reading (thats a good thing to do sometimes) ... page 235 of the Orange Book (yellow?)&lt;br /&gt;The section on Stored Texture Shaders. Implement one by tonight maybe. &lt;br /&gt;... so .. on to spinach and potatoes.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:1670</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/1670.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=1670"/>
    <title>Quaternions - higher education</title>
    <published>2005-11-11T07:07:50Z</published>
    <updated>2005-11-11T07:07:50Z</updated>
    <content type="html">I have embarked on a journey to implement the arcball interface using quaternions. &lt;br /&gt;&lt;br /&gt;so here's how it is&lt;br /&gt;&lt;br /&gt;on mouse-left-button-down&lt;br /&gt;&lt;br /&gt;project the point at which mouse was clicked on to the (imaginary) sphere filling up the screen&lt;br /&gt;(it is (x,y,sqrt(1 - x*x - y*y)) )&lt;br /&gt;calculate the vector from the center of the sphere to this point (radius vector)&lt;br /&gt;&lt;br /&gt;then on the drag event capture the mouse coordinates, project and calculate the radius vector again&lt;br /&gt;&lt;br /&gt;calculate the cross product of these two radius vectors&lt;br /&gt;&lt;br /&gt;that gives us the axis&lt;br /&gt;&lt;br /&gt;the angle between them gives us the angle&lt;br /&gt;&lt;br /&gt;now we can form a quaternion&lt;br /&gt;&lt;br /&gt;and hence the matrix&lt;br /&gt;&lt;br /&gt;note: the center of the sphere must coincide ( I think) with the centroid of the object being viewed. ?&lt;br /&gt;&lt;br /&gt;this is the algorith from &lt;a href="http://www.fas.harvard.edu/~lib175/chapters/quat.pdf"&gt;http://www.fas.harvard.edu/~lib175/chapters/quat.pdf&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;Imagine a hemisphere sitting on top of your window. You can decide where to&lt;br /&gt;center the hemisphere ˜c and how big to make it. You can display the intersection&lt;br /&gt;of the hemisphere and the window by drawing the appropriate circle.&lt;br /&gt;• When the user clicks on a pixel within the circle, that point is lifted up off the&lt;br /&gt;screen until it hits some point ˜p0 on the imaginary hemisphere.&lt;br /&gt;• Computer the vector ˜p0 − ˜c, and normalize it to obtain ˆv0&lt;br /&gt;• When the user now moves the mouse to some second point, repeat these steps to&lt;br /&gt;obtain ˆv1&lt;br /&gt;• Imagine the arc along the hemisphere connecting ˜p0 and ˜p1. The axis of rotation&lt;br /&gt;can be computed as ˆa = ˆv0×ˆv1. The angle  of the arc satisfies cos() = ˆv0·ˆv1&lt;br /&gt;• Interpret this user interaction as a request to perform a rotation of  = 2 arond&lt;br /&gt;ˆa.&lt;br /&gt;&lt;br /&gt;now ... to code.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:1446</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/1446.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=1446"/>
    <title>Complications</title>
    <published>2005-11-06T10:27:54Z</published>
    <updated>2005-11-06T10:27:54Z</updated>
    <content type="html">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. &lt;br /&gt;&lt;br /&gt;Application (CPU)&lt;br /&gt;provides scene geometry and acceleration data structure (as textures) &lt;br /&gt;&lt;br /&gt;Shaders (GPU)&lt;br /&gt;acceleration structure traversal&lt;br /&gt;intersection tests&lt;br /&gt;shading&lt;br /&gt;&lt;br /&gt;textures&lt;br /&gt;&lt;br /&gt;1. ray origins&lt;br /&gt;2. ray directions ( do we need this one ? possible to generate ray directions on the fly? )&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;important distinction: ray tracing a height map is a problem with different complications than ray tracing geometry. how are they different ? &lt;br /&gt;... 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)&lt;br /&gt;&lt;br /&gt;plan: code a bump mapper - to see how texture memory and the like can be used.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:1235</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/1235.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=1235"/>
    <title>Next Steps</title>
    <published>2005-11-02T14:06:20Z</published>
    <updated>2005-11-02T14:06:20Z</updated>
    <content type="html">Ok .. future plan for coding.&lt;br /&gt;Writing the shaders. Before that - what work will be done in the vertex shader, what in the pixel shader. What uniforms, attributes and varyings?&lt;br /&gt;&lt;br /&gt;viewing direction&lt;br /&gt;displacement map&lt;br /&gt;TBN matrix (the inverse actually) to transform the eye/view vector to texture space&lt;br /&gt;&lt;br /&gt;division of tasks ... &lt;br /&gt;&lt;br /&gt;&lt;br /&gt;Vertex Shader&lt;br /&gt;project vertex to get coordinates in clip space&lt;br /&gt;calculate view vector ? (it will be interpolated in the fragment shader - varying variable)&lt;br /&gt;texture coordinates&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;Fragment Shader&lt;br /&gt;get view vector for current pixel&lt;br /&gt;transform to texture space&lt;br /&gt;compute sampling points along ray&lt;br /&gt;at these points, look up texture to get height &lt;br /&gt;see if the sampling point is above the height map or below (using 'z' coordinate?)&lt;br /&gt;find the point where there is a change in sign (above to below / below to above)&lt;br /&gt;use binary search to find point of intersection (within error threshhold ?) &lt;br /&gt;lookup the texture to find the color at that point - thats the final color for the fragment - write it out to the frame buffer&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;this is all I got. I havent slept enough and Im struggling with the ray cast volume rendering.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:1012</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/1012.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=1012"/>
    <title>Some Code - GLUT Application, Simple Texture Mapping</title>
    <published>2005-10-31T08:29:02Z</published>
    <updated>2005-10-31T08:29:02Z</updated>
    <category term="code texture mapping opengl"/>
    <content type="html">Coding - Finally&lt;br /&gt;&lt;br /&gt;Trying to code a small glut application which will load two small shaders to perform displacement mapping. Finally got a small glut program working. pitiful result for a couple of hours work. But there was some funny issue with the texture setup. &lt;br /&gt;&lt;br /&gt;This is the code I had for texture setup : &lt;br /&gt;&lt;br /&gt;	glGenTextures(1,&amp;texName);&lt;br /&gt;	glBindTexture(GL_TEXTURE_2D,texName);&lt;br /&gt;	glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_S,GL_REPEAT);&lt;br /&gt;	glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_T,GL_REPEAT);&lt;br /&gt;	glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_NEAREST);&lt;br /&gt;	glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_NEAREST);&lt;br /&gt;&lt;br /&gt;	glTexImage2D(GL_TEXTURE_2D,0,GL_RGBA,8,8,0,GL_RGBA,GL_INT,NMap);&lt;br /&gt;&lt;br /&gt;NMap was a 4x4x3 arrays of ints which held the texture ( just plane blue square where I had used 1 as the blue component). No matter what I did, I ended up with a blank screen. The problem was this. OpenGL maps ints to color values in such a way that only the maximum value stored by an int to 1 and the minimum value stored by it is mapped to -1 (or 0 if its an unsigned int) ... for example, for a 4 byte signed int, the value 2147483647 is mapped to 1.0 and the negative of that is mapped to -1. So, the value 1 which I was using is so teeny that it was just being mapped to 0 and I was getting the blank screen ! ... one hour to figure that out ... and I had help from John. &lt;br /&gt;&lt;br /&gt;GLUT API Version 3&lt;br /&gt;&lt;a href="http://www.opengl.org/resources/libraries/glut/spec3/spec3.html"&gt;http://www.opengl.org/resources/libraries/glut/spec3/spec3.html&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;Parallax Mapping - ATI&lt;br /&gt;&lt;a href="http://www.ati.com/developer/gdc/Tatarchuk-ParallaxOcclusionMapping-FINAL_Print.pdf"&gt;http://www.ati.com/developer/gdc/Tatarchuk-ParallaxOcclusionMapping-FINAL_Print.pdf&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;Another one on Parallax Mapping from ATI&lt;br /&gt;&lt;a href="http://www.ati.com/developer/SIGGRAPH05/Tatarchuk-ParallaxOcclusionMapping-Sketch-print.pdf"&gt;http://www.ati.com/developer/SIGGRAPH05/Tatarchuk-ParallaxOcclusionMapping-Sketch-print.pdf&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;Overview of Bump Mapping from Delphi3D&lt;br /&gt;&lt;a href="http://www.delphi3d.net/articles/viewarticle.php?article=bumpmapping.htm"&gt;http://www.delphi3d.net/articles/viewarticle.php?article=bumpmapping.htm&lt;/a&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:667</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/667.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=667"/>
    <title>More on spaces - Understanding Texture Space, Normals Maps, Transformations</title>
    <published>2005-10-31T01:32:07Z</published>
    <updated>2005-10-31T01:32:07Z</updated>
    <content type="html">A given triangle - lives in "world-space". Its vertices are specified in world space. &lt;br /&gt;Texture coordinates at each vertex constitue the "texture-space".&lt;br /&gt;&lt;br /&gt;Normal Map - a multi-channel image where the RGB components hold the x,y,z components of the normal at each vertex (or pixel?) of the object. &lt;br /&gt;Normal mapping is of two varieties (this is from &lt;a href="http://en.wikipedia.org/wiki/Normal_map"&gt;http://en.wikipedia.org/wiki/Normal_map&lt;/a&gt;) - &lt;br /&gt;&lt;br /&gt;Object Space Normal Mapping and Tangent Space Normal Mapping&lt;br /&gt;They differ in the coordinate systems in which the normals are measured and stored. &lt;br /&gt;&lt;br /&gt;(again...straight off the Wikipedia) &lt;br /&gt;By using an RGB bitmap textured across the model, more detailed normal vector information can be encoded. Each color channel in the bitmap (red, green and blue) corresponds to a spatial dimension (X, Y and Z). These spatial dimensions are relative to a constant coordinate system for object-space normal maps, or to a smoothly varying coordinate system (based on the derivatives of position with respect to texture coordinates) in the case of tangent-space normal maps.&lt;br /&gt;&lt;br /&gt;Displacement Maps (good definition from &lt;br /&gt;Displacement maps are a special type&lt;br /&gt;of offset surface, and are usually assumed to perturb surface positions a small distance&lt;br /&gt;using some function.&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;...&lt;br /&gt;&lt;br /&gt;went to the mosque to break-fast. Walked with John who suggested all of software engineering is bunk. No but seriously ... he had a point. Instead of getting into "design-considerations" , "userf-friendliness" and all that jazz we acads should just KIS.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:saifjournal:452</id>
    <link rel="alternate" type="text/html" href="http://saifjournal.livejournal.com/452.html"/>
    <link rel="self" type="text/xml" href="http://saifjournal.livejournal.com/data/atom/?itemid=452"/>
    <title>Web Crawl and Survey - Tangent Spaces, Bump Mapping</title>
    <published>2005-10-30T07:50:55Z</published>
    <updated>2005-10-30T07:50:55Z</updated>
    <category term="tangent space bump mapping gpu cg"/>
    <content type="html">Went net hunting for tutorials and articles on programming the GPUs. Exellent article on computing tangent spaces. The whole concept of tangent spaces and texture spaces is clearer in my head. Thanks to these guys at blacksmith-studios &lt;a href="http://www.blacksmith-studios.dk/projects/downloads/bumpmapping_using_cg.php#ref1"&gt;http://www.blacksmith-studios.dk/projects/downloads/bumpmapping_using_cg.php#ref1&lt;/a&gt; &lt;br /&gt;&lt;br /&gt;Tangent Space&lt;br /&gt;tangent space - defined at every vertex of a triangle&lt;br /&gt;defined by a 3x3 matrix containing the basis vectors (the tangent (T) , the binormal (B) and the normal (N) ) - TBN Matrix&lt;br /&gt;essentially the basis of the vectors formed by the texture coordinates of the triangle&lt;br /&gt;algorithm bottleneck - computing the inverse, do it by plugging the formula&lt;br /&gt;consider better methods&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;Bump Mapping &lt;br /&gt;adding fake "depth" to otherwise 2D textures using a normal map&lt;br /&gt;&lt;br /&gt;Forks&lt;br /&gt;- to use Cg or to use OGLSL? &lt;br /&gt;- to use MFC or Win32 - benefits (if any)?&lt;br /&gt;&lt;br /&gt;Link harvest&lt;br /&gt;&lt;br /&gt;&lt;a href="http://developer.nvidia.com/object/mathematicsofperpixellighting.html"&gt;http://developer.nvidia.com/object/mathematicsofperpixellighting.html&lt;/a&gt;&lt;br /&gt;&lt;a href="http://www.blacksmith-studios.dk/projects/downloads/bumpmapping_using_cg.php#ref1"&gt;http://www.blacksmith-studios.dk/projects/downloads/bumpmapping_using_cg.php#ref1&lt;/a&gt;&lt;br /&gt;&lt;a href="http://www.delphi3d.net/articles/viewarticle.php?article=phong.htm"&gt;http://www.delphi3d.net/articles/viewarticle.php?article=phong.htm&lt;/a&gt;&lt;br /&gt;ftp://download.nvidia.com/developer/cg/Cg_1.4/Docs/CG_UserManual_1-4.pdf&lt;br /&gt;&lt;a href="http://developer.nvidia.com/object/cg_toolkit.html#downloads"&gt;http://developer.nvidia.com/object/cg_toolkit.html#downloads&lt;/a&gt;&lt;br /&gt;&lt;a href="http://www.talisman.org/opengl-1.1/Reference/glPushAttrib.html"&gt;http://www.talisman.org/opengl-1.1/Reference/glPushAttrib.html&lt;/a&gt; (GL_CURRENT_BIT - when used with glPushAttrib saves a bunch of information, current color, texture, normal)&lt;br /&gt;&lt;a href="http://pharr.org/matt/"&gt;http://pharr.org/matt/&lt;/a&gt;</content>
  </entry>
</feed>
