Hi Jan, J-S et. al,<br><br><div class="gmail_quote">On Mon, Mar 23, 2009 at 6:32 PM, Jan Ciger <span dir="ltr"><<a href="mailto:jan.ciger@gmail.com">jan.ciger@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Honestly, I think this will be counterproductive. It will only give<br>
companies an excuse to neglect OpenGL support further or to drop it<br>
completely ("You can use the emulation!"). The latter would be<br>
disastrous for all non-Microsoft platforms.</blockquote><div><br>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.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I fail to see the benefits of such move - why to run OpenGL on top of<br>
Direct3D? Is there *any* usable hardware that has only D3D drivers and<br>
does not support OpenGL? Not to mention that you will be chasing moving<br>
targets - both D3D and the GPU APIs.<br>
</blockquote><div><br>I see there are three reasons to investigate the OpenGL subset -> D3D mapping:<br><br>  1) Trying to convince a 3rd party company to put money into OpenGL driver development is not easy,<br>      and if successful the results might well be patchy and take some time to come in effect.  Having a <br>
      OpenGL subset -> D3D wrapper could help those that need a solution right now.<br><br>  2) Porting to XBox + XBox 360, thereby making it possible to port OSG applications to these consoles<br>      without major retooling of the OSG app or OSG itself.<br>
 <br>  3) Takes the pressure off the OSG itself having to support D3D, so the bulk of the OSG devs and <br>      community can remain focused on the OpenGL family of API's.<br><br>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.<br>
<br>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.<br>
<br>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.<br>
<br>Robert.<br><br></div></div><br>