Zini wrote:
We have backface culling and culling against the Frustrum. Also the terrain will probably implement culling. Currently we have no further plans.
It is possible, that we will implement more culling once OpenMW 1.0.0 is reached, but I wouldn't consider it a priority. Culling beyond these special cases is still complex and computing-intensive. Indiscreet culling in a scene as general as MW outdoors can easily lead to a slowdown instead of a speedup.

gus wrote:
As far as I understand, Ogre OctreeSceneManager do some culling, and i think it's the same for the new terrain SceneManager. But of course, batching kills culling

Tes96 wrote:
Culling is where the computer game doesn't render things you can't see in your field of view? You're saying that OpenMW will be able to do some of that but not completely and that the more you try to implement it, the more it will slow down the game?

gus wrote:
You have to find the right balance between culling and batching. Batching mean sending several object together to the graphic card. Having a high number of batches ( = a call to the graphic card) kills performances.

If you do extreme batching, you can send the whole send in one call to the graphic card (basically you see the scene as only one big object). But in this case , no culling is possible, as this object will always be in you field of view.

So more batching means less culling (as when several objects are in a batch, even if only one object is in the field of view, all object will be rendered).
The whole thing is about finding at which point batching starts to reduce performances.

Tes96 wrote:
So how are games like Crysis Warhead able to render so much data and graphics without killing fps like how TESIII does? Does Crysis Warhead use very little batching and mostly culling?

Chris wrote:
Games like Crysis are able to make use of many GPU features that simply weren't available at the time Morrowind was released. To Morrowind, a Geforce 4 was high-end, while to Crysis, a Geforce 4 is a baby's toy. Graphics cards have added a lot of features that help take the load off the CPU and help streamline calls to the GPU. Morrowind works inefficiently simply because there was no better way to do it.

gus wrote:
I am by far not an expert, but if I remember well Crysis use a complex d very efficient culling algorithm that also cull objects hidden by the terrain and such.

It also use (I think) technologies equivalent to the PagedGeometry addon of Ogre, which render objects that are far away as a plan. This really improves performances, and as far as I remember, it's possible to do some batching there.

But it's almost sure there are some batching as having more than 500 batches (ie 500 objects) kills performances. But it must batch (ie group objects together) taking geographic location into account, thus allowing culling.
In OpenMW this could be implemented by grouping together all the objects of the same Cell. This way, each cell is seen as one big object, and it is possible to cull Cells that are not in you field of view. That is what I am currently working on.

In Morrowind, I am fairly sure there were some batching, but complex culling algorithm were too much for the CPU I think, and things like PagedGeometry could not be implemented because it require directX 9 I think.

Chris wrote:
There's also instancing, which allows the GPU to draw something multiple times from one call. I also don't think Morrowind made use of hardware skinning, which is what allows the GPU to do the vertex transformations for skeletal animation... meaning for every animated mesh, Morrowind would have to transform all its vertices' positions, normals, binormals, and tangents on the CPU and reupload them to the card, on each frame.

sir_herrbatka wrote:

things like PagedGeometry could not be implemented because it require directX 9 I think

I guess that It works with opengl as well since supported platforms are windows AND linux and OS X.

Greendogo wrote:
So, after all is said and done, will OpenMW have better performance than vanilla MW? I mean, that's the goal right?

sir_herrbatka wrote:
for now it would be fine to get morrowind-like performance on with all morrowind things to render. But after this stuff we should get better performance at least on more modern hardware.

gus wrote:
I don't think so. That's the downside of using libraries like Ogre: that's a way faster to implement, but performances cannot be as good as with raw DirectX. And Morrowind was designed for older hardwares.

But we might implement pagedGeometry which would allow modders to add forests. And performances *shouldn't* drop too much even if we add high res textures or even shaders on modern hardwares (as it seems that much of the time spend in graphic rendering is spend sending data's to the graphic card, not in "real" graphic processing itself).

PS: i reinstalled Oblivion. In fact, there are less objects than in Morrowind. The big differences is tree and grass. As i said before, PagedGeometry can help us with this.

Chris wrote:

gus wrote:I don't think so. That's the downside of using libraries like Ogre: that's a way faster to implement, but performances cannot be as good as with raw DirectX.

I dunno. I think the same argument could be made as with C over assembly. Sure, if you're really really good with assembly (DirectX/OpenGL), you could probably write code that's faster than C (Ogre3D), but most people aren't that good, and the compiler (Ogre lib) will probably do a better job than you, especially if you want to take advantge of modern features (both for graphical effects and processor efficiency). You'd end up having to rewrite a bunch of Ogre yourself, just so you can try to tweak a few things to your specific needs.

Performance, I think, will largely depend on how good Ogre actually is, and how well OpenMW can properly utilize it. Don't forget, too, that Morrowind used a middleware renderer.

That said, it's likely performance won't be as good as vanilla Morrowind on the hardware Morrowind was designed for.. mainly because Ogre is more modern, thus more optimized for modern hardware, so code paths for older hardware may not be so well optimized.