Slashdot Mirror

To get more out of ARToolKit, try adding osgART so you can use OpenSceneGraph.

OSG, a visualization toolkit (open source, cross-platform) takes over an hour on Linux to compile on a computer that was purchased barely a year ago. That same computer, running windows XP / Visual Studio, compiles in 45 minutes. No joke.

Not sure if an hour is tolerable or not ...

I think this move might have other repercussions than just help the Linux PC game market.

Simulation and Visualization are both huge. Projects like OpenSceneGraph, etc. Lots of people are using Linux to do graphically intense development work - I used to, back when I worked for the Army. nVidia seemed to be the preferred video card by a long shot because it was so well supported. They are probably trying to crack that market.

nVidia also had the advantage of using a unified codebase - 90% of the driver code is identical between Linux and Windows. That's something AMD hasn't been doing (at least back when I kept up on things, they may have changed in the past few years).

So as you say there are markets above and beyond linux desktop gaming (which is pretty minimal ... honestly, its a few FPS's and then WINE. And most games under WINE have issues ... )

http://www.crystalspace.org/ http://www.ogre3d.org/ http://www.openscenegraph.org/

Full disclosure: Paul is a friend of mine, and I helped proof this book too.

In all seriousness, this is an excellent book. Paul wrote this book to fill a serious need -- an updated, quality OpenGL book for this age. So much of what is in the canonical texts is no longer important (geometry by Begin/End), and they won't cover the new recommended practices (VBOs, Vertex Arrays, etc).

On a personal level, Paul is one of the most generous and helpful programmers I know. I owe him lots of beer for all the advice he has provided. He also participates in the open source OpenScenGraph project:
http://openscenegraph.org/
a high-performance 3D toolkit for Windows, Mac and Unix/Linux, used in hundreds of open source and commercial simulator, game and 3D visualization projects (including my company's NatureView Express tool http://3dnature.com/nv.html -- plug plug!)

... like people doing scene generation, rendering, etc. Small biz and hobbyist type work.

Sorry to reply to myself... I totally spaced it. An example of the multi-threaded graphics toolkit would be something like Open SceneGraph (OSG).

Blow by blow:

accelerated 3d

I do 3d development under Linux using OpenSceneGraph. I can personally attest to the fact that 3d acceleration works under Linux. framebuffer

Why the hell you want to use framebuffer with a spiffed up card is beyond me but yes, nVidia has a framebuffer driver, and here's a walkthruough: here

2d & video out

Haven't used it personally but I have friends who do. Again, same driver code is shared between Windows and Linux.

Also of interest:

NVIDIA also provides an open source OpenGL and XFree86 3.3.5 driver implementation on their website. The implementation supports the NV1, RIVA 128, RIVA 128ZX, RIVA TNT, RIVA TNT2, and GeForce 256 chipsets. This driver has lower performance than NVIDIA's proprietary driver but it does include source code.

Yes, I fed a troll, but only so that he might not mislead others. May god have mercy on my soul.

One problem is that OpenGL (pre 2.0, haven't looked at that yet) is horrible to work with if you actually want to get stuff done. I'm using it in a game right now, and let me tell you, using a library with a stateful API is no fun.

OpenGL is stateful because 3D hardware is, and OpenGL always tried to be a thin layer on top of the hardware. Unfortunately, as you've noticed, state leakage becomes a real problem as soon as you start trying to build anything beyond a single static scene. It's just too much bother to keep track of all the state variables you have to save and restore as you traverse render nodes, particularly when the traversal order isn't predetermined. That is why SGI developed Inventor, which takes care of managing the details of state variables so you don't have to. You specify which state you want to carry over between render nodes and Inventor takes care of making sure that's the only state that carries over. Inventor isn't open source, but Coin is, sort of (the license seems to imply the GPLed version can't be sold, which would be an "additional restriction", incompatible with GPL).

Anyway, there's Open Scene Graph which is entirely open, and considerably advanced beyond Inventor.

OpenSceneGraph (http://www.openscenegraph.org) had a pretty good showing at SIGGraph. I attended the BOF (Birds of a Feather) meeting, and presented what my company has done with it.

OSG as it is known is a modified LGPL -- modified to allow code to be included in commercial projects via C++ inline functions, which technically would violate the pure-LGPL stipulation of dynamic-linking only.

OSG is an excellent example of the marriage of commercial/proprietary software and Open Source. Tons of people use OSG to build Open Source and commercial apps. No one minds if my company, or anyone else builds commercial, closed-source apps with OSG, because it's the meat of OSG that is valuable to the community. There may be useful parts in other people's applications, but it's the improvements of the core code that drives the project. If enough closed-source people need the same capability, befor elong, it will ge developed and put into the code OSG project for all to benefit from.

It's a profitable deal for everyone involved, and I think it's a great example of how Open Source and proprietary projects aren't necessarily at odds with each other, and can mutually benefit from their relationship.

Open source 3D for GIS : vterrain.org

See also openscenegraph.org

Both can use Remote Sensing data.

"I'd never do something so dishonest as to develop OSS on company time"

Why even consider it, when you get so much extra contracting work by doing things the hard way?

We've just spent a year writing graphics software for proprietry hardware we're probably going to ditch and do the same again with a different proprietry bit of software. If we'd used OpenSceneGraph (LGPL) we could have been finished 6 months ago.

Well, you are very welcome to write one [Free Software FPS game]and donate it to the comunity.

You may find some of these projects useful:

OpenSceneGraph -- the standard rendering platform for game graphics. Runs faster than commercial systems.
The virtual terrain project -- terrain modelling resources
HFTools -- landscape generation tools (admittedly level-design in blender is more likely for FPS)
Audio library -- most important bit of a game is the music!

for anyone interested in visualization, check out Open Scene Graph, a fast maturing LGPL project that is well suited to games. (and science/med/etc.) Almost zero documentation , though, but that'll change.

IMO, Linux needs games in order to "make it" in the mass market. It already has the good O/S, it has the word processing software, it has GUIs if you want them - the only thing it doesn't have is a good games library.

I agree with you. However, just be patient, it's coming. It takes time to build a whole infrastructure capable of supporting the full lifecycle of a game development project. It takes time for massive numbers of independent developers to absorb the technical background and learn the skills to come up to the same level as a pro game developer. But look here and here and tell me it isn't happening. As open source developers, one thing we have is plenty of time. That means time to get it right, time to build best of breed tools, time to build a community of first hundreds, then thousands, then tens of thousands of open source game developers. It's happening, I can assure you. Sooner than you think the worldwide programming talent pool for open source games will grow to exceed in numbers the largest commercial game company by an order of magnitude. What's more, that talent pool will include many professional game developers, working in their free time just because they love it, or they want to build their reputation. In that, game developers are no different than any other breed of open source developer.

But it takes more than programmers to make a game, it takes artists and game developers with both excellent skills and good taste. Right now, this side of the community lags way behind the programming side, but that too is a temporary situation. The artists will arrive when the tools are there, and the tools are well on their way. Note that the whole animation industry has basically switched to Linux. Sure, most of the software they're using is proprietary/expensive, but that's changing rapidly.

Try the multiplatform OSG. It's a level of abstraction up from opengl, but scene graphs are easier to understand and organize. There are many examples to start with, and the mailing list is quick to respond to support needs. If you ever want to delve deeper into opengl, osg does not get in the way; vertex shaders are fairly straightforward. Even so, it's LGPL, so you could modify the core code too if it ever suited you. Finally there are a dozen or so loaders included, so you can put pretty models into your scene without much experience.

Also, read opengl.org every few days. They post many good resources from tutorials to example apps.

Having played with the ODE...

The parent article is quite correct. If you're doing any solid-body physics based stuff, ODE rocks. Combine it with SDL and OSG and you have the basic tools to produce some really cool stuff. Throw in the Demeter Terrain Engine if you want a bit of scenery to go with it. I've tied all four together for experimenting with what makes a good driver interface for a hovertank. :)

The Stair-dismount makes good use of joints, and collision detection features of ODE - but even if you don't need these, the force model of ODE is a lot of fun to play with on its own. But if you *are* ambitious, it has specialised joint and suspension-spring models for doing things like wheeled vehicles pretty easily.

With all these tools available under LGPL, those of you like me - who don't like writing a graphics/physics engine so much as actually writing cool simulations with said engines - have a much better point to start from than even 2 years ago.

As soon as people talk in terms of patterns, they're talking at a level of abstraction above basic objects, and at a level where you're talking about object construction and interactions.

This also helps when you're trying to wrap your head around a library written by others. Some of the clearest and best use of design patterns I've seen is in the Open SceneGraph library. Although a little short on tutorial docs, the code is so well designed (including naming!) from a patterns point of view that you can pick up what the various classes are doing very quickly.I wouldn't quite recommend it to a beginner in patterns but for someone looking at exactly how they are used in the real world, it's great code.

It's a nice piece of work, but it solves a problem that nobody needed solved.

I'm glad you don't have a problem with calculating and drawing all visible polygons in a 50 000 poly-based world as quickly as possible. Some of us do.

Ogre is a "high-level scene graph engine". This is a level above a standard 3D rendering API, like OpenGL, but a level below a general-purpose game engine. Unfortunately, while high level scene graph engines seem plausible, they're not very useful.

I'm not sure what you mean by plausible - since Scene Graphs are not just theoretical: they work extremely well for their purpose. They are very useful, probably the fastest general purpose method for drawing large scenes available today.

There are quite a few of these things. SGI Inventor was the first major one. Apple had one in Quicktime 3D. Direct-X has one, but Direct-X is mostly used as a low-level drawing API. One was announced for OpenGL (it was called Farenheit) when SGI and Microsoft lost interest, it didn't really bother anybody.

Meanwhile in the year 2002, there are quite a few scene graphs available for many platforms. One of the best is Open Scene Graph, an LGPLed library which is used for games, demos and high-end visualisation systems. Not to mention Ogre itself which looks very sweet indeed.

You need a low-level graphics API to abstract different types of hardware. That's the real job of OpenGL and Direct-X.

Direct-3D I think you mean.

You might want a full game engine if you're building a game, and you can get those from a number of vendors.

You might also want to consider what 95% of game writers do and that is to select the best tools for the job and assemble them yourself. Graphics and rendering tends to be 10% of the typical code base for a commercial game - the bulk is AI, gameplay logic, resource management, menus, and supporting tools.

But mid-level APIs just aren't all that useful. You have to do things their way, but they don't do enough of the job to justify the trouble.

I suppose if you're looking for a game engine which does everything for you while wiping your nose and holding your hand, then a mid-level API won't be very useful. For a game writer looking to solve the one big problem of overdraw, a mid level API like Ogre or OSG is an excellent solution. Plug it in and it does the clipping, culling and drawing work for you. I know from personal experience that OSG is superb at this job - adapting equally well to visualisation, flight simulation and terrain rendering. Ogre's screenshots tell a similar story. Want a Quake 3 level? Load it and Ogre adds it to the graph and takes care of the rest.

Not really. Most people using windows for 3d graphics in the workstation area are using a high end graphics card. By that I mean GeForce3 or faster.

They all come with OpenGL drivers. You dont even notice that MS doesn't ship them. Install video cards drivers, get OpenGL.

MS is really in a position to lose market here to Linux because of this: Linux on a PC with fast 3d (via nvidia for example) is infinitely more like the workstation being replaced than NT on a PC is.

At the higher workstation end (higher than GeForce3), people aren't yet looking at windows because the hardware isn't there anyway.

I think it'll be a while before OpenGL dies, especially as in all markets people are finally moving up the ladder - to scenegraph API's like this one.

If the SG supports both DX and OGL backends then you dont even have to think about it.

my random 0.02,
Mike