Am I the only one that finds OSG's code disgusting?

Started by
2 comments, last by schupf 11 years ago

So I've decided that as an exercise to learn more about engine development that I would develop a platform-independent scene graph with the ability to have renderers for multiple rendering systems. I have heard much praise from OpenSceneGraph, so I decided to have a look at their code for ideas and inspiration.

What I found instead was a sea of bad code. In particular my gripes were:

1) Tons of protected member state. This opens a HUGE potential for problems later on, and would require massive refactoring if the underlying base classes ever changed.

2) Every object extends from a "base object" (similar to Java), and supports only manual reference counting. I once considered a system like this, and came to realize (with the help of others) it causes nothing but problems in the long run. Why OSG?

3) Exposing getters and setters for properties that have no business being exposed. Literally every bit of internal state can be modified through a setter, and in some cases it's extremely inappropriate. The idea of private state is practically nonexistent in OSG.

4) I was expecting an abstraction of OpenGL, and found only a thin wrapper. The idea that OSG could ever support another rendering library is basically impossible at this point.

Now this isn't to say I didn't take away anything positive from my dive into their code. In fact there were several things I liked. But overall, wow what a disappointment that was. Is this the feeling most people get when they look at OSG's code, or am I just being too critical?

Advertisement
OSG started in 1998. That's 15 years of advancement that has occurred in computer science since it began. A lot of what OSG does was "standard procedure" in 1998. You see this kind of problem in lots of aging codebases, not just OSG. Look at the various other open-source rendering libraries and rendering API abstractions. What once was considered correct no longer is in many cases, and programmers as a whole are generally more well-rounded with a wealth of experience to tap via the internet, experience that just didn't exist in 1998.

OSG started in 1998. That's 15 years of advancement that has occurred in computer science since it began. A lot of what OSG does was "standard procedure" in 1998. You see this kind of problem in lots of aging codebases, not just OSG. Look at the various other open-source rendering libraries and rendering API abstractions. What once was considered correct no longer is in many cases, and programmers as a whole are generally more well-rounded with a wealth of experience to tap via the internet, experience that just didn't exist in 1998.

This does make a lot of sense...are there other, more modern projects that you would recommend?

I agree, OSGs code is a mess. But its the lack of documentation that really makes working with OSG such a pain in the ass...

This topic is closed to new replies.

Advertisement