Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Swifty on October 28, 2014, 01:05:32 am
-
It's looking like the deferred lighting and soft shadows code has been stabilized based on the lack of bug reports I've been receiving. As a result, I've been thinking more and more about the future of Freespace Open's graphics and what needs to be done to continually keep the engine state of the art.
- Physically-based rendering: Lighting in FSO is okay and for the most part, it looks really good. But we honestly can do a lot better. As video games start going into the PS4/Xbox One era, AAA games are beginning to take advantage of their increased shader capabilities of their GPUs. More ALU operations means more physically plausible lighting calculations which means more realistic lighting. More detailed information about it can be found on Crytek's website (http://docs.cryengine.com/display/SDKDOC3/Physically+Based+Shading+in+CRYENGINE).
- Gloss/Roughness Maps: Probably the most important feature for artists in a physically-based rendering pipeline. Gloss maps allow artists to control the shininess of their materials (Basically how big the specular highlight is with wide highlight = rough versus small highlight = smooth) while also indicating how blurry the environment relfection map is (Blurry reflection = rough versus sharp reflection = smooth). At the moment, artists can control the intensity of the environment map using the alpha channel in the specular map. It isn't much. Gloss maps makes materials such as brushed metals possible as opposed to always having highly polished metals or dull looking plastic.
- Linear-space lighting: Freespace appears to do all it's lighting calculations in gamma-space rather than linear space which creates really harsh color contrasts. Part of getting a realistic lighting equation is making sure the engine gets all it's assets in linear color space, doing lighting correctly, and giving OpenGL a color corrected framebuffer.
- HDR and Tone-mapping: And part of having linear-space lighting and a physically-based rendering system is to make sure we adequately account for all color ranges meaning being able to account for colors that go beyond a 0-255 range.
- Area Lights: Featured in Killzone Shadow Fall, area lights allow an artist to define a light emitter as a simple shape rather than a point. Kind of similar to how we do tube lights for beams. We can use area lights to apply fixed lights to ships that can't necessarily be represented by a simple glowpoint. Think of a flourescent panel light (represented by a rectangular area light) or a light fixture (represented by a circular area light). Check out the Area Lights section of Guerrilla Game's presentation (http://www.guerrilla-games.com/presentations/Drobot_Lighting_of_Killzone_Shadow_Fall.pdf) detailing the lighting in Killzone Shadow Fall.
- Oculus Rift Support: It'll happen eventually. The debate is whether or not I should finish the task below this one or not.
- OpenGL Core Profile Support: Sigh. The boner killer. But needed if we want the Macs in on all the cool stuff. Probably the first thing I have to do before any of the above get started. And I probably won't start it until deferred lighting and shadows hit trunk because of how invasive it will be.
Anyway, feel free to comment and raise any potential issues or pitfalls you may foresee!
-
IMO HDR/tonemapping would have the greatest visual benefit without the need for asset updates. While FSO doesn't really lend itself to needing HDR per se, it'd be nice to have more realistic bloom, so that skyboxes aren't blown to hell if you want even subtly noticeable bloom on explosion effects and suns.
-
I think those points are fine, I know you've been testing ambient occlusion and found it somewhat worthless. I beg to disagree: ambient occlusion would work best in nebula settings and in capital ships. Nebula graphics could use some updates as well (the lightning effect is still the original!), but it appears some kind of novel research would be necessary in this, since nebula gameplay is somewhat unique in FreeSpace...
I am somewhat doubtful of the need to do area lights in FreeSpace. These things are very useful in closed first person shooter rooms, not in wider space. Could you give us a practical example where this would provide an increase of visual quality in FS?
OTOH, volume lighting could be really really REALLY cool in nebulas. I mean, REALLY cool. Did I say it would... yeah I said it.
You know what would also be really REALLY cool in nebulas? A way to blur out (in direct proportion to the z buffer) beams. The further away a beam is, the more blurred out it is. Bonus points if you could fake the nebula itself around it to be lit. Note: I'm not saying make a really physically correct rendering of a beam lighting a fog, I'm not mental. I'm saying perhaps it could be faked?
-
AO is pretty expensive for how little gain you'd see in most Freespace settings. Baked AO will be superior to any screenspace techniques in pretty much all circumstances when there is very little object-object overlap/contact. Even then, baked AO has pretty minimal benefits in FS (but it's free along with baked lighting on glowmaps, so it's pretty popular in newer models and can look really good)
As for nebulae effect, I'd be already really happy if sunshafts were visible even if the star wasn't on screen. That, and somehow fixing the annoying ship pop-in glitch that somehow still plagues the engine (capship will randomly be fully visible for a few moments when it's pretty far away).
-
I think those points are fine, I know you've been testing ambient occlusion and found it somewhat worthless. I beg to disagree: ambient occlusion would work best in nebula settings and in capital ships. Nebula graphics could use some updates as well (the lightning effect is still the original!), but it appears some kind of novel research would be necessary in this, since nebula gameplay is somewhat unique in FreeSpace...
Consider: AO only concerns itself with close-up geometry. You can't do it efficiently at large ranges. Baked AO is way superior in terms of visual impact vs performance impact.
I am somewhat doubtful of the need to do area lights in FreeSpace. These things are very useful in closed first person shooter rooms, not in wider space. Could you give us a practical example where this would provide an increase of visual quality in FS?
Sunlight, or indirect light from planets.
-
Will someone point me in the right direction of more information about the last point, the OpenGL Core Profile Support. Please and Thank You. :)
As I'm not involved with any of the development and have no knowledge of any of it. I'm quite happy with the graphical levels at the moment and reckon something more back-end could be the next aim.
-
I think those points are fine, I know you've been testing ambient occlusion and found it somewhat worthless. I beg to disagree: ambient occlusion would work best in nebula settings and in capital ships. Nebula graphics could use some updates as well (the lightning effect is still the original!), but it appears some kind of novel research would be necessary in this, since nebula gameplay is somewhat unique in FreeSpace...
Consider: AO only concerns itself with close-up geometry. You can't do it efficiently at large ranges. Baked AO is way superior in terms of visual impact vs performance impact.
I understand. The quality / performance issue kills it. It would be a better visual solution because you could then control AO by ambient lighting, and it would not pollute direct light situations. Perhaps a solution wherein you would have an "ambient mapping", and thus you could stop baking it directly in diffuse mapping would be a really great improvement.
I am somewhat doubtful of the need to do area lights in FreeSpace. These things are very useful in closed first person shooter rooms, not in wider space. Could you give us a practical example where this would provide an increase of visual quality in FS?
Sunlight, or indirect light from planets.
A really close planet indirect lighting would be better rendered in area lighting, yes, but the improvement would mostly come from better smooth shadows from the area lighting... is it worth the predictable framerate drop? Well perhaps it is. I'm a bit dubious but I'd be really excited if you proved me wrong!
-
Will someone point me in the right direction of more information about the last point, the OpenGL Core Profile Support. Please and Thank You. :)
As I'm not involved with any of the development and have no knowledge of any of it. I'm quite happy with the graphical levels at the moment and reckon something more back-end could be the next aim.
Short version: OpenGL since version 3 defines several different profiles. There are currently two that are of interest to us, the "Core Profile" and the "Compatibility Profile". A program using the Core profile can only use commands from the OpenGL 3 (or higher) API, a program using the Compat profile can use stuff from earlier versions. Switching our rendering to use the Core profile only has a few important sideeffects; the code becomes much more readable and easy to maintain (because the core profile is massively simplified compared to earlier GL versions), and since driver support gets better the closer you are to using the Core profile only, there will be fewer issues with things misbehaving between different drivers/manufacturers.
-
It would be a better visual solution because you could then control AO by ambient lighting, and it would not pollute direct light situations. Perhaps a solution wherein you would have an "ambient mapping", and thus you could stop baking it directly in diffuse mapping would be a really great improvement.
I'd just like to note that even currently, absolutely nothing prevents one from having AO as a separate texture/channel which is affected by ambient light or lights in general separately from the diffuse texture. It would even be a rather simple thing to do.
-
While all of these sound great and stuff, can I make a point for something else?
Shields
If there is something that desperately needs a graphical overhaul its the way shields are rendered.
I want nicer shields so much that I'm willing to put down actual money dollar/euros to the coder that takes up the task. If anyone wants to take me up on that offer, please.
Valathil started this:
and then never finished it. And it left me wanting.
The old method of 'paste animated bitmap on shield mesh' looks only half way decent on perfect bubble shields. Tends to look pretty bad overal on capital ships and all sorts of graphical glitches start occuring when a lot of shields are hit at once. I want this improved so badly.
-
I'd just like to note that even currently, absolutely nothing prevents one from having AO as a separate texture/channel which is affected by ambient light or lights in general separately from the diffuse texture. It would even be a rather simple thing to do.
Yeah, my point precisely. I don't think FSO currently supports ambient lighting maps but it would be a simple addition.
-
I guess as long as we're suggesting additions to the list, I'd still like to see some kind of workaround for the aliasing problems seen in beams and missile trails at sub-pixel widths (at long distance). That said, I'm not sure I'd prioritize that over getting Freespace to look like the stuff The E's been posting. (http://i.imgur.com/qZnYyCw.jpg)
-
That, and somehow fixing the annoying ship pop-in glitch that somehow still plagues the engine (capship will randomly be fully visible for a few moments when it's pretty far away).
This bug should have been fixed. Are you still seeing it? If so, with what builds?
-
The reason why I wanted area lights was because of capital ships. Freespace is a game with capital ship battles as the set pieces and I noticed a lot of people like decorating their ships with glow maps. So we have all these bright panels, nameplates being illuminated by light fixtures, flourescent lights in hangars, etc but none of them light up other ships nearby. I figured that if a modeller wants a bright panel represented by a glow map to be an actual light, they can just define a rectangular area light and they can set the light to match the irradiance characteristics of that drawn panel. As good as glowpoints are, they aren't adequate enough to actually light an actual environment and offer lighting solutions that a fictional ship would aesthetically have.
But honestly, this is probably not going to be a priority. A major pitfall I realized is the potential of light leaking out of ships because of the lack of shadowing for non-directional light sources. Maybe I'll tackle it sometime later when I figure out how to get shadows working beyond light coming from the local sun.
As for ambient occlusion, baked AO in the diffuse maps is still really useful. Yeah, dynamic ambient occlusion is really useful for other types of games where disparate objects are always close to each other and geometry is constantly drawn near the camera. But a space game like Freespace rarely has objects being that close to the camera and to each other. That's what I realized when playing around with my AO experiments which prompted me to trash it
-
That, and somehow fixing the annoying ship pop-in glitch that somehow still plagues the engine (capship will randomly be fully visible for a few moments when it's pretty far away).
This bug should have been fixed. Are you still seeing it? If so, with what builds?
Haven't played for a very long time. Probably latest I noticed it was a nightly a few months back, but might be earlier than that. If it's fixed, then great!
-
Haven't played for a very long time. Probably latest I noticed it was a nightly a few months back, but might be earlier than that. If it's fixed, then great!
It was fixed in mid-June, so if you last played on a build from before that, then it's been fixed since you last played.
-
I wish to bring up the long-deprecated experimental feature of damage decals, which I would also like to see combined with persistent surface explosion effects to simulate massive damage from hull breaches.
-
Awesome!, thanks The E.
-
I think HDR and decals would make the biggest difference in practice. I agree with others that AO would be useless for FS2, and often has a minimal impact even in FPS games given its performance hit.
The reason why I wanted area lights was because of capital ships. Freespace is a game with capital ship battles as the set pieces and I noticed a lot of people like decorating their ships with glow maps. So we have all these bright panels, nameplates being illuminated by light fixtures, flourescent lights in hangars, etc but none of them light up other ships nearby. I figured that if a modeller wants a bright panel represented by a glow map to be an actual light, they can just define a rectangular area light and they can set the light to match the irradiance characteristics of that drawn panel. As good as glowpoints are, they aren't adequate enough to actually light an actual environment and offer lighting solutions that a fictional ship would aesthetically have.
A bloom effect around lightmaps and glowpoints on ships may be easier to do and still look good. Many of the Volition renders have an effect like this.
-
Decals could look great. I grew up near Atlantikwall fortifications, and always imagined FS2 capships looking a bit like these after battle.
Imagine beams turning heavy armour plating into this : http://thumbs.dreamstime.com/x/molten-metal-blob-10520869.jpg http://thumbs.dreamstime.com/x/trou-de-remboursement-fine-sur-l-obstacle-rouill%C3%A9-5954174.jpg
And BP2 mass drivers doing that kind of damage on a Deimos : http://i34.servimg.com/u/f34/11/29/35/99/100_3212.jpg
-
I wish to bring up the long-deprecated experimental feature of damage decals, which I would also like to see combined with persistent surface explosion effects to simulate massive damage from hull breaches.
this would be awesome
-
I agree that ways to show permanent damage would be the best next graphical step, since it would add the most to immersion. I also agree with spoon that shields could use some love.
-
I agree that ways to show permanent damage would be the best next graphical step, since it would add the most to immersion. I also agree with spoon that shields could use some love.
I had missed that one and yer would love to see that, especially if the test code is still about
-
I had missed that one and yer would love to see that, especially if the test code is still about
It isn't. It got purged along with the rest of the DirectX code a long time ago; Any new implementation of this feature (and I wouldn't hold my breath for it) will have to start from scratch.
-
That would require a kind of a Valathil-like brilliant shader-fu to pull it off.
-
That's the other thing as well. The original decal code was made long before shaders were a thing in FSO; any new decal code would have to be based on Swifty's work here.
That being said, a working decal implementation would have a few nice sideeffects. Nameplates, for example, would be much easier to do using them (instead of the somewhat awkward way they're done now).
-
Yeah, if we were ever to do decals and better nameplates, they'd likely be a screenspace effect since we'll soon have deferred lighting available. It would be the easiest method of pulling it off but would prevent decals from being available on the forward shading pipeline.
-
The original decals were displayed as simple black burn marks on the surface of a ship. It was never implemented with beams however, because with slash beams, the number of times it makes contact with the hull is dependent on the frame-rate of the machine running the game. As a result, instead of a swath of damage, it would look more like the beam skipped its way along the target hull.
As for my concept of persistent explosions, the effect would have a single large explosion in the center of the impact point, that would be continuously looping. Then it would have a series of smaller explosion effects around it, crossing over with the edge of the central effect. This would give the impression of fires on the surface of the ship fed by hull breaches. Over time, the explosion cluster would shrink as the oxygen is consumed. As the explosions recede, the burn decal would be visible underneath. Obviously, only high-damage weapons would create damage to this extent, and perhaps like beam gutting, it only happens once a ship's overall hull strength drops below a certain level. All of these could easily be modder-controlled in the tables.
-
Yeah, if we were ever to do decals and better nameplates, they'd likely be a screenspace effect since we'll soon have deferred lighting available. It would be the easiest method of pulling it off but would prevent decals from being available on the forward shading pipeline.
I don't think that's a hindrance, really. If we maintain the forward renderer as the low-end fallback option, missing effects on it are a feature, not a bug.
-
I demand Anisotropy!
-
Oculus rift would be awesome....i know it's not the major improvement, but i'd really like to play diaspora with it :)
-
I would love to have a real multi-threaded FreeSpace :rolleyes:
Afaik it is still a single-core application? It would have a big performance boost... especially for all upcoming effects and 4k resolutions :).
Or instead of new graphiceffects, maybe some sound additions? Things like hardware accelerated surround sound, like in Retail. AMD TrueAudio or others... because ears are also very important :).
I think OpenAL uses EFX... but i am not sure if that is used correctly by FSO. Retail uses only EAX(1.0) afaik.
-
I would love to have a real multi-threaded FreeSpace :rolleyes:
Afaik it is still a single-core application? It would have a big performance boost... especially for all upcoming effects and 4k resolutions :).
There have been some experiments done with multi-threading. Unfortunately, since nobody wants to rewrite the entire engine, they've so far been limited to specific sections of the codebase, and the additional overhead tends to cancel out any performance improvements there.
Or instead of new graphiceffects, maybe some sound additions? Things like hardware accelerated surround sound, like in Retail. AMD TrueAudio or others... because ears are also very important :).
I think OpenAL uses EFX... but i am not sure if that is used correctly by FSO. Retail uses only EAX(1.0) afaik.
jg18 has been working on improvements to the sound code (http://www.hard-light.net/forums/index.php?topic=87972.0).