[DaBrain]

Well, Nvidia announced full OpenGL 3.0 support for one of their next Forware driver versions.
So the spec seems finally to be final. And I expect to see an AMD/ATI driver supporting it soon too.

Anyway, I don't expect FSO to instantly support it and use crazy geometry shader stuff.
That's not why I post this. It's rather a technical question.
What I want to know is, if we can even switch to OpenGL 3.0 in the future.

My technical knowledge about this matter is pretty low, but I do understand that OpenGL 3.0 doesn't support a fixed function pipeline anymore...
So... can we still support OpenGL 2.(1?) as well? Or do we run into a big shder incompability problem?

[pecenipicek]

what do the geometry shaders do exactly?

[chief1983]

Geometry shaders can add and remove vertices from a mesh. Geometry shaders can be used to generate geometry procedurally or to add volumetric detail to existing meshes that would be too costly to process on the CPU. Direct3D 10 added geometry shader support to the Direct3D API. OpenGL only supports geometry shaders through the use of an extension, though it will likely be incorporated into the standard itself with version 3.0 or 3.1. If geometry shaders are being used, the output is then sent to the rasterizer.

Shaders on Wikipedia

[blackhole]

Unless you guys all want to go out and buy fancy new graphics cards, adding any kind of support for this stuff would be largely superficial as no one would be able to actually take advantage of it. Motion blur? Post processing? There's still a crapload to do with current hardware.

[chief1983]

Unless you guys all want to go out and buy fancy new graphics cards, adding any kind of support for this stuff would be largely superficial as no one would be able to actually take advantage of it. Motion blur? Post processing? There's still a crapload to do with current hardware.

Why so serious?  He was just wondering if it could be added.

[Topgun]

and I thought my jokes where bad.
I say we (read you) add post-processing before we (read you, again) add some useless geometry shader.
I want cloaked ships!

[Cyker]

Bah, who cares about OpenGL? OpenGL is ancient! We should code for OpenRT! RayTracing is t3h futarrr!!!!!!!1!!!1!11!11111one111eleventyone

[pecenipicek]

Bah, who cares about OpenGL? OpenGL is ancient! We should code for OpenRT! RayTracing is t3h futarrr!!!!!!!1!!!1!11!11111one111eleventyone

actually, i agree with this. however, there is no easy and not-make-your-framerate-die way to do it yet. opengl for the win anyways


just wondering, what would it take in general to add postprocessing into the engine?

[chief1983]

Can't you just write a shader now?

[DaBrain]

Hmm this is going into the wrong direction...

Let me re-formulate my question(s).

If FSO will support OpenGL 3.0, will this break the compability with older non-shader 3.0 systems?
(Which would probably prevent us from doing this anyway...)


And, what kind of proces would it be? Is it like porting the game to another gfx api, or easier/harder/different?
(This is not even  ment to be a FSO related question. I just want to get the concept behind it. I could ask on another board as well.)

[taylor]

The API is different between OGL 1.x/2.x and 3.x.  So supporting it (properly anyway) would mean adding it like an additional graphics API.

[DaBrain]

Ok, I see, that acutally answers both question.

If OGL 2.x would still be in, the fixed function issue wouldn't be a problem.

[Kaine]

The API is different between OGL 1.x/2.x and 3.x.  So supporting it (properly anyway) would mean adding it like an additional graphics API.

Would adding OGL 3.x as an additional API and maintaining both be as painful as DirectX/OGL was? I imagine the inherent similarities between them would soften the blow a little. Is there any word on what the backwards compatability of OGL 3.x will be like?

[chief1983]

Not necessarily, it wasn't that supporting D3D was painful, it's that no one wanted to/knew it well enough.  I imagine maintaining OpenGL 2 and 3 would be an easier task, but could still be too much work for one person.

[Swifty]

It's kinda pointless supporting a platform specific API when you're already supporting an API that supports all platforms anyway.

[chief1983]

Except that OpenGL sucks on some hardware *cough* Intel *cough*.  But that's really not our fault.

[Kaine]

Except that OpenGL sucks on some hardware *cough* Intel *cough*.  But that's really not our fault.

that is nobody but Intel's fault. OpenGL has been around a very, very long time and frankly there's no excuse for having complete and proper support for it. The only real reason Intel have for not supporting it is that none of their graphics chips are designed or aimed at an audience that needs to render anything.

[Swifty]

Uh oh. The new OpenGL spec doesn't seem to be making developers very happy.

...Maybe we should start supporting D3D again.

[taylor]

that is nobody but Intel's fault. OpenGL has been around a very, very long time and frankly there's no excuse for having complete and proper support for it. The only real reason Intel have for not supporting it is that none of their graphics chips are designed or aimed at an audience that needs to render anything.

Intel hardware isn't that bad actually.  They are certainly aiming for the low end, but both ATI and NVIDIA have cards in the same class.  The main problem with Intel hardware is that the drivers don't expose all of what the hardware is capable of doing.

Uh oh. The new OpenGL spec doesn't seem to be making developers very happy.

How things ended up really sucks, but it's not terribly surprising actually.  And anyone that knows about the history of OpenGL shouldn't really be that surprised either.  Those people might not be happy about the lack of changes, but I'm pretty sure that they weren't all that happy before either, so I don't really see how it matters.

OpenGL isn't going anywhere.  It's still the only real choice for cross-platform 3D graphics.  And DX can bite me.

[WMCoolmon]

Uh oh. The new OpenGL spec doesn't seem to be making developers very happy.

...Maybe we should start supporting D3D again.

Nobody is going to care if FS2Open jumps ship to make an idealistic point. All we'd do is alienate the Linux and OS X users and force everyone else to upgrade to Vista. If we just used DX9, we'd still be using the same generation of graphics API as we are now.

I don't really see any value in making DirectX optional, as an add-on, since we'd again be splitting our efforts between two graphics APIs, and now we'd have to support two shader APIs, as well as write new shaders from both. When the material system gets released, mods would have to follow suit or force their users to run on one or the other to use the custom shaders they'd developed, or spend time developing shaders for both OpenGL and DirectX.

Finally, FS2Open is in no way making use of the graphics elements in today to push things to the bleeding edge. Things like burn decals, HDR (which is just being implemented), reflections, motion blur, and more realistic physics are becoming the norm on games today. Not to mention that a lot of games have posable characters as well as space ships, and many of the aspects of making a mod, mission, or model for Freespace are obfuscated and could use a lot of work for making them more people-friendly.

(Dare I also mention dual core?)

In terms of keeping up with the Joneses, there's still a lot that can be done without a version number bump on the lowlevel graphics API.