On 11/4/06, c sklu <[EMAIL PROTECTED]> wrote:
Ahh, I understand what you were saying, if only StateSets and Drawables contained OpenGL commands....
Pretty well all OpenGL stata is managed in osg::StateAttribute subclasses, and all primitive drawing in osg::Geometry. Having OpenGL ES versions of this would not be dififcult to implement, one wouldn't need a extra layer of abstraction like Ogre3D has. IMHO, the key to the OSG's extensibility is not having this extra layer of abstraction, there is a 1:1 mapping to OpenGL, adding new state just means adding an extra StateAttribute and often nothing else needs changing at all, its all located in just that extra class. This also helps keep the footprint down and performance up. The biggest problem is likely to fixed math profile OpenGL ES version, as the OSG uses floats all of the place. If you can target the float path then this isn't so much of problem. The next challange is memory footprint. One might have to be quite aggressive in culling parts of the OSG API, static linking would certainly help do this. Templates would also be something you'd have to look closely at. Perhaps compilers tuned for memory could help cope with this. Art path routes would also be something that would need exploring - since the standard OSG plugins map to standard Node, StateAttribute and Drawables, perhaps a custom converter could be employed. I'm up for porting the OSG to OpenGL ES, but would need a comerical project to fund my efforts on it, as I can't afford to run off an do this stuff just for fun, but fun it'd be. Perhaps members of the community could take on the task. Long term I think that a revamped and slimed down "OSG like" scene graph API would be the ideal platform, such as what I wrote about in the Siggraph 2006 presentation. Like OpenGL 3.0 this is quite a way off though. As for Direct3D, nope, that would be a killer for the OSG's. For starters OpenGL is a hardware abstraction layer (HAL). To support Direct3D and OpenGL you'd need to add a HAL abstraction layer, then scene graph would sit ontop of the HAL abstractation layer - a Hardware Abstraction Layer Abstraction Layer. Now you'd need various implementations under this HALAL, you need a Direct3D 7.0, Direct3D 8.0, Direct3D 9.0, Direct3D 10.0, and OpenGL, and OpenGL ES, ok that 6 combinations of backends to support, so rather than an nice 1:1 mapping, you have a 1:6 mapping, if you are wanting to control what happens down on the hardware in you scene graph you'll need to start hardwiring specific paths to specifc backends. It will start to get messy over time. Also developing and maintaining all these backends really forces up the testing matrix you need to have, this will make making releases more a hassel. You'll also spread all your developer resources between all these combinations. Next up is the performance hit of having a HALAL, it won't be freem, the bigger your database the more CPU bound you will mean, and the greater the extra hit of the HALAL will be. Finally extensibility, if you want support new OpenGL extension then you'll need implement the extension itself, then extend the HAHAL too, so that doubling the amount of work, and then you need to think about the implementations for the other pathways. The extensions to the HALAL also require the core API to be modified, so you can't just do it on you local version, you have to dig into the core source code. Consider how osgGL2 was developed - it existed extirely independantly from the core OSG, the same applies to osgNV. A HALAL would force these extensions to be part of the core right away. So software engineering wise it is a very bad solution. In terms of portability what does it buy you? Xbox is the only platform I can think of. If you are stuck with only decent Direct3D support then perhaps a wrapper mapping OpenGL to Direct3D is a work around. This pushes the HALAL into a layer that is entirely indepdent of the OSG, and doesn't require any compromise in the software engineering of the scene graph. Yes there will be a performance hit, but then the HALAL itself has a performance hit, its really just where do you pay for that hit? Such a HALAL is also portable between high level API's so not only OSG would benefit. The advantage of going this route would be that you only pay for the HALAL hit if you don't have decent OpenGL available, everywhere else keeps the clean and fast 1:1 mapping for maximum performance. Robert. Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
