Unified and Khronos guided Opengl Development strategy tools humbly requested.

Dear Admins,
Please do not roll your eyes about the upcomming post, coz i know these questions have been asked a million times before, but after many years of absense in coding opengl, i have to realize, that nothing has done to boost up the Opengl Community with new people because of the still existing very high barrier to get opengl running.
I would like to humbly ask you to discuss this within the Khronos community to find capable people to finally build us (newbies, Starters, etc.) a unified OpenGL IDE Suite.
Now in the year 2015, there is a huge bunch of additional libraries of various origin but no common srategy.

What i would like to see is Khronos is taken over Guidance and Parentship over these various libraries: glut, glew, glfw, glu, gl. like the Apache is doing with its Foundation and / Incubator.
Get the Graphics card venders into your boat as well.

So the upcomming IDE should be ONE package and must include in its Installer:

  • Check the newest gl libraries and include them correctly
  • Include and configure the GCC, gcc+ for a start
  • Compare them with the Repository, Khronos will have for these gl libraries
  • Make a Sanity check of found gl libraries, missing ones, etc. about version, location, vendor
  • Include Language Support for the big ones: C, C++, Java, Pascal, etc.
  • Include a GLSL Editor
  • Include a GL Debugger
  • Include ALL Demos of the Redbook
  • Include ALL Demos of the current OpenGL Programming Guide
  • Make Ready to Run OpenGL Demos to test the installation
  • Create CodeHighlighting (Like Jogl) in that IDE and make clickable references to the explanation of each gl command.
  • Create OpenGL Projects, GLSL Projects, WEbGL Projects etc in that IDE

The great People who develped the OpenGL Pack for Netbeans were on the right path but they stopped unfortunately.
Please remove all these obsticles from the Beginners (FINDING the correct Gl libraries for their OS, find an IDE which doesn’t suck, setup and configure the ide to run opengl code without studying astrophysics or the klingon language, etc.)

Again, its 2015, now we have an upcomming OpenGL 4.5 but we still don’t have a proper Set of OpenGL Software Development Suites. Imagine the Boost of the entire Opengl community, when newbies can run the installer and can - out of the box - run their first openGl demo with a current OpenGL Version.

We should finally combine the technical aspect of the Infrastructure and the underlaying libraries with the Fun of Coding Opengl in C or C++ or Java etc.
Gosh, even if you make it as a package to buy, people would buy it. I know, i’m not alone in this request. Again, please do not turn this down with the usual answers (not an ide, its a library, etc.) I think its time to take on this endeaveur.

Thank you,
Best Regards,
Normen

Hello Normen,

yes it’s a shame there is not even a SDK, something that works out of the Box for all major languages and platforms with a huge collection of examples.
I played around with Immediate Mode and very basic OpenGL about 15 years ago. A few month ago i decided to learn modern OpenGL and it was not easy to get in even with a lot of programming experience in general and at least a little knowledge from old days OpenGL.

The situation of learning material is as bad as years ago. I don’t think the Programming Guide and the Superbible are understandable for beginners, it must be frustrating as hell for a young coder who want to dive into graphics programming with all that bad books and a lack of a SDK. If i were a total noob i would’ve probably stoped learning OpenGL very fast again.

OpenGL is good, it’s fun to code with, but the learning curve is extraordinary high (especially without immediate mode) what is probably a reason that a lot of beginners chose DirectX instead.
Khronos desperately needs to fix this situation with OpenGL NG. It’s just a lazy excuse that OpenGL is nothing more than an API and standard.

Khronos develops specifications, not software.

In any case, an “OpenGL IDE” is a dumb idea. Software which uses OpenGL isn’t fundamentally different from software which doesn’t. A developer’s choice of development environment will be determined by many factors, but whether or not the project uses OpenGL is unlikely to be one of them. People who use Visual Studio for developing software which doesn’t use OpenGL will use it for software which does. Likewise for Xcode, Code::Blocks, Emacs+Makefiles, and so on.

[QUOTE=elnormeo;1264349]…after many years of absense in coding opengl, i have to realize, that nothing has done to boost up the Opengl Community with new people because of the still existing very high barrier to get opengl running.
I would like to humbly ask you to discuss this within the Khronos community to find capable people to finally build us (newbies, Starters, etc.) a unified OpenGL IDE Suite.
[/QUOTE]
And you think a magic, pre-packaged IDE is a good solution? That’s one of the things I absolutely hated in electronics engineering. Almost every microcontroller vendor seems to think like that.
“You want to use our product? Here you have a fancy proprietary IDE to work with. Actually it comes with a pre-compiled Windows(R) only patched up GNU toolchain, but we don’t want you to
work with our GCC/binutils patches directly, because that’s magic you don’t understand. Oh, you are already using $IDE for software development? Screw that, you’re using this now.”

