Improving the SDK

[PaladinOfKaos]

Note to moderators: I think this belongs in "Items of Importance...". I can't put it there. If there's any sort of good response, I think it ought to be moved there.

Since the SDK came out, there's been a lot of whining about how it's not a "real" SDK. This is more or less accurate. But whining won't fix it.

I propose that the whole OpenGL community pitch in to create the examples and tools needed for an SDK. There are lots of examples to be written, and several tools that need free cross-platform implementations. This is really outside the realm of the ARB, unless the community takes action, it's not going to happen.

I propose a series of meetings on IRC of all parties interested in improving the SDK. If we can create a solid design with well-specified tools and examples, actually coding them won't be hard at all.

Creating it all for Opengl 2.1 may or may not be silly - I suggest waiting until after Siggraph to see what the roadmap is for Opengl3. Once we know that roadmap, we have a better idea of whether we should hold off for a couple months, or plow ahead. Either way, some aspects of the SDK design can be figured out soon after Siggraph.

[knackered]

the people with the time to do that are exactly the people we don't need spreading misinformation around through bad tutorials and bad example code.
The IHV's should collaborate and release a unified set of tutorials and example code. They're the only ones to know what the right thing to do is on their hardware.
Wouldn't you just love to see nvidia and ati actually cooperate on something for a change?

[PaladinOfKaos]

Wouldn't you just love to see nvidia and ati actually cooperate on something for a change?

I certainly would. And I have no doubt the people that do the SDK software would love to cooperate. But marketing and legal always have the final say on everything, and things like "brand integrity" and "proprietray techinques" will outweigh making a unified SDK.

As for the people that have time being the wrong people - that's not necessarily true. I don't expect anyone to spend huge amounts of time on the project. But an SDK doesn't have massive programs - mostly it needs small programs to demo specific features. Each of those is going to be just a few lines of code, especially if there's already a boilerplate that every SDK example uses. If 5 people spend an hour to write one example every week for a month, that's 20 examples. I suspect many of the examples won't take much longer than that once a good boilerplate is in place.

I think the real problem is going to be tools. There are already some tools by nvidia and ati, but they're windows (and mac?) only. OpenGL's biggest strength is cross-platform compatibility, and the tools need to show that as well IMHO. Those tools are going to take a lot more work than the examples, but they're what the SDK really needs. Fortunately, there are already some open-source tools listed on the current SDK pages. Enhancing them is a better choice than starting from scratch, as much of the hard work has already been done.

EDIT: About optimized examples - I think the OpenGL SDK should do what the MS DX SDK does - be generic. Get OK performance on all hardware. Let the vendors' SDKs show how to best optimize for their hardware. And when GL3 comes out, it's supposed to have only one good path anyway, so the whole point might very well be moot.

[bobvodka]

It's not just about code, in fact cut-and-paste code with a small amount of supporting text is the LAST thing we need. Those are possibly the worse kind of "tutorials" out there.

No, to write a decent tutorial, which teaches concepts and not just 'heres how to use the code in this situation' takes alot longer than an hour a week. I seem to recall the FBO tutorials I wrote for gamedev taking me a couple of weeks to write, check, check on different hardware, change to make clearer etc. That was often spending a few hours on it a day. A tutorial is not a thing you can rush.

Also getting people to agree on a boilplate is going to be hard enough; There was a plan to re-write the NeHe tutorials on gamedev.net, a team was setup and then promptly spent the next year or two trying to build a solid foundation and I believe at last count 2, maybe 3 years, after it was setup there have 5 tutorials and an overblown framework.

The DX SDK is probably something which an OpenGL SDK is modeled after but that means;
- code examples (examples, not tutorials)
- articles which are mostly none code
- a generally excellent and up to date API reference (complete with some small in line examples)

It also needs to be both one a single site AND as a downloadable reference as not everyone has net access 24/7 and sometimes it's easier to grab the stuff from your local machine.

[pudman]

I think the OpenGL wiki was also supposed to be helpful to people looking for information. However, it doesn't feature very prominently on the OpenGL main page so people come to the forum where they can get a specific response to their specific question. Ideally someone (preferably the question-asker) would then update the wiki with the answer.

Tutorials and articles plus problem solutions would make a very useful wiki. However I just don't see it happening right now. Someone would have to spend time updating it to show what it could be capable of (the ARB).

As for the "SDK", there would be a simple way to get version 1 out. Include:
The API in downloadable form. Zipped HTML works nicely (look at the Java APIs) but would require some extra formatting to get the pages nicely linked together. The Red Book examples zipped up. They are extremely dated but I think you can already grab them somewhere. Good for newbies. GLUT/GLEW/whatever zipped up, source included. Preferably with example code showing basic usage.

That's relatively trivial. The key is that it's all downloadable in one package. After Version 1 they can start making the examples actually useful, include helpful articles (how about "How to Read the OpenGL Specifications"?). Better tool inclusions. A platform independent shader debugger.

Even Version 1 would probably be asking a lot of the ARB. So far, their speed in doing things is terrible and the quality of their webpage resources leave much to be desired (excluding this forum, of course!).

[Korval]

Any new SDK should be for GL 3.0. Usage of GL 2.x and below should be strongly discouraged. Documentation should remain, but the focus should be on 3.0 and above.

[Mikkel Gjoel]

One of the things missing, that dx has, is a vector library (no, it's not a valid point that that OpenSceneGraph has one, most people don't use osg... and shouldn't :) )

I would like to suggest the following library: http://www2.imm.dtu.dk/~jab/software.html#cgla

Of other things essential are texture- and model-loading. I suggest either a simple .obj-reader, or, more likely to be embraced, a gl-wrapper for a collada-loader.

For textures it would be convenient to have either a libjpg-wrapper, a bmp-loader, or a wrapper for a proper library lige FreeImage.

...this is basically just stuff I would need to add to any project before I could do anything.

[dor00]

Any new SDK should be for GL 3.0. Usage of GL 2.x and below should be strongly discouraged. Documentation should remain, but the focus should be on 3.0 and above.

WHAT SDK??? Where is it?? You talk about community links?? Can we call that SDK??

[PaladinOfKaos]

No, we can't call it an SDK. That's been the point of the whole SDK debate since it was unveiled however many months (years?) ago.

[PaladinOfKaos]

I've created a document regarding the SDK. I humbly request that anyone who is interested in contributing to a community-led SDK effort, no matter how much or how little you think you can add, to read it and comment. It's based on:
1) The small discussion held in the GL3 announcement thread
2) Some standard things (like common licensing) that every project needs to have
3) My own whims and ideas

Everything (especially stuff coming from source 3) is changeable at this point. If you don't like something, don't get pissy. Just explain what you don't like and why you don't like it, and we'll all discuss it like grown ups.

I know there aren't many (any?) notes in the document on what came from which source. This is intentional. It's written as a final document like that would be written.

Now that all that's out of the way, here's your linky (http://docs.google.com/Doc?id=dpcc729_14gb8tmsfd)

[bootstrap]

I've created a document regarding the SDK. I humbly request that anyone who is interested in contributing to a community-led SDK effort, no matter how much or how little you think you can add, to read it and comment. It's based on:
1) The small discussion held in the GL3 announcement thread
2) Some standard things (like common licensing) that every project needs to have
3) My own whims and ideas

Everything (especially stuff coming from source 3) is changeable at this point. If you don't like something, don't get pissy. Just explain what you don't like and why you don't like it, and we'll all discuss it like grown ups.

I know there aren't many (any?) notes in the document on what came from which source. This is intentional. It's written as a final document like that would be written.

Now that all that's out of the way, here's your linky (http://docs.google.com/Doc?id=dpcc729_14gb8tmsfd)First, I think your document is a reasonable start. But the main thought I carry away from it is almost identical to something you (or someone) said, along the lines of "Sorry, but I'm not subjecting myself to styles/policies/libraries that I find personally repulsive (even if they might be better, in [somebody's] theory), and I'm not gonna waste my time learning some library/programming-approach that I do otherwise because I much prefer it". Damn, I almost feel guilty for also having this reaction, because in theory, I agree we should and could create a nice SDK. And I am/was even willing to help. Really.

This is a real problem, and if everyone else responds like us, and/or just advocates their favorite libraries and/or wacko-but-really-freaking-cool-programming-approaches, then everyone will run away at warp speed. Very sad, but it appears like this is true.

Therefore, my ***guess*** is, only 2 approaches might work:

#1: One person takes it upon themselves to provide the whole damn SDK project. True, we could contribute elemets, but he would immediately re-write it into his wacko but consistent personal style/approach/libraries - and we must be ready to accept that.

#2: The "lowest common denominator" approach, which means plain, vanilla, straightforward C (no C++). We all know C, even if we have moved on to supposedly/theoretically "greener pastures".

Personally, I believe #2 is vastly superior. Why? Because it contains NOTHING that "loses people", or bogs them down by requiring them to learn a new tool, style, library, approach, programming language. It might look a bit "ancient" to some folks, maybe even many folks, but it also looks pretty much just like OpenGL. So it is consistent and coherent in every way. And to keep things compact, which is very important in an SDK where people need to see many lines together to see how the various pieces relate, the good old K&R syntax is best:



int function (f64* mat0, f64* mat1, f64* mat2, f64* mat3, int x, int y) {
if (x < y) {
transpose_matrix (&amp;mat2);
} else {
transpose_matrix (&amp;mat3);
}
return (k3x_transform (&amp;mat0, &amp;mat1, &amp;mat2, &amp;mat3));
}


I wish I could find the article that researched and explained where the "modern" style came from that spreads everything out vertically in C/C++. The short answer is - moron professors competing for how many lines of code their students could write per unit time. Of course the easiest way to "win" is to have your students habituate the following "modern" style:



int
function (
double* mat0,
double* mat1,
double* mat2,
double* mat3,
int x,
int y,
)
{

if (x < y)
{
transpose_matrix (&amp;mat2);
}
else
{
transpose_matrix (&amp;mat3);
}
}

return (
k3x_transform (
&amp;mat0,
&amp;mat1,
&amp;mat2,
&amp;mat3
)
);

}


Justified by hyper-abstract professorial jargon-BS.

The last part is meant to be funny, not start any arguments!

-----

As it turns out, I personally might have a way to "get off the hook" (evade these problems) by contributing my super-efficient SIMD/SSE2+ assembly language functions for the fundamental 3D transformations that get executed a zillion times (I never did like those "silly" OpenGL stacks!). But virtually everything else in the SDK runs into the problems I mention above.

I mean the above to be honest, helpful, respectful. Really. :-)

[bobvodka]

In fact, I DON'T know C and I bet most people who think they do because they know C++ don't either (and probably don't know all that much about C++ to boot but that's a side issue); oh I can muddle along with C89 because it's a subset of C++ but some of the things I don't know about because I've never used the language as is.

Also SIMD/SSE2+ assembly language in an SDK is both redudant (and over kill) and locks the SDK to a single platform; not useful when OpenGL is meant to be cross platform.



So it is consistent and coherent in every way. And to keep things compact, which is very important in an SDK where people need to see many lines together to see how the various pieces relate, the good old K&R syntax is best:

Great, unless of course you have people who dislike putting the openning brace on the same line as the function/condition/whatever as it obscures your ability to spot nesting without parsing the whole line.

In short; another point of contention.

[Korval]

This is a real problem

Yes, it is. The fundamental issue is this:

1: I know what would be good in an SDK.

2: I don't want to spend my precious free time writing that.

While I don't think "K&R" syntax or pure C is the natural way to go for an OpenGL SDK, simplicity is an obvious goal. But the simple fact is that my free time is limited, and I spend enough of my non-free time working with horrific code. If I'm going to program as a hobby, I will do it in a style that I enjoy.

Which is why I say that I'm not a good candidate for helping to code this. Because I know that my style, which is reasonable when you have read a 20 page document explaining how and why it works, is not simple. It is not appropriate for an SDK.

Whatever style is agreed upon must be simple. It must adhere to certain reasonable conventions.


locks the SDK to a single platform

Except that you can always #define around these things, so that they'll work in the absence of an appropriate build environment.

[Jan]

I agree with suggestion #2 of bootstrap. Of all the tutorials online, NeHe's are the most popular, because they always contain the whole code of a project, they explain one main feature, but REPEAT at least some explanations about all the boiler-plate code, there is no complicated framework you need to learn/understand, and the code uses only very limited features of C++. All that makes it great code to learn from. Boost might be nice, but for beginners it IS a problem. Boost is huge and thus frightening to beginners, even if your projects will only use a tiny fraction of it. Also Boost contains mainly code that uses C++ features so cleverly, that most beginners would need to first look up all the C++ keywords used in there, that they have never heard of before.

Glut WOULD be a nice idea, if it wasn't so outdated (since the SDK is supposed to only use GL3 code...).

In my opinion it would be best to have a FEW basic routines supplied by one person. For example for setting up a window with a GL context, destroying it again and maybe to load a texture from a common file-format (like TGA). Everything else should be up to the one who writes the tutorial. There could be guidelines, like "keep the code simple", "don't use classes" etc. And maybe a hand full of tutorials should be written by the SDK maintainers, such that others can copy their style.

I think this is a difficult task and lots of work, so don't make it too complicated for others to help you out. If there are a few example tutorials, i am sure people will see it as an honor to contribute their tutorials in the same style.

Don't think too much about "good programming practice". There are way too many different opinions about it and it is not what the SDK should be about. Save yourself the trouble.


Jan.

[Korval]

In my opinion it would be best to have a FEW basic routines supplied by one person... Everything else should be up to the one who writes the tutorial.

An SDK is not, and should not be a bunch of tutorials. The purpose of an OpenGL SDK is as much to explain how to write GL code as to have a codebase that makes GL more usable. If you look at the DX SDK, you'll find a lot more than just tutorials.

The fundamental beginning of any real SDK for OpenGL is an extension loading library. Especially since you can't even get a GL 3.0 context unless you load at least one extension.

[PaladinOfKaos]

I can see how to agree and disagree with all of your points =)

bootstrap: I agree that #2 is a vastly superior option. I also think we need a unified style to keep the SDK as one solid unit rather than a bunch of example programs glommed together.

bobvodka: You may very well be correct on the "I know C if I know C++" problem. Perhaps a "C for C++ programmers" document could alleviate some of the problems there. And most C compilers these days can handle some C++ elements (especially one-line comments), so we don't need to be _too_ stuffy about ANSI C.

Jan: I think more than just a "few routines" would be better. We need something like the NeHe basecode, with a "setup" routine and a "render" routine that can be added to for each tutorial and example. It makes writing a tutorial much easier - you can leave out the basecode after the first few tutorials.

Korval: I agree that we need more than tutorials. A library of common routines is a must, as is a good basecode. The document didn't describe it because it's a prototype for a document that comes after we have that library in place - the thing new contributors get to read before we let them do anything.

All: Most people can get used to coding in a slightly different style than they're used to (brace position, spacing) if they really care about the project. The consistant style of projects like Wine and KDE is a testament to that.

korval again: Would you be willing to be sort of a technical editor, helping to make sure that tutorials and articles are technically correct? You're one of the most knowledgeable people about OpenGL on this board, after all.


I can start another document of things we'll need for the boilerplate and library, if you all want a single place to look at it and have ideas listed. There are lots of logistical things that need to be sorted out as well. Perhaps a third document is in order for that.


EDIT: I updated the coding style section. I still expect that to be a point of contention, but it's closer to a lowest-common-denominator situtation now. If any of you have google accounts and would like to be involved in this for the long haul, PM me your accounts and I can add you as collaborators for the document. I'll do the same for any future documents that come up until we get a website with a real CMS.

[bootstrap]

In fact, I DON'T know C and I bet most people who think they do because they know C++ don't either (and probably don't know all that much about C++ to boot but that's a side issue); oh I can muddle along with C89 because it's a subset of C++ but some of the things I don't know about because I've never used the language as is.I cannot imagine anyone programming with OpenGL unless they understand the fundamental features of C. I mean, all the OpenGL functions are C function calls! What documentation are they reading to program OpenGL without understanding basic C syntax?


Also SIMD/SSE2+ assembly language in an SDK is both redudant (and over kill) and locks the SDK to a single platform; not useful when OpenGL is meant to be cross platform.You are absolutely correct. But of course I always write C functions first, make them work, then write an assembly language function that performs exactly the same. So the normal function call serves the "learning" and "understanding" aspects of the SDK, while the SIMD/SSE2+ assembly language serves the "solid core/extension code base" aspect of the SDK. At least that's what I thought people seemed to agree were the two main goals.


