« News

Jan
24

Vendetta Online 1.8.322

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.