Who are the people that need a fancy-clicky-IDE for using a certain API? People who barely understand the programming language they are using, have no idea what the
compiler and linker do or how they work together, and have no interest whatsoever to read up on the subject. “You started learning $LANGUAGE and decided that writing
your own operating system is too much work, so you want to write a 3D game now? Here you go!”. Those people are certainly gonna be an enrichment for this community.

It’s simple: OpenGL(R) is an API standard; install the hardware drivers that implement it; the API declaration is in that header; link against this library; some stuff is OS specifiy,
if you don’t want to deal with it, there are those libraries that wrap it up.
Premise: You understand the programming language you are using, you roughly know how libraries work, basically, you know what you are doing.

Does Direct3D come with its own IDE?

AFAIK, some IDEs like Code::Blocks actually have a “create OpenGL(R) demo project” setting.

OpenGL(R) is an effort to create an API standard no more and no less. OpenGL(R) is nothing like the GNU project. Khronos is not the FSF or the Apache Foundation. Something like that
would be way beyond the scope of a standards body.

Libraries like freeglut, glew, glfw are developed by independend third party groups, who have no affiliation whatsoever with Khronos and developed the libaries in their spare time. There is no
grand strategy, because they are completely independend and don’t have central management.

Besides, how do you imagine this to work? Should the Khronos group walk up to the GLFW developers and say “this is our stuff now, you do what we tell you to”? Even if the developers of all
those packages agreed to become part of the Khronos group somehow and develop their software after a certain master plan. There’s no way explaining why exactely those projects should
be put in such a position, while there are lots of others out there that can load OpenGL(R) functions, or create a context.

What you describe sounds like something the Eclipse people could do, or anyone so inclined, but is way beyond the scope of a standards body.

As I already mentioned, it is fairly easy, given that you know what you are doing.

Realtime 3D computer graphics is a very narrow field of software engineering. If you know the basics of software development, getting an OpenGL(R) sample to compile and run is simply
a google query away. Setting up your existing development environment is easier that using a magic black-box installer that comes with it’s own fancy clicky IDE.

If somebody does not understand the programming language they are using, has no idea of software design/software development, doesn’t know anything about even basic linear algebra,
a magic black-box installer with a fancy-clicky IDE, loaded with sample programs and libraries won’t help you understand a thing either. It would get people started compiling OpenGL(R)
code fast, alright, but you still have to know what you are doing to get anywhere.

What we really need is more tutorials and teaching material. The more the better.

I’ll ignore the merits of this suggestion (other people have covered those quite well) and instead talk about a few factual issues with it.

What i would like to see is Khronos is taken over Guidance and Parentship over these various libraries: glut, glew, glfw, glu, gl. like the Apache is doing with its Foundation and / Incubator.
Get the Graphics card venders into your boat as well.

GLUT and GLFW both do the same thing. So appropriating the development of both would serve no purpose.

So the upcomming IDE should be ONE package and must include in its Installer:

What you are describing would more be accurately called an SDK (Software Development Kit), not an IDE (Integrated Development Environment). The Khronos group claims to have an OpenGL SDK in existence already. I’ll leave it to you to decide whether or not their claims have any basis in reality.

  • Include Language Support for the big ones: C, C++, Java, Pascal, etc.

There is no reasonable definition of “the big ones” for which “Pascal” would be a member. Unless you’re suggesting that the entire Tiobe top-20 should be supported. Which is rather absurd, considering the difference between those languages.

  • Include ALL Demos of the Redbook
  • Include ALL Demos of the current OpenGL Programming Guide

The Red Book is the OpenGL Programming Guide. Perhaps one of these were intended to be a reference to the Superbible?

  • Create OpenGL Projects, GLSL Projects, WEbGL Projects etc in that IDE

“GLSL Projects”? You might want to investigate GLSL further (or at all). That way, you could discover things like whether GLSL was an appropriate language for a stand-alone project (FYI: it is not).

Also, you should be aware that WebGL requires a web browser that supports WebGL. Unless you’re suggesting that this IDE install one for you, which would be extremely rude, since web browser preference tends to be very tribal and personal.

Then again, so is one’s software development environment, yet you’re suggesting that Khronos install their preferred IDE…

offtopic

[QUOTE=Agent D;1264354]
OpenGL® […] Windows® […] [/QUOTE]
:doh:

Hello,
i want to thank all of you for your current insights on this matter and actually not ripping my head of because of my questions! :wink: Especially Alfonse for the more seniority insights and thoughts about it.
Best,
Normen

As someone having worked on and off as a hobbyist with OpenGL but now getting deeper into it due to development for non-Windows platforms I have to agree with some of the sentiments. That doesn’t mean I agree with the general attitude of the OP as most what he want seems to be targetted at the wrong people.
Here’s a few comments:

I would like to humbly ask you to discuss this within the Khronos community to find capable people to finally build us (newbies, Starters, etc.) a unified OpenGL IDE Suite.
Now in the year 2015, there is a huge bunch of additional libraries of various origin but no common srategy.

No, we do not need an IDE. OpenGL is just a programming API, after all, it should not require special tools to develop software for. As long as it can be used within existing development toolchains it is fine.

