OSG port roadmap and design plans

[psi29a]

Congratulations! Extra features too and with less code overhead.

To be fair, do you think that this might be due to the second systems effect? You know, you're first is the prototype while the real application is the one you write afterwards with all the lessons learned?

In getting this far with OSG, are there any potential pitfalls you see ahead?

[raevol]

Yaaay awesome work scrawl! It all sounds very exciting!

[Chris]

I also took the opportunity to add some NIF features missing from the master branch, namely StencilProperty

As an aside, I wonder what NiStencilProperty's effect is supposed to be. The stencil buffer's purpose tends to be rather tightly bound to the rendering pipeline, and different rendering methods may use the stencil buffer differently. Stencil shadows, for instance (which I believe vanilla uses) masks out areas that fall into the shadow volume in screen space, with an on-or-off mask. However, modern shadow techniques use shadow mapping, which don't use the stencil buffer at all. With my deferred shading pipeline, for another example, the lowest bit of the stencil buffer would instead be used as a mask for surface materials that don't receive light (separately from shadows).

That makes me question whether we can properly implement NiStencilProperty, beyond simply setting the specified stencil state, and still expect it to function correctly without also replicating what the original renderer used the stencil buffer for (which we may not want to do).

[scrawl]

Stencil shadows, for instance (which I believe vanilla uses) masks out areas that fall into the shadow volume in screen space, with an on-or-off mask.

I considered stencil shadows might conflict, but it depends on how they are implemented. If it's a modulative pass rendered after the scene geometry, then using a stencil property in a mesh would not conflict with the shadow algorithm.

That said, stenciling requires a stencil buffer to work, which OSG doesn't even create by default. We can request one, but there's no point in doing so if it's not being used.

[Chris]

I considered stencil shadows might conflict, but it depends on how they are implemented. If it's a modulative pass rendered after the scene geometry, then using a stencil property in a mesh would not conflict with the shadow algorithm.

That said, stenciling requires a stencil buffer to work, which OSG doesn't even create by default. We can request one, but there's no point in doing so if it's not being used.

Right, that's what I mean. We don't currently have or use a stencil buffer for anything, and it's unlikely we'll use one for the same purpose vanilla did, so I don't imagine NiStencilProperty will ever work as it did with vanilla. Additionally, I imagine the rendering pipeline will be changeable as new rendering methods become doable, which could cause changes to how the stencil buffer is utilized. Thus, it doesn't seem as though stencil properties really belong in the models' material, and should instead be controlled by the engine.

[pcercuei]

The scrawl/osg branch does not build here (and actually never did), it tries to include some files that have been deleted in the repo. This is the kind of errors I get:

Code: Select all

../apps/openmw/mwrender/sky.hpp:14:10: fatal error: 'components/nifogre/ogrenifloader.hpp' file not found

[scrawl]

You're trying to build openmw, which is not expected to build yet. (it builds here locally, but that isn't pushed yet).

What I've used for testing is OpenCS, and a new target called "nifosgtest" which is a command line NIF file viewer.
To build them you just do

Code: Select all

make openmw-cs

or

Code: Select all

make test

or alternatively, open cmake and untick the BUILD_OPENMW checkbox.

[scrawl]

Long time no post... I've done some profiling recently, and now I'm implementing point light lists, which is the last missing feature before we can make "realistic" performance comparisons.

The basic issue is that MW environments contain a ton of lights, so to apply them efficiently you need to check which lights could possibly affect any given mesh before you render it.

Ogre did this automatically for us - for better or worse, as it wasn't very efficient doing so. OSG on the other hand while not offering this feature, gives us all the tools we need to implement it.

I have a proof of concept using push/popStateSet from a CullCallback, meaning we can inject state without actually modifying the scene graph. The CullCallback has access to the current modelview matrix and the node bounds, so from there we can determine what lights need to be active. For example:
- Get the list of all affecting lights
- If there's more than MAX_LIGHTS, sort by proximity to the camera
- Take the lights up to MAX_LIGHTS and sort them by their light IDs (this ensures a consistent ordering, so we don't create more than one StateSet for permutations of the same light list)

From there we could look at some optimizations, for example pre-culling the global light list by the camera frustum. Or reusing a similar enough StateSet when appropriate, e.g. one containing all the requested lights plus some extra ones. I'm sure keeping the unneeded lights enabled is cheaper than changing state again. Or skipping the callback if the scene currently has less than MAX_LIGHTS.

We also need to think about handling multiple cameras. Currently we have one camera only, but later on cameras for shadow mapping and reflection mapping will be added. For shadow mapping no point lights are needed, so this stage can skip the callback all together. Reflection mapping however needs it. We should be able to reuse at least partially the light lists from the scene pass. "reuse" may not be an appropriate word since OSG can run multiple CullVisitors in parallel when multiple cameras are used, so we'd need some form of synchronization. That's a bit further down the line though, I'll start looking at shadows and reflections once the game is fully playable.

I don't think we want to do it for every drawable. One of the supposed benefits of OSG is that it can better sort drawables by GL state to avoid unnecessary state changes. But if each drawable has a unique set of lights, thus unique state that's changing on every draw call, that would defeat the purpose.

But we need it per drawable in some cases. That is exactly the problem with the StaticGeometry approach in the Ogre branch. If you define a fixed region size we'll have the blinking lights back. I don't think anyone wants that. A more dynamic approach would be possible though. Applying a few heuristics (e.g. overall number of lights in the scene, bounds of the current node) we can probably attach the callback to a Node in some cases instead of the Drawable. A very small mesh consisting of multiple sub-meshes wouldn't need a fine grained light list.

I'm not sure if that's worth the effort though. I found that if pushing the same StateSet pointer, OSG is smart enough to not change any state. So for drawables with the same light list, in theory no light state changes need to be made, and the state tracking shouldn't have a big overhead given that all it needs to do is compare the StateSet pointers. I haven't tested though how that interacts with state sorting.


Oh, and before Chris mentions deferred shading again: yes, that is a solution too, but it has implications on the renderer architecture that I do not want to commit on right now. For one, implementing vertex lighting would be impossible, which is necessary for vanilla assets compatibility (don't laugh, it really is - they're using negative lights in some corners to achieve ambient occlusion, but with pixel lighting that just looks like a black spot. That, and some lights at the ghostgate). Second, I highly doubt performance would be better, given the bandwidth requirements.

[raevol]

Thanks for the update scrawl! Looks like working with OSG is giving you a real workout for rendering stuffs... fun fun.

If anyone wants to keep up with scrawls commit activity on his OSG work, you can look here: https://github.com/scrawl/openmw/commits/osg

[Chris]

I have a proof of concept using push/popStateSet from a CullCallback, meaning we can inject state without actually modifying the scene graph. The CullCallback has access to the current modelview matrix and the node bounds, so from there we can determine what lights need to be active. For example:
- Get the list of all affecting lights
- If there's more than MAX_LIGHTS, sort by proximity to the camera
- Take the lights up to MAX_LIGHTS and sort them by their light IDs (this ensures a consistent ordering, so we don't create more than one StateSet for permutations of the same light list)

If it's going to get its own unique list of lights, wouldn't it make more sense to first sort them by proximity to what's being lit? Otherwise you'll have lights that are close to the camera and far from the lit surface, fighting with greater priority over something closer to the lit surface but farther from the camera, causing more blinking light problems. You'll also need to take into account the brightness and rolloff, since a nearby dim light should have less priority than a really bright light that's a bit farther away.