Re: [osg-users] OpenGL NG: thoughts?
I think a key issue with OpenGL 3 was that it implemented Cool New Stuff, but froze out people from integrating that with the code they'd already written. OpenGL NG seems to be about just more efficient access to and control of the same old stuff. If there is any new stuff, then for a while, I expect they will continue to include it in minor revisions of OpenGL 4. Mirroring this policy in OpenSceneGraph and a new successor seems to be the sensible approach. As regards the existing device/OS-specific APIs, I'd expect AMD to sideline their API in favour of both DirectX 12 and OpenGL NG, and Apple to take up NS as a standard alternative to Metal, too. Microsoft? I'm sure they'll keep on with DirectX, but they caved on WebGL in IE the end, so they might be persuaded to let OpenGL ES or NG on to their mobile/console/store platforms, especially if more people are going to just use ANGLE anyway. Alistair Baxter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL NG: thoughts?
I like the idea of revamping the OpenGL API. In fact, I liked that idea when it was originally proposed in 2007 as OpenGL 3. Unfortunately, most other developers did not like what Khronos and the ARB put forth in that design. It was not well-received. The final OpenGL v3.0 spec came out a year later with almost no mention of the previous year's promised sweeping API changes. Most hardware vendors found themselves doing a mea culpa, recommitting to the FFP and promising software vendors continued support and backwards compatibility. Will OpenGL NG suffer the same fate? Let's see how it's marketed. They'll have to do something different this time, that's for certain. OpenGL v3.1 subsequently introduced the concepts of compatibility and core profiles. Most of my recent work has been directly with OpenGL v4.x core profile, and I've found it to be an amazingly flexible and powerful API. I like the idea that I'm writing code for a state-of-the-art API and not depending on deprecated functionality. But apparently this was a false sense of security for me. Little is known about OpenGL NG at this time, but one thing is almost certain: It will bear little resemblance to OpenGL core profile. So, while I thought I was writing state-of-the-art code, and was telling my clients it was the right thing to do for a long-term investment, it now appears that OpenGL NG is going to invalidate that. I've been in the 3D graphics industry for almost 30 years and I've seen APIs come and go. If you would've told me back in 1994 that I'd still be working with OpenGL today, I would've laughed in your face. OpenGL FFP has had an unprecedented run -- testimony to a great API. But there are new kids in charge now, and they want to take OpenGL in a new direction, to make it a better fir for today's chips, systems, and programming use cases. Thus, my first point: Change is going to happen. OpenGL has been very stable, but maintaining that stability forever would probably be harmful to the API in the long run. As developers, we like stability. But we also jump on new technologies as they come out. OpenGL NG? Some of us will like it, some of us won't. Secondly: Note that OpenGL NG is just vaporware at this point. The announcement mentions several other new APIs that have been recently become available. In my career, I have seen a lot of marketing FUD. I don't know whether OpenGL NG will ever be a reality or not, but right now it smells a little like FUD, dangling the promise of a shiny new redesigned OpenGL API in front of any OpenGL developers considering jumping ship to another API. Third, and finally. I'm tired of the OpenGL versus DirectX debate. I am so tired of it. If Khronos feels it needs to churn out an OpenGL NG solely for the purposes of competing with DirectX, then that is a sad statement. OpenGL's evolution should not be driven by team mentality. I hate what Microsoft has done to try to kill OpenGL. Every time I start a new OpenGL-based project that must be cross-platform, I have to re-evaluate which one of the crappy GLEW-like kludges I'm going to use to get the code running on Windows. Has anyone from Khronos approached Microsoft regarding a single unified API? I doubt it. Remember Fahrenheit, yeah, yeah. But I have to wonder if Microsoft is also getting tired of this particular API war. They are in an especially vulnerable spot now, given the prevalence of OpenGL on embedded devices, and their recent disastrous Windows 8. They might see some benefit to contributing to OpenGL, rather than continue to fight it. This is not the first time I've publicly stated that Khronos/ARB and Microsoft should work together. It benefits us, and it benefits them. Call me an idealist. If you've read this far, then you've indulged me much further than I deserve. Go back to work. :-) On Mon, Aug 11, 2014 at 5:13 PM, Ethan Fahy ethanf...@gmail.com wrote: OpenGL NG was announced today and is a complete API break. It's not clear what the timeframe is on this project, but it does seem like a big deal long-term with major implications for OSG. I'd be curious to hear any opinions on this development from the OSG community. http://www.anandtech.com/show/8363/khronos-announces-next-generation-opengl-initiative -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=60633#60633 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL NG: thoughts?
Hi Ethan, Paul, et. al. Having been around OpenGL for a long time and seen various claims of revamp come and go I'm inclined to like wait and see what happens. The only certainty will be that it'd be yet another API that hardware and software vendors will need to support. It only really helps if it can replace other existing or proposed API's, what we want is less API's for hardware and software vendors to work on so we can all concentrate on making what we have perform well and work reliably. In terms of replacing other new/proposed API's it'd need to replace MS's Direct3D 12, AMD's Mantel and Apple's Metal in terms of the hardware vendors focus. Unfortunately MS, AMD and Apple all have their own agendas and ego's so it's unlikely they'd just drop their own efforts on concentrate on OpennGL NG. This really means it'll be market forces that will need to force their hand, i.e. the software vendor world needs to tell MS, AMD and Apple no thanks, please just concentrate on OpenGL as we aren't going to code for your API. With OpenGL NG being just vapour-ware right now it's kinda unlikely that we'll see any real movement away from this competing for mid-share API's. For OpenGL NG to work well it also needs to be back-ported to old OS's, NVidia's recent promo on OpenGL 4.5 and Windows XP support gives me a little encouragement in this direction, as I it sounds like OpenGL NG might also fit in this role. Having one OpenGL API across mobile and desktop just makes sense for everyone, hardware vendors and software developers, but the difficulty initially will be that vendors will need to maintain multiple driver teams for a good deal longer. Perhaps if adapter libraries could be written that do OpenGL NG to ES drivers and OpenGL ES to NG drivers would help, a bit like what ANGLE is doing right now for GLES - Direct3D. Making an open source reference implementation of OpenGL NG would also be something that would be useful. The planned conformance suite is something that could easily fit into this open source framework. -- What it means for the OSG and users of the OSG is not something we can make judgements on right now. If the new library is major break from OpenGL and ES in design then it may be an awkard fit for the OSG design, so just adding into the GL, ES mix would not be easy or elegant to achieve. Personally I'd love to be able to write a new clean scene graph API in modern C++ an fully portable OpenGL NG library without need for lots of platform specific code. The OSG itself has traditionally retained a significant level of backwards compatibility so just like OpenGL itself - the consequence is an API is bigger and more complex that a clean slate scene graph would be. Just like in OpenGL to OpenGL NG, one could also envisage an OSG NG, however, it's essentially a new project, the old OSG would still need to live on for a good deal longer simple because it's needed. Last year I started talking a little about a new scene graph project to follow on from the OSG, I labelled it LSG (Lightweight Scene Graph) for want of better name, and I've continued to think about it over the last year but haven't done any coding on it. I was thinking of LSG separating the scene graph nodes from the graphics implementation in a way that would allow multiple graphics implementations - so an OpenGL backend, and separate OpenGL ES backend etc. OpenGL NG could make the need for multiple backends mute, which would simply development, but unless OpenGL NG was quickly rolled out across all platforms, including old ones like XP, old versions of Android etc., it would heavily limit LSG's use. Another aspect to the LSG development is that I was looking at ways that one could utilize LSG objects and rendering from within an existing OSG application. A OSG adapter node could enable a LSG scene graph to be added to an OSG application and have the LSG take over rendering. This approach would enable one to retain existing OSG application code and move across to LSG in a piece wise fashion rather than having to throw out the all the OSG specific code in your application. I don't know how seamlessly it could be made to work, but if you have developers in both camps then it'd be much easier to make it work. If I were to spearhead an LSG effort I'd obviously want to make sure it's leveraged as much as it can from the OSG community and code base. All the OSG's viewer and loaders you could potentially leveraged if one had an OSG adapter node written very early in the projects inception. If this integration is their from the start then maintaining it long term becomes much easier. Perhaps one could envisage the OSG development slowing to become a maintenance model, primarily adapting for platform changes rather than new core features, and then focus new development work on the LSG. Such a model might see the last OSG release being finally tagged in a decade or two's time... I suspect just like fixed function pipeline
Re: [osg-users] OpenGL NG: thoughts?
I will merely throw in secondary comments because Paul and Robert have said many of the major points. I welcome our new direct-state overlords. I think OpenGL NG could be a great idea. Apple and AMD have clearly seen the light with their own Mantle and Metal efforts and Microsoft has been pushing this way with DX12. But they are likely to suffer NIH-syndrome because no competitor wants to sign on to an API that their opponent controls completely (cf CUDA, DirectX, etc). I too, am wary of past failures like Fahrenheit and the original OpenGL 3. But recent events (these new APIs, the change in market share to OpenGL ES devices) have changed a lot of the landscape. Perhaps today they can succeed where they failed in the past, if properly supported. I suspect Microsoft might even have a teeny bit of interest in it, but they are so internally conflicted that who knows. The fact that they are shipping Office for iPad is a sea change over there and Satya Nadella could be the difference. Robert, what you describe as LSG sounds VERY much like the JAG project Paul has been working on for a couple of years. Right down to the using OSG as a transitional loader. JAG currently works pretty nicely with OpenGL 4 and OpenGL ES, leaving out support for legacy/FFP features and leveraging mature modern library dependencies (BOOST, POCO, GL3W, GMTL). I can't comment on how JAG's current architecture might map to a NG API, especially since we have no idea what that API might be. But I think it's probably adaptable to it somehow, and is a good base to work from in the future. I am actually excited about the future potential of the OpenGL NG API. I hope it goes good places and I'm looking forward to going there with it. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
