To be fair I get the impression from a couple of things posted in this thread that Michael was one of those who wanted the new API but were overruled by other considerations.
To be fair I get the impression from a couple of things posted in this thread that Michael was one of those who wanted the new API but were overruled by other considerations.
By other people, you mean.
Personally, I appreciate that Michael went to bat for us. But the ARB’s failures and continued refusal to provide a satisfactory explanation (oh, it was the CAD people. No, it wasn’t the CAD people; regular GL was just stagnant for too long, etc) creates frustration. Particularly for someone like Knackered who has no choice but to use this API, and would have abandoned it long ago if certain functionality were available to its competitors.
The simple fact is that the ARB are poor stewards of the API; they have been for years. After two years and innumerable promises, seeing no progress being made to fix the implementation issues with OpenGL is going to create a lot of anger. The ARB as a whole needs to stop complaining about that anger, man up, and accept their responsibility in creating it.
No individuals are accepting any responsibility, so when an ARB member, any ARB member, criticises another organisation for creating something messy the hypocrisy has to be noted. They’re all hiding behind group responsibility, so they’re all to blame, including individuals.
Was a bit of a cheap jibe though. Sorry.
Interesting articles, but sad:( check the users point of view also.
http://www.tomshardware.com/reviews/opengl-directx,2019.html#
http://www.neowin.net/forum/index.php?showtopic=670942&st=0
User POV doesn’t matter. A user just clicks your icon and runs your game.
A user should be more concerned about his OS.
The only interesting talk in the forums was from a Linux user saying that it should be easy to install software (ex : Opera).
Another user thinks that it is great that he can run games through WINE. It’s too bad that you can’t run everything through WINE. I’ve had little success. WINE is also a DX wrapper so there is probably a few % performance loss and errors, perhaps some shaders won’t even translate correctly, etc. I find that offensive and I’m betting most user’s as well.
Actually user POV matter, they are choosing the OS:)
I started a thread where people could post some more details about their OpenGL applications and what needs they would like to see addressed in future spec releases and implementations. It’s here in the suggestions forum and is titled simply “Talk about your applications.”
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=246133
What happened to the ARB_framebuffer_object extension spec. Wasn’t is supposed to be released within 1 month after the 3.0 spec was released, since it was in the cool down period?
Given any useful GL documentation/programming guide, looking at extension specs is better than having nothing at all, since the specs at least contain a focused description of what one can with a specific feature.
What happened to the ARB_framebuffer_object extension spec. Wasn’t is supposed to be released within 1 month after the 3.0 spec was released, since it was in the cool down period?
The spec is right there on the extension registry page.
Consider myself embarrased :eek: I was expecting it to appear on the end of the list, rather in the middle, as it did
Thanks!
Absolutely agree!
Quads are very useful feature for things like particles or many billboarded distant objects (trees) etc.
Also useful for drawing of text (quad per letter) tho for that one can also use point sprites if the text is in screen space(which is most often the case)
You can’t often replace quads with point sprites because the latter can only be screen-space axis-aligned squares (if you use bigger sprite and cut the unneeded parts with texkill, you waste gpu time and/or fill rate)
They are far more useful than triangle fans for example yet the last aren’t deprecated but the quads are.
This was one of the nice OpenGL features that contributed to it’s charm in contrast to direct 3d
About the quad_strip and polygon, they are unneeded indeed: the first is a triangle strip with different vertex order and the second is triangle fan
But i’m so unhappy about the quads 
The ARB_fbo extension does have some very useful enhancements. Nice to see that the limitation, that all render-targets need to have the same sizes (width, height) and format, will be lifted.
Jan.
IIRC the same-width/height/stride limitations were based on hardware, so that extension won’t be exported on all OpenGL hardware, just the ones that do not have that limitation. Roughly speaking, parts which can run DirectX 9.0 are in that category.
Probably the biggest difference the lack of quads will make is that when I am rendering terrain, the indice data will be 50% larger. Not a huge deal, but it’s something to think about.
As pointed out, particles become a little awkward. Not a huge deal, just a little annoying.
…That means you’re literally using GL_QUADS. 6 indices instead of 4. But why not use a triangle strip?
Depending on what LOD-schemes you use, you might very well not be able to render your terrain with triangle-strips, at least not without nVidias (proprietary) restart-extension.
I’d actually like to see GL_POLYGONS implemented:
Each polygon would start with the number of indices, followed by that many indices. So you could mix triangles, quads, pentagons, whatever. It would be useful for CSG geometry.
While I can sympathize with this whish, I’d personally oppose it if the issue was raised. For one thing it would open a can of worms in areas such as “interpolate between n vertices”, “what if the vertices describe a concave surface” and “what if these point’s are not on a plane?” - not to mention different implementations might have different optimizations or calculations, making one impl. see an n-polygon as planar, while another not.
I think you see the problem.
As for CSG, that’s outside the scope of OpenGL (as I’m sure you know 
).
It would expect a concave coplanar surface, just like GL_POLYGON or GL_QUADS does. Really it is just a compact way of drawing triangles. But I agree, it’s not important, and if I can just have triangles work on all targetted hardware without any bugs, I would be happy.
OpenGL 3.0 sucks
It just wasted our time