Hard Light Productions Forums

Community Projects => The FreeSpace Upgrade Project => Topic started by: Nemesis6 on March 28, 2009, 09:25:00 am

Title: OpenGL 3.1
Post by: Nemesis6 on March 28, 2009, 09:25:00 am
http://developer.nvidia.com/object/opengl_3_driver.html

Well, that driver is supposed to add support for OpenGL 3.1. If I got this right, FS2 is using OpenGL 3.0, or am I misunderstanding something? Would upgrading to OpenGL 3.1 fix anything or allow any new features? That's really it.

Edit: Thought I posted this in the code section. Oh well.
Title: Re: OpenGL 3.1
Post by: castor on March 28, 2009, 10:40:56 am
Isn't OGL3.0 pretty new too? I doubt FSO depends on even that yet.
Title: Re: OpenGL 3.1
Post by: captain-custard on March 28, 2009, 11:03:07 am
isnt FSO using opengl 2.1 atm ?
Title: Re: OpenGL 3.1
Post by: The E on March 28, 2009, 11:07:57 am
I think it was OGL 3.0 and GLSL 2.0 or something like that.
Title: Re: OpenGL 3.1
Post by: chief1983 on March 28, 2009, 02:59:54 pm
Shader Model 3, which I think was in OpenGL 2.0 or 2.1.
Title: Re: OpenGL 3.1
Post by: Zacam on March 28, 2009, 06:18:08 pm
Quote from: http://en.wikipedia.org/wiki/GLSL
Originally introduced as an extension to OpenGL 1.4, GLSL was formally included into the OpenGL 2.0 core by the OpenGL ARB. It was the first major revision to OpenGL since the creation of OpenGL 1.0 in 1992.

Quote from: http://en.wikipedia.org/wiki/Shader
OpenGL (version 1.5 and newer) provides a C-like Shader language called OpenGL Shading Language, or GLSL

Fixed Render pipeline (non-GLSL mode) is capable of using Pre-2.1 OpenGL.
GLSL mode can also use pre-2.1 GLSL, but it really is not recommended. These prior versions support earlier SM versions.

The OpenGL compiler for using GLSL should be 1.20 from the OpenGL 2.1 subset or better in order to support SM3.0.
FSO currently shows no operational difference when using OpenGL 3.x as compared to using 2.x.
However, there are changes to be made if OpenGL 3.x code was to be implemented, but those changes would not be reverse compatible.
(Please note that prior OpenGL code is capable of running on newer versions, even if the structure or command is now depreciated.)

Any OpenGL fixes from drivers that also contain newer versions of OpenGL may not actually have required those newer versions of OpenGL to be fixed.

So, in short: FSO Uses Shader Model 3.0 which requires full support for OpenGL 2.0 or higher.
Title: Re: OpenGL 3.1
Post by: blackhole on March 28, 2009, 06:29:14 pm
Upgrading to a new version of openGL does not magically make the game look better or run faster.
Title: Re: OpenGL 3.1
Post by: Zacam on March 28, 2009, 06:31:11 pm
You would be surprised. Newer versions of OpenGL rendering code may have more efficient ways of processing the same commands and functions.

Your statement is analogous to saying that Platinum spark plugs vs. generic spark plugs will have no effect in the same engine.
Title: Re: OpenGL 3.1
Post by: The E on March 28, 2009, 06:35:30 pm
Isn't that dependant on your GFX-card and its drivers?
Title: Re: OpenGL 3.1
Post by: High Max on March 28, 2009, 07:04:37 pm
.
Title: Re: OpenGL 3.1
Post by: Zacam on March 29, 2009, 12:01:07 am
*sighs*

Look. The OpenGL API in your drivers can be (within the context of the hardware constraints) updated to take advantage of newer API functions or better processing of existing functions. These updates can be applied to existing hardware (again, pending the hardware limitations) with minimal issues.

