WTF!!! Rendering System Broken

[Zini]

WTF and I would put that into bold even in the posting subject text, if our forum software would allow that.

It seems our rendering system is broken in multiple places. Stumbled upon it while trying to figure out what was wrong with the light. No progress with light yet, but what I see:

1. Batching seems to be completely disabled.
2. We don't clear up movable objects when removing a cell.

#2 was probably present right from the beginning. No idea if it causes us any harm. But why on earth didn't we notice #1 and when did that happen?

Right now I am too frustrated to continue with this crap (okay, also running out of time). I will try to put together a branch that at least fixes these problems on Monday.

[gus]

1. Batching seems to be completely disabled.

that's because every object is created with static_ = false in insert begin.

Edit: wow, was there some optimization done?? when i reactivate batching, i get 70-80 FPS in vivec, which is a way better than what I previously had (30-40 FPS iirc)!

Maybe we have an explanation: the refactoring(or something else) boosted performances a lot, so we did not even noticed batching was disabled

[jhooks1]

Just now I changed it to _static true in each class in mwclass, but it didn't make a difference. Am I missing something? Would love to see a performance improvement

[jhooks1]

Got it working now. 27fps animating all npcs, with 8 on screen, in the House of Earthly Delights

[gus]

Just now I changed it to _static true in each class in mwclass

That's a little... brutal^^ if you do that, you won't be able to pick up objects. The only class that should be static are (i think):
*static (obviously)
*container (not sure about this one, but i've never seen a container disappear in the original game)
*misc(?)

[Zini]

Static only for now. Misc and Containers can be moved freely. This is only stopgap anyway. We will have to refine the whole system when are move to more advanced batching. But we can worry about that later.

[Yacoby]

Probably worth rendering things like containers at batched geometry. I think it is possible to move statics so whatever we do at some point we are going to have to write something to remove an object from batched geometry.

[Zini]

Yeah. Basically the idea is to replace the boolean static/non-static distinction with a couple of modes. Let's say: is unlikely to ever move, might occasionally move, constantly moving. Probably more. We might give each of these a separate static geometry. Or group some of them together, if we find the rebatching isn't taking too long. We even may make this configurable.
We will need to develop some clever heuristics, because simply going by ID type (misc, activator, static, ...) won't get us there. I have some ideas, but that is a task for another day (and another release).

[jbo_85]

There's a bug in Actors::removeCell() in actors.cpp regarding the iterator usage there. You need to change the code to something like

Code: Select all

    for(std::map<MWWorld::Ptr, Animation*>::iterator iter = mAllActors.begin(); iter != mAllActors.end();)
    {
      if(iter->first.getCell() == store){
        delete iter->second;
        mAllActors.erase(iter++);
      } else {
        ++iter;
      }
    }

to not invalidate the iterator. The incorrect code caused a crash on cell-change in gdb but wasn't crashing without a debugger attached.

[gus]

Thanks! that caused a "silent" crash in my debugger, and i did not know what was wrong....