Forums » General
Vendetta Online 1.8.322
Cross-posted from News..
VO 1.8.322 includes:
- Added prototype shadows to Linux OpenGL 4 driver. This implementation differs from the DirectX 11 version in that it uses a Percentage Closer Filter with a Poisson distribution to anti-alias the shadows.
- Added dynamic light sources to more "neon-style" signs, visible in the prototype DX11 or OpenGL drivers.
- Decreased the font size of the account conversion menu for mobile devices.
Getting closer to wrapping up our work on the renderer, we should hopefully have just a bit more related work, and then be done for awhile.
Shadows are kind of an interesting set of challenges, as each algorithm comes with its own set of visual problems (artifacts) that need to be mitigated. We're using 4X anti-aliased variance shadow maps (VSM) on DX11, as we appreciated the smooth shadow edges we get from anti-aliasing, but we don't love its inherent problems with thin-object shadows "fading in" near their origin.
Thus, on OpenGL (for Linux, not yet for Mac) we're testing an implementation of traditional Percentage Closer Filter (PCF) shadow maps using a poisson disc to smooth the edges. This has the added benefit that it can be implemented on mobile by packing floats into RGBA, where this is not really possible (or is at least highly problematic) with a numerically-unstable variance algorithm. It may also be a little faster on older hardware (and uses less memory); but really, shadows have not been a big speed hit for us, compared to dynamic lighting and other factors. Unfortunately, PCFs also come with their own set of visual problems/artifacts, issues like shadow acne, a kind of flickering of maps appearing on certain surfaces, that have to be optimized with specific bias settings. There are particular challenges with rounded rotating asteroids. But on average it looks pretty good (which can be said about either algorithm).
In both cases, the maps are placed on a single texture atlas for all four cascade levels. Cascades being shadow maps rendered to cover various distance-ranges, so you get high resolution close to you, but lower resolution off in the distance. Because of our huge view distance (20km or more), we're probably going to need another set of cascades to achieve the desired "final" fidelity on PC, but it's not bad as it is.
So far, these algorithms have all been implemented for relatively fixed, "directional light" shadows coming from the primary lightsource (the nearest star/sun), but we intend to also add another couple of cases. Omni/spot lights under some situations (short distance shadows that don't travel far, cast by ship engines, for instance) will add a lot of nice effect with movement; a capship flying near a station or asteroids, for instance. Similarly, a special shadow map on your own ship (for 3rd-person views) will add a lot higher fidelity to self-shadowing than what we can achieve using the cascades-covering-20km.
It's very common for game engines to use several different types of shadows for different environments and effects. Variance shadow maps can be easily blurred in hardware, for instance, where PCF shadow maps cannot. Thus, if we want to create heavily softened maps for omni lights in a fogged sector, for instance, that might lend itself to VSMs. Or, even with all directional and omni lights in unfogged scenes using anti-aliased VSMs, we might still use a PCF for self-shadowing your ship, so that all small details are sharply shadowed and defined (even when the shadow-caster is relatively small or thin, like a winglet or turret).
As always, game development is a series of calculated tradeoffs to try and achieve a desired effect. There are few ideal solutions, mostly it's based on what works best for the specific kind of game, content, environment, desired experience, etc. This is one of the reasons we've been happy to have our own in-house engine. While we may spend time on this kind of R&D, where shadows might simply be a "check box" on an available middleware engine, we're doing the best implementation for our specific situation. Most engines are built for first-person shooters and/or lightweight "casual" games, not for open-world space MMOs with galactically-gigantic universes. Even at triple-A studios who are actually making first-person-shooters (many friends of ours), they often end up spending practically the same amount of time heavily-modifying and "hacking" the middleware engine to do what they want, a sometimes-ironic set of tradeoffs.
Of course, back when we started in the mid/late 90s, there practically were no middleware engines anyway, let alone the free ones of today (the quake1-test debuted about the time we were building network code, and by the time Unreal shipped, VO was recognizably playable). But even so, being able to implement our own optimal solution to our specific set of challenges has always been a strength, and the game is better for it.
VO 1.8.322 includes:
- Added prototype shadows to Linux OpenGL 4 driver. This implementation differs from the DirectX 11 version in that it uses a Percentage Closer Filter with a Poisson distribution to anti-alias the shadows.
- Added dynamic light sources to more "neon-style" signs, visible in the prototype DX11 or OpenGL drivers.
- Decreased the font size of the account conversion menu for mobile devices.
Getting closer to wrapping up our work on the renderer, we should hopefully have just a bit more related work, and then be done for awhile.
Shadows are kind of an interesting set of challenges, as each algorithm comes with its own set of visual problems (artifacts) that need to be mitigated. We're using 4X anti-aliased variance shadow maps (VSM) on DX11, as we appreciated the smooth shadow edges we get from anti-aliasing, but we don't love its inherent problems with thin-object shadows "fading in" near their origin.
Thus, on OpenGL (for Linux, not yet for Mac) we're testing an implementation of traditional Percentage Closer Filter (PCF) shadow maps using a poisson disc to smooth the edges. This has the added benefit that it can be implemented on mobile by packing floats into RGBA, where this is not really possible (or is at least highly problematic) with a numerically-unstable variance algorithm. It may also be a little faster on older hardware (and uses less memory); but really, shadows have not been a big speed hit for us, compared to dynamic lighting and other factors. Unfortunately, PCFs also come with their own set of visual problems/artifacts, issues like shadow acne, a kind of flickering of maps appearing on certain surfaces, that have to be optimized with specific bias settings. There are particular challenges with rounded rotating asteroids. But on average it looks pretty good (which can be said about either algorithm).
In both cases, the maps are placed on a single texture atlas for all four cascade levels. Cascades being shadow maps rendered to cover various distance-ranges, so you get high resolution close to you, but lower resolution off in the distance. Because of our huge view distance (20km or more), we're probably going to need another set of cascades to achieve the desired "final" fidelity on PC, but it's not bad as it is.
So far, these algorithms have all been implemented for relatively fixed, "directional light" shadows coming from the primary lightsource (the nearest star/sun), but we intend to also add another couple of cases. Omni/spot lights under some situations (short distance shadows that don't travel far, cast by ship engines, for instance) will add a lot of nice effect with movement; a capship flying near a station or asteroids, for instance. Similarly, a special shadow map on your own ship (for 3rd-person views) will add a lot higher fidelity to self-shadowing than what we can achieve using the cascades-covering-20km.
It's very common for game engines to use several different types of shadows for different environments and effects. Variance shadow maps can be easily blurred in hardware, for instance, where PCF shadow maps cannot. Thus, if we want to create heavily softened maps for omni lights in a fogged sector, for instance, that might lend itself to VSMs. Or, even with all directional and omni lights in unfogged scenes using anti-aliased VSMs, we might still use a PCF for self-shadowing your ship, so that all small details are sharply shadowed and defined (even when the shadow-caster is relatively small or thin, like a winglet or turret).
As always, game development is a series of calculated tradeoffs to try and achieve a desired effect. There are few ideal solutions, mostly it's based on what works best for the specific kind of game, content, environment, desired experience, etc. This is one of the reasons we've been happy to have our own in-house engine. While we may spend time on this kind of R&D, where shadows might simply be a "check box" on an available middleware engine, we're doing the best implementation for our specific situation. Most engines are built for first-person shooters and/or lightweight "casual" games, not for open-world space MMOs with galactically-gigantic universes. Even at triple-A studios who are actually making first-person-shooters (many friends of ours), they often end up spending practically the same amount of time heavily-modifying and "hacking" the middleware engine to do what they want, a sometimes-ironic set of tradeoffs.
Of course, back when we started in the mid/late 90s, there practically were no middleware engines anyway, let alone the free ones of today (the quake1-test debuted about the time we were building network code, and by the time Unreal shipped, VO was recognizably playable). But even so, being able to implement our own optimal solution to our specific set of challenges has always been a strength, and the game is better for it.
Must be a nightmare keeping up with all the changes Inc. We do appreciate that it all takes a while and that it has to be done to keep the game up to date.
Hey Inc!
Thanks for giving us an insight about game development R&D. For me it was really interesting to read. I'm just more keen on, how cool the other stuff will look that are also in the pipeline.
Keep up the good work!
Thanks for giving us an insight about game development R&D. For me it was really interesting to read. I'm just more keen on, how cool the other stuff will look that are also in the pipeline.
Keep up the good work!
Yeah, it's great to hear fellow-programmers in a completely foreign field (I'm into automatic text processing) talk about their troubles and trade-offs.
Inc, you might not be at liberty to talk about it, but I can imagine that if you would be able to license your engine it might make the whole model a lot more sustainable, and the "works across platforms" should be a great selling point I think? Or would it take so much work to turn the engine from something written for VO into something more generally applicable that it wouldn't be worth the hassle?
Inc, you might not be at liberty to talk about it, but I can imagine that if you would be able to license your engine it might make the whole model a lot more sustainable, and the "works across platforms" should be a great selling point I think? Or would it take so much work to turn the engine from something written for VO into something more generally applicable that it wouldn't be worth the hassle?
@vanatteveldt: http://www.naos-engine.com/
"Sign Up for the Alpha Test - We're looking for developers to help us test the engine, when it becomes available. There will be no cost associated with this, we're just looking for feedback on how to make our engine best fit your needs."
I am curious whether the engine is actually generating any sales, and if so, what other products are (planning to) use the engine. Inc's statements about the joys of building your own engine is probably true, but it is also quite a heavy load on dev time, so I guess you would ideally share the cost between multiple products...
I am curious whether the engine is actually generating any sales, and if so, what other products are (planning to) use the engine. Inc's statements about the joys of building your own engine is probably true, but it is also quite a heavy load on dev time, so I guess you would ideally share the cost between multiple products...
No, it isn't generating any sales, it isn't a released product yet.
The shadow effects are really cool. After the update I went flying around and the ship shadow actually surprised me. heh Keep up the good work guys. :)
This is clearly an anti-pirate update. Now all the unsuspecting miners will see pirates' shadows on their rocks in advance, giving them early warning. Can't believe the VO devs pander to these ninnies.
:P
:P
Assuming the traders don't mine from the shadowed side of the roid like a noob, anyway.