Consider: OpenGL 3.0 and 3.1 is available for any nVidia 8xxx series card or newer. But OpenGL 3.x did not exist when these cards were made. So obviously there is little in the way of the hardware being an issue to enable full feature support. Now granted, there may be some isolated functions on more reduced cards that may prevent a _full_ compatability, but the ability is there.

Consider the GeForce FX 5xxx series cards. Original drafted for the OpenGL 1.5 spec, while they do not have _full feature_ support for all of the OpenGL 2.0 specs, they can still claim an 80% feature set capability for using OpenGL 2.0. (What they are lacking is the computational ability to support Shader Model 3.0).

So yes, in _some_ cases, performance is better achieved by changing to newer hardware. However, declaring that updating one's OpenGL without changing the hardware because it will be of no benefit is ridiculous. So yes, it can be just as easy as updating OpenGL or drivers. And given that the OpenGL is usually bundled with the drivers (except in SDK's) you can get an improvement without having to adjust or change your hardware.

Wether or not you will actually see or be able to meassure this improvement is another matter entirely. Some platforms/games will see little in ways of improvements either because they are already as optimized as they will get, or are so fuster clucked that no amount of improvements to the driver will accomplish anything.
Title: Re: OpenGL 3.1
Post by: chief1983 on March 29, 2009, 12:25:17 am
He's right, the new beta nvidia drivers are proof of that.  They're basically turning on support for many OpenGL 3.1 features that weren't previously available, via a simple driver update.
Title: Re: OpenGL 3.1
Post by: blackhole on March 29, 2009, 12:37:50 am
Quote
Wether or not you will actually see or be able to meassure this improvement is another matter entirely.

That is the point that I was trying to make. Why upgrade to a new version if you can't tell the difference? Whether or not you can see an improvement is the only thing that matters - unless you plan on adding new features later on. I don't care if openGL 3.0 has speed optimizations or better ways of rendering things - have you SEEN the graphics rendering code?! You are perfectly correct in saying that you can get preformance increases by upgrading openGL, but my point is that with FSO, you won't. There's no way you are going to get anything more then a couple of frames improvement. That is not significant. The main point I was trying to make is that upgrading to openGL 3.0 does not magically make FSO be able to support bloom or whatnot.
Title: Re: OpenGL 3.1
Post by: chief1983 on March 29, 2009, 12:44:56 am
Maybe it won't make existing games look better, but maybe it will allow certain games to run at all that previously could not.  Think if certain cards suddenly could run the GLSL required by FSO that previously couldn't.  Wouldn't it be worth it then?  This is basically the same thing.  It allows the hardware to do more than it previously could, period.
Title: Re: OpenGL 3.1
Post by: blackhole on March 29, 2009, 12:48:28 am
Maybe it won't make existing games look better, but maybe it will allow certain games to run at all that previously could not.  Think if certain cards suddenly could run the GLSL required by FSO that previously couldn't.  Wouldn't it be worth it then?  This is basically the same thing.  It allows the hardware to do more than it previously could, period.

But FSO only uses shader model 2.0?

I mean, you're right, there's no reason not to upgrade the driver, I'm just saying a code re-haul is pretty pointless.
Title: Re: OpenGL 3.1
Post by: Zacam on March 29, 2009, 12:52:08 am
Because you cannot make the assumption that you WONT see an improvement. And there can be many improvements that you may NOT see. Like, if the processing of certain functions is now optimized, it lowers the GPU processing, which saves your video card a few degrees of temp.

And yes, I have seen the rendering code. Very impressive. Wether or not it will actually require as much of an overhaul as some people think is another matter for elsewhere. That some changes will need to be made is definitely not in question. Besides, bloom could already be supported, and for older than OpenGL2 as neither bloom nor HDR strictly require SM3.0. It's just better on SM3.0.

Given a choice in running FSO on drivers that support OpenGL 2.0, 3.0 or 3.1, I will have to say, I'll take OpenGL 3.1 and I hope it makes it into mainstream drivers really damn soon along with Ambient Occlusion support. Because I do happen to notice a difference by comparison to just how everything looks and how much smoother the same framerate is.

