OpenSceneGraph vs. OGRE.

[surf]

OpenSceneGraph is another open source graphics rendering engine.
you can check it out by
http://www.openscenegraph.org.
Lots of projects based on it including the famous VTerrain project.
(http://www.vterrain.org)

His scene graph is different from the OGRE's,and it use the smart pointer
,Open Threads (http://openthreads.sourceforge.net) and open producer
(http://www.andesengineering.com/Producer) in his implemention.

Does OGRE plan to use these techniques in the future.

and how OGRE to ensure the thread safe?

thanks.

[sinbad]

Ogre is deliberately not thread safe, because using mutexes has an overhead which is not justified in most cases because the actual rendering process is asynchronous anyway. Apps can use their own multthreading if they want, they have to enforce any mutexes they see fit.

We already use reference-counted smart pointers where they are useful. .

[larryq]

Sinbad, when you say "the actual rendering process is asynchronous anyway", are you refering to the RenderQueue classes? I've seen them in the code but wasn't sure how they worked --at a high level. Can you or someone provide a little overview?

When I think of queues I think of offline processing and when I think of *that* I think of slower-than-usual response times. Which you can't have in a renderer. OGRE avoids this somehow but I wasn't sure how you guys pulled it off. Sounds interesting.

-larry

[sinbad]

No, what I mean is when you call Direct3D or GL, it does not render then, it queues it up for the API to render later. Actual frame rendering is done in parallel with Ogre itself, and since this is the most expensive thing, it would be pointless making Ogre multithreaded because it would always be waiting for the render to finish anyway.

RenderQueue is Ogre's internal queue, which is not for asynchronous processing, but to allow Ogre to group and sort the items which need to be rendered, for performance (minimising state changes) and to implement effects like shadowing.

[Game_Ender]

I would like to reopen this topic for discussion. I am currently working on a project and there is some discussion on whether Ogre of Open Scene Graph would be a better choice for a 3D engine. For this project we need to simulate a simple 3D environment and animate a few free flying objects along with compilcated robotic arm. This mainly going to be used on Linux, but being cross platform would make developement easier.

Currently here is how I see it
-Ogre has better docs than OSG
-Ogre supports D3D while OSG only supports OpenGL (not really important, but provide more options in the future)
-Ogre has more built in features, like skeletal animations (really important for the arm).
-Ogre seems alot easier to use

Does anyone have any opinions on this? Is OSG really that much harder to use? Does it really lack a lot the features compared to ogre?

Any help would be much appreciated.

[Olex]

I have looked at OpenSceneGraph some time ago, and then later, I looked at Ogre.

Let's just say I saw more in Ogre right away. Docs, tutorials, etc. really help you know. Long story short, in two weeks, I migrated my project to Ogre.

[:wumpus:]

I've also looked at OSG a bit before Ogre, and found the scene graph not that different from Ogre. The aims of both engines are quite different though

Ogre:
- Optimized for utilizing all the fancy GL features like hardware vertex buffers supported by mainly ATI, NV and mainstream cards
- Supports GL and D3D
- Animation features, particle systems, shaders, and other 'fun' stuff

OSG:
- Optimized for compatibility with scientific platforms like SGI, which generally have all kinds of peculiar bugs to work around
- Only GL
- Computional and geometric algoritms like delaunay triangulations, planesweep, graph rendering and tesselation are built in

As you can see, it all depends on the kind of project and the targeted hardware. On the other hand, if you really need the scientific algorithms you can also look at VTK which generally offers more flexible algorithms than OSG and is modular enough to combine with Ogre.

[Game_Ender]

I completely agree Olex, now I just have to convince my boss (i.e. make a demo).

Thanks for the insite :wumpus:, but you you expand on what kind of things you would use these "Computational and geometic algorithms" for?

[:wumpus:]

Those are used in modelling packages, but also for visualisation of medicial, geological or other datasets that are not in a convient model format so need to be tesselated. Something you generally don't encounter in games, as you want to do modelling, level creation and animation in a preprocessing step for faster loading. That's why we choose to not let those things burden the Ogre core.

[NeoPain]

I read on OpenSceneGraph.org that OpenSceneGraph supports occlusion culling so we can make large outdoor areas. Will OGRE support it ever?
Thanks in Advance.

[johnhpus]

OSG looks a little punch-drunk.

[DWORD]

LOL

[:wumpus:]

Please do a little searching if you want to know about occlusion culling or how we think of it; the discussion has been done here a zillion times.

[NeoPain]

I know. But there was some commercial plugins for that. And i'm asking will it ever be built in like in OpenSceneGraph?

[sinbad]

If you read the API you'd have seen HardwareOcclusionQuery already exists. Using it effectively in a scene is more complex than just 'flipping a switch' though - that's why you need a scene manager to support it. Given that OGRE doesn't dictate how you structure your scene or how you set up your scene manager it isn't possible to give you a 'one size fits all' solution; instead we give you the tools to build what you need.

[Robomaniac]

lol @ johnhp

[NeoPain]

Ah...i got it. You know... if there would be OC than OGRE could be become several times more popular imho. Besided there is no tutorial on building such SceneManagers...

[lgoss007]

Actually OSG has animation, particle systems, shaders, vertex arrays and more as you can see here:
http://www.openscenegraph.org/osgwiki/p ... troduction

And while it is mostly used for VR systems and simulations, a pretty cool game is being created with it:
http://www.openscenegraph.org/osgwiki/p ... oftPirates

I'd say it depends on what your goals are and what you want from graphics engine/scene graph. OSG isn't that much harder.

[Game_Ender]

I do agree that the game does look very cool, but the main thing I don't like OSG about (after having used it for a while now) is the fact that it doesn't really abstract you away from all the nasty scene graph stuff like matrix transforms and design stuff like using visitors. Now I know that after a while I will get good understanding of the system, but in the end it comes down to me liking OGRE's design better.

[vgmdev]

But osg is better organized and only use opengl, so less overhead stuff…

[Game_Ender]

I don't have a whole lot of OO experience, from what I know its always a trade off, the more you abstract the easier and faster it is to right code, but the slower the library.

Can you elaborate on the organization and overhead issues? I don't think that Ogre's flexibility in rendering engines provides that much of preformace hit, could someone with more experiencec elaborate?

[stodge]

"the more you abstract the easier and faster it is to right code, but the slower the library."

I don't think this is necessarily true. If it is slower, it's marginally so in general usage and you probably won't notice much. I think the real performance difference depends on the quality of the developers and designers. I think you're spouting a common myth of OO.

[johnhpus]

vgmdev: While the subject is going that way I'd be interested to know in what way you think OSG is better organized than Ogre. I've never used it and I'm not looking to switch but Ogre is the best I've used so when someone else says something else if better, I'd like to know how.

[Game_Ender]

I don't think this is necessarily true. If it is slower, it's marginally so in general usage and you probably won't notice much. I think the real performance difference depends on the quality of the developers and designers. I think you're spouting a common myth of OO.

That is why I prefaced the statement from what I understand. Does anyone have some technical knowledge on this front?

[sinbad]

But osg is better organized and only use opengl, so less overhead stuff…

There is zero overhead to supporting multiple rendersystems; if you only want to support one, drop the other rendersystem plugins. They then contribute nothing to the app. There seems to be a misconception in some circles that somehow supporting only one rendersystem clutters the design less - I'd say the opposite is actually true. Remember that underneath GL and D3D the GPU is identical and performs the exact same operations. GL and D3D are just interfaces / views on that base functionality. Each one has its own design foibles (D3D is generally too coupled to what the manufacturers currently support, GL is cluttered with vendor extensions and just-too-late standardisation processes), and by knowing both of them, you can often pick the best approaches of both, mapping one approach to the other. Often systems that are based on just one directly extrapolate from that underlying API therefore being coloured by it's own assumptions and foibles (I don't know if that applies to OSG since I'm not familiar with it, but it has applied to others).

'Better organised' is subjective so I won't comment on that one.

As for the cost of abstraction, this subject has been discussed at length in comp.lang.c++ many times, search Google Groups if you want the full beef. The bottom line is that virtual function call cost is minimal, and avoiding them in anything but the tightest loops is pretty pointless since the speed you'll gain from doing so will either be negligible, or eaten up by the benefits of inlining or cache usage. You'll find many sweeping generalisations from the 'I never use C++ because it's much slower than C' camp, but they're just the rantings of uneducated fools. There is plenty of evidence to the contrary. Of course nothing is without cost, the point is to not worry about it except in the very, very small amount of code where it actually matters, typically less than 5% of your code. And here, templates can come to your rescue much better than a relapse into the old ways.