I will speak like a idealist (in bad english, y’m french). Don’t take care of my vision : we frequently start from a idealistic vision to find real evolutions.
You know, the GL API is incredibly powerful. Y have started to learn OGL 3 weeks ago for my first 3D engine, and I’m very impressed by the liberty and clarity provided by the GL API. In one week, y have done a MRM class (multi resolution mesh) with TnL compliance.
So, an API is “a door to access to contained knowledge’s and accumulated work and innovations – i.e. soft and hard”. My idea is based on the generic aspect of OGL calls : OGL is the first API I use to never need structures. With Arrays and other basic data (float, long…) type, it is possible to encapsulate the EXTentions of the openGL to provide the high level of knowledge of the best programmers like the nVidia’s one. Nvidia engineers brings a big and “to big” D3D sdk to make optimal usage of the hardware, or presentations that need hours and hours of understanding and implementations. It’s a SDK over a SDK, over a HAL… It’s to complicate, need a to long learning and cannot be splited. Microsoft have understand one thing : integrate the features in our API said “not need to do the job” for developers.
D3D is less interesting for “dreaming”. It should be greater that each month we can download the last version of detonator with simple new GL exertions, like the support of per-pixel shading. Or in other vision, each constructor should do a GLUT, like a NVGLUT that is not a utilities lib but a extension lib, that we can use with a OGL like API, which contains simple calls and computational intensive code.
The OGL is a layered black-box HAL, not a hierarchical monolithic technology like D3D. So, it should be easy to do a command like : NV_ACTIVATE_DOT_PRODUCT, NV_COMPUTE_PER_VERTEX_VECTOR, with intelligent and cooperative parameter like floats arrays. It should be very useful that OGL start to compute and integrate external knowledge.
You know, in real-time 3d imaging, actually more and more programmers doesn’t know how a rasterizer run ! But it’s not a problem. We have to understand the global mechanisms, what we can do, what we can’t. Not more. Look at the benefit of GLUT : with GLUT, OGL is become a standard.
The reason why a lot of programmers like OGL is his API. The reason why they should prefer D3D is because direct 3D do more things, and become a real full features 3D engine : developers don’t like that, but they will not have the choice, because accumulated techniques in D3D will become a real efficiency.
For an example : we should have some developers that know 3ds or Maya file format do an importer of file : but never use more than float arrays, to let the developer having the hand on what live in his program. Other exemple : one should integrate a lighting BUMP_GLUT, not build a full utilities, but just make the most important function like glDo(EXT_BUMP_COMPUTE_VECTOR_MAP,byte *src,byte *dst,…); This is a knowledge ! No file format, no utilities, no structure…
Well, what’s your ideas ?
Gabriel RABHI / Z-OXYDE / France