And no, FSO uses OpenGL 2.0, Shader Model 3.0. Shader Model 2.0 is usable in -no_glsl mode, mileage may vary if you choose to use the Shaders without  Shader Model 3.0.
Title: Re: OpenGL 3.1
Post by: blackhole on March 29, 2009, 02:21:00 am
And yes, I have seen the rendering code. Very impressive. Wether or not it will actually require as much of an overhaul as some people think is another matter for elsewhere. That some changes will need to be made is definitely not in question. Besides, bloom could already be supported, and for older than OpenGL2 as neither bloom nor HDR strictly require SM3.0. It's just better on SM3.0.

Oh my god, this is not my point. Have you tried implementing HDR and bloom on the current graphics? It just doesn't work! As taylor has pointed out numerous times the graphics code needs a complete rehaul before HDR and bloom start going in, the first being for it to stop rendering everything in little chunks with its own depth sorting.

Quote
Because you cannot make the assumption that you WONT see an improvement.

Yeah, I can.
Title: Re: OpenGL 3.1
Post by: castor on March 29, 2009, 05:41:18 am
Hmm, if the software using the API has not been modified and the hardware is the same, but you still get an improvement, wouldn't it simply mean that the older OGL implementation for the HW was crappy? (so the improvement wouldn't be due to the updated OGL spec)
Title: Re: OpenGL 3.1
Post by: DaBrain on March 29, 2009, 05:42:25 am
@blackhole

Unless you're a genius and I'm a complete moron, I'd say HDR in a space game doesn't make much sense anyway.

As for bloom, I guess if we don't overdo it, it would be a nice improvment.
Title: Re: OpenGL 3.1
Post by: Herra Tohtori on March 29, 2009, 06:01:32 am
@blackhole

Unless you're a genius and I'm a complete moron, I'd say HDR in a space game doesn't make much sense anyway.

Well it could be used to make it so that when brightly lit objects are visible, the side in shadow is really pitch black, whereas when you're on the shadow side (and don't see the sun directly) the dynamic range would mean you would still be able to see the dark side of the ship or whatever.

At the moment you can either set the dark side to be really dark (-no_emissive_light -ambient_factor 0) and the shadows will be realistically dark for space... in which case it's a pain in the ass to see anything in the dark side of ships. High dynamic range would simulate human eyes adapting to the general brightness of the image... which I'm certain you know.


Quote
As for bloom, I guess if we don't overdo it, it would be a nice improvment.

Bloom would make much less sense to me (except if used masterfully to simulate cockpit glass distortions and reflections) since space is empty and there's no stuff to scatter light. Atmospheric and Nebula missions would benefit from it though.


I would still prefer having shadows (cast on other and self by any object) though... :p
Title: Re: OpenGL 3.1
Post by: blackhole on March 29, 2009, 07:31:37 pm
HDR makes even more sense in a space game. Think about it - HDR was invented because we can't accurate portray the full range of dynamic contrasts on earth, where we have an atmosphere providing a buffering ambiance. In space, you are presented with even more extreme contrasts, and so to accurate depict space you would most definitely need HDR. That's why turning down the ambiance results in a more realistic feel - but it is limited by LDR constraints. HDR would allow for even more contrast.

In general, when done correctly, HDR will benefit any situation - even a single room with a lightbulb. The commercial games just like to abuse the crap out of it to try and make themselves look cool. They also attach excessive bloom to the effect.

The same goes for bloom, actully; slight bloom actually does make sense because bloom is also an artifact of our own irises, it's just only apparent with extreme contrast (like say, a space environment) and is far less obvious then what is usually depicted in games.

I once was playing around with a fake bloom effect and inserted some screenshots to see what they would look like. Looking back, the bloom effect was far, far too strong, but here is a decent example:

