With DrawElements you still only have to store the unique vertices, and the index array will reference the shared vertices how ever many times necessary. To keep performance similar to triangle strips you will want to make sure you draw all triangles with shared vertices close enough together that the shared vertices will still be in the cache.

While I haven't spent the time to benchmark it I'd guess it's still a relatively relevant issue, as there's an extension to help reduce the amount of binding needed, http://www.opengl.org/registry/specs/EXT/texture_array.txt

It was even promoted to core in 3.0

The type argument is used just to indicate the size of the data to expect, so signed or unsigned should be the same size but the GL spec says unsigned only otherwise it'll throw an error and ignore the command.

And while Java only supports signed values the underlying GL implementation will still treat the values as unsigned so if you have your bit patterns all figured out correctly you can still supply it with the upper half of the 2^n index values :-).

I guess it all comes down to how you are accessing the data. If you expect any sort of random access just say no to RLE. You say S3TC won't cut it, but spend a little more time looking at the algorithm, you'll see that there's nothing requiring it be applied to 4x4 blocks, you can actually choose any block size you want. Same thing goes for the reconstruction equations. All of which should be easily doable in a shader.

I think I see what you mean, there's no level argument to Texture.updateImage(), sorry about that. I've not looked at that code but I would imaging that call in particular is probably a fairly simple wrapper around glTexImage. The fastest way to get the changes into the project would be to make them yourself and submit them. Hopefully Ken Russell can chime in a bit here on how to do that.

Textures are orthogonal in that mipmapping/filtering, wrap/clamp modes, and coordinates all [size=8pt](are supposed to)[/size] work the same. Or at least that's the case for 1D, 2D, and 3D textures, with cube maps being something of an exception. But yes, glTexCoord3f would be what you'd want and the coords will need to be normalized.

In short no, http://opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/texsubimage2d.html

I refer you to the 2nd error condition...


I could go into the uglinesses of OpenGL's textures and mipmap pyramids and the bizarre things you can legally do with them that no sane person would ever have reason to do in a real app. But the short and sweet of it is a glTexImage call defines the allocation's size for each mip level, otherwise glTexSubImage is attempting to operate on undefined data over an undefined range.

Easy, use glTexParameter with the filter modes set to GL_NEAREST.

for reference.
http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/texparameter.html

The term you're looking for is parallax mapping and the technique can be performed in the fragment shader on cards going all the way back to the Radeon 9700.

This sounds like it may be helpful...

http://www.opengl.org/resources/faq/technical/polygonoffset.htm

There might be some helpful hints here...

http://www.java-gaming.org/topics/antialiasing-question/18119/msg/142271/view.html

You are correct there are nearly identical initializations shown in the spec.