Great, unless of course you have people who dislike putting the opening brace on the same line as the function/condition/whatever as it obscures your ability to spot nesting without parsing the whole line.It does not obscure anything - only the cues are different (match the indent of the beginning of the line with the closing brace). But I do not debate the absolute fact that many of us just shudder, if not suffer epileptic seizures, when we see code organized the "wrong" way.


In short; another point of contention.It is truly amazing and incredibly sad how bad this problem has gotten! So who is gonna write the "display processor" program that reformats the K&R "original" text into whichever style each person prefers? BTW, nobody needs to see the code for your program - so you can write it any way you wish. What a relief!

I guess I wasn't clear, but when I said "plain, simple, vanilla C", I mean limit the code to the absolute minimum set of the simplest C features as possible. And yes, I agree with the person who said it needs to be written very carefully so it is as clear as possible. We want someone to write code like the diametric opposite of a "show off".

Seems like we need to find someone universally liked/admired/respected to accept this responsibility. Otherwise he/she will be torn to shreds by contradictory demands - and give up.

Sad but true; somebody should probably just take the SDK project on quietly, then drop the finished SDK on us all in 6~12 months.

----- later thoughts -----

My engine creates windows and such with GLX (on linux) and WGL (on win32). I prefer that, and it stays within the "core" too. Also, I found that easier than the alternatives - but then again, I *always* find the lowest-level options to be easiest and most reliable.

Here is a really impractical idea - unless it works. How about trying to get [one+] of the authors of "OpenGL SuperBible" to help with this (even oversee it perhaps), and let him include the SDK with the next (fifth) version (or simply include or reference any parts that he finds appropriate). Or pick *your* favorite OpenGL author ("OpenGL Distilled" is another good one).

[HenriH]

I think the SDK proposal looks very good. C is the best language to use due to it's simplicity IMO. You will also need to address the issue of portability framework. And by the way, GLUT is not that outdated. FreeGLUT is being maintained and new features have been added to it.

If somebody wants to contribute but must use something like C++ or boost, then some other person can take the code and port it into plain C89 (or C99). Also good idea is to fix and clean every piece of code before submitting it to the final SDK.

I have not been programming 3D graphics or OpenGL for some years, but I think I could help. If not by writing code, but fixing, cleaning up and ensuring conformity to the "SDK standarnd" maybe.

[PaladinOfKaos]

Henri: Welcome aboard. I'm sure we can find a place for you to help. Having someone dedicated to code review might be overkill right now, but if the project takes off, it could be handy. I certainly don't want to have to vet all the code coming through.

[Korval]

I cannot imagine anyone programming with OpenGL unless they understand the fundamental features of C.

The main point of having an SDK is to get people who have never used OpenGL before. So they are not OpenGL programmers. Yet.

The very concept of function pointers, central to loading extensions, throws off people. They're something that C programmers are very familiar with, but most C++-only programmers are not.

[HenriH]

Henri: Welcome aboard. I'm sure we can find a place for you to help. Having someone dedicated to code review might be overkill right now, but if the project takes off, it could be handy. I certainly don't want to have to vet all the code coming through.

Thank you. I will be watching this thread with interest. When you need my involvement, you may drop me a private message.

[PaladinOfKaos]

Korval: I think we're going to try to hide function pointers behind a nice extension loader. I agree most new programmers aren't going to know about them.

[PaladinOfKaos]

OK, I've got a list up of basic components needed before we can even write the boilerplate code. http://docs.google.com/Doc?id=dpcc729_15wprqnkd4 . Questoins, comments, and suggestions are, as always, welcome.

[HenriH]

Well okay. It came to my mind that we could perhaps use mixed C and C++. C++ classes for the math system and C for some others. Do you think this could work? I would have some code for math classes, such as vectors and matrices. Althought, we could code this in C too.

For the file system abstraction, we could implement some function that translates the path to the OS path.

Other issues: We should also decide on the naming convention of functions and classes (if we use C++).

[pudman]

So who is gonna write the "display processor" program that reformats the K&R "original" text into whichever style each person prefers?

Already written. The Eclipse IDE has that feature. Much more importantly, however, is to NOT worry about style. As with any project, if you get too "low level" before you even know what you want, you're screwed.

Style... libraries... What do you WANT from an SDK first?

Here's what *I* would do if I were to start that project.
1) Look at existing examples of 3D SDKs. There's the DX beast. Both nvidia and AMD put out DX/GL SDKs (no, ATI's GL SDK hasn't been updated since 2005). What do you like about these SDKs? What do you not like? What do they provide?
2) After doing that research, come up with a list of what you think should be in the GL SDK. Think high level: Documentation, tutorials, full source demos, utility libraries, tool utilities.
3) Refine your list into more specificity:
3.1) What tutorials? Tutorials for beginners? For tools? For performance? For advanced topics? Should the tutorials include a "tutorial framework"?
3.2) What documents? Reformatted man pages? Annotated spec? Extension guide? Performance guides? Pretty pictures?
3.3) What demos? What are the licensing arrangements for using nvidia demos/amd demos/GPU Gems demos/user xyz's demos?
3.4) What utility libraries should be included? GLUT? GLew? Links to nvidia/AMD debuggers/analyzers/composers? A simple GL modeler? Model/texture importers?
3.5) Could be more things to list...
4) Task assignments to further research items in #3. Tutorial submission requests. Demo licensing investigation. Document gathering and formatting... Tons of tasks... BEFORE A SINGLE LINE OF CODE IS WRITTEN!!!

Debate style, and hell, language too, when you actually know what you want.

If you jump right into coding tutorials you'll at best duplicate the NeHe effort, not create an "SDK". At worst you'll waste time at work trolling this thread with arguments about your favorite C++ feature/style.

Sure, OpenGL is an API for CODE but please, stop talking about code IMPLEMENTATION until you figure out what you want in an API.

[HenriH]

There is also a UNIX tool called 'indent' which is able to transfer code between various coding styles.

[PaladinOfKaos]

Standard C is probably better. We won't have operator overloading for vectors (which is unfortunate), but it's the lower common denominator.

A gl-inspired naming scheme for functions would probably be best. Perhaps "glsdkAwesomeFunction" (the prefix is up for debate).

Can we all agree that hungarian notation should be avoided, except in OS-specific code where it's standard (namely Windows/WGL code).

[Korval]

If there's going to be a serious effort to achieve this, then we probably need a SourceForge project or something similar for it. That way, we can have a place for discussing this, as well as a place for donating code.

Also, I offer my services as a document writer. I love DocBook XML, and I can do some pretty amazing things with it in terms of documentation (making HTML in virtually any format you would like to see, PDF versions for printing, etc).


1) Look at existing examples of 3D SDKs. There's the DX beast. Both nvidia and AMD put out DX/GL SDKs (no, ATI's GL SDK hasn't been updated since 2005). What do you like about these SDKs? What do you not like? What do they provide?
2) After doing that research, come up with a list of what you think should be in the GL SDK. Think high level: Documentation, tutorials, full source demos, utility libraries, tool utilities.

I agree on some level that research should be done into other SDKs to see what they offer, but there are enough tasks that any reasonable OpenGL SDK should cover (extension loading, for example) that it's something that can be put off until later. Those tasks should be broken down and assigned fairly early on.

[HenriH]

I agree on the hungarian notation. However I would not recommend a naming prefix for tutorial/example code. We could use the GNU naming like_this.

pudman also has good points there. We should first think about the content and the design of the SDK first before anything.

Edit: I see the naming prefix overly verbose and redundant without any benefits for sample code.

[PaladinOfKaos]

pudman: Thanks for the reality check. I tend to get bogged down in details too soon, as you noticed =).

I'm on Linux, so I can't look at the DX SDKs. And NVIDIA's linux SDK is pretty much a collection of examples. It's not a good reference point. Someone one windows needs to do that bit for me, I'm afraid.

From what they say on their websites, and from what we've discussed here, I think we need something like this:

An API reference (like the manpages, only includes non-deprecated 3.0 stuff) A series of tutorials on the basic concepts needed to get an OpenGL program running. This is rather involved, since fixed-functionality is gone Annotated examples and/or tutorials on higher-level concepts. Things like lighting equations and other fun graphics math that everyone needs to know A set of libraries for matrix math, extension loading, context management, and filesystem abstraction Fancier less-documented demos purely for showing off what GL can do.

Does everyone agree with this? Questions, comments and concerns are welcome, as always.

[PaladinOfKaos]

OK, responses to all the cross-posts:

Sourceforge project: I can go with sourceforge. I'd prefer git to SVN, but I'll survive with SVN.

Henri: The prefix would only be for library functions that come with the SDK - image loading, extension management, and that sort of stuff. Functions within examples don't need any particular prefix.

Korval: Docbook is a pain to learn. I think we'd all be grateful to be able to use a system like that and have somone on the team who knows what's actually going on with it.


EDIT: If there are no objections by this time tomorrow night, I'm going to request the sourceforge project

[HenriH]

It looks good. I have a Windows machine at my disposal, I may check the DXSDK. I read from somewhere that ARB is updating the manpages to conform to GL3. I am not sure can we use them for the copyright reasons. We could also write our own pages.

I am willing to put time and effort for implementing the math libraries or some parts of them. First, we need to agree on them and design them. Put it is not the time for them yet.

[Korval]

An API reference (like the manpages, only includes non-deprecated 3.0 stuff)

I think that one we should take from the ARB. When they update the "not-SDK", we can just use their HTML.


Docbook is a pain to learn.

No, it isn't. You're just not using the right tools. The writing of a DocBook document is simplicity itself; it's more the use of it that takes some effort.


A set of libraries for matrix math, extension loading, context management, and filesystem abstraction

No filesystem stuff. All the SDK should do is take a string (UTF-8) that represents a path and use it using standard reading functions. Anything more than that is well beyond the scope of an SDK.

[HenriH]

I think Korval meant that he can write the DocBook files. We can send him the raw text in plain ASCII format etc. and he does the conversion into DocBook.

[PaladinOfKaos]

I think we'll need to write our own pages. I'd rather they be in docbook, or some other low-level format like that. That way we can create a PDF, HTML, and all sorts of other formats very easily.

The math libraries are on the list of things to do once we have a plan and some idea of how we want to code things. They're one of the first pieces of code we're going to need to write, so it might not be too early to start designing them.


EDIT: cross-posted with korval on this one. We migh have licensing issues with the ARB-released manpages. We need to verify we can use them before we copy them.

[PaladinOfKaos]

OK, these cross-posts are getting kind of ridiculous. Can we switch to IRC or something like that?

[HenriH]

IRC is fine. Lets choose Freenode server and #glsdk channel.

The DirectX SDK is a big thing containing many things. The documentation is split into parts, each part describing one subsystem of DX. Each part has somewhat these basic things:

* Programming guide
* API reference
* Tools
* Tutorials and samples

I think we should do some sort of Programing guide also, describing some basic 3D graphics and math background, like matrices, 3D transforms and coordinate systems. Another good one is a section devouted to our portability layer.

[PaladinOfKaos]

OK, I'm in the channel. And your list of sections looks good to me. Next step is to prioritize them, and break them down into subsections

[Mars_999]

I am going to throw this out there, what about just using SDL? It covers all platforms. Plus it will load textures instead of messing with a texture loader to complicate the SDK for new coders. We can just concentrate on the API and leave a basic operational framework working with SDL... The whole point is to get this out to as many platforms as possible, and if you can read some C/C++ code I hope you can at least follow a simple SDL app with very few lines of code, vs. the nature of win32 or Cocoa...

As I said before, what about a webpage on opengl.org for this SDK? Or there is going to have to be a sourceforge page for this then...


I have no preference for C or C++, as was stated with function pointers by Korval, for C, C++ uses virtual functions instead, but GL uses function pointers, but couldn't we get around this with just using a extension loader? Then what would the user really need to mess with function pointer for?

[PaladinOfKaos]

Mars_999: If we're gonna have all sorts of samples and examples, we need a VCS. If khronos is willing to set that up on their servers, we can have a page on opengl.org. Otherwise we can start on sourceforge, and maybe move to our own server if necessary.

As for SDL... it's big. It covers a lot of things not related to OpenGL, and there are some idiosyncracies (like texture coordinates) that make mixing the two kind of strange.

[Rick Yorgason]

A file system abstraction layer. At the very least this needs to hide the "/" vs. "\" problem.
That's not really a problem, is it? Both the C and C++ file I/O libraries accept forward slashes on most (all?) platforms. They'll also accept back slashes on Windows, in case you're accepting user input.

Oh, somebody also mentioned that modern C compilers "accept" C++-style comments. Actually, C++-style comments have been standard since C99; you can use them and be guilt-free.

[Stephen A]

What about glfw? (http://glfw.sourceforge.net) It's as simple and light-weight as you can get, like FreeGLUT but with a saner API.

Glee or glew would also be very valuable, but otherwise it would be a good idea to keep dependencies to a minimum.

[ZbuffeR]

I really like GLFW too, but it lacks UI and text, contrary to FreeGLUT.

Maybe both could be used, GLFW for games and visual demos, *GLUT for apps with menus and buttons.

[k_szczech]

Yes, glfw is very nice - I think it's the best choice actually. No unnecessary stuff :)

As for math library - I could provide C++ classes for vectors, matrices and math functions that have syntax identical to GLSL. I allready use such classes in my applications. Yes, swizzling is also included, so you can do this:

vec3 a;
vec4 b;
a.zxy *= clamp(b.yyz, 0.0f, 1.0f);
directly in you C++ application.

They require some more work. Vectors are mostly compatible with GLSL and most math fnctions from GLSL are implemented but matrices need quick rewrite.
There are still some cases when compiler requires explicit typecast when using swizzlers, but I believe that can be solved, too (partially solved allready).

The main problem is that I don't have time right now to work on this. Perhaps someone would take over?

[Jan]

Is this SDK supposed to be online-only (like the current SDK/wiki), or is it supposed to be downloadable or both ?

I like downloadable SDKs, but then there is the problem to support all the different platforms with an installer (WE cannot ignore Linux...).

Jan.

EDIT: It could be distributed as a simple zip-archive.

[k_szczech]

As for me, if it's not downloadable then it's not an SDK :)

[Rick Yorgason]

I assume both, given the talk about using DoxyGen.

In the case of DX, I like having both. I use the downloadable DX SDK because its sample browser is a convenient way to browse the sample binaries, but I use the web-based SDK to look up code samples and function docs, because Google is a much better search engine than Microsoft's crappy help system.

Of course, the actual DX library is distributed through the SDK, so you don't have much choice but to download it.

Which brings up an interesting question: will FreeGLUT/GLFW/Glee/Glew/whatever be distributed with the SDK? That would certainly be convenient on Windows, although *nix systems are probably better served by their own package management systems.

[HenriH]

Oh, somebody also mentioned that modern C compilers "accept" C++-style comments. Actually, C++-style comments have been standard since C99; you can use them and be guilt-free.

This is what I meant; C++ style comments have been standard since C99 as opposed to C89. C99 is not, however, necessarily that widely adopted. GCC lacks some of its features.

----

We had a brainstorming session with PaladinOfKaos last night and we did some designing. He will probably post some topic you to comment about once he gets all that stuff organized.

Edit: the main focus was the math library and we decided to stick with plain C. C++ wrappers can be done later on.

[Stephen A]

A tangential question is, will the samples be precompiled, or distributed in source form? If the dependencies are kept to a minimum and the build system is simple enough, the latter may actually be easier to support.

But that's actual a little less important than deciding to *what* is going to be in the samples; *how* it will be presented (NeHe style? shudder); by *whom* it will be written. (First decide the scope of the material and then how to implement it).

My opinion is that each sample should present a concept in written form, accompanied by a short program that contains the minimal amount of code that implements the concept. A "sample explorer" would list all available samples, possibly with links to further information, articles etc.

It would also be great to have the online function reference available offline. I don't know if there are legal issues with this, but seeing that PyOpenGL (and other bindings) already provide their own versions of the online docs, it should be possible.

One more thing: should the sdk provide its own utility functions, or should it link/use existing libraries? For practicality's shake, I think the latter approach might be better: collect the "best of breed" libraries for each category (e.g. math, windowing, texture loaders, GUI, fonts, etc. taking maturity, usability, community and license into account).

Edit:
This is what I meant; C++ style comments have been standard since C99 as opposed to C89. C99 is not, however, necessarily that widely adopted. GCC lacks some of its features.
The only C compiler I've used that didn't support C++ style comments was written in '88 for DOS. GCC 2.95 supports these and VC6 does too - there's absolutely no reason to worry about this.

