I'm writing a second email on slightly different tack, as the one I've
just written covered the anti-trust/support for OpenGL aspect, this
one I'll do a what if tack that looks at practicalities.
With looking at any new feature one has to weigh up the costs vs
benefits, considering Direct3D support is no different.
A) Benefits of introducing DIrect3D.
1) Marketing value of providing support for API that some end users
see as important.
2) Access to better drivers where OpenGL drivers are poorly
featured or implemented.
3) Access to XBOX / XBOX 360
4) Possible growth in community due to attracting those who are
convinced by the marketing on
Direct3D value.
B) Costs of introducing Direct3D.
1) Core scene graph API must be converted to across to an API
agnositic interface, this would break
backwards compatibility.
2) Implementations of HAL API's (OpenGL/Direct3D/OpenGL ES etc)
would have to be decoupled from
scene graph.
3) Developer time in designing, implementation and debugging new
infrastructure.
4) Ongoing Developer time in maintenance and development once
infrastructure is implemented.
5) Division of labour - rather than everyone using and testing
OpenGL, the community gets split
over multiple profiles. If you labour gets split too much then
quality will go down, and forward
progress would falter.
6) Testing matrix goes up significantly as you now have multiple
paths to tests, so the testing load
goes up and the number of combinations of failures goes us.
Cost of doing releases would go
up and the risk of regressions not being spotted also goes up.
7) Risk of undermining support for OpenGL within software and
hardware vendors.
8) Risk of culture clash and increased community friction.
OpenGL/OpenGL ES centric developers
in general will be relatively platform agnostic and value
portability, Direct3D centric developers
will care about Windows and unlikely to be bothered by
regressions in portability or OpenGL support.
Now in the context of OpenGL/OpenGL3.0/OpenGL ES discussions about the
costs of B.1 to B.6 are something that we will have to consider, so
the cost of adding Direct3D into the mix is potentially lower, however
there is still a significant cost that can't be hidden by the other
work. There is no doubt that a larger active development community
and would be required, and managing this bring extra strain on the
project, keeping the community cohesive would be priority. Even a
couple of years of cash injection to fund this effort wouldn't elevate
the ongoing project costs of maintaining ports - one would have to
mark sure that a larger and still cohesive community is able to pick
up when specific dev funding peters out.
At this point in time, I believe the cost vs benefits of supporting
OpenGL ES exceeds that of OpenGL 3.0, given that we'd be able port
existing OSG applications to new devices/platforms, and we'd pull in a
new breed of application developer into the community. OpenGL 3.0
doesn't offer any new platforms, applications types or community,
rather it's just a continuation of how we refine the scene graph to
better handle modern hardware. These refinements are just as relevant
to OpenGL 2.0 as well, so I think port to OpenGL 3.0 is possibly a bit
mis-leading as a goal in itself, rather it would fall out of a goal to
refine the scene graph for hardware programability, and a goal to
support OpenGL + OpenGL ES + OpenGL 3.0.
The strategy I feel we should take is to look at refactoring the core
API so that it is more HAL API agnostic, but retain the OpenGL/OSG
language conventions where possible, also at the same time look at
making the state management far more flexible and better suited for
handling shader only implementations. This work would then give us
the ability to do OpenGL 2.x, OpenGL 3.x, OpenGL ES and OpenCL. There
are costs involved in this, and dangers in running the community too
thin if we can't introduce enough new blood, and keep on board enough
of the existing community that are OSG-2.x based.
Once we are in the position of having a re-factored core scene graph,
and with the infrastructure to do multiple rendering back-ends, the
costs of a introducing and maintaining a Direct3D profile will be
lower. Whether the benefits would outweigh the costs at this point is
still hard to say. The benefits aren't likely to go up over time,
rather with a faltering MS and it's competitors getting significantly
stronger time is likely to diminish the benefits of Direct3D support.
A successful campaign in support of the OpenGL family, and better
support for OpenGL drivers would also diminish the value of Direct3D
support. If we got the technical issues with OpenGL dirvers sorted
out, and we got the value of OpenGL out to the application buyers then
pressure for such a port would be diminished. This isn't entirely
under our control. What is under our control is getting the message
our, and putting pressure on the hardware vendors that don't yet
support OpenGL well enough.
If we achieve this then the only value proposition for a Direct3D port
would be XBox and XBox360 support. This takes us in the context of
more general console ports. Which ones do we target and which ones
first? Wiii? Playstation2/3? XBox/XBox360? New consoles in
development?
Another take completely to take would be to look for, instigate, and
project that converts OpenGL calls to Direct3D ones. Such projects
have existed in the past, but none I know of are in wide use. One
could possible make things easier be selecting just portions of OpenGL
to expose, perhaps by us providing OpenGL profiles that make it easy
to do such an API mapping. Such a OpenGL subset -> Direct3D project
would be of wider value than just to the OSG community so one could
spread the costs of development and ongoing support.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
