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
