PDA

View Full Version : Object Oriented OpenGL



alberto
09-08-2007, 08:27 AM
I have spent some time converting a fairly large number of those nice OpenGL sample programs to C++ and revamping them to use object oriented techniques to different extents, and also to build under MSVC 2005. I also added lots of comments. Much of my motivation has been to give samples that my Grad School Graphics students could learn from.

I feel like sharing these programs with the community, but I don't know how pertinent this still is, vis a vis shaders and newer stuff. Also, I do not want to get in trouble with Copyright issues.

Does any of you have any opinion that you could share with me ?

Alberto.

Lindley
09-08-2007, 01:42 PM
I don't think wrapper classes have any legal issues. However, they're also likely to become rather redundant once OGL3 gains momentum. I gather it's significantly more object-oriented than 2.x.

Korval
09-09-2007, 12:29 AM
However, they're also likely to become rather redundant once OGL3 gains momentum.Oh, I suspect that there will be some need for wrapper classes in GL 3.0. Even if it's just a one-to-one mapping of C functions to C++ members. It's still useful to be able to look in your header and know what your options are for this particular object.

But you're right in the sense that GL 2.1 wrappers won't be much in demand.

Komat
09-09-2007, 02:48 AM
As I understand that, alberto is not talking about simple object wrappers over the api. He is talking about modifying sample programs to use objects where it makes sense.

I am not a lawyer so I might be wrong. Unless you rewrote the sample programs entirely, the original author has copyright over parts of the code which you did not rewrote. Because that are sample programs and you are using them for scholarship, the fair use doctrine might probably apply when used in USA however the best approach would be to ask original authors for permission.

alberto
09-09-2007, 06:37 AM
These aren't wrapper classes, but often total rewrites. I reorganized user C code in classes, replaced malloc with new, used polymorphism to simplify calls, converted x,y,z,w individual code to member functions that manipulate whole vectors instead, used higher-level objects whenever possible, added override operators (for example, v1*v2 for dot product of two vectors, v1^v2 for cross product, !v for normalization), and so on. As far as Copyright, sometimes it's there, sometimes it's not; the same for the authors, more often than not there's no name associated to a program. Because I'm a cautious dude I haven't given them out to my students yet: they're sitting on my hard drive at home.

Alberto.

Lindley
09-09-2007, 09:33 AM
Maybe a pointer to which sample programs you're modifying? Hard to address the "how pertinant this is" bit directly without that.

With regards to malloc vs new, I feel it's important to learn both, and what the difference is. And I feel operator overloading should be done cautiously and with restraint; it's too easy to make a program unreadable if you go overboard with it. Particularly since most matrix operations should be done by OpenGL internally, or in shader programs, I'm not sure what the relevance is in C++ classes.

Korval
09-09-2007, 07:25 PM
Really, the first and last question is this: what license was the source code released under?

If it was under any license defined by the Open Source Definition, you're probably in the clear, so long as you release your version under a license compatible with theirs.

If not, then you have to deal with questions of how much you've changed vs. how much original source remains.

However, since these are sample and tutorial applications, I don't imagine anybody's really going to care one way or another.

Y-tension
09-10-2007, 01:26 AM
Lindley wrote:

And I feel operator overloading should be done cautiously and with restraint; it's too easy to make a program unreadable if you go overboard with it. Particularly since most matrix operations should be done by OpenGL internally, or in shader programs, I'm not sure what the relevance is in C++ classes.
Very true about operator overloading however, I think matrix wrapper classes will become very relevant once OpenGL 3 comes out since there's talk about no matrix stacks and manipulations..

About the copyright issue, here in Greece you are exempt from copyright issues if you're using part of an original document purely for academic reasons. This information can be found by googling for copyright laws for your country. And of course you can always ask a lawyer, just to be on the safe side.

ScottManDeath
09-10-2007, 08:31 PM
I think using "*" for "dot", "^" for cross and "!" for normalize is dangerous, since it doesn't follow canonical math notation. If in doubt I follow "Do it as the ints do".

alberto
09-12-2007, 04:57 AM
For an extensive use of "^" for cross products, try "Geometric Algebra for Computer Science", by Dorst, Fontijne and Mann, Morgan Kaufmann. About using * for dot products, we use it for multiplication in spite of the canonical math notation of not using anything: blame our parsing techniques for not being able to tell whether "ab" is the symbol ab or the product of a and b. In fact, disambiguation for multiplication in canonical math notation is a dot, which confuses scalar multiplication with a vector dot product. As for "!" for normalization, "!v" beats "v/||v|" hands down!

Lindley
09-12-2007, 05:31 AM
It's not in question that those operators could reasonably be used to represent those functions. Merely whether doing so is a good idea.

I'd think v.norm() or d = dot(u,v) would be simpler for readability, particularly since "dot" is an actual Cg function which may be encountered by students in the future.

ScottManDeath
09-12-2007, 08:10 PM
Mathematicians != Software engineers :D

Even Matlab, which is supposed to be good for math uses norm and cross, rather an obscure overload of totally unrelated operators.

Another problem is that ! and ^ have different precedence, so you might shoot yourself into the foot and get surprising results.

Bjarne Stroustrup apparently thought (http://www.research.att.com/~bs/whitespace98.pdf) about changing the C++ parsing rules to make this universal programming language more suited to math by overloading the whitespace operator.

I know I will open a can of worms (http://www.ddj.com/cpp/184402076) , but I couln't resist.

alberto
09-13-2007, 05:20 AM
I have a long history as a developer of OpenGL ICDs and kernel-side debugging software such as DriverStudio and SoftICE. I write volume rendering device drivers for a living. Mind you, some Software Engineers can be competent at applied math too!

I'm very aware of operator precedence, and, you know, that's why we have parentheses in the language. It behooves every programmer to know the difference between !a^b, a^!b, and !(a^b), just as -a*b, a*-b and -(a*b) yield different results; and those are yet different from the mathematically standard ab.

Operator overloading existed way before C++, in Ada, which for many years (I don't know if this is still the case) was a required language for government contracts.

Lindley
09-13-2007, 08:33 AM
Originally posted by ScottManDeath:
Bjarne Stroustrup apparently thought (http://www.research.att.com/~bs/whitespace98.pdf) about changing the C++ parsing rules to make this universal programming language more suited to math by overloading the whitespace operator.
Dear lord! Mark that down in the "seemed like a good idea at the time" column.....

santyhamer
09-13-2007, 09:52 AM
Originally posted by alberto:
!a^b, a^!b, and !(a^b)I don't like that notation at all. Prefer:

a.Dot(v)
Vector::Dot(a,v) for "static" version
c = a.Cross(b)
c = Vector::Cross(a,b) for "static" version

longer to write but definitely much more clear

pudman
09-13-2007, 10:36 AM
Using method names also avoids any ambiguity when writing or maintaining code that could could several different meanings of an operator depending on the class type.

If I see !(a^b) should I be thinking "NOT a XOR b"? or "normalize a cross b"? Obviously knowledge of the what types a and b are is required. a.cross( b ).normalize() is self-explanatory and is consistent with some shader language definitions (until the evil day comes that shaders allow operator overloading).

That said, every programmer has their own convention, or must support the convention of their employer. Those who play mostly in C++ land tend to enjoy the convenience of operator overloading.

I would hazard to suppose that visual IDE's make use of operator overloaders much more convenient. Visual assist is a wonderful productivity tool. (Full disclosure: I must admit I do enjoy a good vim session.)