-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello,
Robert Osfield wrote: > Hi Jan, > .. > I wonder if it would be possible for use to write some analysis tools > to find out what OSG API's users are using, to try and get some > profile for what parts will be the most problematic to migrate. > Perhaps one can take an evolutional approach. I certainly hope so. Otherwise the migration to OpenGL 3.0 will be a really slow one (or not happen at all). I think that this is not OSG-specific issue, though - if the driver vendors will support one version or the other, but not both on most hardware, there will be a mess - all commercial OpenGL applications need to be supported/migrated too. > This is a real issue, splitting user base can be a killer, with > neither branch having sufficient critical mass to make a successful > project. > > In general I'm trying to consolidate the user base onto > classes/libraries that everybody users so that these classes get more > testing and debugging, and avoid supporting disparate > classes/libraries. For instance CMake is largely about consolidation. > Making it easier for users to track the SVN and dev releases again is > trying to bring more people on to the same version. This is certainly appreciated, even though I didn't have a problem building OSG before CMake (but I am not Windows user :-p) > Evolving OSG 2.x to support GL3 should be possible, the question is > how much will you compromise the use of GL3 in the process, and how > will you complicate management of the project with multiple GL > backends. > > There is another element to throw into the GL mix, and that is support > for OpenGL ES in its various incarnations. Personally, I do not think that OpenGL ES should be the focus. First, it is a moving target. Second, what would be the goal? To run OSG-based applications on a cell phone? Realistically, do you (or anybody) think that it a) makes sense b) is even technically possible? E.g. my new Nokia N95 has accelerated OpenGL ES support. I have three nice 3D games with it. However, if I wanted to develop *anything* for it, I would have to pay a crazy amount of money to Nokia/Symbian to have my applications signed to be even able to run it on the device. And it gets worse - I have bought my phone unbranded and paid in full. If you buy it from an operator with a subscription, very often the phone will not allow installation of anything except what was approved (read bought from) the operator. DRM everywhere ... Again, you as a developer would need to pay through the nose to get through that. Unless you are a big software house, this is not a viable path, IMHO - Symbian has lost plenty of freeware and small-time developers over this recently. Moreover, the hardware (brand new, latest whiz-bang phone, btw) has only a 1GB of flash disk total and a very little RAM available. The CPU is not too powerful neither. I can't imagine what I would need OSG for on this platform. On the other hand, if Nokia pays somebody to do it ... Regarding OGL 3.x - I think that the way to go would be in abstraction. If sufficient amount of detail, such as OpenGL states, is abstracted and packaged in utility classes, the user doesn't have to even notice unless he or she is using OpenGL commands directly somewhere (custom drawables, for example). For example, I have spent the last weekend working on a quake-like console for debugging of my application. I needed to implement text rendering in a better way than current osgText which seems to choke my laptop's graphic card with the deluge of glyph textures on each start (ATI mobile FireGL card, it sucks, I know). I have made a custom node using Cairo and Freetype and basically didn't need to touch "raw" OpenGL except for things such as blending, lighting and depth tests - state management. If this can be packed into classes which will either use fixed functionality if running on OpenGL 2.x platform or some provided default shaders on OpenGL 3.0, great - then my code will work with few changes and I could accommodate it easily. On the other hand, if I will need to rewrite major parts of my code to set the shaders up myself to handle these issues, I am not going to be too happy (or even to bother to port it - my university is paying me for research and teaching, not for coding, unfortunately). > osgProducer is open source, and I'm still merging submissions when > they come in, so if there are fixes required then please just send > them in. Alternatively others could have write permission and handle > this as well, personally this would work well for me as I'm just plain > overloaded. Robert, I wasn't complaining about this - I have migrated my application away from Producer for exactly these reasons and I am not dependent on it anymore. I am glad that you are still willing to maintain it, though. The specific issue I had was something with removal of tablet support in Producer. osgProducer still needs some classes which are missing from Producer that is on the web site. However, I wasn't able to access Producer's CVS to see what exactly was done and why (it was reporting a repository error :( ) or whether this was only temporary breakage, so I do not have a patch at the moment. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGwhW0n11XseNj94gRAvDiAKDs+GDd4kpSquq9JsrWOJ3f21zpEACeJu/j oLrp58YVhnNQZUmuG0vyeZM= =E/KN -----END PGP SIGNATURE----- _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
