Depth textures and shadow textures, enabling real-time shadows and related image-based rendering techniques
Vertex programming framework, setting the stage for user-defined geometry, lighting and shading programs and enabling high-level general-purpose shading languages
Automatic texture mipmap generation, providing rapid updates and high-quality texture filtering for dynamic textures
Numerous smaller enhancements including:
Multiple draw arrays, for higher geometry throughput
Window raster position, for precise 2D and image rendering
User-defined fog coordinate, for advanced fog effects
User-defined secondary color, point parameters, texture level-of-detail bias, texture crossbar, and new frame buffer blending modes and stenciling functions for more flexible shading and rendering effects
“new frame buffer blending modes”
Which ones? Blend-subtract?
I like it, it’s a good update. Stuff like auto-mipmap should help get rid of quick box-filter hacks; depth textures ea killing off a bit of the extension jungle; etc… Yeah, most of it gives a bit of a “about time” feeling but at least it is there now… Should be a while until 2.0 comes along, so 1.4 = kewl.
Originally posted by knackered: “new frame buffer blending modes”
Which ones? Blend-subtract?
Hi
I think the NV_blend_square extension is meant, because there you can use SRC_COLOR/ONE_MINUS_SRC_COLOR as blending factor for source and DST_COLOR/ONE_MINUS_DST_COLOR for destination
AFAIK the blend-subtract mode is part if the imaging subset.
BTW when will GL1.4 be offical with a spec and an implementation ?
Nope, I’m part of the group that is often overlooked (see especially the thread about the patents) – the guys using OpenGL for engineering/CADCAM stuff I’m happy when an upgrade offers some features that previously required extensions and their relatively low level programming style – which I usually can’t sell to management unless for really important cases (eg VAR).
So… ofcourse it will only be The Bomb with 2.0, but till then, 1.4 is definitely an improvement… I hope it will find its way to end user machines.
Now don’t kill me for being short sighted But I think it’s important to remember there’s other uses besides games… (the comment about dropping immediate mode in the patents thread nearly gave me a heartattack :] )
If you managed to persuade your management to use VAR, then you can easily persuade them to use pixel shaders - register combiners are supported on tnt upwards (and you must be using nvidia hardware, as you’re using VAR).
I’m surprised there’s no standardised vertex object extension. The VAR extension is really nice, using the write/read frequency/priority hints is very “OpenGL” anyway - why don’t the ARB standardise that?
Originally posted by knackered: register combiners are supported on tnt upwards
gf1+, tnt doesn’t support it.
oh, and… cad software normally doesn’t need fancy pixelshaders. sweet renderings will be done offline anyways due to complex lighting stuff like radiosity that has to be precalculated, and for the rest, you need tons of lines and flat triangles…
Okay, but the thing is I don’t need pixel shaders VAR otoh is very useful for large, static engineering models. So what I meant is – I can see where the ARB is coming from when they hold off a bit on “exotic” (ie gaming) features like pixel shaders when some of the more basic stuff (mipmapping) isn’t taken care of properly yet…
imho etc :]
Originally posted by knackered: bpeers, so the lack of any kind of pixel shading language (even a simple one, so Cg might suddenly be useful) doesn’t bother you?
There is no fragment shading standard, so I don’t see how it could be part of GL1.4.
Just wait for ARB_fragment_program, and if you can’t wait then do as you always did: use extensions (register combiners or Cg on NVidia hardware, pixel shaders on ATI, etc.).
I can’t understand why that single lack bothers you so much: can’t you see that the light is coming? In only few monthes we’ll have a generic vertex/fragment programmable API!!
Originally posted by DJ_GL: when will 1.4 be available for download, i’d really like to play with it now.
eh? download? they’re extensions which will become available in your drivers and on the registry site.
I can’t understand why that single lack bothers you so much: can’t you see that the light is coming? In only few monthes we’ll have a generic vertex/fragment programmable API!!
LOL! It bothers me so much because a standard interface has been available in d3d for some considerable amount of time, deepmind!
Tell me why a similar interface isn’t available in opengl 1.4 …please, I need to know.
ah, thanks, I didn’t know that… just sounded so hyped, and i’m here using 1.2 (i believe) and decided, wow, this upgrade looks interesting. Thanks for the insight!
Originally posted by knackered: LOL! It bothers me so much because a standard interface has been available in d3d for some considerable amount of time, deepmind!
Tell me why a similar interface isn’t available in opengl 1.4 …please, I need to know.
AFAIK, there is no such thing in D3D. No NVidia card supports Pixel Shaders 1.4 in D3D, just as well no ATI card supports NV_register_combiners in GL.
I’m sure something like NVParse exists for ATI extensions, so you can play with some obsolete ps1.0 shaders on both cards. But what’s the point anyway?
The truth is, ARB_fragment_program will be the firt unified API ever (assumed it’s released before it’s D3D alterego). Period.
Originally posted by deepmind:
[b] AFAIK, there is no such thing in D3D. No NVidia card supports Pixel Shaders 1.4 in D3D, just as well no ATI card supports NV_register_combiners in GL.
I’m sure something like NVParse exists for ATI extensions, so you can play with some obsolete ps1.0 shaders on both cards. But what’s the point anyway?
The truth is, ARB_fragment_program will be the firt unified API ever (assumed it’s released before it’s D3D alterego). Period.
Julien. [/b]
hm… ps1.3 works on every dx8 compliant gpu. gf3,gf4,radeon8500, new matrox, and all following ones anyways (as they yet support dx9 most of them)
oh, and they have one unified interface for it yes. does not mean every card can provide pixelshaders but thats not the point. dx always does have an unified interface for each of its features.
thats actually what currently is bitched all the time on opengl, and thats why a fully refactured gl (gl2) is really needed.
I’m happy when an upgrade offers some features that previously required extensions and their relatively low level programming style – which I usually can’t sell to management unless for really important cases (eg VAR).
