Simon Su wrote:
Hello All,
Hi, Simon, I remember you from the Performer list :-)
We have a rather complex graphics application (about 100,000 lines of code) developed on Performer that we need to port to openscenegraph. What do you think, in the ballpark, the effort will be in man month for someone with mid level experience with openscenegraph and performer? The application worked on multipipes system (ie SGI's prism systems).
I just finished a port of a moderately-sized Performer app (about 25k lines). It's not as large as yours, but it was fairly complex and it was old (from the IRIX/IrisGL/Performer 2.0 days), so that added a bit of complexity. It took me about three-four weeks. I'd rate my experience with both scene graphs as "extensive", so it might take someone with "mild" experience a bit longer.
In most cases, OSG maps to Performer pretty directly. There are differences, but they're usually not difficult to handle. Overall, I think OSG is more flexible than Performer. For example, you can put state anywhere in the scene, not just at the leaves. You might run into a case or two where Performer does something that OSG doesn't do. These are what can take the most time. pfEarthSky is the most obvious example of this. If you want a Performer-like earth/sky model, you'll have to use an external nodekit (like osgEphemeris), or you'll have to write it yourself.
One other thing to consider is dealing with geometry. If your app uses pfGeoSets with indexed attribute lists, it would be a good idea to de-index the lists. Modern graphics cards don't handle indexed attribute lists very well (they'll run really slowly). You mentioned that you were using a Prism, though, so hopefully your app already uses pfGeoArrays, which don't use indexed attribute lists.
One possible concern would be, a question on the architecture. Performer has a concept of separate "APP" and "DRAW" processes. In a multi-processing environment these are separate processes. And Performer takes care of multi-processing and multi-piping. How is this handled in openscenegraph?
Instead of multiple processes, OSG uses multiple threads. There are several threading models to choose from (similar to Performer's options for splitting the processes, but not exactly the same).
The threads are set up by whichever Viewer class you choose. The Viewer classes also help you deal with multiple displays. You'll either pick Viewer (a single viewpoint on a single scene, possibly with multiple cameras/displays slaved to the master viewpoint), or CompositeViewer (multiple viewpoints and/or multiple scenes).
Another possible challenge is memory management. Performer puts everything into shared memory, where multiple processes can access stuff. Is this handled the same in openscenegraph? or this is handled transparently?
As mentioned above, OSG uses threads instead of processes. Typically with Performer, you'll have a per-channel shared memory structure that you pass with pfPassChanData() or whatever. When you port, you can still use that structure to keep it simple. You don't need to call anything special to share it because your memory space is already shared between threads. You might need to protect it with a mutex, though, depending on how you use or access the data.
There are both c and c++ interfaces to Performer. The software package we want to port uses the c interface, as one of the required external module is in C. I am assuming this will not be an issue?
I'm not sure what you're asking here. OSG is C++ only, so you'll have to port the C Performer code to C++ OSG code.
Hope this helps. If you have any more questions, let me know. --"J"
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
