wiseman303

Members
  • Content count

    29
  • Joined

  • Last visited

Community Reputation

127 Neutral

About wiseman303

  • Rank
    Member
  1. Free Resource Thread (updated 5/27/06)

    Don't forget Polycount for free 3D models.
  2. OpenGL GL_EXT_packed_pixels_12? (resolved)

    Okay since I couldn't find any info on the internet, I decided to do some testing myself. I'll post my results here in case anyone else is curious. For testing I used an Intel 82810E, which supports OpenGL 1.1.2, EXT_packed_pixels and EXT_packed_pixels_12. I created an array of unsigned shorts, zeroed it, and called glTexImage2D with GL_UNSIGNED_SHORT_5_6_5 as type. Then I check glGetError() for various errrors, especially GL_INVALID_ENUM. Running this test produced no errors, and drawing a quad with the texture showed it black. Next I changed it to fill every element of the array with 63488 instead of 0, recompiled, and ran it again. This time the quad showed up as bright red. From this I conclude that the Intel 82810E supports at least one of the packed pixel formats introduced in OpenGL 1.2 that are not part of OpenGL 1.1 or the original EXT_packed_pixels extension. It seems likely that EXT_packed_pixels_12 is an indicator that these formats are supported.
  3. The looping to eliminate the pink texels is done in a preprocessing phase, at the same time the alpha for those texels is set to 0. This will eliminate the halo but still allow you to use smooth blended edges when rendering. If you turn off blending and look at your linear filtered texture, you'll see the pink "bleeding" into the other colours around the edges. Because the alpha is also being interpolated, those not-quite-pink pixels are also not fully transparent, so their pinkish colour gets blended with the background, giving the pink halo. If you preprocess the texture to recolour the pink texels at the time you set the alpha values, then instead of blending between pink and the colour of the opaque pixel when you render, you'll get blending between the opaque pixel and a colour closely matching the opaque pixel, which elliminates the visible outline or "halo" effect.
  4. OpenGL GL_EXT_packed_pixels_12? (resolved)

    20 views and no replies? Okay I guess nobody knows it, so I'll just have to try it and see if glGetError() says anything...
  5. Oh I understand the problem now, the colour of the transparent pixels is leeching into the opaque pixels. There was an article on the virtual terrain project about this. http://www.vterrain.org/Plants/Alpha/index.html When you loop through the pixels setting the pink ones alpha to 0, also set the RGB values for that pixel to 0 (you'll get a black outline, but it's better than pink.) Another thing you could try is, after setting the alpha values, while there are still pink pixels in the image, set each one's colour to the average of it's (non pink) neighbors. That should remove almost all outline or halo effect.
  6. Are you talking about this kind of problem? http://www.wiseman303.dyndns.org/temp/cacti-artifact.jpg That is caused by using that is caused by using both alpha test and blending together, but still writing to the depth buffer. To fix it you can either disable blending, disable alpha test, or disable depth writing (glDepthMask(GL_FALSE);). I recommend disabling blending. You won't have quite as smooth edges, but it will elliminate the halo. For the other two options you'd have to render the sprites in back-to-front order. [Edited by - wiseman303 on March 29, 2005 8:02:56 PM]
  7. Hi, I'm curious about an extension called EXT_packed_pixels_12. There is no specification for it on http://oss.sgi.com/projects/ogl-sample/registry/ or anywhere else that I can find. Searching google has revealed that most (if not all) Intel cards advertise this extension, and it's only advertised by Intel cards. My guess is it shows support of the extra packed pixel formats introduced in OpenGL 1.2 which are not part of the original EXT_packed_pixels specification, such as GL_UNSIGNED_SHORT_5_6_5. Does anyone know if that's right? [Edited by - wiseman303 on March 31, 2005 4:23:46 PM]
  8. Horizon Mapping on Intel Cards?

    Quote:Original post by vincoof It's just a matter of what "effort" and what "worth" means in your project. I for one can not afford implement it in my 3D engine for the "generic" case because of the time needed to do it and the limitations of it. But maybe *you* need to have such quality and have enough time to do it. I just recommend you look into the pros and cons before going further. Not that I want to sound harsh, but my humble opinion is that anyone who buys an Intel graphics board should be ready not to get top-of-the-line 3D algorithms. Again, that's jm2c :) Haha, thanks for the advice, and for clearing up the misunderstandings. I agree that horizon mapping seems too limited for general cases. I'm hoping to impliment it as special case shadows for terrain, and use zbuffer shadows for general shadowing cases. This would allow shadows on the ground, at least, to be free of 'shadow acne.' As for the Intel graphics card, it came with the computer and I haven't gotten a new one yet. (I know, I know, poor excuse...) Also some of my friends have Intel graphics cards, and I want my game to at least work on their computers :)
  9. Horizon Mapping on Intel Cards?

    Quote:Original post by vincoof Quote:Original post by wiseman303 As I understand horizon mapping could be done like this: (horizon1 * t + horizon2 * (1-t)) <= Elevation Granted that you know the 't' parameter for each face, yes. But I prefer encoding the direction selection into angle basis textures, even though it needs extra processing on the GPU side. But if the light angle is in object-space, 't' should be the same across the object, right? As for basis textures, you're referring to the technique used by Sloan and Cohen in http://research.microsoft.com/~cohen/bs.pdf right? The problem is that would take more texture units than I have available, or else a copy to texture which can be a real framerate killer. The reason I worked out the other method is because I wanted something that will work decently on my Intel 82810E graphics controller. Limiting it to object space means only two horizon maps have any influence, so the others don't need to be rendered. Quote:Original post by vincoof Quote:Original post by wiseman303 Obviously it would be limited to object-space horizon maps, In essence horizon maps can't work in tangent space. OK, I don't know about that. I was only going by the demo on Delphi3D that claims it's in tangent space, but since it just uses a plane, skips the tangent space transform. Quote:Original post by vincoof Quote:Original post by wiseman303 Please tell me if I'm on completely the wrong track. I don't want to sound rubbish, but the simple fact you're using the horizon mapping is a wrong track IMHO. The algorithm has too many limitations to make it useful in practice. Moreover, the need of unique horizon maps for each object in the scene make it even more difficult to use in a full scene. jm2c So basicly you're saying horizon maps in general aren't worth the effort?
  10. As I understand horizon mapping could be done like this: (horizon1 * t + horizon2 * (1-t)) <= Elevation Where horizon1 and horizon2 are the two horizon maps most closely representing the direction to the light, t is the amount the light's direction is closer to horizon1 than horizon2. Elevation is the light's vertical angle over the horizon. It seems that this could be done using two texture units with a GL_INTERPOLATE_EXT texture environment, and an alpha test, both of which would be possible with Intel 810 graphics cards. Obviously it would be limited to object-space horizon maps, and directional lightsources, but it should work right, or am I missing something obvious? Please tell me if I'm on completely the wrong track.
  11. Shadowing Techniques

    Quote:Shadow mapping Render depth information for each light, then render scene with depth information projected onto geometry, doing a pass/fail test for occlusion Suffers from aliasing artifacts due to limited texture resolution Requires shader hardware 1 render per light per relevant update (can be cached while scene is static) Actually shadow mapping can be done without shaders, using multitexture and gl_texture_env_combine. Here's a demo I found that impliments this technique on older hardware. [url]http://www.paulsprojects.net/opengl/shadowmap/shadowmap.html[/url]