OSG vs. OpeSG

Hello.

I need your oppinion on which to use: OSG (american) or OpenSG(german).

For stereoscopic apps running on an Onyx, using a wanda (3d mouse). Possibly moving everything to cluster soon.

As i understand it, OpenSG was originally designed for use in clusters and with funky input devices, whereas OSG only added these features later… does this mean OpenSG is the way to go?

I tried some OpenSG demos on red hat 9 and they are kinda slow.

Please discuss which and why.

Thanx!

Dingo

Looks like OpenSG more solid by idea (probably, becouse it developed by one team and for german govenment).
OSG is more updated from technology point of view (i.e. GLSlang/ARB_vp&fp/VBO/etc.), but Producer(including cluster support) is quite new(and probably, not tested enought).

Documentation for both projects is not really exist.

Whats about OpenInventor(from TGS/Coin/) or SGI Performer?

Originally posted by Dingo Egret:

I need your oppinion on which to use: OSG (american) or OpenSG(german).

Not sure what you mean by “american”. OSG is open source. Don Burns (US) and Robert Osfield (UK) maintain it.

I just went through OSG training last month with Don. I recommend it since documentation is so limited. We’ve been quite pleased with OSG – using it for Windows and Linux development. We’re just now looking at adding IG capabilities to it – hopefully to utilize it on a couple of near-term projects.

I hope OSG continues to progress. I’m a firm believer in open source philosophy.

I’m the development lead of OpenSG, so take my comments with that in mind.

Unless they changed something significant, OSGs cluster capabilities are much more retricted than OpenSGs. Ours works with any application code, any change to the scenegraph can be distributed over a cluster without the client having to write any code for that. This is a result of our design for reflectivity and independent multi-threading, which allows pretty flexible data management.

The biggest performance problem that we have is other people’s models. By default OpenSG does not optimize the loaded models much if at all. The main reason is that we don’t know what the user wants to do with those models, so we can’t just merge materials or remove useless nodes and trasnformations. This is a big difference to Performer and perfly, who totally restructure the loaded model for speed. For models that have been exported from the typical modelling packages that’s a problem, as they are not optimized in any way (3DS Max is extremely bad in that respect).
We have most of the necessary tools to get better performance, and we’re currently working on an easy way to have the app decide how much and which optimization it wants.

Oh, and OpenSG is not really german. In addition to the people in Germany we have me in the US and another core member in Singapore, so I think we’re pretty international.

If you have other questions feel free to ask.

Yours

Dirk

Thanks for the info. Is OpenSG free? The name implies it is open source.

Thanks everyone for the info.

Dirk, my problem with OpenSG now is that it doesnt seem to support FLT or PFB files, and OSG does. Is there some sort of plugin for this?

The OSG doesn’t have any direct support for cluster right now, but this really isn’t a difficult task to add at the application level. Simply create an IG with an appropriate interface to control the moving models and events.

The OSG does support multiprocessor multipipe system like the Onuyx right out of the bag. Almost all the exmaple in the distribution can run multipipe just with a simple configuration file. Producer manages all the configuration or windows and threads via a simple config file.

Producer is similar in concept to OpenGL Multipipe SDK, just cleaner, more portable, and better integrated with the OSG :slight_smile:

The OSG also has optimization utilities which do the various operations to one poorly conditioned dataset. On really big datasets this can lead to an order of magnitidude difference in peformance.

Stereo can be enabled right out the bag too, for instance:

osgviewer --stereo cow.osg

Anaglyphic, quad buffer, split screen, HMD stereo modes are all supported.

The only things really holding back usage of the OSG is documentation… but if you are familiar with Peformer then the scene graph concepts you’ll be used to will map over to the OSG quite while. You’ll just have to get used to all the added extensibility that’ll be on offer :slight_smile:

Both OpenSG and OSG are open source, so there is no cost save your own time in trying both out and doing the taste test yourself.

Robert.

Yes, OpenSG is Open Source (LGPL).

No, OpenSG doesn’t support PFB and FLT, it’s not quite as targeted at the performer community as OSG is.

Originally posted by Robert Osfield:
The OSG doesn’t have any direct support for cluster right now, but this really isn’t a difficult task to add at the application level. Simply create an IG with an appropriate interface to control the moving models and events.
That’s a pretty optimistic view on things, IMHO. :slight_smile: Be aware that you have to write code to transfer EVERY change to the scenegraph that you plan to do, and for many interesting apps that’s a little more than moving the viewpoint or a model around (which for OpenSG is the same thing anyway). Our clustering just takes care of it, without user intervention.

But as Robert says: they’re both Open Source, give them a try and decide yourself.

Dirk

Originally posted by dirk:
[b] [quote]Originally posted by Robert Osfield:
The OSG doesn’t have any direct support for cluster right now, but this really isn’t a difficult task to add at the application level. Simply create an IG with an appropriate interface to control the moving models and events.
That’s a pretty optimistic view on things, IMHO. :slight_smile: Be aware that you have to write code to transfer EVERY change to the scenegraph that you plan to do, and for many interesting apps that’s a little more than moving the viewpoint or a model around (which for OpenSG is the same thing anyway). Our clustering just takes care of it, without user intervention.

But as Robert says: they’re both Open Source, give them a try and decide yourself.

Dirk[/b][/QUOTE]Driving a clustered IG the way I suggest is something that is done very commonly in the vis-sim industry. There really isn’t any unusual and optimistic about it, hundreds on sims on lots of different scene graphs successful use this technique.

It may even more efficient to drive the OpenSG this way too :slight_smile:

Robert.

Originally posted by Robert Osfield:
Driving a clustered IG the way I suggest is something that is done very commonly in the vis-sim industry. There really isn’t any unusual and optimistic about it, hundreds on sims on lots of different scene graphs successful use this technique.

IGs usually are pretty limited in the changes that happen to the scene, primarily moving the ownship and the other simulated entities, that’s not a lot of work to code network transfer for those.

Things become more interesting (and more tedious) when you have apps that actually do change the scenegraph a lot, and from many different places of the code.

It may even more efficient to drive the OpenSG this way too :slight_smile:
Robert.
Some times it probably is. :wink: You can always construct cases that kill either method of doing things.

But if you want to do the communication at that level, you can also look into more general toolkits like VRJuggler, which are based in input distribution, which gives you the most minimal data transfer.

As always: the solution depends on the specifics of the problem, it’s up to you to decide what works best.

Dirk

I might be biased since I am using OpenSG too, but from the perspective as an application programmer I really like it much.

When implementing applications that really change the scenegraph and I mean every single aspect from totally restructuring to things like movie textures there is NO difference in code for running it as a simple standalone application on a laptop or driving a huge 48 pipe tiled display wall. OpenSG just takes care of it.

I cannot comment on the quality/featureset in OSG, but OpenSG has nearly everything I need from optimization, shading support (arb stuff as well as glsl). I will be more than happy once the support for parametric surfaces and tesselation will appear. Some things are still missing but most of them can be implemented and contributed (after all its opensource)

Its really simple choosing the right scencegraph. Just take a closer peak at your needs and analyze all toolkits you could use. Rate how important the features are for you. Simply pick the one which helps you best

Matthias