The framerate issues aren't really related to graphics at all. The problem is caused by all of the other systems throughout the game engine that are running. Creature AI updates, script execution, combat AI, etc. All those things take up CPU time and make it slower for the game engine to complete '1 loop' so that it can render the next frame. Which is why you'll probably find the slowest framerates in combat.
The trouble with framerates is a side effect of using what was essentially a PC game engine on a console. PC engines tend to be written with convenience and flexibility in mind. But the side effect of this 'designer friendly' approach is that the game is slower. Data is stored as strings more than binary data, and string compares are rampant throughout the code, which are overly expensive (CPU-wise) operations compared to alternative approaches.
Console-specific engines tend to be written a lot tighter. They tend to be far more memory efficient and clockcycle efficient. To solve these problems in KotOR2, we would have to have rewritten a lot of the engine, which the timeline for the project did not allow for. And even still, we made amazing improvements over many of the systems, it's just that we then turned around and pushed the systems harder than they had been pushed before.
Early on in the project, we roughly doubled the average framerate of KotOR1, but then added a lot more stuff to the areas and the framerate went back down. We're also loading roughly 2 to 3 times the data per area load that KotOR1 loaded, but we were able to speed the loading process up enough that the load times are roughly equivalent to KotOR1. If we were loading KotOR1 levels with our changes, the load times would have been much faster.
Most of the time, we considered KotOR1 the 'as bad as we can let it get' in terms of load times and framerates, then kept adding content to areas until the game slowed down to roughly the KotOR1 performance, figuring that was a safe baseline to operate from.
-Akari