Using other C99 features however is probably a no-go.

Edit 2:
the main focus was the math library and we decided to stick with plain C.
What about existing math libraries? Intel/AMD both provide such libraries and there are many more to be found in the web. Is there really a need to write a new one from scratch? Yeah, I've been guilty of that thrice, in C, C++ and C# - but I think we should avoid unnecessary complexity wherever possible :).

Another thing to note is that we could modify/wrap existing APIs to make them fit together in a nicer way.

[HenriH]

A tangential question is, will the samples be precompiled, or distributed in source form? If the dependencies are kept to a minimum and the build system is simple enough, the latter may actually be easier to support.

We don't know this at this point yet for certain, but I suppose that for Windows we should come up with both. For Linux, it would be source package mainly.


My opinion is that each sample should present a concept in written form, accompanied by a short program that contains the minimal amount of code that implements the concept. A "sample explorer" would list all available samples, possibly with links to further information, articles etc.

It would also be great to have the online function reference available offline. I don't know if there are legal issues with this, but seeing that PyOpenGL (and other bindings) already provide their own versions of the online docs, it should be possible.

These are also my thoughts and I agree with you completely.


One more thing: should the sdk provide its own utility functions, or should it link/use existing libraries? For practicality's shake, I think the latter approach might be better: collect the "best of breed" libraries for each category (e.g. math, windowing, texture loaders, GUI, fonts, etc. taking maturity, usability, community and license into account).

We are considering options. I think we will be choosing some existing utility libraries and write some of our own.



What about existing math libraries? Intel/AMD both provide such libraries and there are many more to be found in the web. Is there really a need to write a new one from scratch? Yeah, I've been guilty of that thrice, in C, C++ and C# - but I think we should avoid unnecessary complexity wherever possible :).

Another thing to note is that we could modify/wrap existing APIs to make them fit together in a nicer way.

While I am not completely aware of existing math libraries, I think we should do a "native" OpenGL math library that looks and feels like OpenGL. I am talking something like D3DX has.

In the mean time while Paladin gets stuff organized, take a look at this draft.

OpenGL SDK Math library draft (http://nor.fi/~henrih/glmath.h)

We will be staying in touch...

[dletozeun]

The math library draft looks nice for me as it is intuitive and recall the Opengl style.

For tutorial, I don't know your opinion, but I always really hated the NeHe layout. A bit of text, a bit of code, a bit of text, a bit of code.... this is very difficult to read I think.

I would rather have tutorials, with many explanations and especially illustrations with almost no code or only the important parts not the details. Details will be in the well commented attached source code

[HenriH]

The math library draft looks nice for me as it is intuitive and recall the Opengl style.

For tutorial, I don't know your opinion, but I always really hated the NeHe layout. A bit of text, a bit of code, a bit of text, a bit of code.... this is very difficult to read I think.

I would rather have tutorials, with many explanations and especially illustrations with almost no code or only the important parts not the details. Details will be in the well commented attached source code

I tend to agree. The source code should have normal amount of comments and the detailed explanation somewhere else.

[Rick Yorgason]

I really liked the Nehe tutorials when I was first learning, all those years ago. It coincided with the way I like to use tutorials, which is to copy each line of code manually, making sure I understand what each line does.

Once I had learned enough that I could diverge from the tutorials, though, it became less useful. I would rather have had a tiny example showing only the feature in question.

Nehe is going to rewrite their tutorials for OpenGL 3, though, so there's no need to duplicate their work.

Precompiled binaries are definitely appreciated on Windows. They're appreciated on Linux too, but again, that's something best left to each flavour's packaging system.

[PaladinOfKaos]

I don't think there's much point to distributing demos in the SDK if people can't pick them apart and see how they work, so source code is a must. We can discuss binary packaging on all platforms once we actually have source that can be turned into binaries.

Even though NeHe does exist, I think we need to have a set of clear tutorials in the SDK that use the utility libraries we distribute. That way when someone goes from the tutorials to the examples, they're not wondering what glmVecTransform() does, and why it exists. We can certainly included NeHe in a list of "other resources", along with Gamedev, this forum, and the ARB's erm... "SDK"

[Mike C. Fletcher]

One suggestion for improving the SDK; provide the DocBook source files for the man-pages in a downloadable form. At least, it would certainly make it easier for me to produce 3.x documentation for PyOpenGL :) . The board obviously has at least 2.1 docbook available (since they use it to produce the online SDK). Doesn't need to be pretty, just the raw docbook files would be sufficient.

[dletozeun]

Rick, personnaly, I don't think that copy and paste is a good way to learn. This way you don't really understand the details, I think it is better to first read an abstract explanation with good illustrations (which heavily lack in NeHe tutorials) and then apply this theory coding with OpenGL. This way learning Opengl is more intuitive IMHO and you don't get stuck in a way of thinking bound to the code.

[PaladinOfKaos]

Mike: I'd like to get the DocBook source into the SDK VCS so we can update and clarify the docs outside of the ARB's decisions to do so. so the raw source would be available.

dletozeun: Clear and consistent with OpenGL is what we were going for with the design. I'm glad we achieved that.


Tutorial layout is going to be something to debate later (but soon later, not way later). I think the NeHe style is going to be best for the basic stuff (the DX tutorials use that same format). More advanced things should have textual articles with example code.

[HenriH]

One problematic of the SDK is that if we are going to make utility libraries of our own, development cycles of them can be tricky and rapid.

I think a better option would be to develelop the libraries as a separate projects in Sourceforge etc. then just link them in the main SDK project. In this way, people could continue on the library development independently from the main SDK and also download them as separate packages if they so desire.

Of course, we should agree on some general guidelines and conventions to make all look clean and mean, and generally agree on the directions we are taking, but I think making a separation could be good idea?

We should think what utility libraries are we going to use in the SDK and what we need to do ourselfves. I recommend using freeglut or GLFW as somebody did mention it. The OpenGL math library I think is generally a good idea. Also, perhaps we should use GLEW as the extension library if they get to update it to OpenGL3.

Also, we need to decide some sort of SDK devteam structure, assign responsibilites etc... At this moment, we are not properly organized.

Edit: Or maybe we should do like they do in boost, organize the project into subprojects, which may be downloaded and developed independently...

[PaladinOfKaos]

We can get the devteam structure and responsibilites assigned through the Sourceforge tools.

I think we should keep the full SDK, including libraries, in one SVN repository. that way we can easily make the bundles for an SDK release. We can, however, tag the libraries for releases more often than we tag the full SDK.

I'm OK with using GLEW, although I think we should mirror it in our repository and keep our own .spec file (that only contains post-3.0 features). GLFW is a C++ library, so I think we should prefer GLUT over it, if possible. I'll shoot an email to the freeGLUT developers about GL3 support.

[Rob Barris]

Is there consensus on what the right starting point should be ? One triangle? Teapot? Ocean waves with froth ?

There might also be an opportunity here to be forward looking - to anticipate some common questions that are going to come up for future GL as deprecations take hold.

One example I'm strongly familiar with is efficient transport of CPU-sourced dynamic data using MapBufferRange - some of the known problems in emulating glVertex*** have to do with efficiently managing transient vertex storage without blocking or being forced to allocate buffers on the fly. This would be a great GL3 focused example.

[PaladinOfKaos]

ooo, goody. Rob's here =)

The standard starting progression in almost every tutorial set I've seen is empty window > triangle > colored triangle, and then they tend to diverge to differing effects depending on the tutorial set. I figure those three tutorials are must-haves. After that, it's (like so much in this project right now) up for debate.

[Stephen A]

Regarding the math header, one problem is that stack-based objects cannot be returned by functions. This means that returning a value through a parameter:



GLMvec2f in(0, 0), out;
foo(&amp;in, &amp;out);

can be quite a bit faster than using a return value:



GLMvec2f in(0, 0), *out;
out = foo(&amp;in);
free(out); // since the object is malloced.

On a different note, using structs can be conceptually cleaner than arrays, especially if they provide accessors, i.e. out.X, out.Y.

Regarding docbook: that would be great, indeed! I've been looking for a way to generate OpenGL docs for OpenTK/Tao for a long time - if I may ask, Mike how do you generate the PyOpenGL docs?

Edit:
GLFW is a C++ library, so I think we should prefer GLUT over it, if possible.
GLFW is a C library, not C++. It has excellent documentation, is extremely intuitive (unlike, ugh, GLUT), plus it has one of the cleanest code-bases I have ever seen.

[HenriH]

I think we should strive to get the first SDK release to be quite something simple and minimal. We could write tutorials for the basic OpenGL use, for example, how to use VBOs and FBOs, and go from here to more advanced stuff in future SDK releases. The goal is to get something working, up and running in relative short period of time (some months).

Also, we should strive to reuse existing GL libraries as much as possible, but nonetheless strive to include only native OpenGL libraries that are in plain C. GLUT would be good candidate, while SDL not because it does not have "the look and feel" of OpenGL and contains much stuff we don't perhaps need.

[PaladinOfKaos]

