MoroseTroll on 31/10/2009 at 06:58

---

Albert: I think the Dark Engine's lighting is similar to the Quake 1&2' one. Could it be improved? Probably. But right now, I think, OPDE Team has different goals :).

Volca on 31/10/2009 at 14:09

---

Interesting question. From time to time I try to tackle with the graphics improvements from different standpoints, purely on "paper". I'd love to improve the rendering by introducing fully dynamic lighting and shadows, for sure (but it is low on the list). There are some problems along the path to get there though:

1. The amount of lights in dark is quite big. Some classification would have to be done (which to shadow, which not to shadow).
2. Extensive use of omnidirectional lights complicates things: Omni lights have expensive shadow maps (f.e. Ogre3d does not even do them, it reduces them to spotlights for shadow purposes). Shadow volumes could be used instead but:
3. The nature of the WR (interior based maps) complicates shadow volume handling. A custom shadow volume solution would have to be written and could be easily really expensive (it is easy to conclude that some portal edges would make up the silhouette, but that seems to break when reaching the next portal). If anyone knows a good paper about stencil based light volume lighting (logic needs to be inverted for global lighting, so we would render light volumes instead of shadow volumes) please inform me.
4. I sort of dislike stencil based volumetric shadows. This is one of the reasons I dislike both Doom 3 and Thief 3 graphically. Much better volumetric shadow solutions are based on penumbra wedge rendering techniques, but those need much more CPU and GPU horsepower so are rarely used even in today's games.

That's about it :)

Volca on 31/10/2009 at 14:36

---

Yep, read a few of them, tried to understand with my limited understanding of advanced graphics. Biggest problem would be to adapt these to the interior based rendering (if even possible, everything is reversed then)

Volca on 31/10/2009 at 14:50

---

You mean Room Portal by that. Then there are the WR portals used for rendering. It all works like this:
WR is a collection of Convex cells, with polygons making them up. Some of the polygons are portals, meaning that instead of rendering them, the cell connected to the portal from other side will be rendered (etc. etc.). Due to this approach, using volumes for global shadows in fact means introducing light volumes instead of shadow volumes. If you think about it for a while you'll realize these light volumes have some properties totally inverted compared to shadow volumes.

Stencil shadow volumes use front faces to increment stencil, back faces to decrement stencil, with non-zero stencil value meaning shadow. This logic does not work on endless light volumes. Thus exclusive, per cell volume chunks would have to be constructed - and these would be quite expensive to compute.

We have light propagation for dynamic lights computed in a similar way to this, only cheaper because no geometry is constructed from those. Still it was a huge throttle to try those with all lights in mission (see DarkLight::traversePortalTree).

Object only shadows would somehow work, with ghost shadows through walls.

Edit: I invite anyone who would want to try this, of course.

Albert on 30/11/2009 at 02:40

---

Some sort of boolean-operator trick, possibly? Heh, I should stop while I'm ahead.

But it seems to have slowed down again... Is it just the holidays, I'm guessing?