Hi Jan, J-S et. al,
On Mon, Mar 23, 2009 at 6:32 PM, Jan Ciger <jan.ci...@gmail.com> wrote:
> Honestly, I think this will be counterproductive. It will only give
> companies an excuse to neglect OpenGL support further or to drop it
> completely ("You can use the emulation!"). The latter would be
> disastrous for all non-Microsoft platforms.
I do think this is a factor, our first interest should be in getting 1st
class support for OpenGL drivers across all hardware on all OS's. Even if
there is a viable OpenGL -> D3D wrapper we shouldn't rest on putting
pressure on the hardware vendors to write better drivers.
> I fail to see the benefits of such move - why to run OpenGL on top of
> Direct3D? Is there *any* usable hardware that has only D3D drivers and
> does not support OpenGL? Not to mention that you will be chasing moving
> targets - both D3D and the GPU APIs.
>
I see there are three reasons to investigate the OpenGL subset -> D3D
mapping:
1) Trying to convince a 3rd party company to put money into OpenGL driver
development is not easy,
and if successful the results might well be patchy and take some time
to come in effect. Having a
OpenGL subset -> D3D wrapper could help those that need a solution
right now.
2) Porting to XBox + XBox 360, thereby making it possible to port OSG
applications to these consoles
without major retooling of the OSG app or OSG itself.
3) Takes the pressure off the OSG itself having to support D3D, so the
bulk of the OSG devs and
community can remain focused on the OpenGL family of API's.
Big questions for us will be how pratical is to to take over maintenance of
GLDirect. GLDirect being dormant right now suggests that it's not enough of
an itch to enough people to keep it alive. Is it because GLDirect was never
good enough/badly architected? Is it because developers just caved in an
wrote to D3D directly? Or is because developed just found that OpenGL
worked well enough anyway? It would be interesting finding out the
history and the dynamics of the library and it's code base so that those
thinking about contributing can avoid making the same mistakes.
At this stage I guess it would be worth a few hardy souls checking out the
code base and doing a test to see what GLDirect is capable of and the state
of the code base. Quick checks like how much code is it, can it be easily
built would be worth doing as well.
One thing we can possible help out on the OSG side would be to consider
making a profile in OSG-3.0 that provides a subset of OpenGL that simplifies
the task of implementing and mataining GLDirect. For instance if we have
seperate rendering backends (profiles) for OpenGL 1.x, OpenGL 2.x, OpenGL
3.x and OpenGL-ES, then a OpenGL 1.x or OpenGL 2.x subset might be easy to
introduce.
Robert.
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