Despite it being uglier, I think pointers with the "void glmVecAdd2f(GLMvec2f out, const GLMvec2f v1, const GLMvec2f v2)" is the better solution. That way, we can pass the computed vectors directly to OpenGL without worrying about struct alignment issues (every compiler on the market now probably would pack the structs fine, but I'd rather be safe than confuse a poor newbie using a weird compiler)


EDIT:
Upon closer inspection, GLFW is, in fact, C. I looked in the FAQ for language stuff and read the beginning of the "Why another toolkit" section, and had one of those "I hate my language" moments on the last sentence of the first paragraph there. Negatives are always weird in english when combined with conjuntions.

[HenriH]

So okay. Should we for this approach number 1:



typedef GLfloat GLMvec2f[2];
typedef GLfloat GLMmat4f[16];

void glmVecSet2f(GLMvec2f out, GLfloat x, GLfloat y);
void glmVecAdd2f(GLMvec2f out, const GLMve2f v1, const GLMvec2f v2);

GLMvec2f a, b, c;
glmVecSet2f(a, 1.0f, 1.0f);
glmVecSet2f(b, 2.0f, 2.0f);
glmVecAdd2f(c, a, b);

GLMmat4f mat;
glmMatIdentity4f(mat);
glLoadMatrixf(mat);


Or the approac number 2:



typedef struct { GLfloat x, y; } GLMvec2f;
typedef struct { GLfloat m[16]; } GLMmat4f;

GLMvec2f *glmVecSet2f(GLMvec2f *out, GLfloat x, GLfloat y);
GLMvec2f *glmVecAdd2f(GLMvec2f *out, const GLMve2f *v1, const GLMvec2f *v2);

GLMvec2f a, b, c;
glmVecAdd2f(&amp;c, glmVecSet2f(&amp;a, 1.0f, 1.0f), glmVecSet2f(&amp;b, 2.0f, 2.0f);

a.x = 1.0f;
a.y = 2.0f;

GLMmat4f mat;
glmMatIdentity4f(&amp;mat);
glLoadMatrixf(mat.m);


As a sidenote, they used approach number 2 in DirectX mathlib.

There are pros and cons. The struct approac allows functions to be chained, but array approach allows data to be passed for OpenGL functions directly.

Edit: The use of structs may also be more streamlined if we are going to make other libraries as well (which may need complex data structures as structs).

Edit: My personal choice would be the struct way.

[Stephen A]

Pack alignment is probably a non-issue (plus, most compilers provide extensions to control it, if necessary). On the other hand, structs have the advantage of being cleaner in normal use:


vector.X = -vector.Y;
vs
vector[0] = -vector[1];

The latter actually looks like an array of vectors, not the 1st and 2nd element of a vector!

Besides, you can always use the union trick to alias X, Y to [0], [1] in a struct - but you cannot do this the other way round in an array.

[PaladinOfKaos]

Structs are probably best. And as long as we can keep them tightly packed, we can just use a cast to pass a struct as an OpenGL vector.

[Stephen A]

And another possible approach (to avoid the cast):


typedef struct GLMvec2f_t
{
union
{
GLfloat Data[2];
GLfloat X, Y;
};
} GLMvec2f;

GLMvec2f vector;

glUniform2fv(location, 1, vector.Data);


Edit: We should also avoid anonymous structs, as these might cause name collisions in large projects...

[HenriH]

This is a good idea, althought I would use lowercase letter naming convention.

[PaladinOfKaos]

Stephen: We're not going to be using immediate mode (its deprecated), so a cast wouldn't happen very often. Either option should work fine.

[Stephen A]

This is a good idea, althought I would use lowercase letter naming convention.
Ah, slip of the finger (been coding too much C# at work) ;)


Stephen: We're not going to be using immediate mode (its deprecated), so a cast wouldn't happen very often. Either option should work fine.
Of course, glVertex was only an example. Updated the example to use uniforms.

[HenriH]

Should we then decide to use unions for matrices as well? And should we use which memory layout for them? Column-major or row-major?

I have updated the glmath.h to reflect what we have discussed.

[Mike C. Fletcher]

DocBook to HTML was originally done with a huge pre-processing step that turned the DocBook into one big DocBook book and then used the DocBook-XSL transformation to turn it into XHTML pages. That worked, and had lots of formatting and other options (nice looking output). It took > 2hrs for each production run, however, so I wound up letting it get out of date.

I'm just finishing up reworking that to use straight lxml.etree in Python to load the individual pages and dump them. Code for the transformation is here:

https://code.launchpad.net/~mcfletch/pyopengl/directdocs

That can produce the docs in 30s or so, so fast enough that you can play with the format.

You could strip 90% of the code, as it's doing Python introspection to annotate the docs, the basic transformation of docbook-to-xhtml is done in the .kid template (it's pretty trivial).

Beyond that it's just a few xpath queries to find the various elements and use those to create cross-references and the like. The code is a bit rough (was really just intended for internal use), but it should get you started... assuming we get 3.x docbook some time :) .

[PaladinOfKaos]

Should we then decide to use unions for matrices as well? And should we use which memory layout for them? Column-major or row-major?

I have updated the glmath.h to reflect what we have discussed.


Whichever layout OpenGL uses, so we can just pass the matrices to the GL as uniforms.

EDIT: Just looked at the spec, it's column-major.

[HenriH]

We have been discussing the license terms with Paladin and how come up with a conclusion that zlib may be the best choice. Does anyone have recomendations?

Edit: What kind of build system should we use?

[Stephen A]

Thanks, Mike. I'm skimming through the code - this helps a lot!

The final plan for the C# bindings is to provide inline documentation to OpenGL functions (just hover the mouse over the function and see what it does). Still a long way off, but who says you can't dream? :)

Another thing we should discuss is which compilers are we going to support. Obviously, we'll need to support MSVC, GCC, [the one Apple is using] in both x86 and x86_64 configurations. It would also be nice to support MingW and Intel's compiler, but what about more obscure ones like Digital Mars and Borland C and MingW x64?

Edit: Another good choice would be the MIT/X11 license, which is supposed to be compatible with just about everything (including closed-source, BSD and GPL licenses).

Regarding the build system... that's a big can of worms.

Is it reasonable to expect users to install extra software just for building? If yes, CMake (http://www.cmake.org/) is the cleanest system I've ever used.

If not, maybe we should go with native options (e.g. MSBuild for Windows, make/autoconf for Linux and XCode for MacOS) - but how the heck do you keep these in sync?

[PaladinOfKaos]

If it runs in GCC x86 and x86_64, it should run in mingw. There's very little difference (Aside from things like the side of long on 64-bit).

Apple uses a custom version of GCC 4.X (4.1, I think).

As for buildystem, I'm a fan of cmake. It can generate project files for quite a few IDEs, as well as makefiles for GNU make and nmake. We can pre-generate those project files for packaged distributions, and only keep the cmake files in SVN.

[Stephen A]

If it runs in GCC x86 and x86_64, it should run in mingw. There's very little difference (Aside from things like the side of long on 64-bit).
Problem is that should is a long way from does :) (compilers have bugs, too). We'll need to test anyway, especially optimized builds.


Apple uses a custom version of GCC 4.X (4.1, I think).
Thanks, didn't know that.


As for buildystem, I'm a fan of cmake. It can generate project files for quite a few IDEs. We can pre-generate those project files for packaged distributions, and only keep the cmake files in SVN.
This sounds ideal!

[k_szczech]

Why such choice for math library? Do you want it to be cross-language?


The math library draft looks nice for me as it is intuitive and recall the Opengl style.
Honestly, I'd prefer GLSL style for math.


I think we should strive to get the first SDK release to be quite something simple and minimal. We could write tutorials for the basic OpenGL use, for example, how to use VBOs and FBOs, and go from here to more advanced stuff in future SDK releases.
I was about to say the same. Put too much weight to the project and you'll never get it off the ground and ARB will be laughing that we promised so much and delivered nothing (no offense) ;)
Keep your heads cool guys.

[PaladinOfKaos]

Cmake is at www.cmake.org (http://www.cmake.org), so anyone who hasn't used it can review it.

What about integrating the helper libraries? Should we dynmically link? statically link? just include the source file in the list of files for each tutorial?

[HenriH]

I am not a build system expert so I will leave this up to you. I have began implementing the math library and it is looking nice. I have not used CMake, so I will leave writing mathlib makefiles for you. We also need to decide on the license. I am fine with any open source license.

Also, should we officially call this library 'glmath' or just 'glm' to keep up with the convention to name GL libraries with letter combinations?

[HenriH]

Why such choice for math library? Do you want it to be cross-language?

We want to implement something minimal and stay faithful to the OpenGL look and feel. C is a good choice for the implementation language as OpenGL spec is written for C. We may also later implement cross-language wrappers too, yes.

[PaladinOfKaos]

k_szczech: GLSL style would be fine if we were in C++. We're sticking to C for the SDK, since that's the language that the GL targets natively.

EDIT: Henri beat me to the punch

[k_szczech]

Using C++ library does not enforce C++ style programming in samples - you only need .cpp file extension and C++ compiler.

But of course if cross-language is the ultimate goal, then I understand this form of library and there's no further need to convince me ;)

It's just that as a C++ programmer I'd never go back from my current GLSL syntax to calling a function just to initialize a vector.
My point is, that trying to write a library for everyone may end up in writting library just for C/Lua/Python developers, while C++/C#/Java developers will start looking for something more convenient. If you take other languages than C/C++/C#/Java into account, then it makes more sense.

[HenriH]

That is true and you have a point there. Maybe you would be interested of coding a C++ version of the GL math library? If so, we need to discuss about this and make some common decisions for both libs.

At the moment, I have my hands full with the C mathlib.

[PaladinOfKaos]

Since I think the plan is still to do tutorials and most of the example code in C, having support libraries for other languages should be low priority for now, IMHO.

[HenriH]

Agreed; support libraries for other languages are low priorty. However, if he wishes to contribute, allow him.

I have done fairly amount of coding now. You may find the source file for the C mathlib in here (http://nor.fi/~henrih/glmath.c). Implementations for matrix inverses and for some projection matrix generators are still missing.

Edit: As you may see, I have used the GNU coding convention for the source, as this is the convention I like to use. However, when we decide on the general conventions for the SDK, I am willing to conform to that.

[PaladinOfKaos]

I use Emacs, so I can load a custom elisp file to conform to any convention. The GNU convention is pretty well-known, I have no problems with that.

[k_szczech]

I'll upload my code to FTP later and give both of you a link on PM so you may have a look at it. It's not a top-secret code, but I don't like releasing unfinished work to public.

IMHO there are two main goals of SDK - education and providing tools/libraries. So I think it's ok if it would provide both cross-language and C++ only math library.

[HenriH]

I generally agree with you. However, we are low in resources and libraries in other languages are not the top priority ATM.

I propose a general directory structure for the whole SDK, as the following:



GLSDK/ the root directory
examples/
glm/ mathlib examples
doc/
glm/ mathlib docs
inc/
GLSDK/ headers
src/
glm/ mathlib sources


Users of GLSDK would need to point their compiler's search path to GLSDK/inc, so that one could #include <GLSDK/glm.h> for example.

Here is the list of GLM files so far:
http://nor.fi/~henrih/GLSDK/inc/GLSDK/glm.h
http://nor.fi/~henrih/GLSDK/src/glm/glm.c
http://nor.fi/~henrih/GLSDK/examples/glm/vectors.c

[PaladinOfKaos]

Looks good to me. I take it all tutorial code goes in the "examples" directory, maybe in tutorials/tutorial1, tutorials/tutorial2, &c?

[HenriH]

Probably its best to make a separate directory, GLSDK/tutorials.

Edit: or maybe under GLSDK/doc/glm/tutorials, depending what kind of things we are going to make. In generaly, the root of the API reference for each module is at GLSDK/doc/xxx/index.html.

Edit: I consider examples to be source code only, while tutorials are documentation with source code samples scattered around.

[HenriH]

The OpenGL API function glRotate{fd} takes in angles as degrees. Should we conform to this convention in GLM also? I prefer radians. Agreed?

[PaladinOfKaos]

The GLSL trig functions take radians. We should match that.

[Korval]

Well, this thread exploded overnight.

Which is why I suggested that we get a place where we can discuss the SDK on its own. Either a mailing list or another forum or something. Something where each thread of discussion (math module, extension module, etc) can be its own separate thread of discussion.

[Stephen A]

Sourceforge offers mailing lists, too. Maybe it's time to register a project?

[HenriH]

AFAIK, Paladin is registering a project for this?

The mathlib is almost ready (safe from the vigorous bug hunting, optimization and documentation writing). Check it out:

http://nor.fi/~henrih/GLSDK/inc/GLSDK/glm.h
http://nor.fi/~henrih/GLSDK/src/glm/glm.c

Edit: Does anyone have implementation for the glmRotateYPR3f(GLMmat3f *out, GLfloat yaw, GLfloat pitch, GLfloat roll) ready made somewhere?

[PaladinOfKaos]

Yeah, I'm going to register the project. I wanted to wait 24hrs from my original post of intent to make sure everyone with an interest in this around the world would have time to object.

The sourceforge name will be "glsdk", unless that's taken. IIRC, sourceforge lets you change the plain-text descriptive name, so we can set that to something pretty another time.

[HenriH]

Would somebody be interested of writing documentation for GLM (perhaps not just right at this moment, but later)? I think we should write it in DocBook format. I could myself be involved in this too, except that I know next to nothing about DocBook. We should also setup some documentation conventions etc.

[Korval]

Would somebody be interested of writing documentation for GLM (perhaps not just right at this moment, but later)? I think we should write it in DocBook format.

I could, but it would take time. Though it might be better to use Doxygen for source code. I have a version of Doxygen I hacked to export a more... reasonable XML format, which can be converted into pretty much anything, including DocBook.

I would have given it to the Doxygen guys (because their current XML format is terrible), but they no longer support Visual Studio 7.1 as a build platform, so I can't build later version of Doxygen.

[Mike C. Fletcher]

Anyone know if there's a convenient file somewhere that lists each deprecated function in the 3.0 API? I'd like to include warnings (both run-time and in the documentation for PyOpenGL) to let devs know that their code is going to become obsolete with 3.1.

[Korval]

Anyone know if there's a convenient file somewhere that lists each deprecated function in the 3.0 API?

No. Not even the GL 3.0 specification is that specific. The most you get are broad generalizations. Besides, much of the deprecated functionality is based on enums.

Besides, if you want to give runtime warnings, just use the "forward-compatible" context; any deprecated field (enum or function) will return a glError.

[PaladinOfKaos]

Mike: Not yet. I'm working on a list of non-deprecated functions, but organizing the SDK effort has taken priority over that. By the time I get around to it the ARB might have such a list of their own.

All: Before I submit it to sourceforge, I'd like some feedback on my planned proposal. It's here (http://docs.google.com/Doc?id=dpcc729_16chcbxsfg)

[Korval]

I'd like some feedback on my planned proposal.

It's fine for a SourceForge submission. They pretty much accept anything.

[HenriH]

It is fine and good to go.

[HenriH]

I prefer to the use DocBook over Doxygen, like they do in boost project. Documentation can wait, its not the top priority atm. I may also write some documentation into plain text format, which may be later converted to DocBook and integrated as part of the SDK docs.

[PaladinOfKaos]

OK, registration submitted, decision pending. Should be done by next wednesday at the latest, monday at the earliest. (1-3 business days)

[HenriH]

Should we use a unit testing framework for our libraries? Is there any good ones for C?

[ScottManDeath]

Visual C++ has pragmas to deprecate stuff ( http://msdn.microsoft.com/en-us/library/c8xdzzhh(VS.80).aspx ) so one could write/generate a special header file <GL/gl_3_0.h> which would mark all the identifiers which are deprecated in 3.0. Later one could write a <GL/gl_3_1.h> with the newly deprecated stuff.

GCC has similiar ways http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Function-Attributes.html#Function-Attributes

[Stephen A]

Should we use a unit testing framework for our libraries? Is there any good ones for C?
It would be good, especially for the math library.

I've never used any testing framework on C, but here is a fairly comprehensive list such frameworks: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.

[Korval]

The unit testing framework should only be to ensure that the SDK is functional. It should not be something that users have to use, so it can be in whatever language we want.

[Mike C. Fletcher]

Deprecation list: I'm looking at providing the warnings before my devs even have OpenGL 3.x drivers, that is, letting them enable a flag that will report deprecated functions so that they can write OpenGL 2.x + OpenGL 3.x code while still on OpenGL 2.x.

Want to get them (and me ;) ) working on the "fast path" code for all new code (most of them tend to be learners who use fixed-function operations or maybe 1.1 arrays).

Anyway, guess the deprecation stuff can wait on the SDK work.

[PaladinOfKaos]

As soon as someone has a list of deprecated functions, we'll let you know :)

[Mars_999]

Holy crap, I get back from work and there are 70+ posts!

As for Rob's post, yes we should start with simple triangle and work out way up to more complex ideas, using GL3, with the depreciated functions removed, not any old crud, as that code base is all over the net already, if someone wants to code Gl2.1+ examples I guess go ahead add them as a side note...

And I would interested in your idea Rob as a tutorial, I think it would be useful for most people...

[RenderBuffer]

I'd like to point people to Sony's Vector Math library:
http://www.bulletphysics.com/Bullet/phpBB3/viewtopic.php?f=18&t=1322

I've only used the scalar C implementation but there are C++ and SIMD implementations too, and it's already well documented.

[HenriH]

OK. Anyways, the first draft of the GLM math library is now "ready". I am going to next proceed on implementing some sort of test suite for it.

http://nor.fi/~henrih/GLSDK/inc/GLSDK/glm.h
http://nor.fi/~henrih/GLSDK/src/glm/glm.c

I still think this sort of native OpenGL math library is good to have, even thought perhaps not so fast the Sony's SIMD capable library. It is good for beginners and good for the SDK. Perhaps, we can implement SIMD capabilities to it sometime later...

[Rob Barris]

Henri H, I like the lib you posted, short and sweet. Straight C and readable. I don't think "peak SIMD performance" falls within the scope of a focused SDK at this point, if we want it to focus on GL3.

I'd like to jump in with MapBufferRange examples once there is a shell running (hello triangle).

Avoid yak shaving! -> http://sethgodin.typepad.com/seths_blog/2005/03/dont_shave_that.html

[HenriH]

Thanks Rob :) It took me whole day to write it up.

[PaladinOfKaos]

I'm home and back in the #glsdk channel on freenode. Although I don't think there's much I can do until the project on Sourceforge is approved, or until the blasted GLX extension is released so I can work on improving GLFW and/or GLEW to include GL3 support.

[PaladinOfKaos]

OK, it must've been a slow day at sourceforge, the project's been approved already =). I'm going to make a simple HTML homepage and load the glm library into SVN. Once that's done, we can look at starting to get other things into the SDK. Korval just proposed to write a GLEW replacement so we have more direct control over the API (or may just because he wants to). When that's done it will get integrated as well.

[HenriH]

I think it might be beneficial for the SDK if we had an OpenGL mesh file format like DirectX has .X files. We could make a library for loading and rendering these OpenGL mesh objects and a tool-set for exporting GL meshes from Blender 3D, LightWave, Maya, XSI etc.

http://nor.fi/~henrih/OpenGL-Meshlib.txt

Another approach is to use COLLADA files and an API for loading them into memory and rendering with OpenGL.

[bobvodka]

I would avoid that; COLLADA as I understand it is an interchange format, which means it would have pleanty of things lurking in it which aren't needed in a final model and you don't want to get people into the habit of throwing COLLADA files around.

If you are just providing a lib then there is little worry about what to use, I'd just take something well known and easy to decode/load. You could even use .X itself, or the various Quake formats have pleanty of loaders around.

The point is, you don't want to spend too much time worrying about it and writing a COLLADA parser is going to take time (I've seen the source for the tool at work which process our COLLADA files into the various files the engine needs... horrific springs to mind).

[HenriH]

Agreed; COLLADA is huge. There are however some open source libs for parsering them and building a DOM tree out of them. Still, they are intended as intermediate formats.

I would not consider of using .X files or Quake models either a good idea. X-files are more like optimimized for Direct3D rendering and Quake models are optimized for a fps game engine.

I think a simplified "OpenGL mesh" file format could be what this SDK needs at some point in the future. This would be something that supports OpenGL "natively", by containing direct parameter values for OpenGL 3.0 calls. In pratice, the file format would be a very thin layer between the model geometry and the OpenGL API.

This is just a proposal and not on top of our current priorities. I personally don't have OpenGL3 hardware at my disposal at this moment, so somebody else would need to implement this library.

[Korval]

X-files are more like optimimized for Direct3D rendering

So? They'll still function under OpenGL, and an SDK isn't about performance.


I think a simplified "OpenGL mesh" file format could be what this SDK needs at some point in the future.

Absolutely not. The world has enough mesh formats; it doesn't need another.

[HenriH]

The problem with using third party mesh file formats is that they don't necessary integrate well with OpenGL3. For example, lets say you wish to use OpenGL shaders with some models that you have, for example, in LWO file format. This is problematic because the LWO file format does not have correct kind of links into shader files. Can you think of any mesh file format that could contain information about GL shaders, values of uniform variables etc.? We could even integrate this system with the GLFX when and if they get a spec out someday.

The point of doing a GLMesh file format would be that it is supposed to be a thin wrapper around OpenGL3. Files are minimal, require no kind of preprocessing at load-time. They would just be basically dumps of VBO data that will get uploaded into graphics memory by GL calls and a list of primitives that match those of OpenGL too.

I agree that the SDK is not about peformance. But the SDK is about simplicity and cleaniness, and OpenGL mesh would go very well with this line of thought.

Edit: From the API perspective, I am thinking something like this:


// "GLO" stands for "OpenGL Object", GLM namespace is already taken for my mathlib

GLOmesh mesh;

if (!gloLoadMesh (&amp;mesh, "teapot.glo"))
return -1;

GLMmat4f matrix;
glmMatIdentity4f (&amp;matrix);

GLuint groups = gloBeginDraw (&amp;mesh, matrix);
for (GLuint t = 0; t < groups; ++t)
{
gloBeginGroup (&amp;mesh, t);
gloDrawGroup (&amp;mesh, t);
gloEndGroup (&amp;mesh);
}
gloEndDraw (&amp;mesh);

[Korval]

Can you think of any mesh file format that could contain information about GL shaders, values of uniform variables etc.?

No, but that's the user's job. They have to decide how the particular vertex attribute should be used by the shader. We can even impose certain conventions, attribute names that the loader automatically uses which appropriate programs must explicitly key off of.

At no time should the SDK define a mesh format. There are plenty of formats out there; how to use them is something that can be worked out.

If you create a new mesh format, you have to write exporters/cross-converters for every mesh format that people actually use. And if you're doing that, just put the cross-converter in the application code.

Remember: the SDK is not for production work. It's just to get things up and running with a minimum of fuss. If you want to display a mesh, you can. Move it around with matrices, sure. Maybe even some skinning. But it doesn't need to be anything too hardcore.

[Rob Barris]

Hold the chatter about mesh formats til we have a triangle :)

[HenriH]

No, but that's the user's job. They have to decide how the particular vertex attribute should be used by the shader. We can even impose certain conventions, attribute names that the loader automatically uses which appropriate programs must explicitly key off of.

At no time should the SDK define a mesh format. There are plenty of formats out there; how to use them is something that can be worked out.

If you create a new mesh format, you have to write exporters/cross-converters for every mesh format that people actually use. And if you're doing that, just put the cross-converter in the application code.

Remember: the SDK is not for production work. It's just to get things up and running with a minimum of fuss. If you want to display a mesh, you can. Move it around with matrices, sure. Maybe even some skinning. But it doesn't need to be anything too hardcore.

Okay, I certainly do appreciate your feedback and don't want to start an argument on this topic, yet...

My view on the mesh format is that it somehow would contain information of what vertex arrays in the mesh would be bound into what variables in the shader code. This is the idea; mesh files are self-contained packages, that are easy to load and setup using the mesh API and even easier to render. With few function calls and the mesh is there.

And no, we would not have to write cross-translator for different formats. We would just write an exporter for 3D suites we want to support in the SDK. At the beginning we support Blender 3D as it is an open source solution, for others maybe later or never. If somebody wants to cross-translate from GLMesh into format X, he can do it himself (or use Blender as a mediator). Remeber; we don't have to do everything ourselves. This is open source.

And GLMesh files could be very well used in production code if they are good enought.

Rob has a point there. Mesh API is not the top priority at all. So for now, I have nothing more to tell at this moment.

[Korval]

We would just write an exporter for 3D suites we want to support in the SDK.

And therein lies the problem.

Have you ever written a mesh exporter? Because I have. It's not fun. It's not nice. Supporting it takes time. And it only gets worse when you have to deal with what to call each individual attribute. And what if the user is using a tool that isn't one that "we want to support?" Each supported tool is just another layer of added complexity and overhead.

Trust me, it's not a good idea. There's a really good reason why the very complicated Collada format came into existence: to keep people from ever having to write another exporter again.

Consider this: would you consider a "gltexture" file format? Of course not; there are plenty of formats out there with lots of code on how to load them: .dds, .tga, .png, .jpg, .bmp, and so on. Requiring the user to use just our "supported" tools is not a good way to encourage use of the SDK.

[Rob Barris]

For an SDK of basic examples, I figured it would be easier to make some procedural geometry generators.

[PaladinOfKaos]

OK, we now have a SF.net project page and a mailing list, so we can move our discussions there. For the record, here're the current conversation methods:

#glsdk@irc.freenode.net (that's an IRC channel, not an email)

glsdk-devel (at) lists (dot) sourceforge (dot) net. This list is moderated, so you need to subscribe before you can post to it. You can subscribe to the list without getting a full-fledged sourceforge account here (https://lists.sourceforge.net/lists/listinfo/glsdk-devel).

glsdk-users (at) lists (dot) sourceforge (dot) net. This list is for users of the SDK, so it should be empty for a while. It's just here for completeness for now. You can subscribe here (https://lists.sourceforge.net/lists/listinfo/glsdk-users) if you want to.

I'm still waiting for the sourceforge subdomain to propagate through the DNS properly. When it does, the homepage will be http://glsdk.sourceforge.net. Expect that to give a sourceforge error page for another 20 hours or so.

[Mars_999]

I am going to vote for the .obj or .3ds file format. Nvidia actually has a decent .obj lib, maybe they would allow us to use it with the SDK?

Yeah, the math lib is simple and sweet. I was wondering if it was going to be straight C or not, as my Math lib is C++ and uses operator overloading a lot... Which is nice. But KISS is the name of the game here.

Reason I vote for .obj is it can store normals and avoid having to calculate them in the examples, which I hope would keep it simplem, and if the user wanted to learn how we could just reference some material about it or show a quick example on how to...

We should really have a list of top 20 examples to start with, that we want to code up, and maybe we could get some people to take ownership of each example? Or maybe if a few people wanted to help out they could work together?

[PaladinOfKaos]

Once we get the sf.net project all set up, a lot of that sort of planning is going to be moved there. That should be done by the end of the weekend. Once we have that together, we can break tasks down, and make a list of things people can claim.

Myself, HenriH, or Korval will post here when we've got a list of tasks we need help with. Anyone who wants to be involved in the planning can join us on the mailing list and in the IRC channel over the next few days.

[bobvodka]

First, as Rob says meshes a secondary to getting something on the screen, hell most examples can be pulled off with flat polygons or coloured cubes.

Secondly a mesh format shouldn't be about 'do everything for the user' if only because you are trying to teach them the API; having things magically happen in the background doesn't help this as at some point you have to explain it to the user.

A better method would involve just supplying the data and going through the stages of how it all links to shaders; this should be part of the progression plan for the articles/tutorials.

The reason I suggested the Quake formats is because;
- MD2 is popular, pleanty of loaders exist and simple to render without getting into too much heavy shader usage (side note: the SDK shouldn't touch on the FFP; it's dead and gone, introducing shaders from practically day one makes the most sense).
- MD5 is a simple text based format which has a skeleton, normals and the data to perform normal mapping, one of the more popular detail adding techniques, and has skeletal animation support.

These are free formats with pleanty of code and models in the wild which people can use as well as having free tools which can output the format.

[k_szczech]

First things first guys - DO keep that in mind.

For SDK samples we need:
-no meshes at first (first samples)
-procedural geometry (lighting and other examples) - we need procedures to draw a cube, sphere, cylinder
-textured procedural geometry (for examples that do some stuff with textures)

For all basic examples we only need functions to draw them.
For advanced examples we may need functions to create them in form of vertex arrays for later drawing.

That's what I would focus on right now. Complex meshes loaded from file will come later.

[Rob Barris]

I was just thinking a good "chapter 0" introduction to shaders would be a sprite emulator - using uniforms to slide colored/textured quads around on the screen. Very short shader, very short code and it would convey "here is how you can pass values into the GPU per drawn instance".

(yes, you can do this with dynamic geometry too, of course - this would be to illustrate what can be done with no geometry changes)

[HenriH]

Yes I agree with the above posters that meshes come later.

PaladinOfKaos & Korval: Just checking, I posted a message to the glsdk-devel few moments ago but did you get it? I think the mailing list service is supposed to send my own messages back to me, but it did not do so. I have registered the #glsdk IRC channel to the Freenode and setup myself as the channel manager. I am willing to give full access to each member of the devteam, but I need to confirm your account names on Freenode. I am assuming that 'branan' is your account name PaladineOfKaos, but 'korval' is not registered.

[HenriH]

Hello,

I am now fully working on the GLM test suite and I am using CUnit for it. We will need to think on the build system which we will be using. Somebody mentioned CMake? I don't know about this system much or other systems, so I will leave this up to you completely. I wish someone else would take this to his/her responsibility. Choosing and implementing the build system would ease my work as for now I need to manually run the gcc commands from the terminal every time when I need to compile something.

Edit: I will use Makefile locally for now until we setup a build system.

[PaladinOfKaos]

I like CMake because it's what I know. Autotools are... well, they're called "autohell" by many, so you get the idea there.

Even though CMake does have an external executable needed, it's included as one of the "standard" build tools on many modern linux distributions. On Windows we can just build the .vcproj files from CMake and ship those as part of the distribution, and on OS-X, we can build xcode project files before shipping it out (if anyone working on the SDK has OS-X. Otherwise it'll be "unsupported, but you can build it with CMake" until we get an OS-X guy.)

[Rob Barris]

Won't be much participation on OS X platform for writing GL3 samples until there's an OS X GL3 driver. (That said I don't mind rebooting mine into Windows to use the NV beta driver as a vehicle for working on this).

[ScottManDeath]

Any idea when this will happen?

[CrazyBillyO]

and on OS-X, we can build xcode project files before shipping it out (if anyone working on the SDK has OS-X. Otherwise it'll be "unsupported, but you can build it with CMake" until we get an OS-X guy.)

I wouldn't mind helping out on the OS X side when the time comes, though my Xcode experience is limited.

[PaladinOfKaos]

CrasyBillyO: no Xcode experience should be necessary. Hopefully it will just be a matter of running "cmake -G xcode ../ ; cd ../ ; ./build_osx_package.sh" or something like that. But that's quite a ways off right now.

[bootstrap]

For SDK samples we need:
-no meshes at first (first samples)
-procedural geometry (lighting and other examples) - we need procedures to draw a cube, sphere, cylinder
-textured procedural geometry (for examples that do some stuff with textures)

For all basic examples we only need functions to draw them.
For advanced examples we may need functions to create them in form of vertex arrays for later drawing.

That's what I would focus on right now. Complex meshes loaded from file will come later.Well, my engine focuses on procedural object/sounds/texture/etc generation, but then again, my engine has never had anything but VBOs and shaders. So I'm not sure I get the drift of this. Does this mean my functions (or modified versions) are not what you want?

[Leadwerks]

I'd be willing to provide some simple image -> DDS conversion apps if that would be helpful.

I suggest including some C or C++ DDS loader code.

[HenriH]

That may very well become useful at some point, but however our SDK development is still in a very early phase and now is not yet the time for DDS. At the moment, I am working hard for the GLM (mathlib) implementation and the test suites for it, and PaladinOfKaos is working on a shapelib for drawing basic geometrical objects. You are welcome to join our mailing lists (http://sourceforge.net/projects/glsdk) and participate on the discussion.

[Mars_999]

I see PaladinOfkaos beat me to it, I was going to make up some drawing functions e.g. cylinder, cube, torus, maybe a teapot... and throw that in the SDK.... But guess that is taken care of.

[PaladinOfKaos]

You can do the teapot if you want. I wasn't going to do that one.

[k_szczech]

Just render the teapot in feedback mode and generate .c file with const arrays.

Later we will probably need some other stuff like terrains and trees. I can provide a converter from Terragen v1.0 heightmap to greyscale image or our own geometry format once we choose them.
But we will worry about that later :)

[v8671]

I have registered just today , and i ahve been an opengl coder since 6 years, in all this time i have written tons of opengl code, i would like to partecipate in your sdk development
actually i could help in this areas

math library both basic and advanced
texture handling / loading
mesh handling / loading / optimizing
and other stuff if it is requested.

[k_szczech]

As for basic math library I think we should just leave coding to HenriH, but we gonna need documentation for it - regardless of format we choose, someone must write descriptions for every function in the library (I assume that would be HenriH, unless he wants to move on with other things).

As for advanced math library there's still some coding to do. It would certailny use some good unit testing. The only problem is, that such unit tests should be generated, because swizzling boosts number of operators/functions to test.
So basically I need a tool that gnerates unit-testing code that tests all operators and functions in all combinations of swizzling except for those not allowed (so we do test a.xyz = b.xxy, but we don't test a.xxy = b.xyz).
If you're interested, then I could focus on finishing GLSL-style math library ASAP, and give you it's complete source code.

Textures - as for "official" image file formats for SDK I'd vote for PNG+DDS+JPG. I myself use FreeImage library which is simply awesome.

Meshes - that's for later. Optimizations are not required for SDK. Optimizing meshes would rather fit into advanced tutorials.

[greg2]

Hi,

i am waiting for an OpenGL SDK for a long time.
Before nothing was done before, and before i need D3DX-like helper functions for my futur projects, i have started to write a D3DX-like library for my own project in BSD style license:
http://texel3d.free.fr/projets/glgx/index.html
Maybe it could help to create your "Official non official SDK". It is not well writted because i am not an expert. But you can use/copy its source code for what ever you want.

I think an image loader module for the OpenGL SDK should be independant of external libraries in order to be easily ported to different compilers/OS. In GLGX i have created GLGXImage which is an intermediate between GLGXTexture and the image loader (DevIL, or Win32 API, or ...). So the external image loader can be easily changed.

The extension loader should also not be an external library. For the same reason.

Image loader, math lib, shader loader, ... should be in different libraries to make it more flexible (if someone just want to use the shader loader, or just want to use the image loader).

The OpenGL SDK example should not depend on SDL, GLUT or anything else. Functions pointers should be used in main.cpp to give to the the specific SDL/Win32/... api the Draw/FrameMove/... functions.
I have done something like that in my Anim8or file viewer. But maybe i am wrong.

I have also made an Anim8or .an8 files loader libraries:
http://texel3d.free.fr/projets/liban8/index.html
I think the Anim8or file format is simple and logical.
Maybe it can help.

An OpenGL SDK for Java and C# (openTK) would also be a good thing.

[k_szczech]

The OpenGL SDK example should not depend on SDL, GLUT or anything else
They must depend on something eventually. And it's better to depend on portable library like GLUT/GLFW than native API like Windows API :)
Other choice would be to make our own platform abstraction layer, but then it would be up to us to maintain all it's implementations.

Keep in mind that it doesn't have to be our goal to provide examples that are portable to every possible platform.
Someone that wants to use OpenGL on "exotic" platform X can still learn it on "popular" platform Y. Hell, even different programming language shouldn't be a problem.
If he's working on some exotic platform then he's probably used th lack of support anyway.

[HenriH]

Thanks for your interest in GLSDK!

Mathlib is coming well and I am writing test suites for it. This will take some time as matrix tests are tedious to write. I am also willing and interested of writing the API reference for it, but somebody else needs to convert it into DocBook, or at least instruct me how to do it :) (and maybe do a proof reading as English not being my native language). Also tutorials, sample code and a short programming guide is a good idea.

When I get the mathlib done and working on a relative stable level, we will probably release a sort of alpha of it for you to test upon and experiment.

I am also very interested of contributing to GLSDK beyond the mathlib. I could write an .obj loader for the shapelib. The problem is just that I don't have a GL3-able hardware at the moment, nor the extra money to invest into a new computer (I would have to buy a new motherboard and stuff).

As for the 'advanced' mathlib... What do you mean by this? I think we could at some point do a C++ wrapper around the C mathlib but we need to discuss the style about this. I recommend you to join our glsdk-devel (at) lists.sourceforge.net mailing list. At this very moment, we don't have actually any need for an advanced library, but by all means if you feel like it, you may implement it on your own and send it to us. We may need to do some modifications and tweaks for it, but we will give you a full credit for it. :)

For other issues:
- Terragen: This is not needed ATM and is beyond our scope.
- GLFW/GLUT replacement: We could implement our own native system abstraction layer, but this would take sometime as it would be a huge project to do. IMO, I would like our SDK to have minimal amount of external dependencies as possible, so implementing our own windowing library makes sense and I agree on the above poster.
- Image IO: The same. We could perhaps implement our own library that would only depend on the low-level image format libs such as libpng and libjpeg. Great deals of time is needed and our resources are limited.

If you are willing to contribute, please feel free to do so, as long as you understand that we have hands full and don't necessary have time to respond to your requests immediatly. Also, we may need to do tweaking for your libs to fit into our general style...

For the initial release of SDK that will hopefully come at some happy day, we intend to have stuff for the basic workings of OpenGL (how to draw basic stuff and basic shaders). Advanced stuff such as the mentioned terragen will come at some later point...

Edit: If someone is willing to contribute and would like to write test suites for my mathlib, please let me know. Currently 3x3 and 4x4 matrices are lacking test cases. Contact me first, either by a forum PM, or IRC (henux, #glsdk @ Freenode), or by the mailing lists.

[HenriH]

I see PaladinOfkaos beat me to it, I was going to make up some drawing functions e.g. cylinder, cube, torus, maybe a teapot... and throw that in the SDK.... But guess that is taken care of.

You may also discuss with Branan (PaladineOfKaos) if he wants to take a look at your code and use some of it.

[Korval]

I think an image loader module for the OpenGL SDK should be independant of external libraries in order to be easily ported to different compilers/OS.

It would make more sense to me to simply ship those "external" libraries as part of the whole SDK. I don't think any of us should have to rewrite libpng or whatever just because we don't want to use their already platform-neutral code. It would simply make the SDK take longer for little gain. If FreeImage saves us a months of coding image loading routines, I think we can deal with properly adding it to our build system.


An OpenGL SDK for Java and C# (openTK) would also be a good thing.

It might be interesting to port the appropriate SDK features to those languages. But we've already got our hands full with just getting the SDK up and running. Let's hold off on such things until we have a functioning codebase.

[PaladinOfKaos]

libpng, libjpg, and several others are small, 1-2 source file libraries with very liberal licenses. We can easily bundle them with the SDK

[Korval]

Oh, and Henri, as for documentation, once you feel the API is pretty much set, let me know and I'll add those functions/structs/etc to the documentation framework.

[Mars_999]

We are going to need a file format with alpha channel for sure. I vote for .tga or .png. The only thing is with .png my PS7 copy doesn't like them... With .tga we wouldn't even need a library for it, as we could just use uncompressed images...

[Leadwerks]

Why are you messing around with all these lame image formats, when DDS does everything, takes less memory, and loads much faster?

[Stephen A]

An OpenGL SDK for Java and C# (openTK) would also be a good thing.

It might be interesting to port the appropriate SDK features to those languages. But we've already got our hands full with just getting the SDK up and running. Let's hold off on such things until we have a functioning codebase.
OpenTK already comes with its own windowing library, input, extension loading, mathlib, fonts etc, so it's just a matter of rewriting the samples in C# (which I'll probably do when the time is right).

Java and Python have similar projects, so that part of the sdk is (or will be) covered.


With .tga we wouldn't even need a library for it, as we could just use uncompressed images...
Please, no uncompressed images in the sdk. If we need a format, my vote goes to DDS (and if we target GL3.0, we don't even need to decompress that).

[PaladinOfKaos]

DDS is a good target, since it's small and already has mipmaps.

[Korval]

Why are you messing around with all these lame image formats, when DDS does everything, takes less memory, and loads much faster?

DDS is a good format to have. But if you're making a texture in MS Paint, you're saving it in .bmp format. If you're making something in PaintShopPro or Paint.NET or GIMP, you'll be saving it as a .png or a .tga. And so on.

We don't want to force the user to use a specific image format. It's best to work with what the user wants to work with, where reasonable. Remember, we're targeting the neophyte graphics programmer here; they don't care (yet) about storing mipmaps and so forth in their images. They just want to see this image applied to that surface.

[Seth Hoffert]

There's also ImageMagick, which is a great library for loading many formats of images, and it has a great C++ API (as well as C). However, this may be going beyond the scope of the SDK. Just a suggestion.

[ScottManDeath]

Devil seems to be back to life after 2 years of exile.

http://openil.sourceforge.net/

[PaladinOfKaos]

DevIL is, as I recall, rather convoluted if you just want to use it for image loading.

Regardless, if this conversation is going to continue, let's move it to the mailing list. If all the decisions are made there, then we have one place to look when we want to know what the f**k we were thinking later on :P

[v8671]

This is all the code i have written so far.
It is intended for gaming, since i am writing my engine.
So everything is written for speed rather than educational purpouse.
If you are interested in including in the opengl sdk, drop me a
line at mjwpan@tin.it
Sorry for my english being not my native language.

Utility library
string wrapper for easyer retrieving of path , filename, file extension descriptions.
Timers , exception handling, logging.

Math library
Vector 2-3-4 dimensions.
quaternions,
3d intersections / inclusion
Matrix 3x3 4x4.
fast conversion beetween numeric format
fast assembly functions for computing sin,cos, sqrt.

Array
Stl-like dynamic arrays for storing vertex, normals, texcoord, colors , just wrappers for pointers, everything is managed , you have only to add a new vertex , with colors and normals attributes, texture coords are separated from the vertex itself, because i have found many models with an unbalanced ratio of vertex and texture coords.
SurfaceList , and stl-like dynamic array for storing surface
description, you add the vertex indices which describe the surface, the library computes, normal, binormals, area, volume, and rejects degenerated triangle
Mesh , a class using the above arrays for storing a mesh description.
TextureManager, a database, which handles everything about textures, loads jpg, png , pcx, bmp, raw , tga , handles
allocation,binding and manages pointer associated with a texture list.
The texturelist is an stl pointer, which manages texture reference beetween meshes, you can have multiple references to a texture, for example different meshes use the same texture.
Both texture list and texture manager disallow duplicates.
the texturelist is part of the mesh class
Optimizer , computes, triangle adjacency( sp??) , normals computation, vertex adjacency, striping, allows vertex duplication if number of vertices are different from number of texcoord, remove duplicated vertice, remove unreferenced vertices , finds isolated components in a mesh.

[Mars_999]

Sure we can use .dds as it supports everything. But what about Mac or Linux users? Do they have any tools that can load/save to .dds files? I don't know I don't use Linux...

Is there a lib out there already that does all the .dds support formats? Mipmapping, texture compression, cubemaps, texture arrays, 3DTextures... and the list goes on. Or are you just talking about a simple 2D Texture .dds loader?

[PaladinOfKaos]

Anyone that can use the GIMP can get the DDS Loader plugin for that, so the covers all platforms. I believe ImageMagic also handles DDS files, at least 2D ones, maybe with mipmaps.

[Rick Yorgason]

Please, no uncompressed images in the sdk.
Nobody is forcing you to use uncompressed images. But the fact is, when you're teaching a user how to load an image, using a BMP is the most direct way to do that without muddying the article with off-topic information.

[Stephen A]

Nobody is forcing you to use uncompressed images. But the fact is, when you're teaching a user how to load an image, using a BMP is the most direct way to do that without muddying the article with off-topic information.
I disagree.

a) Noone in their sane minds should use uncompressed images. SDK samples should be in touch with the real world.
b) A single 1024x1024 BGRA bmp is 4MB.
c) The examples should focus on how to use textures, not how to load images.
d) Writing a BMP loader is more complicated than using DDS textures directly.

