OGL2.0 tools

OpenGL
1

What about to include in a “real” ogl2.0 sdk:

  1. An “offline” glsl compiler like dx’s fxc.exe/vsa.exe/psa.exe . Sometimes is good to pre-compile your high level shaders and add them as a “resource” in the .EXE, protecting a little your precious shaders against strange eyes…
    To compile the raw string shaders in runtime has advantages, but problems too. Give us the opportunity to decide if we want to precompile or not our glsl shaders pls. So make an offline compiler BUT maintain the glCompileXXXARB…

  2. We want to debug in a visual-way the shaders, again, like MS Visual Studio and dx does. Like ogl should remain portable, perhaps it will be a clever idea to make a NVShaderDebuger-like program ( providing its source code, of course )

  3. Implement, damm again like dx, a “debug” ogl implementation, so you can change with a button the lvl of “internal debug logging” and see in the stdout the reduntant calls, errors, warnings, etc…

  4. Add a “performance” tool like VTune + NVPerf, so we can see if the ogl driver is eating too much draw calls, or is our CPU , etc…

  5. Add a “math-image” namespace in ogl. Let me explain it… Have you seen D3DX? It includes a basic image library to load into textures PNG, TGA, TIF, DDS, BMP etc images… and some vector/matrix useful basic operations.

  6. Perhaps ( i am not totally sure of that ) OGL2.0 should include a propietary texture format ( like dx .DDS ). This is good for various reasons… It is faster to load pre-formatted textures into ogl, textures will remain portable against different OS and machines… And, of course, add some tools/methods to automatic mipmap generation using advanced filters as gauss, normal map creation from a height map, color reduction, texture compression, etc… After all, NVIDIA has its famous PS plugin… just include things like this in OGL as “extras”.

  7. Create a real SDK ( where sdk means == examples, tutorials, whitepapers, ogl core, installer, debug tools, compiler tools, wizards, wrappers, beta things… blah blah ). Why should you include ALL as a unique SDK? cuz ppl is lazy to go NVIDIA and download the plugins… then go ATI and download NMaper… then go www.opengl.org and download tutorials… bah BURN ALL IN A CD WITH THE SDK!

thx to all, dont blame me pls, you know i am a Microsoft addict :stuck_out_tongue:

2

  1. no, this is a feature in GLSLang, it alows for better driver optimations.

  2. it would certanly be usefull.

  3. ok, i won’t be using it though.

  4. this would be nice

  5. this is one of those things thjat you would have to do yourself, it’s not that hard.

  6. why, it’s not needed in ogl, do it yourself if you want it but there is no real reason having a special image format just for ogl.
    WHy not use .dds, the only difference from dds and other format’s is that dds it contains pregenerated mipmaplevels.

  7. would be nice.

3

Apparently 3d modellers like the .X file format,
and like to use nice tools like Maya, 3DS Max, etc.
It would be nice to have the native ability to
load such models, as in the DirectX sdk.
It would also help out a LOT of people new to opengl, in that they could suddenly have things OTHER than Borg-cubes and shoebox cars…
…

4

i must admit all these ideas would go a long way to speed up development times,

but the thing is, opengl is focused on the very minimums of 2d/3d graphics…

i would like to see this stuff, maybe like an extra library or something

:slight_smile:

5

Hmmm, by precompiled stuff, all that would really be is compressing the info and store it in the exe. That could be useful.

As for math stuff, I’m pretty sure, there is already that functionality in glu. It would be nice to have a processor optimizing vector library though, which glu might do already. I’m not so sure about image stuff, but there are plenty of open source libraries for that.

DDS and .X is not proprietary at all. It’s pretty simple actually. You can look at both on MSDN. DDS is a bit more complicated than just extra mip levels, as they can also store 3D textures, environment maps, etc. As for texture compression, it is more complicated when you’re working with DX specific stuff, but you can convert it using an MS tool.

For many of these other things that get hacked into DX, there are plenty of fairly robust tools out there (eg. NVidia/ATI SDK). And if you’re too lazy, ask someone to host a combo package (or sell one yourself) of all the crazy stuff. Otherwise, I’m afraid you’re SOL, because lazy is NOT the way to get by in the game industry or probably any other.

It WOULD be nice to have a nicely explained set of docs, with examples etc. At the moment that is probably one of the biggest problems with OGL (especially with extensions) IMHO.