Since it’s inception, OpenGL has been re-processed a number of times. As such, parts of the api which (perhaps) should have been culled have been left to fester. I’d like to propose that parts of the api be re-organized or removed, so as to eliminate the number of pitfalls, and reduce “baggage”, and at the same time make a few suggestions for additions.
glBegin/End are a prime example of api-remnants that should be cleaned up. They are often abused, and serve little purpose. I’m not suggesting removing them from the api - instead rather, making them only valid in a display list, where they seem most appropriate.
Support for color index mode seems quite unnecessary, and perhaps could be culled from the api.
There are many other parts that seem superfluous and should be looked at - I can’t list them all here. Instead, I’d like to see the ARB re-evaluate OpenGL, and attempt to reduce any clutter they percieve.
I realized this may bring up backward-compatability issues. Of course, I dont know how they would be dealt with, but then, I’m not the arb.
For making my own life easier, I’d like to see a new state added. I think something along the lines of glEnable(GL_AUTO_MULTIPASS_TEXTURE) would be useful, whereby attempting to render with more TMU’s than what your hardware supports results in a multi-pass modulation.
glBegin/End are a prime example of api-remnants that should be cleaned up. They are often abused, and serve little purpose. I’m not suggesting removing them from the api - instead rather, making them only valid in a display list, where they seem most appropriate.
glBegin/glEnd are not useless functions. They are vital to implementing the immediate-mode API on various pieces of hardware. For example, some hardware may want to know how many vertices are coming in a strip before processing (for whatever reason). Since the primatives are not rendered until the call to glEnd, the OpenGL implementation is free to buffer-up vertex data until it knows when you are done with each strip.
Support for color index mode seems quite unnecessary, and perhaps could be culled from the api.
Color-index textures or color-indexed framebuffers (assuming OpenGL has such things)? If it is textures, I would like to point out that palatted textures are still pretty handy. S3TC and its ilk are good alternatives many times, but in cases where their lossyness are noticable, it is better to use palatted textures.
Besides, it is always better to have the option.
I think something along the lines of glEnable(GL_AUTO_MULTIPASS_TEXTURE) would be useful, whereby attempting to render with more TMU’s than what your hardware supports results in a multi-pass modulation.
Unfortunately, you cannot easily guarentee that multi-pass and multi-texture will produce the same results. This is especially true if it trys to multitexture some of it while multipassing other parts, or if the polygon itself is transparent and it tries to multipass render it. These are not trivial issues to resolve.
Once again, I think this is a confusion between power/flexibility/ease-of-use. You could, if one desired, get rid of immeadiate mode all together (and all the associated glbegins and ends), however, there are users who use it. You could lump all structures together as loose tris and get rid of quads, strips, etc, but there are people who use that too. I don’t think getting rid of glBegin() and glEnd() will solve the problem you are thinking of. Perhaps like Cg, you want a higher level language that writes the primitives for you, in which case check out openscenegraph.org and similar and only use the higher level API.
There are people who still use assembly programming to optimize routines, sometimes even large programs (eeep), but most of us use C/C++ and other higher level languages that compile to Assembly and then to executable form. One does not necessarily find an advantage in getting rid of the lower in favor of the higher, the existence of BOTH enrich our existance. (darn, I sound like a DC speech writer now!!)
Shaders are being integrated into OpenGL 2.0 and it is being rearranged, to some extent, to keep up with current technologies.
I wouldn’t say Im confused about wanting to remove emphasis from glBegin / glEnd. I’ve been using OpenGL for quite a while and I’ve seen a lot of things create a lot of problems for certain individuals.
glBegin/End seems like one of a few pitfalls that need to be “cleaned up” (as I said before not removed… maybe moved to glu or a glu-alike for gl2 if you dont like the display list idea) in light of more recent developments.
I’m quite familiar w/ the shading capabilities of GL2.
Regardless, I was talking about something else in the mean time.
glBegin/glEnd are quite useful for quickly checking out new features or testing stuff.
I’ve lost count of how many quick GLUT apps I’ve whipped up to test stuff (correctness, features, stability issues) and they all used glBegin/glEnd and discrete glVertex and related calls.
There are times where you simply can’t be bothered to declare, define and fill vertex arrays, let alone wrestling with the various transfer extensions like CVA+DRE vs VAR and VAO.
A programmer using that stuff in production code deserves to be punished - and is punished with low performance. But really, nothing can be gained by removing these tinker-toy features.
true, one should not use something just because it is there. However it does serve a purpose. If you make the glbegin only valid in one instance, you are in fact removing it. I think the “de-emphasize” aspect will be to make it “optional” in many cases where it makes sense to. This helps you and others too.
btw, many gldebug apps utilize immeadiate mode, it is still handy.