[Mars_999]

We can put compressed images in later, as a more advanced tutorial... We should have both. No reason not to.

[PaladinOfKaos]

Children, behave. =P

There are valid points on both sides. I say we include support for loading various image types, but ship most of the SDK images as DDS files. We can include 1 or 2 images of other types just to show we can load them.


Also, the website is now (sort of) live! Check out http://glsdk.sourceforge.net

At some point a CMS needs to be decided upon and set up, but for now simple HTML pages will suffice.

[Leadwerks]

Well, you can get my Image > DDS and Image > normal map DDS converters here. They don't use any external libraries and are very small:
http://www.leadwerks.com/ccount/click.php?id=51

I can rename the app "OpenGL DDS Maker" or whatever, if you like.

[Groovounet]

So great!!! Something I want to participate too!

For HenriH who is working on a math lib, I suggest you to have a look on mine, http://glm.g-truc.net. I guest you can find some good idea from it.

The basic idea is to create a C++ math library based on GLSL specifications and extend with more features. I'm currently working on a version based on GLSL 1.30 specification.

[Rick Yorgason]

a) Noone in their sane minds should use uncompressed images. SDK samples should be in touch with the real world.
b) A single 1024x1024 BGRA bmp is 4MB.
c) The examples should focus on how to use textures, not how to load images.
d) Writing a BMP loader is more complicated than using DDS textures directly.
The point is, you've just changed an article from "This is how you use textures" to "This is how you use textures; we're using a format you've never heard of, and here's why it's a good format to use, and here's a list of software you can use to make these textures."