(http://img106.imageshack.us/img106/3792/86ruumdar6.th.jpg) (http://img106.imageshack.us/img106/3792/86ruumdar6.jpg)
(http://img516.imageshack.us/img516/1926/thirdpicpn4.th.png) (http://img516.imageshack.us/img516/1926/thirdpicpn4.png)

Obviously a real implementation would be much more refined, based on HDR, and more subtle, but you get the idea. Of course, simply adapting the picture to the average luminance is just a basic implementation of HDR. Advanced HDR techniques enhance the image as a whole based on the HDR information.

Personally I tend to agree with Herra Tohtori in that we should be implementing HDR and either no bloom at all or a very subtle version of it. Besides, where are the stinking shadows?! We should be implementing shadows before HDR.

Title: Re: OpenGL 3.1
Post by: Wanderer on March 30, 2009, 05:06:54 am
I would like to have an option for fairly strong bloom on certain items.. Say like with thrusters, suns, and possibly some - most likely not all - explosion effects. That is bloom would for all that i know provide extremely convenient way of getting rid of the clipping issues which are all too common with the thrusters these days.
Title: Re: OpenGL 3.1
Post by: FreeSpaceFreak on March 30, 2009, 01:35:28 pm
I read somewhere that the bloom would be able to fix the warp clipping planes as well, the sharp edges where ships (dis)appear.

Would it be able to do other clipping planes as well? Thrusters, like Wanderer said, and possibly beams? Explosions? Would sure be nice...
Title: Re: OpenGL 3.1
Post by: Aurora Paradox on March 30, 2009, 04:19:53 pm
Bottom line will the downloading the upgraded version of Open GL give any kind of boost?

Title: Re: OpenGL 3.1
Post by: blackhole on March 30, 2009, 05:01:52 pm
I read somewhere that the bloom would be able to fix the warp clipping planes as well, the sharp edges where ships (dis)appear.

Would it be able to do other clipping planes as well? Thrusters, like Wanderer said, and possibly beams? Explosions? Would sure be nice...

(http://img106.imageshack.us/img106/6947/secondpichn3.th.png) (http://img106.imageshack.us/img106/6947/secondpichn3.png)

Quote
I would like to have an option for fairly strong bloom on certain items..

This is why HDR is used in conjunction with bloom. Make something be really really really bright in comparison to everything else, and the resulting overflow is expressed in bloom.

Quote
Bottom line will the downloading the upgraded version of Open GL give any kind of boost?

It might. I remain skeptical as to whether or not it will have any noticeable difference on FS2, but there's no reason not to download a new version.
Title: Re: OpenGL 3.1
Post by: chief1983 on March 30, 2009, 05:19:31 pm
Other than currently, the Nvidia OpenGL 3.1 drivers are in Beta.
Title: Re: OpenGL 3.1
Post by: AthlonBoy on March 30, 2009, 06:20:24 pm
Quit posting pictures showing off bloom. You'll make people demand it. :(

And yes, HDR is perfectly suited to a space game. The perception that critics have is that HDR means overexposed outdoor scenes with hueg amounts of bloom around everything that isn't matte black. This is not 'good' HDR. A well-implemented dynamic exposure control system, coupled with bloom on areas out of gamut, would result in FSO jumping ahead a few generations in terms of graphics.

Just imagine the HLP Ulysses flying around you. It rolls around and catches the sun for the briefest moment, giving you a bright flash of light; he hits his afterburners and the thrusters glow brightly, truly obscuring the engines, none of that sprite clipping nonsense; before zooming towards the sun, becoming as black as pitch next to the intense light of the star. You wouldn't have the unrealistic sun glare that we have now, which simply brightens the whole screen up. This incorrect approach to sunlight actually makes the dark side of ships easier to see. With HDR, the sun would force the exposure down, darkening even the stars, while the sun blooms out over anything obscuring it.

There is no doubt that FSO would be better off for having HDR. Assuming a fully complete HLP remake, it would be almost on par with EVE Online.

The problem is, I have no idea how easy it is to implement. I don't get the feeling it's a walk in the park. If OpenGL 3.1 defines a new function for HDR, so be it, but it's rarely that easy. I remember that Valve had to re-write all of their shaders to work in a high gamut range when adding HDR to Half Life 2.

And therein is my doubt. How easy or difficult would it be to implement HDR? I'm not a software engineer, I only know what HDR technologies are designed to simulate, not how they're implemented.
Title: Re: OpenGL 3.1
Post by: chief1983 on March 30, 2009, 07:15:25 pm
The problem is, I have no idea how easy it is to implement. I don't get the feeling it's a walk in the park. If OpenGL 3.1 defines a new function for HDR, so be it, but it's rarely that easy. I remember that Valve had to re-write all of their shaders to work in a high gamut range when adding HDR to Half Life 2.

They had to redo quite a bit, just play through Lost Coast with the commentary.  They mention a few times what work had to be done for the new HDR features.
Title: Re: OpenGL 3.1
Post by: AthlonBoy on March 30, 2009, 08:24:43 pm
The problem is, I have no idea how easy it is to implement. I don't get the feeling it's a walk in the park. If OpenGL 3.1 defines a new function for HDR, so be it, but it's rarely that easy. I remember that Valve had to re-write all of their shaders to work in a high gamut range when adding HDR to Half Life 2.

They had to redo quite a bit, just play through Lost Coast with the commentary.  They mention a few times what work had to be done for the new HDR features.

That's where I got my information from. I just don't have a good memory. :p
Title: Re: OpenGL 3.1
Post by: blackhole on March 31, 2009, 11:03:56 am
And therein is my doubt. How easy or difficult would it be to implement HDR? I'm not a software engineer, I only know what HDR technologies are designed to simulate, not how they're implemented.

It would not be a walk in the park. The first step is rendering everything to an HDR texture rendertarget, then writing a bloom+color correction shader to work with HDR, then implementing one of the various techniques for determining overall screen brightness. I'm pretty sure Valve used a trick where they down-sampled to a 3x3 texture and weighted the middle pixel's lighting value. After that a bloom shader would have to be written, several textures and effects would need to either use HDR textures or be re-calibrated so they have the proper lighting values, I would assume the lighting would need to be adjusted, and that's just for a basic implementation. A far more advanced post-processing shader would be required for more complex utilization of HDR.

And we'd still need shadows.
Title: Re: OpenGL 3.1
Post by: Zantor on April 18, 2009, 09:24:42 pm
In my knowledge, FSO does NOT use OpenGL 3.0 or 3.1. I have an nVidia GeForce 7600GS ASUS card that supports up to OpenGL 2.0 (proof (http://www.xpcgear.com/en7600gs25.html)). In another thread about compatibility issues, a n00b user posted asking about OpenGL 1.2, which is the version that FSO uses (for proof do a forum search for "OpenGL 1.2"). I do not know about OpenGL 3.0, but I do know that it if it were to be used, it would be too new for some people.
Title: Re: OpenGL 3.1
Post by: chief1983 on April 19, 2009, 02:18:34 am
Just because it uses it doesn't mean it requires it.  The fixed pipeline does indeed require OpenGL 1.2, or so.  Use of the OpenGL Shading Language bumps the requirement significantly, and the bump can vary based on how the shaders are written.  The minimum for any shaders at all I believe is some form of OpenGL 2.0 or 2.1 support.  You could easily write shaders that take advantage of, or require OpenGL 3.0/3.1 if you wanted to, I imagine.
Title: Re: OpenGL 3.1
Post by: Tomo on April 25, 2009, 07:26:58 am
Shadows are extremely difficult.

I spent my entire MSc trying to do good shadows with multiple lightsources, and I failed to get an effect I was happy with. The stencil buffer came close though.
- I did manage a perfect haze which is unfortunately pointless for FSO as there is no haze in space. (Those beauty shots in some space-based sci-fi showing beams of light around a ship are *wrong*)

The games that implement shadows either have them baked-in, or have baked-in shadows plus single lightsource shadows using the stencil buffer.
- Even Half Life 2 Ep 2 does them the latter way.

There are two situations where they happen:
1) Self-casting shadows, eg the 'nose-sticky-down-bit' on the Colossus casting a shadow onto the stem to the nose section.
2) A fighter/bomber flying *very* close to a capital ship.

IIRC, the stencil buffer can't do self-casting shadows so these need to be done a different way.

To do shadows properly, we'd have to support the following light sources:
A) The local star. This is a single point source, which casts hard-edged shadows. Relatively simple.
B) Multiple Beams. These are long, linear sources, which produce a very distinctive kind of shadow - soft edged along the beam, hard edged across the beam.
C) Multiple explosions. These could be treated as point sources casting hard-edged shadows, but there are quite a lot of them!
Title: Re: OpenGL 3.1
Post by: Herra Tohtori on April 25, 2009, 09:43:08 am
Shadows from static light sources (suns) would likely be the most important thing; I doubt anyone would notice the lack of shadows from effects (enough to care).
Title: Re: OpenGL 3.1
Post by: wolf on April 28, 2009, 04:25:27 am
The games that implement shadows either have them baked-in, or have baked-in shadows plus single lightsource shadows using the stencil buffer.
- Even Half Life 2 Ep 2 does them the latter way.
Uhm. Since when HL2 had technically advanced engine?

