The Future of OpenGL

from what I''ve read of the specs (which is a brief run over the inital short doc a while back) it does look to be VERY promising, and some of the features I''m acculaty looking forward to.

It should also sort out the Nvidia/ATI/Maxtrox problems which are going to start appearing more and more, perticualy with regards to vertex and pixel shaders (the high level shader lang is a very nice feature, I know ya dont NEED to use ''em, but its nice to have ''em there for effects which would benifit from them).

The object system for things such as textures etc is also a great step forward from the current system, I cant remember if you have a way to force things into video RAM using it, but if not it should be, if so then yey!

Future wise, well, D3 proves that current OGL isnt dead, and as long as the API can keep up with the hardware without going back to the current maddness of extensions (yes extensions are good but atm it does feel like over kill and its bit of a mess) the future looks good.

Also, the other projects linked to OGL2.0 (like the one for video replay via OGL, or something like that) all give a nice future possiblity, and I look forward to the OGL2.0 becoming released and the first cards to full support it all.

imho, the future has never looked better for OGL, and hopefully with the relase of OGL2.0 we''ll start to see more games released with OGL support, which as a side effect, might well help x-platform dev.

There ya go, a starter for ya to all pick apart
[excuse the typos, I''m tired but this subject does excite me a lot so I had to write something, better review the specs again later :D ]

OpenGL 2.0 should put OpenGL back where it should be, leading the hardware instead of following it like the graphics API''s of today do. I can''t wait.

I think the proposed features look very good, and will not only bring the API up to date, but bring it into the furture as well. I am, however, concerned that version 2 may fall victim to some of the same problems as version 1. First, I hope that the ARB does not let the standard fall into extension hell again, particularly having similiar, but slightly different extensions for different vendors. Second, I hope that it does not take as long to update the standard in the future, so we aren''t stuck on version 2.0 for 5 years after it comes out. Third, I would really like to see a ultility library included with OpenGL, to do things like SIMD accelerated matrix,vector and quaternion math, load common texture formats, and load a basic model format. Lack of these basic functions which are included in direct X represents a barrier to those just getting started with OpenGL. Fourth, I really want to see someone, game companies, engineers, defense contractors, or whoever, force microsoft to include OpenGL 2.0 support in windows. Otherwise, I fear that we will be stuck on version 1.1 in windows forever.

OpenGL 2.0 Looks great! I was looking over the papers on it today and I just happened to notice that the NV_Occlusion Extention was not on the list that was in the overview but the HP_OCCLUSION was and it is uncertain What they will do with it. I think that the something like the NV_Occlusion extention should be included. but it was not on the list at all.

quote:

---

Original post by invective
Third, I would really like to see a ultility library included with OpenGL, to do things like SIMD accelerated matrix,vector and quaternion math, load common texture formats, and load a basic model format.

---

OpenGL, being purely a graphics library, should probably not include those features directly. However, a utility library (like you said) could. However, again, I think that functionality can be found elsewhere.

Textures: OpenIL (now DevIL, but I like its old name better) loads textures (images) with an OpenGL-like interface.

SIMD acceleration: There is some library for ''fast math'' that''s open source. I can''t remember the name, but it was made by some important group (heh). It probably used AT&T style assembly, so good luck getting it to build outside of GCC.

Models: I was (kind-of am) working on a model loading and conversion library/kit called OMA, but it kind of stalled after the other members died (well...). I did a lot of work on it a while back, but I either don''t have the time or I am not in the mood to work on it most of the time now. If anyone would like to pick-up where I left off, feel free to, it''s under the BSD license so it''s pretty open.

quote:

---

Original post by Null and Void
OpenGL, being purely a graphics library, should probably not include those features directly. However, a utility library (like you said) could. However, again, I think that functionality can be found elsewhere.

---

I know you can find this kind of functionality else where (you can even just link in the D3DX lib on windows), but the thing is that these functions are so common and fundamental to just about any OpenGL app that I really think they should be included with the API. You can''t do anthing remotely complicated without some kind of vector or matrix class, and everyone has to at least load a texture. It makes it much easier to use if you have this kind of support out of the box, particularly if it is guaranteed to be cross platform. It also standardizes code, avoids duplication, and would make examples clearer to those who are learning. The inclusion of so many useful helper functions is really the one aspect of Direct X, that I like much better than OpenGL.

I think one can use d3dlib from within Opengl and glu within d3d. I''m not sure how Opengl2 will work on the windows platform with MS and all that. Other than that Opengl 2 looks really good so far. I like the idea of including audio api with gl2.

For the last time, kids, OpenGL is a graphics library and will never be anything but that. The same is true of Direct3D. Both APIs have auxiliary libraries which provide common functionality--contrary to common belief, Direct3D is only a graphics API. And if you want an everything-but-the-kitchen-sink solution, use SDL or, mix and match things like DevIL and OpenAL.

