Long-term SDK plans

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?

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:

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

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.

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.

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:
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

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.


Is FreeImage enough?

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.

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.

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:

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…

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


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