Hi Robert, hi all, Well, so in that case I agree we should support OpenGL+ES+CL in OSG 3+. About topics/actions you mentioned...
> 1) Campaign individually and as group publicly support of OpenGL > and it's promote its benefits. > 2) Publicly put pressure on the hardware vendors to better support > OpenGL w.r.t driver quality and features. I suggest we create a "Communication/advertising" section on the wiki. Here are some ideas to fill in the pages of this section: - Articles on OpenGL and OSG (so that we link our personnal websites/blogs to them). Official OSG blog could have links and/or copies to/of them. - Campains, logo and various advertising materials (ditto) - Copy of letters we would have sent to to vendors + list of vendors to contact. - Presentations - etc. And we may discuss as usual on the mailing list (or on a "osg-communication" specific list?). > 3) Work with hardware vendors on a suite of unit tests that can > test the range of OpenGL features. > 4) Come up with compelling benchmarking suite that shows off OSG/OpenGL. I have no strong ideas about this. Could we start by using current examples, and creating benchmark-examples? > 5) Coordinating between us on best practices to sell OpenGL to > skeptical clients. This may go with 1+2 on the "advertising" section. > 6) Investigate the possibility of using OpenGL subset -> Direct3D layer. Yes. However, I guess such a layer would have much delay (between new features in APIs, and the reflection of such features in the layer)... Should we start a thread about 1+2+5? May we use a tag (that Art would add to the forum), such as "[Com]" or "[Adv]"? Any idea about precise subjects? Any more ideas about things to put on the wiki? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 26 Feb 2009 10:41:37 +0100, Robert Osfield <[email protected]> a écrit: > Hi Sukender, > > On Thu, Feb 26, 2009 at 12:15 AM, Sukender <[email protected]> wrote: >> Okay, so admitting we're dropping D3D... > > Well it's hard to drop something that you have picked up yet :-) > > In terms of making a D3D backend a goal, as mentioned in my earlier > post this has some pros, and lots of cons/risks for the project. > Given we are already talking about taking on a risk API refactoring > over the next couple of years I'd suggest we should keep conservative > and avoid taking on further extra risks/loads. > > If the API refactoring targeting API's already close to use goes well > then one could consider taking further steps w.r.t rendering alternate > back ends. Waiting a year or two more will also see some wider > market trends work themselves out, there is a chance that D3D will > actually be less compelling even under Windows. If we do a good job > on helping the hardware vendors properly support OpenGL with robust > and feature rich drivers then this will change the landscape as well. > > As an interim solution the OpenGL subset -> Direct3D is something that > could be investigated independent of other OSG efforts in coping with > new API's. Such an approach could work with the existing OSG as well > as future revs. Such a solution might also buy us more time. > >>Will the problem be similar for OpenGL-ES/OpenCL (I mean raytracing and such >>for OpenCL)? This is not ironic: I don't know much about these. But I wonder >>if we would have the same "abstraction" problem with them. I was thinking >>that if OSG 3 would support these, then why not others (such as D3D)... >>However, if they're quite close to OpenGL, then yes, the situation is >>different. We thus could think about OSG not as "API agnostic", but as >>"Khronos API agnostic" or such. >> Thoughts? > > The Khronos API's are all part of family which means language and > concepts as well as API style, and end user culture all fit in well > together. This includes similarities in GLSL implementations, method > naming, coordinate system conventions (for instance where 0,0 is on a > viewport or a texture). This should mark it easier to port/support to > OpenGL ES, OpenGL 3.0, and OpenCL in addition to OpenGL 1.x + 2.x. > This are the soft targets for us - being Khronos API agnostic would > certainly be a smaller step than being abstracting totally from the > HAL API. Smaller steps are less risky, and in the case of OpenGL ES > and OpenCL the benefits of opening out new platforms and new ways of > working are very significant - far more significant than any D3D port > would ever provide. Less risk, greater benefits, pretty easy decision > really :-) > > This doesn't mean we should look at trying to resolve some of the > pressures to support D3D that some existing OSG are seeing. For this > I'd see a three pronged approach as being helpful : > > 1) Campaign individually and as group publicly support of OpenGL > and it's promote its benefits. > 2) Publicly put pressure on the hardware vendors to better support > OpenGL w.r.t driver quality and features. > 3) Work with hardware vendors on a suite of unit tests that can > test the range of OpenGL features. > 4) Come up with compelling benchmarking suite that shows off OSG/OpenGL. > 5) Coordinating between us on best practices to sell OpenGL to > skeptical clients. > 6) Investigate the possibility of using OpenGL subset -> Direct3D layer. > > 1+2 are related, so it would be good to coordinate this, the carrot > and stick. Could we start up working group within this community to > spear head this? Is this effort works well then we'll get better > quality drivers and the visibility of widespread support will help > convince those won over my MS marketing that D3D is not necessary or > compelling. > > 3+4 are also related - they are engineering responses to the ongoing > problem of driver quality and getting the OSG used actively as a tool > for testing and benchmarking. Again a working group without the > community could be formed to look at this. Perhaps we might even be > able to get funding from Khronos and other bodies to undertake some of > this effort. > > 5 is just us talking really, but it's not a topic that we often chat > about. Perhaps putting up some pages on the wiki would help > coordinate final conclusions. > > 6 is a quite different take, again it's an engineering solution. A > 3rd party lib to do this would be least work for us, ideally an open > source one. Does anyone know of something like this? > > So... over to your guys, volunteers, suggestions? > > Robert. > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