With all that said, I''m sure that OpenGL 2.0 will also have an updated set of auxiliary libraries to complement it, just as has been true since the beginning.

One thing I''m curious about is whether drivers and video cards will always have that legacy support for OGL 1 stuff. In the docs on 3DLabs'' site they say that 2.0 will keep support for 1.0-1.3 for a while until the switch to pure 2.0 is complete. Does that mean that once there, and all the new vid cards coming out support only pure 2.0, that I will not be able to play my old copy of Doom 3 on my brand new Geforce XII Ultra? I doubt this would happen though. The community at the very least would provide the support, kinda like they did when 3dfx died, and Glide with it.

--Buzzy
(formerly buzzy_b)

We'll always have 1.1 support for playing games (if MS have anything to do with it, we'll never have anything else). It's hard to say from the pdf I looked at, but it looks like we won't get the option of developing with a mixture of 2.x code and legacy gl code, although with the initial 2.0 release, this won't be the case.

____________________________________________________________
www.elf-stone.com

[edited by - benjamin bunny on June 9, 2002 12:08:28 AM]

D3DX header files are much like GLU headers, except MS went and added much more features. Am sure with 2.0 GLU will be updated to. But to what extent? Maybe they should add new features like texture loading and there own model format much like the .x from MS.

Wow N & V you still working on that? I guess I coulnd''t agree on a few things Plus am really busy

quote:

---

Original post by ANSI2000
Wow N & V you still working on that? I guess I coulnd''t agree on a few things Plus am really busy

---

Yeah, but it''s an off and on project for me. It''s pretty much done except that it needs to support more model formats and I haven''t really had time to learn any. The developer library even looks like OpenGL now (that state machine-ish style).

Im hopping that opengl 2.0 will have some helper function like DX have for mesh loading (.x) and stuff like that.

quote:

---

Original post by Alexandre Brien
Im hopping that opengl 2.0 will have some helper function like DX have for mesh loading (.x) and stuff like that.

---

Honestly, I personally hope it doesn''t . If you really want to have an OpenGL-like method of model loading, help out on the OMA project that I posted above. I can give you all the information you need to add code to it, and I''d really like people to write more model import/export routines. Or, if someone wants to help but can''t or doesn''t want to write code, simply suggest things to add to the OMA and OMX model formats.

I say keep OGL for 3D/2D renendering related things, and let 3d party dlls/apis handle things like gfx/model loading and window setup like is currently done.

quote:

---

Original post by Null and Void
I can give you all the information you need to add code to it, and I''d really like people to write more model import/export routines.

---

(slowly drifting off-topic)
What model formats does it already support? What formats are you looking to add?

quote:

---

Original post by Martee
What model formats does it already support? What formats are you looking to add?

---

It supports most of the basics from the WaveFront OBJ format, that''s the only independent format it supports. It also supports the binary ''OMA'' format and the XML based ''OMX'' format, which mirror the library''s internal data structures as much as possible. I most want to add DXF (ASCII, there''s also a binary version) and 3DS (which I know nothing about ). I''ve been reading about the Lightwave format too.

If you read the document here, documenting the OMX XML format, you''ll get the idea of how the inside of the code is structured. You''ll notice that I don''t have information on curved anything or skeletal anything in there yet, because I''m not experienced with those topics and didn''t want to commit anything flawed to writing.

The code is 100% ANSI C (compiled with -ansi -pedantic in GCC without warnings ) broken up like this:

endian.*: Code for endian correction (not that I''ve tested this on a big endian system yet).

get_*: Code to load for a specific model type.

list.*: Code for my really evil singly linked list (you''ll see what I mean if you look at the source ).

mem.*: Code for the memory leak detector.

model_data.*: Code for the internal model structure.

oma/*: anything for the OpenGL-like developer library.

omx_*: More random stuff for OMX loading/saving.

opt.*: Code to simplify vertex/texcoord/normal/color arrays into indexed versions.

put_*: Code to save for a specific model type.

tc_*: Code for the command line conversion tool.

type.h: Typedefs.

xp.*: My hackish XML parser.

I''m working on getting OMAPI into a CVS as we speak (I''ve never set one up myself, so I screwed up a lock file my first time through, SF just contacted me saying it''s fixed ). It can be downloaded here. The whole things is under the modified BSD license.

I''d also love an easier way to load .3ds files, it''s a pain loading them yourself, if only they could make it as easy as adding fog to the scene :-D

hmmm... let''s get a bit back on topic here. There''s one developement currently going on that I couln''t find in OpenGL 2.0. Hardware Deformation Mapping. It''s being developed my Matrox on their new card. DirectX 9.0 is going to support it. I''ve also heard Doom3 uses a technique quite like it. Anyone knows if it''s goint to be in OGL 2.0?

Sander Maréchal
[Lone Wolves Production][Articles][E-mail]