Jan Ciger wrote: > -----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 > > -- Robert Penn Taylor Graduate Research Assistant Department of Mechanical Engineering Iowa State University (515) 294-5311 _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
