RichardS

Members
  • Content count

    178
  • Joined

  • Last visited

Community Reputation

298 Neutral

About RichardS

  • Rank
    Member
  1. GLSL Texture and variables

    I wouldn't worry about 1 texture bind. You may want to try to entirely eliminate redundant state changes, but in general, it's much better for your sanity to just set it up at the begining of a frame, rather than trying to track state across frames (for a program this small it probably does not matter, but as they get larger...) However, the glGetUniformLocation calls might actually be a performance issue. They exist so OpenGL doesn't have to do string comparisions and table lookups every time you load a new uniform. Using the API in this way negates that advantage. Query the uniform locations once during setup, and cache the values. It'll have far more of an effect than removing the BindTexture.
  2. iostream header

    Use <iostream>. To find cout, you need to let the compiler know that it'll be part of the 'std' namespace. Either explicitly do it with: std::cout << "foo!" << std::endl; Set std as the default namespace for the whole file (insert "using namespace std" at the top of your file, after includes) Set std as the default namespace only for those symbols (at the top of the file, include "using std::count; using std::endl")
  3. generic vertex attributes question

    Are you using GLSL or ARB_vertex_program/ARB_fragment_program? That changes the answer.
  4. What have you set the wrap modes to?
  5. Using Vertex Arrays or VBO's

    How much data will you be changing? If you're going to be poking a relatively small amount of data, then BufferSubData is the way to go. If you're uploading large quantities of new vertex data, I suggest the streaming VBO route. BufferSubData requires an extra copy of your vertex data to be done on the CPU, which will hurt if you're generating lots of new geometry. For small quantities, the extra work does not really matter. It is also sometimes found to be faster because that copy can be done immediatly, rather than waiting for outstanding rendering on the buffer object to complete. For MapBuffer, follow the pattern in Listing 8-3. The advice is solid on all platforms. The key is calling BufferData(NULL) before MapBuffer(WRITE_ONLY). That informs the OpenGL implementation that the old contents of the buffer do not have to be maintained, avoiding that synchronization. It also avoides BufferSubData's extra copy.
  6. glVertexArray

    You need to enable the color array, just like you did for the vertex array. glDrawArrays should be glDrawArrays(GL_TRIANGLES, 0, 3)
  7. OpenGL Shaders without CG ?

    Why would you use CG when you could use GLSL directly? The new shader model features are available both via extensions to GLSL and extensions to the ARB program languages.
  8. writing to texture in shader?

    The FBO spec explicitly states that rendering to a texture and sampling from it at the same time will cause undefined results. The fact that Renderer A seems to fall to SW, and renderer B seems to work OK, is irrevelant. Both behaviors are correct, and both implementations can change to entirely new, unpredictable behavior later (such as, with a driver update). You MUST double buffer the texture.
  9. This is even better, it only requires ARB_texture_env_combine (or OpenGL 1.3). It will work on a wider variety of hardware. // get RGB values from texture unit 0 glActiveTexture(GL_TEXTURE0); glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE); // get ALPHA values from texture unit 1 glActiveTexture(GL_TEXTURE1); glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE); glTexEnvi(GL_TEXTURE_ENV, GL_COMBINE_RGB, GL_REPLACE); glTexEnvi(GL_TEXTURE_ENV, GL_SOURCE0_RGB, GL_PREVIOUS); glTexEnvi(GL_TEXTURE_ENV, GL_OPERAND0_RGB GL_SRC_COLOR; glTexEnvi(GL_TEXTURE_ENV, GL_COMBINE_ALPHA, GL_REPLACE); glTexEnvi(GL_TEXTURE_ENV, GL_SOURCE0_ALPHA, GL_TEXTURE); glTexEnvi(GL_TEXTURE_ENV, GL_OPERAND0_ALPHA, GL_SRC_ALPHA); Note that for both of these examples, you'll need to load the alpha texture with an internal format of GL_ALPHA, not GL_RGB.
  10. If you are just loading two textures, it would be much better to combine the two images into a single RGBA image (on the CPU), and use it as a single texture. However, if you have many greyscale images and many RGB images, and you want to mix and match at runtime, the total number of combined textures could grow too large. So, with that: // use a COMBINE texture environment glActiveTexture(GL_TEXTURE1); glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE); // get RGB values from texture unit 0 glTexEnvi(GL_TEXTURE_ENV, GL_COMBINE_RGB, GL_REPLACE); glTexEnvi(GL_TEXTURE_ENV, GL_SOURCE0_RGB, GL_TEXTURE0); glTexEnvi(GL_TEXTURE_ENV, GL_OPERAND0_RGB, GL_SRC_COLOR); // get ALPHA values from texture unit 1 glTexEnvi(GL_TEXTURE_ENV, GL_COMBINE_ALPHA, GL_REPLACE); glTexEnvi(GL_TEXTURE_ENV, GL_SOURCE0_ALPHA, GL_TEXTURE1); glTexEnvi(GL_TEXTURE_ENV, GL_OPERAND0_ALPHA, GL_SRC_ALPHA); // this is all done in texture unit 1. Because the combine modes are REPLACE, we really don't care what the product of texture unit 0 is. Warning: I've not tried this, and I really haven't used these kind of complex texture environments before. This comes to you, untested, from a reading of the OpenGL 2.0 spec. This requires ARB_texture_env_crossbar, or OpenGL 1.4 And, as zedzeek said: get to know GLSL. It makes things like this much easier (and you can do a lot more with it). It is a very good thing. [Edited by - RichardS on October 21, 2006 10:20:55 PM]
  11. OpenGL State Change Benchmark Data?

    If you want to benchmark these things, you need to be aware that practically every major implementaiton attempts to defer state management until the state is actually needed (ie, you actually draw something). If you just put a whole bunch of glBindTextures in a loop, it will be quite fast, because basically no work is being done. It will actually be glDrawArrays (or glBegin, or whatever) that takes longer to execute. The following is a rough grouping of state changes from slowest to fastest. Depending on the given implementation, the list may shift around a bit, but this is a reasonable average. Program binding FBO binding Texture binding Vertex array specification Buffer binding glUniform* Update current vertex state (glColor, glVertexAttrib, etc).
  12. Problem on FBO

    Even though an OpenGL implementation may be able to texture from a texture object, that does not guarentee you can render to a texture of that max size.
  13. Again, for reference, the final working bit, which emulates the behavior of a FPS view. dx and dy are scaled mouse position deltas. quaternionf inputx, inputy; inputx = quatf_from_axisangle(vector3f(1.0f, 0.0f, 0.0f), -dy); inputy = quatf_from_axisangle(vector3f(0.0f, 1.0f, 0.0f), -dx); orientation = quatf_multiply(quatf_multiply(inputy, orientation), inputx);
  14. Just for reference, I found the solution to the problem. I needed to swap the order of multiplication for the second axis. I haven't yet convinced myself *why* it works though.
  15. I just got my basic quaternion camera almost working, except that some motions introduce undesired roll to the view. Specfically, if I move the view in a circle around it's original direction, the view rolls clockwise (contents roll counter-clockwise). Does anyone know what might be introducing this issue, and how I may be able to resolve it? As a worst case solution, I can entirely disallow roll, and remove it in a post-processing step, but I would like to preserve the ability to do a deliberate roll if at all possible. The relevant bit of code: quaternionf input; input = quaternionf::axisAngleToQuaternion(vector3f(1.0f, 0.0f, 0.0f), -dy); orientation = orientation.multiply(input); input = quaternionf::axisAngleToQuaternion(vector3f(0.0f, 1.0f, 0.0f), -dx); orientation = orientation.multiply(input);