Including support for both not only makes sense, but there's good pedantic reasons to use them in some of the articles (mind: not all the articles, and not most of the examples).

[HenriH]

IMO, we should not support BMP. BMPs are nasty things. PNG and JPEG are better. DDS is probably good too.

Groovounet: Thanks for your suggestions. I see that we have chosen unknowingly the same name for our mathlib as you have, GLM.

At the moment, we are not working on C++ code. We intend to use plain C for our libraries. The reason for this is that we want simplicity and streamlineness. OpenGL specification is written for C, so C is the one we will use too. Also we feel at this moment that complexities of C++ is unnecessary for our needs.

At some later point we may want to use C++ wrappers around our libs and other language support too. We have had plenty of suggestions for the C++ mathlib. At the moment, however, we are not looking for C++ libs nor working on them. Our hands are full of things to do, our time and resources very limited. We also want to keep things under control, concentrate on the obvious things and avoid feature bloats.

Thanks for your support and interest :)

[PaladinOfKaos]

There are good points on both sides, as I said. Now can everyone place take a break for a minute? Image formats don't matter until we have examples that need to load images. And we won't have those until we have context initialization together.

[HenriH]

Yes indeed. I think we are heading too far ahead. The project has been working only for few days now. Images come in time, so does the C++ mathlib.

[Groovounet]

Making sens to me and actually I don't really think that a C++ library for a kind of official OpenGL math library. In other hand I'm not sure I would enjoy to work with a C library for my own projects... Anyway this SDK think is great, I have regiser to the mailing this to follow this :)

[PaladinOfKaos]

OK everyone, we now have a FAQ up on our website. Please read it. All of you. You can all argue as much as you want, but unless you can convince at least two of myself, Henri, and Korval, it's most likely not going to happen. http://glsdk.sourceforge.net

And right now we're not worrying about the image loading code. So please take your debates about image formats to another thread. I'd like to keep this thread focused on positive discussion about the SDK.

Thank you,
Branan

[dor00]

Well, you can get my Image > DDS and Image > normal map DDS converters here. They don't use any external libraries and are very small:
http://www.leadwerks.com/ccount/click.php?id=51

I can rename the app "OpenGL DDS Maker" or whatever, if you like.

DDS stands for Direct Draw Surface. For proper use in OpenGL you need to flip the 4x4 blocks.

I dont see why DDS should be included in "openglsdk".

[dor00]

OK everyone, we now have a FAQ up on our website. Please read it. All of you. You can all argue as much as you want, but unless you can convince at least two of myself, Henri, and Korval, it's most likely not going to happen. http://glsdk.sourceforge.net

And right now we're not worrying about the image loading code. So please take your debates about image formats to another thread. I'd like to keep this thread focused on positive discussion about the SDK.

Thank you,
Branan

Your "sdk" already failed.

Will not be OpenGL official SDK. Will be "paladin sdk" or "community sdk" and have nothing to do with official SDK.

[HenriH]

Your "sdk" already failed.

Will not be OpenGL official SDK. Will be "paladin sdk" or "community sdk" and have nothing to do with official SDK.


Okay please! That is way out of line. We are working on this SDK and it takes time. Paladin was just a rather frustrated for arguing which he felt was taking place in the forums and the sheer amount of administrative task that fell upon him.

His attempts of trying to control this thread does not help our goal to deliver a good OpenGL SDK but neither does this line of accusations. Open discussion is good and I encourage it, but non-constructive argumentation and flaming from either side always ends up badly.

There is already an official OpenGL SDK which is in fact a wiki solution. What we are trying to do is a community-led OpenGL SDK which hopefully will have much more. If you want an official SDK from Khronos, I suggest you to go for the wiki.

Let's be nice and constructive. People willing to contribute are welcome.

[Xmas]

DDS stands for Direct Draw Surface. For proper use in OpenGL you need to flip the 4x4 blocks.
You don't.

[dor00]

DDS stands for Direct Draw Surface. For proper use in OpenGL you need to flip the 4x4 blocks.
You don't.

No, you have to, as OpenGl and D3D use different texture addressing mode.

[greg2]

i think you should first find what you exactly want to do for this SDK.

If you create an utility library. What will it be used for ?
Will it be used only for the tutorial and example code of the SDK or will it be useable for professional developpement (like D3DX for DirectX).

If you want to create professionnle utility library: the math lib should be optimized (SSE), the image loader should be able to load a lot of file format (jpg,dds,png,bmp,gif,...)

[Xmas]

No, you have to, as OpenGl and D3D use different texture addressing mode.
OpenGL defines the texture origin (0, 0) as the lower left corner. D3D defines the texture origin as the upper left corner. However, OpenGL also uploads texture data from bottom to top.

This means that the first texel in the image buffer, i.e. the one at the lowest memory address, is always in the (0, 0) corner of the texture regardless of whether you're using OpenGL or D3D.

The difference in coordinate systems is only relevant when you render to a texture.

[dor00]

No, you have to, as OpenGl and D3D use different texture addressing mode.
OpenGL defines the texture origin (0, 0) as the lower left corner. D3D defines the texture origin as the upper left corner. However, OpenGL also uploads texture data from bottom to top.

This means that the first texel in the image buffer, i.e. the one at the lowest memory address, is always in the (0, 0) corner of the texture regardless of whether you're using OpenGL or D3D.

The difference in coordinate systems is only relevant when you render to a texture.

No, you wrong, you forget DDS is 4x4 block compressed.

[HenriH]

i think you should first find what you exactly want to do for this SDK.

If you create an utility library. What will it be used for ?
Will it be used only for the tutorial and example code of the SDK or will it be useable for professional developpement (like D3DX for DirectX).

If you want to create professionnle utility library: the math lib should be optimized (SSE), the image loader should be able to load a lot of file format (jpg,dds,png,bmp,gif,...)


Yes. We have been thinking and discussing these things in this forum and in our mailing list also. The main point which we want to achieve with the SDK is to be a centralized location for up-to-date tutorials, documentations, sample code and a set of libraries targeted for OpenGL3 and beyond. We want to lower the level to get started with OpenGL for beginner programmers by describing the core functionality without the need of buying expensive printed manuals or searching through various sites for possible obscure materials. We would like our documentation and libraries to be clean and streamlined. A package which has sort of all of this in one, which is downloadable as an installer in Windows or a native package in a Linux distribution, or a source tarball.

We don't want to restrict our libraries solely for hobby programmers per se. Of course, it would be nice if the tools and utilities we implemented would be so good quality that they would get used in a professional, production level code. But the reality is, as it has been stated earlier, that our resources and time are limited. DirectX SDK has been in development for many years. The D3DX library is stable, optimized, and Microsoft has an army of coders and probably millions of dollars in reserve to spend. The coders of the Silicon Valley are doing it as their jobs, we are doing this in our spare time along with our personal lifes and some of us have even jobs. And not to mention the fact that our efforts are hindered by the lack of GLX specification for creating OpenGL3 contexes. At the moment we have only three active members and the project has been up less than a week and it has already been stated by one as a failure...

As you will probably understand from the comparison, at the moment we strive for simple things. Our goal is to get something done, something simple, but still a release. We wish that our SDK will get support and interest from the user community, once we get something done. We are using open source software methodologies which means that our system evolves dynamically in time. We don't want to set heavily restricted and defined goal other than the one stated above. It would be a fool's job to set a goal to implement professional level, SIMD optimized, top-notch SDK from the very beginning. It would never get done and the goal reached for with this mentality.

Therefore, we begin simple and build up from that, dynamically through natural evolution.

Edit: By active members I mean developers. There also other members who have joined our mailing lists for discussion.

[pudman]

@HenriH

Don't worry too much about the noise in this thread. The valuable opinions will be presented in the glsdk mailing list.

Concentrate more on the SDK than on responded to all concerns in this forum. If something keeps coming up here, add a response to the FAQ. Not everyone here will grasp what will be attempted with the SDK until the first real release so as long as you stay focused there's not too much to worry about.

As for the number of active developers, that number (3) is slightly artificial. The three of you simply have *tasks* assigned to you. There's a bunch of developers waiting in the wings to start doing something. There are, of course, dependencies on what you guys are doing but that shouldn't prevent early versions of the basic tutorials. They can easily be rewritten to use GLFW/GLE/GLM.

Everyone wants to write math and image loaders because those things are "fun" in some sense and most people have done those before so they're "easy". However, the more import part of the SDK is the tutorials, documentation, and examples. I'd say if anyone has these items, get them ready (possibly write them!) for possible inclusion!

[PaladinOfKaos]

OK, I've had a good night's sleep, and I'm less grumpy now.

Sorry if I came off as a bit of an [censored] earlier. My main concern was that this thread would be the first place people hear about the SDK, and it would just be people arguing. Of course, in hindsight being a jerk about it won't make a good impression either.

[HenriH]

Thanks for the constructive post that you replied to me.

There has not been much discussion on the mailing list yet of the actual tutorials or examples, other than that they should deal with basics of OpenGL3 for the initial release of the SDK. Our efforts so far have focused on implementing the framework, and for a reason; without them there is not much to be done.

The lacking of OpenGL GLX specification has also an indirect hidden consequence; GLFW/GLUT guys won't be implementing support for GL3 until there is GLX. Thus, someone who would be writing a GL3 tutorial would have to write some sort of WGL-dependent temporary context creation wrapper, which will eventually be replaced by GLFW/GLUT. Nobody wants to do this. GL3 hardware support is still very immature and writing down the actual code for the tutorials may be premature at this point yet. We are also a bit undecided what kind of tutorials and what is the structure and layout we will be having. This is a topic we will need to discuss in the mailing list.

So our hands are bit tied. There are guys who would like to contribute by writing tutorials. Rob Barris has shown his initial enthusiasm for our project and we are glad to have him. So it ends up to us Three who are working to get the baselibs working.

[pudman]

GL3 hardware support is still very immature and writing down the actual code for the tutorials may be premature at this point yet.

Yes and no. Tutorials can be written against 2.1 without fixed-function usage, to a degree. It at least builds some momentum towards the real 3.0 tutorials. Refactoring code from 2.1 to 3.0, especially the basic tutorials, will not be that difficult of an effort.

I'm not saying the tutorials should be written right now. We still need to wait until at least the topics are chosen. But there's no technical reason why they *can't* be created right now. Call them "alpha" versions that may or may not be 3.0 compliant. The documentation for creating a triangle using 3.0 conventions will be the essentially the same as the 2.1 version (using the same conventions).

[Korval]

GL3 hardware support is still very immature and writing down the actual code for the tutorials may be premature at this point yet.

The key here is to pretend that certain parts of OpenGL don't exist so that:

1: You don't confuse neophytes by giving them too many options.
2: You keep them on the fast path.
3: You let them know up front what they need to do to make things work.

So it isn't so much that it requires a 3.0 forward-compatible context that we will simply not accept/rewrite tutorials that use deprecated functionality.

[Rob Barris]

I agree, the first demo should be a single colored triangle using only VBO and shaders.

[v8671]

I would like to be a developer, with whom should i talk to ?

[PaladinOfKaos]

v8671: Please sign up for the mailing list and get the current source from our SVN if you're interested in helping. http://sourceforge.net/projects/glsdk

Branan

[Mars_999]

I agree, the first demo should be a single colored triangle using only VBO and shaders.



Ditto. As this is GL3, and VBO is the new immediate mode of old. That is what you will/should be using day one. And shaders, does anyone really even use FFP anymore! ;) I ditched it as soon as GLSL came out.

I sent my initial run of the teapot and cube images to Branan, and I have the code about ready, so shapes we are in good shape. No PUN intended!

I put in normals, texCoords, tangents for all those nice bump mapping, parallax mapping demos we will be making! ;)

[v8671]

I see two mailing lists here, one devoted to opengl gaming and another for the mac, i joined the first one.
Second, is this sdk going to be a collection of tutorials ?
this sounds a little odd to me.
We are going to make an sdk, something much like a framework to start serious graphics programming, i understand that beginners, and advanced users need to look at examples , but i don't think that this is the main point of discussion.
You may have a nice collection of tutorials just collecting documents which are scattered among the net , and make an 'sdk', is this what we are talking about here ?

[obirsoy]

We are going to make an sdk, something much like a framework to start serious graphics programming, ...

The purpose of the sdk has been discussed in the glsdk forums (http://sourceforge.net/mailarchive/forum.php?forum_name=glsdk-devel) already. I suggest you to post there if you have different things to say...
[Glsdk-devel] The purpose of the GL SDK (http://sourceforge.net/mailarchive/forum.php?thread_name=48B061E7.4080208%40gmail.com&forum_name=glsdk-devel)

[HenriH]

I recommend you to do this:

1. Sign up for Sourceforge.net and create an account there if you already don.t

2. Join our glsdk-devel (at) lists.sourceforge.net mailing list.

3. Checkout the current code base from the SVN repository.

4. BE SURE TO READ THIS OPENGL THREAD FROM THE BEGINNING and the glsdk-devel ARCHIEVE before you post comments or ask questions. We have been discussing the details of the overall SDK and the details of baselibs. Be sure to familiarize what we are actually doing. This is an important part!

5. If you want to be a developer, post into mailing lists what you would like to do. Currently we have three baselibs under development and each has it's own developer. For these libs, we don't necessary want to get a new developer but we may want to get contributions. If you have an idea for a new baselib, post your ideas to us before coding. You may also wish to design tutorials / samples / programming guides. Be patient!

[HenriH]

Also, read our FAQ:
http://glsdk.sourceforge.net/

[Brianj]

The first tutorial could be modeled after this post (http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=244952#Post244952). I find it fairly easy to understand (as someone without knowledge of shaders and doesn't have a strong background in math). It should be trivial for you professional programmers to fill in the blanks and cut out the wxWidget stuff.

[knackered]

I don't understand why you're so bloody mindedly sticking with C. It makes no sense whatsoever. Just saying you're using it because the GL specs don't seem to do anything C++-like is not a good argument. It's not even an argument. It's just as easy to make language bindings between c++ as it is for c.
Just use C++ and make the code simpler to understand. Most newbies will not have used plain C. I haven't met a single graduate in the last 5 years that learned C at all. They will stare blankly at the code wondering how they can mentally connect the objects that have been obfuscated.

(edit) unless of course your target audience is an ex-database programmer in his mid-40's, in which case carry on.

[pudman]

I haven't met a single graduate in the last 5 years that learned C at all. They will stare blankly at the code wondering how they can mentally connect the objects that have been obfuscated.

Sucks to be those graduates. I had the fortune of learning C before I went to college where they started out with C++ (which has since been replaced with Java, who knows maybe C# by now). Give that they all share basically the same syntax, switching between them is relatively painless. Sure you don't have "objects" but everyone's written a function/method that doesn't use object-oriented concepts. (Like a math library!)

I can't speak for ease of creating language bindings, but while OpenGL is straight C there is absolutely no disadvantage to using C for an SDK. It's purely an academic exercise to wrap it in C++. If that's your need (or you need to hold your graduate's hands with C++) then there's nothing preventing you from object-orienting it.

[knackered]

or you need to hold your graduate's hands with C++
and there we have it - the big reveal. Your motives are clear to me now.

[v8671]

This is one of the reason why i dropped this project , all the math is pure c, you need to do horrible things like
addvector( v1 , v2 ) , i understand that you want to align code to the glsl , but , there are tons of guys who already have their math library, where you can easily write v=v1+v2, this is simpler, neat, and easy to read.
Don't say that you can always write a wrapper for this function, since this is a very sloppy solution.
I advice you to switch to c++ , we are in 2008.

[pudman]

or you need to hold your graduate's hands with C++
and there we have it - the big reveal. Your motives are clear to me now.

Huh? I thought I was insulting those who only know C++. I have nothing against C++. My day job has me coding mostly in Java. I just see nothing weird with coding in C.

[pudman]

I advice you to switch to c++ , we are in 2008.

I personally see nothing wrong with including non-C libraries like a C++ math library whose operator overloads make the math more like GLSL. But I also understand the rationale for keeping all the code consistent and GL-like. It is a bit strange to me to stay away from something simply because it's C, when it's mostly just a teaching tool for GL beginners.

[knackered]

Tell me the rationale for writing framework and example code in a GL-like fashion. I still don't get it. The GL specification was written a long time ago, when the C++ standard was still in flux. This SDK is supposed to be modern. Code that essentially sends messages, like the GL API, can get away with being purely functional - but an sdk, whose aim is to demonstrate and teach OpenGL, should concern itself with abstracting away complexities in order to focus on what it wants to teach. You start adding callbacks and 'handles' into the mix and you're just going to confuse the poor little dears.
Just look at the DevIL library to see what happens when you get too carried away trying to do things like OpenGL. Does DevIL need to work with an x server? No. So why that awful interface?

[PaladinOfKaos]

The only really ugly part is the math library, which is no worse than the D3DX math library that Direct3d novices get to learn with (we use the exact same output-argument system they do).

Here's a couple more points on C:

* On Linux, the C++ ABI is still in flux (better than it was, yes, but still in flux). The LSB is fine for programs, but getting a distro set up to build an LSB program is a pain. Because of that, we can't release the SDK as an LSB package. The only way to keep the ABI clean, then, is to use C.

* The object-oriented features of all the different C-derived languages have so many different caveats that it's just as easy, if not easier, to confuse a Java programmer with C++ as with C.

* Some of us just like C.


Please everyone remember that we're not banning C++ (or any other language) from the SDK altogether. Demos and other extras can be in whatever language the author wants. We will most likely include an optimized C++ GLSL-like math library at some point. But right now we're concerned with getting the core libraries in place so we can get the boilerplate code down so that we can get the first tutorials in place. If there ends up being a good enough selection of libraries for a langauge, we may even create a boilerplate code for that language. Please note the "MAY" in that sentence. I can't make any promises about that right now.

[knackered]

you're making work for yourselves - I envisage people bitching at you for how long it's taking to get a decent SDK, 6 months from now. Henri desperately trying to fix bugs in his home grown maths lib, for example (nothing to do with teaching OpenGL).
I particularly find it incredible to see you dismiss the GLM library, simply because you want to stick with C. All we'll end up with is yet another plethora of reinvented wheels.
drop the C obsession and just use the existing (well documented) tools available now:
http://glm.g-truc.net./

[pudman]

Some of us just like C.

That's not a reason I care about. If I had my choice for some new project I'd do C++ or Java.

However, in the interest of simplicity, C is it.


You start adding callbacks and 'handles' into the mix and you're just going to confuse the poor little dears.

Same confusion to beginners applies to "objects", "virtual functions", "overloaded operators" (huh?), and "polymorphism" (poly-what?). It's all relative. Same crack, different pipe.

If I'm going to jump into a new API, I personally can't stand other's frameworks. They're annoying and hide the details I'm interested in. The ideal SDK makes those things easy to discover. C or C++, as long as it's simple, easy, and clean.

[knackered]

They pretty much all get taught about polymorphism these days. They're lost without it, to be honest. That kind of thing only confuses C programmers, and they're the ones likely to *not* be graphics programming novices.

[Rob Barris]

I don't see anything wrong with writing up the first set of examples in C (they won't be very long after all) and potentially adding C++ versions down the road. The focus should be on the API, with just enough glue and support (math lib) to make the examples concise.

That said there is nothing at all preventing an independent group from doing their own examples in pure C++ top to bottom. Staying focused on C is merely the decision made by the gl-sdk project at present. Given that it hasn't drawn anything yet, my personal opinion is that it should stay on the track set at least until some of those early examples are up and running.

[ScottManDeath]

One can use C++ as a better C, so you get niceties such as new/delete, argment passing by reference &, operator overloading for math classes. Escpecially since GLSL has them also. One doesn't have to go DesignPattern right away.

Using the STL containers for storing and manipulating vertex data beats the crap out of your own handrolled dynamic C arrays, hiding data types behind a void* or some macros.

D3DX contains operator overloading for the D3DXVECTOR* and D3DMATRIX classes. Only Cinosaurs can't use them.

http://msdn.microsoft.com/en-us/library/bb205546(VS.85).aspx
http://msdn.microsoft.com/en-us/library/bb172912(VS.85).aspx

[knackered]

Using the STL containers for storing and manipulating vertex data beats the crap out of your own handrolled dynamic C arrays, hiding data types behind a void* or some macros.
yup, exactly. Not using C++ means losing STL, which in turn means reimplementing those containers, which in turn means clogging up the sdk with stuff not related to OpenGL.
But whatever, you've made your decision so stick with it. Pretty much what the ARB has just done - and we're all the poorer for it.
I am looking forward to seeing an old C maths lib again, for nostalgic reasons. Will you be using macros for speed? Great. Macros. What's the point in namespaces anyway? If any user of the sdk already has some symbols with the same names, then that's their fault isn't it?

[Seth Hoffert]

The only really ugly part is the math library, which is no worse than the D3DX math library that Direct3d novices get to learn with

Except D3DX makes use of operator overloading, which makes for more readable code.


We will most likely include an optimized C++ GLSL-like math library at some point.

Ah. Good. :)

[HenriH]

Well what can be said ...

1. Choosing C as the language for the mathlib was also a personal choice; I like C and I feel myself to be a sort of "old-school UNIX hacker".

2. C is (in my opinion) a clean and simple programming language. Especially I like C99.

3. The focus of the SDK in our minds are the tutorials. To explain basics of OpenGL does not require the use of C++ and the focus of the tutorial should not be the programming language used. The fact that no tutorials have not been written is a shame, but maybe you would like to contribute for us? This is an open source community-led project ...

4. OpenGL is written for the C language. GLFW and other OpenGL libraries are C libraries. Making the GLSDK corelibs as C libraries is a natural choice.

5. Nothing prevents you from using C++ libraries in your own projects.

6. Nothing prevents C++ mathlib to be implemented for the GLSDK later.

Edit: 7. We can't please anyone. If we would have chosen C++ for the mathlib, then someone would complained about our use of GLFW which is C etc.

[PaladinOfKaos]

Korval made an excellent post about C vs C++ on our mailing list


Nobody agrees on what is the best style for writing C++. I don't mean irrelevant things like where braces go or naming conventions. I mean complicated things:

- When to use inheritance instead of containment.
- The use of Resource Acquisition Is Initialization.
- The use of exceptions.
- The use of Pimpl.
- How much templating to use.
- How much operator overloading to use.

I have my own ideas about what good C++ style is. I like them, and I have a pretty good defense of them. I even have a rarely-updated Blog about what I consider to be good C++ coding style.

But programmers are a very, VERY picky lot. C++ programmers are pickier than most, because choosing a library that clashes with your preferred coding style is very painful. If you're not using exceptions and RAII, trying to use a library that does can be nightmarish.

The takehome point being this: C isn't nice. It isn't as clean as C++ can be. But it's standard. Everyone knows what good C code looks like. Everyone understands it, even if things like "typedef struct" are confusing to C++ programmers. And it will never hurt you the way that using exceptions when your user doesn't want to will.

[Seth Hoffert]

I suppose this is understandable.

Anyway, I would love to write some geometry shader examples. ;) I am joining the mailing list.

[PaladinOfKaos]

HexCat: Welcome aboard =)

[knackered]

Err, so is korval saying a team should never use c++ because they could never agree on a consistent style? I've used c++ in teams, and honestly, hand on heart, it has never been a problem. The benefits of c++ sweep aside these petty concerns.

[Korval]

so is korval saying a team should never use c++ because they could never agree on a consistent style?

Within a team it's fine; everyone can agree on/is forced to use a particular style and everything is OK. The problem is with a library and people who may want to use it.

Know why Boost, despite all of its coolness and obvious advantages, isn't more widely used among C++ programmers? Here's a hint: it isn't download size. It's the fact that many C++ programmers don't like its style. They don't buy into RAII and exceptions, so the (for example) threading library is a bust for them. Having to create an object to lock a mutex (technically not a requirement) for them is the epitome of bad coding. And so on. Some C++ programmers don't even use the standard library.

Regardless of what C++ style you choose to use, you will automatically alienate some part of the C++ audience. Use RAII, and you alienate the anti-RAII crowd. And vice versa.

The GLSDK exists to get people interested in using OpenGL, as well as teaching them how to do so and providing some basic utilities. It has to be something that people choose to use, rather than are forced to use. Therefore, it must adopt a style that everyone can accept. There is no C++ style that everyone accepts, so we use a C style that everyone does accept.

The last part is this: we don't benefit from C++ that much. The math library is the only thing that would benefit from C++. Everything else is basically function calls. Window/context creation, extension loading, etc. It's all pretty mundane and doesn't lend itself to any of the advantages of C++.

[pudman]

Using the STL containers for storing and manipulating vertex data beats the crap out of your own handrolled dynamic C arrays, hiding data types behind a void* or some macros.

I don't see the GLSDK using even simple data structures. Obviously, if an individual coder found the need for beyond-basic features he can do whatever he wants.

I think people need to understand exactly what the SDK intends to accomplish. It's not an API, like OpenGL. You are not forced to use it. Yes, it will come with some utility libraries, but they are for the purpose of consistency within the tutorials and examples. Again, you don't have to use them.

If you are looking for documentation or examples of feature usage, the SDK should be the ideal place to find them. If you don't want to be bothered to write your own math library or hunt down GLFW setup code, it's all in there too.

[knackered]

Korval, who is this SDK aimed at?
Like you allude to at the end, you're writing mundane services for demonstrating OpenGL, you're not writing something akin to Boost. This is not something that people will use in their own projects (although maybe they'll use the maths lib, if it were C++).
Nobody uses C anymore. Not even on embedded platforms. It's used in maintaining old C applications, and that's it.
I know that most novices will be much more comfortable deriving off a framework 'app' class and overriding some clearly documented methods. They will be more comfortable with operator overloading in the maths lib. They will be more comfortable dealing with an image object.
If this is aimed at novice GL programmers, as well as teaching newer techniques to more experiences ones, then C++ will give you a clearer route.
That's just my opinion, of course. I can just about grasp the reasons you're giving for using C, but I just don't think they're good enough to justify what I envisage being the result of this decision. Make it better than the d3d sdk, but use some of the things that make the d3d sdk popular now.

[CatDog]

Wouldn't managed code be best for example code, especially for novices?

CatDog

[Stephen A]

Wouldn't managed code be best for example code, especially for novices?
Indeed, something in Python, C# or Java would be far more approachable. But try selling *that* to C++ programmers :-)

At least C is a universal standard. Every platform has a C89-compliant compiler, most people can read C code and most high-level languages can interface with C. Heck, a C++ wrapper could be built on top of GLM with no loss of functionality or speed.

[bobvodka]

Frankly, any C++ programmer who is any good will recognise that;
a) C++ ISNT the best language ever made and has faults
b) that other languages are better suited to other tasks, such as teaching

Generally those who will defend C++ to the death are people who are new to the language or are just too blinkered to learn anything else.

Well, I say 'C++ programmers' I mean programmers in general; if you get 'stuck in your ways' you are a bad programmer.

