Sweet! OpenGL 1.5 extensions are out! :)
- Thread starter Ostsol
- Start date
arjan de lumens
Veteran
Some comments:
- ARB_occlusion_query: Requres hardware support, as it reports back not only a true/false flag, but the actual number of pixels/samples that would be drawn for a given set of primitives (!). This seems to be actually supported in current Nvidia hardware (dunno about ATI); it doesn't look like it is possible to implement very efficiently in deferred renderers.
- ARB_shader_objects: This is basically a framework for managing shader programs (load, unload, compile & link, that sort of stuff).
- ARB_vertex_shader: Supports texture lookups, and seems to be written to support a setup where vertex/pixel shader pipes are shared. Mipmapping is supported, but it is the vertex program's responsibility to determine appropriate mipmap levels.
- ARB_fragment shader: Seems to have no way of communicating limitations on program length and temporary registers - if this is correct, then it is indeed time to get rid of such limitations for good,
- ARB_shading_language_100: This is the actual GL shading language (although the actual extension text just points to a document at 3dlabs.com)
- ARB_texture_non_power_of_2: This one gets rid of a lot of the weird limitations and restrictions of previous non-power-of-2 texture extensions; 2D, 3D and cubemap textures are all supported, so are texture repeat and mipmapping (!), and texture coordinates are mapped to [0,1] rather than [0,n]. This requires hardware support that NV3x/R3xx cards don't seem to have, so it's unlikely that we'll see it supported until NV40/Loki.
- ARB_point_sprite: Nice to have, although it is so simple to implement in software that I am surprised it took this long to make it this far.
- "Uber-buffers", which basically allow a chunk of video memory to be swapped between arbitrary uses (render target, texture map, vertex array). Needed for render-to-vertex-array, which is a rather powerful way to produce higher-order surfaces. Seems that the ARB are working actively on this one.
- A standard, non-vendor-specific way to specify floating point texture maps and pbuffers (for now, Nvidia and ATI have implemented them in totally incompatible ways, which kinda sucks)
- Read access to the frame/Z-buffer from within the pixel shaders. There are some effects that can't be done well without; for example, water refraction effects look better if you can get an estimate of the 'depth' of the water (by, say, comparing Z values from the Z-buffer with the one for the incoming pixel). Will probably appear as a feature of the Shading Language some day, but not very soon (has issues with multisampling and performance).
- GLX_ARB_render_texture: Needed for render-to-texture on Linux. Should have been passed ages ago, but seems to have fallen through the cracks in the ARB discussions.
What about floating point blending? It limits the usage of the floating point rendertargets a lot. It would be great if this is exposed in some way soon.
Isn't S3's Deltachrome supposed to feature color/z buffer reads from the fragment shader? Any idea how well it's been implemented?
Isn't S3's Deltachrome supposed to feature color/z buffer reads from the fragment shader? Any idea how well it's been implemented?
Hellbinder
Banned
Actually ahead of D3D???? It was not till just recently that D3D was even in the same league as OpenGL. OpenGL has been more robust than D3D for years.Yes Dx9 Stepped up the mark, but only partially. There are still several functions easily accessable by OpenGL extensions that are out of Reach, or very difficult to use with DX9.
Similar threads