http://delivery.acm.org/10.1145/1290000/1281671/p97-mittring.pdf?key1=1281671&key2=9048090421&coll=ACM&dl=ACM&CFID=15151515&CFTOKEN=6184618 (http://delivery.acm.org/10.1145/1290000/1281671/p97-mittring.pdf?key1=1281671&key2=9048090421&coll=ACM&dl=ACM&CFID=15151515&CFTOKEN=6184618)
Title: Re: OpenGL 3.1
Post by: chief1983 on April 28, 2009, 10:18:16 am
HL2 is probably closer to something we could accomplish than a DX10 game.  Just a guess.
Title: Re: OpenGL 3.1
Post by: wolf on April 28, 2009, 12:27:08 pm
Crysis is not a DX10 game. There was much of the babble about what DX10 can do and what DX9 can't and some developers (including Crytek) played the ball. By manual tweaking of config files it's possible to enable "DX10 only" features on DX9.

http://www.gamespot.com/features/6182140/index.html (http://www.gamespot.com/features/6182140/index.html)
Title: Re: OpenGL 3.1
Post by: chief1983 on April 28, 2009, 12:55:20 pm
Then how is it so much more advanced than HL2.  If they're both basically DX9 games what's the big difference?
Title: Re: OpenGL 3.1
Post by: wolf on April 28, 2009, 02:27:23 pm
http://img.gram.pl/upl/artykul/20070921134340.jpg (http://img.gram.pl/upl/artykul/20070921134340.jpg) vs http://pcmedia.ign.com/pc/image/article/966/966403/gdc-09-crytek-talks-cryengine-3-20090325035851934.jpg (http://pcmedia.ign.com/pc/image/article/966/966403/gdc-09-crytek-talks-cryengine-3-20090325035851934.jpg)

Is this even a serious question? Because, you know, both solitare and Crysis basically require WinAPI to run, so they can't be that much technically different.
Title: Re: OpenGL 3.1
Post by: chief1983 on April 28, 2009, 02:47:06 pm
I said how is it more advanced, not how does it look better.  So they have more processing power, etc to take advantage of.  I'm just saying, they're built on the same technology, but it seems that Cryengine2 has managed to make a few nice technical achievements.  However, many of those could be added to the Source engine without it requiring a full rewrite as they're still built on top of the same API.  And since Valve seems to keep doing stuff like that, I have a feeling the next big release of the Source engine will still be on the ball.