What i would like to see is Khronos is taken over Guidance and Parentship over these various libraries: glut, glew, glfw, glu, gl. like the Apache is doing with its Foundation and / Incubator.

No, sorry, that’s not how things work, because these have very different goals. One central maintainer wouldn’t help here, because some of these have to be tightly integrated with the underlying platform (gl), or need to be programmed platform specifically (glut, glfw) or are mostly obsolete (glu).

I agree that some more unified means of getting extension entry points is needed, but this shouldn’t be GLEW which is probably the worst of the existing tools if you want to target more modern OpenGL (I had my fair share of issues with GLEW’s ‘let’s make everything public’ method and switched to an extension manager that allows me to explicitly specify which GL version and which extensions I want to enable, so that accidental use of obsolete features triggers a compile error, not some hour-long bug hunt.

There are good tools for that, unfortunately they are not promoted well, so people always revert to the better known but inferior ones.

Get the Graphics card venders into your boat as well.

I don’t think they’ll go any further as they are already, i.e. developing drivers for their hardware. Which should be ok.

So the upcomming IDE should be ONE package and must include in its Installer:

As I said above: No! Windows users use different versions of Visual Studio, Apple users use XCode, Linux users may use Code::Blocks but often stick to simple makefiles. You’d alienate all these people by forcing a custom IDE that will most likely be inferior to all the present options.

  • Check the newest gl libraries and include them correctly

That’s never going to work. There’s several OpenGL versions so more control is needed, including some THINKING by the developer. You have to make up first which versions of OpenGL to target before you can include the proper libraries/headers.

  • Include and configure the GCC, gcc+ for a start

Outside the Linux world nobody uses GCC anymore so how would that help?

  • Compare them with the Repository, Khronos will have for these gl libraries
  • Make a Sanity check of found gl libraries, missing ones, etc. about version, location, vendor
  • Include Language Support for the big ones: C, C++, Java, Pascal, etc.

That’s not how software development works. You absolutely do not want a third party to decide on its own to change the headers and libraries a project uses. NEVER!!!
About language support, it’s not about supporting languages, but development tools. But last time I checked most of these already come with GL support, as long as the platform supports GL.

  • Include ALL Demos of the Redbook
  • Include ALL Demos of the current OpenGL Programming Guide
  • Make Ready to Run OpenGL Demos to test the installation
  • Create CodeHighlighting (Like Jogl) in that IDE and make clickable references to the explanation of each gl command.
  • Create OpenGL Projects, GLSL Projects, WEbGL Projects etc in that IDE

Ok, here we get to the stuff where things really start to break down.
The most frustrating issue with OpenGL in general is a profound lack of good documentation. Just compare to the extensive docs that come with DirectX and it screams ‘Trouble!’
It can become a chore to find good explanations about how to do stuff, all we have is the extremely verbose and mostly useless specifications, it even gets worse for extensions: The way they are ‘written against’ a base spec makes them a nightmare to read and comprehend.
What developers really need is not a wall of words about technical minutiae but some understandable explanation of what this does and how it is to be used. Again: Just look at the DirectX docs, they often helped me understand things about OpenGL when the GL docs were too obtuse about it. In this regard: Shame on you, Khronos!

Please remove all these obsticles from the Beginners (FINDING the correct Gl libraries for their OS, find an IDE which doesn’t suck, setup and configure the ide to run opengl code without studying astrophysics or the klingon language, etc.)

Again, its 2015, now we have an upcomming OpenGL 4.5 but we still don’t have a proper Set of OpenGL Software Development Suites. Imagine the Boost of the entire Opengl community, when newbies can run the installer and can - out of the box - run their first openGl demo with a current OpenGL Version.

That’s clearly not the problems that need to be solved. You have to do some work yourself.
Even a newbie needs to be familiar with the development tools available for the platform they want to target, that’s clearly not the business of some API designers.

To summarize, I think there’s two problem areas with OpenGL:

  1. stop promoting bad extension loaders, instead pick one that does the job right and allows to create configurable headers with the precise content a project needs - and then make that one the ‘official’ one.
  2. take the time to write some actual developer friendly (and FREE!) documentation. Not some heavily overpriced books that do a piss-poor job at introducing developers to OpenGL. I think this has been one of the biggest reasons why OpenGL tanked so badly against Direct3D on Windows which always came with some extensive and well written documentation. It’s not a difficult decision to choose against GL in such a case. But now with other platforms like mobile phones and MacOS X gaining more popularity this easy way out is getting harder and the frustration level of developers is increasing. Also Provide an extensive suite of examples, covering all important aspects of OpenGL with that documentation.

I really don’t think more is needed.

[QUOTE=Betrayal;1264356]offtopic

:doh:[/QUOTE]

Haha! Yes, right, I have been reading through some of Agent D’s posts and this boneheaded adding of (R) sure does make them look stupid on sight, if not worse. :stuck_out_tongue:

take the time to write some actual developer friendly (and FREE!) documentation.

cough cough