Long-term SDK plans

OpenGL
1

I think myself and the others working on the SDK have mad it pretty clear that in the short-term, we’re more concerned with the portions of the SDK that are important to beginners. Tutorials, simple libraries to handle loading images, a simple model format, etc.

In the long run, adding features that more experienced developers can use is certainly going to happen. One thing I know is wanted is a C++ vector library. Are there any other features that advanced GL programmers want?

2

Maybe you can like some of my ideas in my wrapper/sdk here: http://www.savefile.com/files/1810223 (the main.cpp is just used as a quick post-reply for the problem at http://www.gamedev.net/community/forums/topic.asp?topic_id=509703))

I’ve spent only a few hours in typing that lib, so only some of the planned functionality is currently present:

  • compile shaders via cgc.exe, have cached ARB asm shaders. Definition-switches for the compilation will be present (outside direct,outside env, and inside shader-file), as well as hiding shaders’ main() into a file “shaderSys.h”. (you can spawn many shader-variations easily like that). Coders must use semantics, to define where uniforms and vtx-attribs are. I’m a bit worried about ATi support, but will get a HD2400 or something for my second PC to test things later.
  • use nv_math.h for vectors, you just put it in your project and you’re ready. Will add optimized multiplication of a vec3 (or vec4) array with a mat4. May fix some readability issues of the nv_math
  • load DDS, jpg, bmp, png. Facilitate the making of texture-streaming (pbos internally, arrays of DXT levels, back-to-front - to upload smallest LOD first).
  • load several common model-formats, provide translation into a VBO-friendly format. (see vertex-declarations idea in tutorial1.cpp)
  • provide immediate-mode stuff, internally handled as streaming VBOs (already implemented, see tute and code)
  • basically, provide everything useful that DX9 and DX10 give, plus more. I’m somewhat confident in making things easy, usable and readable. Hide OpenGL, because old-timers and informed coders may find their way to the real path, but newcomers will be really overwhelmed with old irrelevant documentation/tutorials.
  • provide mechanism to debug shaders’ variables and pixels. (internally done with RGBA32f MRTs, readpixels)
  • keep it possible and easy to prototype code/graphics. (hassle-free loading of .obj/stuff models, textures, shaders, and debug shaders’ pixels). Provide VKDebug-like debugging :slight_smile:
3

Have you considered using ASSIMP ( http://assimp.sourceforge.net/main_features.html ) for model formats instead of doing it on your own?

4

Using existing technologies is always an option, especially for the “advanced” section. I’d like to keep a unified API style, but in the long run that might not be possible.

That being said, we’ve had a discussion about C++ libraries in the beginner portions of the SDK before, and I don’t want to re-hash it here.

5

I think you should be using existing technologies, not using the sdk as an excuse to show off your programming style and to bolster your CV’s.

6

Math:
vec3, matrix3x3, matrix4x4, quaternion, make sure to include the projection math stuff from GLU (i.e. glProject/gluUnproject, gluPerspective etc.), frustum class (for culling & visualization of the view area). Drawing functions for primitives, solid and wireframe (without GLUT).

Texture loaders:
BMP, TGA, DDS, JPG, PNG
I suggest that these be independent, single file C headers that anyone can add to their programs without the slightest trouble. Not everyone (certainly not beginners) wants to figure out how to find/build/link libpng/jpeglib etc. when they don’t need it. And please, rule out any dependencies on DirectX SDK for a DDS loader!

I would also highly recommend to include a 4x4 matrix visualization program + tutorial to help beginners understand how matrices work in GL, like this: http://home.pacific.net.hk/~edx/matrices.htm

7

Well, making a C wrapper over existing C++ libraries is not a bad idea and it should not violate your current coding conventions. Anyway, I am ok with C.

EDIT:

Is FreeImage enough?

8

Some of the above math functionality are already done in the C mathlib and quaternions are under development by me. Drawing geometric primitives falls under the GLS library which is under development by PaladinOfKaos.

Our libraries so far are C libraries, as it was the design decision made in the beginning. However, I am myself beginning to become more open to the possibility of also adopting C++.

What we actually need more than fancy utility libraries is the actual tutorials and documentation.

9

An idea for the SDK:
Put a new version of the OpenGL header (gl.h).
This new header would just be the Visual C++ gl.h header but without depreacated function such as glVertex.

The user would just have to replace the original gl.h of its compiler by this new one.

10

To be honest I thought that the idea of a C math library was so pointless for me as I ussually program in C++ and my own library is quite mature now with almost 4 years of development and feedbacks.

But I changed my mind just like that… I have to work in C for a project… damn it!

So keep up the good work, or maybe if there is already a good C math library, I’m could enjoy!

Anyway I checked out the sdk to have a look and I let you know any feedback I could have :slight_smile:

11

Damn it! Doing a good math library is so complicated … This one doesn’t really seem mature enough yet.

Why did you add the add the concept of color? This will involved cast to vector anyway in so many cases … and almost all functions ned to be defined for both vector and color, this imply code duplication as well.

A function like this could be very useful:
GLMvec3f *glmVecMul3f (GLMvec3f *out, const GLMvec3f *v0, const GLMvec3f *v1);
And other component wise operations.

For quaternion both cross and dot products are defined so I maybe glmQuatCrossf instead of glmQuatMulf would be less misleadind.

Is it really necessery to make the math library dependent of OpenGL types? I meens based on GLtypes. I believe that one big issues to solve is how to make a math library being “cross software”. What I mean behide this is for example how to make it works with OpenGL, D3D, 3DSmax SDK and PhysX for example.

That’s quite a chalenging issue.
Unfortunalty this being to OpenGL sticky imply that I can’t use it…

12

A maths library is perhaps the one simplest thing to make “cross software”. I really don’t understand why you would think otherwise.

13

?

It’s OpenGL dependent I don’t even need OpenGL.
So yes a math library but without dependences or possibly without dependences.