Nvidia uses their Cg (Nvidia's shader language) compiler for GLSL as well, so something that might be worth looking at is whether or not Cg allows uniforms to be initialized like that. That will at least help narrow it down if it is a driver issue.

The same effect can be achieved in OpenGL using vertex texture fetch in the vertex shader, and with the advent of the geometry shader I'm sure an endeavoring mind could come up with some real interesting uses.

Here's an old paper on vertex texture fetch...
http://developer.nvidia.com/object/using_vertex_textures.html

When you select a pixel format descriptor (pfd) you need to pick one that says isn't accelerated.

There's two likely situations that cause this. The first is if you choose a pixel format descriptor that isn't hardware accelerated. The second is that you need updated drivers for your video card.

It sounds like the issue is probably related to blending with the frame buffer, and unfortunately there's no good solution I know of, it's just slow.

Not to make you jealous but it was my job to read the new specs this morning  .

All in all, not as ground breaking as they had lead us to believe but a worthwhile and necessary update.

The biggest problem I can see is that they didn't immediately deprecate the features they decided upon. Instead by extending their life it'll only make the process of finally removing them that much more painful.

It's finally here!!!

Press Release:
http://www.khronos.org/news/press/releases/khronos_releases_opengl_30_specifications_to_support_latest_generations_of/

New Spec's PDF:
http://www.opengl.org/registry/doc/glspec30.20080811.pdf

New Shader Language PDF:
http://www.opengl.org/registry/doc/GLSLangSpec.Full.1.30.08.pdf

I'd hardly say that it uses a fair chunk of memory, it's only a single extra back buffer, width x height x bit-depth, which would be roughly comparable to a single additional texture without mipmaps.

You usually see this when you've enabled v-sync (vertical sync) for your video card and then the timing is off slightly for when a frame is ready versus when the display is ready to display it. When this occurs the frame is delayed a refresh before it is displayed (which explains the exact multiples of the refresh rate), and in double buffered rendering the front and back buffers can't be swapped while waiting for the display.

The solution is called triple buffering, and unfortunately there aren't many (any?) tutorials on how to implement it with OpenGL nor do I have that knowledge.

Setting double buffered in the capabilities object is the only thing that needs to be done.

And unfortunately I think you misunderstand what double buffering does. It doesn't really make animation smoother, rather it avoids tearing, and at that you need to have vertical sync (v-sync) on to completely avoid tearing.

Now what is tearing you might ask? It's an artifact that shows up in double buffering with v-sync off and when the monitor is part of the way through the verticle refresh the video card then directs it to use the other buffer, causing the image on the screen to tear because the first portion was drawn from one rendered image and the rest from a second image. In a single buffered display, tearing will be seen as an unfinished image in the process of being draw and then when finished probably abruptly cleared and the process starts over again.

I know that wasn't the clearest description but I hope it helps.

Your card likely doesn't support the appropriate extension... http://www.opengl.org/registry/specs/ARB/wgl_render_texture.txt

You'll need to use one of the old fall backs like glReadPixels()

I don't have time for a lengthy answer but this sounds like what you're looking for.

http://www.opengl.org/registry/specs/ARB/point_sprite.txt

If it's actually a Radeon 7500 then no driver up date will get GLSL working, Radeon's first got GLSL support with the 9500-9800 series. Of course they've wrapped their number scheme around and it's soon going to be hard to tell what's what if you're try to support legacy parts.



As of this moment, no Intel part supports GLSL on Windows, while some do on Mac.

We might be able to help more if you shared some of the pertinent code.




Unfortunately Unichrome and stable don't exactly go together, thankfully they are fairly rare. In comparison the much complained about Intel IGPs are stunningly compatible and feature rich(and VERY common).

I really shouldn't be posting while at work, but I'm stalled waiting for someone else at the moment so here we go!   


The basic algorithm for doing it is...
1.) draw your scene
2.) get your scene into a texture some how (FBOs, pbuffer + Render_texture, glCopyPixels)
3.) bind your scene texture
3.) draw a fullscreen quad with a fragment program that looks up the scene texture and performs your effect.



Well the 945 is about as low end as it gets and is frighteningly common. Basically anything from ATI or Nvidia should be well beyond a 945 in features, the Geforce 3 and Radeon 8500 supported these features I believe, which should give you a feel for the era the 945 was designed for.

You've got it, that second one on the list, GL_ARB_fragment_program, and I assume the vertex version is somewhere in there too.

As for the lack of multisample extension I'm vaguely remembering there is no support for that, though strangely enough isn't there an option for it in their control panel? Or is that anisotropic filtering that they have, but is limited to a really low sample count?

Believe it or not I don't program Java for a living. Unfortunately I get paid to write C and every day I'm reminded how much I love Java.



The 945 does support the ARB programs, at least under XP and Vista, it's just a matter of making certain you have the appropriate drivers installed. Check the vendor string, if it says anything about GDI, Microsoft, or Mesa under Linux then you need to update your drivers, and even if it doesn't I'd look into getting the latest drivers.

The 945 does support the ARB programs, it's possible you need to update/install drivers for your card though.

Here's a handy little program that will show you all the interesting details of your cards OpenGL implementation...
http://www.realtech-vr.com/glview/

And as for the multi-sampling, if my memory serves me correctly the Intel part does support it but with only 2 samples, so the 4 sample examples probably won't work (change the 4 to a 2).