As for the 'C++ programmers' who don't use certain features because "it doesn't match my style", well, they are bad programmers as well. Sound technical reasons for not using something, great, but "I don't like it" just doesn't wash.

I would also put forward the reason why Boost isn't used more is simply because the vast majority of 'C++ programmers' aren't. They use it as a 'C with classes' and avoid modern constructs, including templates, because they are misinformed or simply don't understand them. Even the C++ Standard Library is avoided by people due to this belief that it is 'slow' or 'bloated', which is just bizzare; with every other language going you'll use the standard library without thinking, but for some odd reason people avoid it with C++.

Of course, the unfortunate truth is the world is full of bad programmers, indeed as I once said to a friend; you can teach anyone to program, you can't teach anyone to program well.

[Mars_999]

Good grief is this ANOTHER C or C++ vs. the world flame war in the making?

Please move on, the SDK people decided with C. I would have rather used C++ myself, but whatever. If someone else wants to make a SDK for GL3 then start a new project in C++ and use Boost/STL if you like.

All I know is GL3+ is going to need some new examples, and correct examples to learn from this time around...

[Seth Hoffert]

Yes, let us reinterpret_cast<void *>(this) discussion... ;)

[dor00]

Please move on, the SDK people decided with C.

... and this is how you make me lol irl.

[pudman]

Nobody uses C anymore.

Oh. Oops! I think you should tell the ARB. And Linus, while you're at it. I believe it *might* be more accurate to say that "few use C exclusively for their projects". Anyway, it could be fun! Challenge your habits and conventions! The SDK stands for Super Duper Kfun!

[knackered]

statistically, nobody uses C any more. Rounded to the nearest integer. When I say use, I mean in projects started within the last 5 years. Poor old Linus and the ARB are dealing with code specified going on for decades ago.

[HenriH]

Well I think that's quite utter nonsense really.

C is still widely used especially in the Linux world for good reasons. Object-oriented paradigm is excellent for some things such as GUI programming, but procedural still has its uses. As you may perhaps know, Linux as an operating system has a complete different feel and style than Windows and not everything has to have a GUI.

I think this C vs. C++ flame war shows that people are really missing the point here. The SDK is meant to teach people OpenGL programming foremost. As I see this, C language is fine for our purposes and if we really want to, and like it has been said many times here, we may implement a C++ wrapper on top of GLM. I would even be interested of doing this but at this moment it is simply not needed.

[knackered]

No, I think I'm rather the opposite of missing the point of the SDK in my objection to using C. Using C++ would make clearer what's being taught. If that weren't the case, why have a number of people in this discussion mentioned the possibility of writing C++ wrappers on top? What would be the point in that if C were doing its job? Why are people proposing a wrapper when C will build fine under a C++ compiler?

[bobvodka]

I'm with Knackered on this one and I'd also like to add that over on gamedev.net we try to stear new people away from C++ and towards C# and Python as much as possible for programming learning.

Coupled in with that I can't recall the last time anyone was advised to pick up C or even asked if they should; in the former case with C vs C++ then C++ is adviced, and in the case of those who ask we'll stear them towards the aformentioned languages but point out that if they really want to learn C++ then it's up to them.

---

Just because something doesn't have a GUI doesn't mean that objects suddenly don't apply; the reason objects are used is for ease of modeling both interface and data. Sure, you can do it with C but it's painful when C++ already does it for you (features such as virtual functions for example). I would argue infact that, certainly coming out of the academic world where Java is very much a core language for teaching, the use of objects is considerably more common and more natural.

Not that C++ doesn't let you do 'procedural' programming as well; it is a multi-paradigm language (http://en.wikipedia.org/wiki/C%2B%2B), not just an OO language.

Finally, I would wager that the reason C turns up alot in Linux code is due to;
- legacy
- people not knowing C++ and not wanting to leave the 'comfort zone'
- misinformation that somehow C is 'faster' than C++ or some other equally misguided 'feeling' on the subject.

Still, surely this code is going to be crossplatform so it doesn't matter what linux does..? unless you have an unhealthy linux bias ofcourse which could prove a problem with a cross platform sdk (you do plan on supporting Visual Studio projects for the source code, yes?)

End of the day you are using C because you like it, and if that's your reason then fine, but don't try to hide behind some other dressed up reasoning because alot of it simply isn't valid in the modern programming world.

(for the record I have no C++ bias, while I use it for work and it is the language I consider myself most proficant in I can see it's flaws I have branched out into Lua and C# (and become alot more productive in the later), I'm currently in the process of teaching myself Haskell and I know various other languages to varying degrees.)

[Korval]

If that weren't the case, why have a number of people in this discussion mentioned the possibility of writing C++ wrappers on top?

Because people want them?


Finally, I would wager that the reason C turns up alot in Linux code is due to;

Don't forget the Linux C++ ABI issues that still haven't been worked out.


you do plan on supporting Visual Studio projects for the source code, yes?

We're using CMake, which generates makefiles or VS projects (and other things).


End of the day you are using C because you like it, and if that's your reason then fine, but don't try to hide behind some other dressed up reasoning because alot of it simply isn't valid in the modern programming world.

If you're talking to Henri, you'd be correct. But I have no liking for C, and I stand by my prior commentary on using C++ in the SDK.

[Simon Arbon]

No, I think I'm rather the opposite of missing the point of the SDK in my objection to using C. Using C++ would make clearer what's being taught.
So whats the problem? Let them write a C SDK and then when they have a few lessons done, start a sub-project to do a C++ version as well.
I would be happy to help with a translation for Delphi programmers.
Bobvodka could start a sub-project to do C# and Python translations if he wants to.

Why dont we just let them get on with it so we actually get an SDK.
The hard part is producing the actual tutorials to teach beginners the basics of OpenGL.
Once thats done the code examples can be translated into other languages quite easily, and a different math library substituted that better uses the features of that language.

We should all be encouraging those who are willing to donate their own time to help more people learn OpenGL, and we should be helping them as much as we can, not getting into arguments about which language is best.
OpenGL is used by people who's personal preference in programming language varies wildly, and i would hope that one day we can have an SDK that includes all of them, but for now its important that we concentrate on getting the C language version done and not get distracted by side issues that can be fixed after OpenGL SDK 1.0 is released.

[Rick Yorgason]

Look, I don't like C, but I agree that C is the best choice for the SDK. You're missing something:

I know that most novices will be much more comfortable deriving off a framework 'app' class and overriding some clearly documented methods.
The SDK isn't intended to be used it in production code. After all, in production DirectX code, nobody uses the D3DX math library (which, incidentally, was written to be friendly to C and C++ programmers). The libraries in the OpenGL SDK should eventually make themselves obsolete as each user becomes familiar with OpenGL.

If the SDK asks people to derive from an "app" class, then we can't focus on simply teaching users how to use OpenGL; now we also have to focus on teaching them how to use the SDK's libraries, and that's a waste of time for something which intends to obviate itself.

Also, while C++ is my language of choice, it's not the only language out there. I imagine Python programmers would have an easier time translating a C program than a C++ program. And after all, I have no trouble reading C documentation and reimplementing it with C++ features. I'd even go so far as to say the C code almost reads like pseudo-code; you wouldn't want to write production code with it, but it's perfect for pedantic purposes.

Here's some guidelines:
The SDK should require as little prerequisite knowledge as possible, including knowledge of other parts of the SDK itself. The SDK's libraries should support the SDK's documentation and tutorials, not the other way around. The SDK's documentation should be useful to somebody who has never learned how to use the SDK's libraries, or who has abandoned the SDK's libraries for greener pastures.

[HenriH]

I respect everyone's opinions and I think this kind of open discussion is good and productive.

I don't feel myself to be biased to C over C++ other than that I like C as a personal preference. I know and use different programming languages ranged from dynamically typed languages such as Python, Scheme and Lua, to statically typed languages such as C, C++, Java, C#. The choice of programming paradigm and programming language used should always be project based.

Object orientation is especially good GUI programming where widgets can be modelled as classes and polymorphism can be used. Procedural programming is a good choice when a program is not data centric but rather procedure driven. For software which don't need to have a GUI and are invoked from the command line, procedural programming paradigm is an excellent choice as it is often enought to express data as simple C structs. UNIX command-line tools such as 'tar', 'ls', 'cp' are implemented using C because of history but also because C is enought and porting them to C++ would not offer benefits.

[HenriH]

No, I think I'm rather the opposite of missing the point of the SDK in my objection to using C. Using C++ would make clearer what's being taught. If that weren't the case, why have a number of people in this discussion mentioned the possibility of writing C++ wrappers on top? What would be the point in that if C were doing its job? Why are people proposing a wrapper when C will build fine under a C++ compiler?

There are not that many people requesting for C++ wrapper over the mathlib in this forum at this moment. You and bobvodka.

Perhaps the reason why so many people think C is "outdated" is the fact, like you said, that the so called "academic world" uses Java for teaching programming. Object orientation is used in the Windows world extensively because of the GUI nature of the operating system and Windows has the biggest market share at the moment. Students are tought in the ways of the OO as that is the paradigm they will need to know and use in the commercial software development scene once they graduate.

Edit: Excuse me, it wasn't you who talked about the academic world but bobvodka. My apologies.

[Korval]

For software which don't need to have a GUI and are invoked from the command line, procedural programming paradigm is an excellent choice as it is often enought to express data as simple C structs.

Well, to be fair (and even more off-topic), C++ provides a lot more than polymorphism. But even polymorphism is useful for more than GUIs (and personally, I think polymorphism is overused in GUIs).

Also, there's more to classes than just polymorphism. They provide encapsulation, public vs. private interfaces, the ability to attach code to data, constructors/destructors that the language guarantees will be called, and so forth. There is exception handling in C++, which allows for a category of error messages that C can't handle. You can't have RAII and therefore guaranteed resource management in C. I can keep going, but I think my point is clear.

And that doesn't deal with how much more useful and comprehensive the C++ standard library is compared to the C standard library. Nor does it deal with the sheer awesomeness of what C++ can do as exemplified by Boost (smart pointers, Boost.Spirit-based parsing, Boost.Bind, Boost.Any, Boost.Lambda, etc).

You're misrepresenting C++ by simply thinking of it as "C with classes" (a common misconception). I still don't think C++ is appropriate for the SDK, but I just wanted to correct your misrepresentations.

[HenriH]

Just because something doesn't have a GUI doesn't mean that objects suddenly don't apply; the reason objects are used is for ease of modeling both interface and data. Sure, you can do it with C but it's painful when C++ already does it for you (features such as virtual functions for example).

Yes and no. Programs can be implemented using objects and classes but not necessarily. Programs can also be implemented by procedures and forking. It is the choice of the programming paradigm used that determines which programming language to use. If you wish to employ object oriented paradigm with full class inheritance etc. then object oriented language should be chosen.


Not that C++ doesn't let you do 'procedural' programming as well; it is a multi-paradigm language (http://en.wikipedia.org/wiki/C%2B%2B), not just an OO language.

Yes that is true also. Perhaps the reason why people don't do that is that C89 compilers are widely available on many platforms. Personally I would like to use C99, but that is not widely supported yet.


Finally, I would wager that the reason C turns up alot in Linux code is due to;
- legacy
- people not knowing C++ and not wanting to leave the 'comfort zone'
- misinformation that somehow C is 'faster' than C++ or some other equally misguided 'feeling' on the subject.

I agree on the legacy part but I would also suggest that in Linux there are also other programming languages widely available that do a better job than C++ such as Python. C++ is quite low-level and when doing object oriented programming with it, there are better alternatives.


Still, surely this code is going to be crossplatform so it doesn't matter what linux does..? unless you have an unhealthy linux bias ofcourse which could prove a problem with a cross platform sdk (you do plan on supporting Visual Studio projects for the source code, yes?)


Well, I am 'biased' to Linux over Windows in that way that Linux is the personal choice of operating system for me. I like Linux due to it's open source nature and that Linux software tend to be more lightweight, more customisable and can be operated from command line.

If this biasness is unhealthy or not, I let you to decide. However I would point out that we are aiming this SDK to be cross platform. I am not any kind of "leader" of this project and I see that my personal preference for Linux is not a problem.

[HenriH]

Well, to be fair (and even more off-topic), C++ provides a lot more than polymorphism. But even polymorphism is useful for more than GUIs (and personally, I think polymorphism is overused in GUIs).

Also, there's more to classes than just polymorphism. They provide encapsulation, public vs. private interfaces, the ability to attach code to data, constructors/destructors that the language guarantees will be called, and so forth. There is exception handling in C++, which allows for a category of error messages that C can't handle. You can't have RAII and therefore guaranteed resource management in C. I can keep going, but I think my point is clear.

And that doesn't deal with how much more useful and comprehensive the C++ standard library is compared to the C standard library. Nor does it deal with the sheer awesomeness of what C++ can do as exemplified by Boost (smart pointers, Boost.Spirit-based parsing, Boost.Bind, Boost.Any, Boost.Lambda, etc).

You're misrepresenting C++ by simply thinking of it as "C with classes" (a common misconception). I still don't think C++ is appropriate for the SDK, but I just wanted to correct your misrepresentations.

Well I stand corrected, thank you, but I know about C++, don't need a lecture about it and neither do you I believe. I could counter-argument about C++ Standard Library, C++ data hiding, exception handling and Boost but I don't feel like it, it would be unnecessary and off-topic. I was giving polymorphism as an example what benefit C++ can give for GUIs, not saying that is the only thing.

[bobvodka]

Object orientation is used in the Windows world extensively because of the GUI nature of the operating system and Windows has the biggest market share at the moment.

I've just one problem with this statement btw; the Win32 API is a C API for the same reason OpenGL is implimented as a C API; it is the langua franca (http://encyclopedia.farlex.com/Langua+franca) of the computer world in that every language worth anything out there understands the C calling convention. That is to say, neither are 'written for C' but exploit the stable C ABI/calling convention to make sure it works for everything and anything.

Also, as a side point, i'm not sure what the C++ ABI on linux has to do with anything; given how common compiling of source is on linux, and that this is a developer resource, I would have thought providing the source files with a build system would have been enough there.
Probably the same with Windows as well, although providing statically linked binaries is more common here.

[Xmas]

The SDK isn't intended to be used it in production code. After all, in production DirectX code, nobody uses the D3DX math library (which, incidentally, was written to be friendly to C and C++ programmers). The libraries in the OpenGL SDK should eventually make themselves obsolete as each user becomes familiar with OpenGL.
I tend to believe an actual Software Development Kit instead of a collection of tutorials would be much more valuable to developers.


If the SDK asks people to derive from an "app" class, then we can't focus on simply teaching users how to use OpenGL; now we also have to focus on teaching them how to use the SDK's libraries, and that's a waste of time for something which intends to obviate itself.
Not arguing for any particular language, but you need some initialisation and event handling code in any case. Whether that is wrapped into functions or methods is hardly substantial.

[Rob Barris]

No, I think I'm rather the opposite of missing the point of the SDK in my objection to using C. Using C++ would make clearer what's being taught.
So whats the problem? Let them write a C SDK and then when they have a few lessons done, start a sub-project to do a C++ version as well.
I would be happy to help with a translation for Delphi programmers.
Bobvodka could start a sub-project to do C# and Python translations if he wants to.

Why dont we just let them get on with it so we actually get an SDK.
The hard part is producing the actual tutorials to teach beginners the basics of OpenGL.
Once thats done the code examples can be translated into other languages quite easily, and a different math library substituted that better uses the features of that language.

We should all be encouraging those who are willing to donate their own time to help more people learn OpenGL, and we should be helping them as much as we can, not getting into arguments about which language is best.
OpenGL is used by people who's personal preference in programming language varies wildly, and i would hope that one day we can have an SDK that includes all of them, but for now its important that we concentrate on getting the C language version done and not get distracted by side issues that can be fixed after OpenGL SDK 1.0 is released.


Simon you really hit the nail on the head here. The GL-SDK sourceforge project is just one project and it's been decided that it will use C. There is nothing stopping anyone from writing examples in another language, and the GL-SDK group (IMO) should encourage any such efforts. More is better.

IMO it's better to state what you will do, rather than try to tell others what not to do. Two people / groups can do two different things, and that is fine.

In fact I don't think anyone who is interested in doing C++/C# GL3 examples should even wait to see what comes out of GL-SDK. My hope is that the majority of examples will be concise enough that one won't really have to consider language complications that much - keep focus on API usage.

[HenriH]

Fine words Rob :) That's the spirit of open source.