Cloofoofoo
Regular
Baking lighting allows for higher quality lighting. Depending on how the T&L code is written, there's not much difference between a single parallel light and baked in terms of speed, but the baked could look a lot better.
The raw polygon counts for some rooms seem like they might be hard to pull off. The 67k polygon room (it doesn't actually look like that much in that screenshot, but whatever) would have trouble running on the Dreamcast. The CPU load wouldn't be a problem if you settle for 30 FPS, but the amount of video memory needed to store the scene buffer would be difficult to work around. I would estimate it could use up to something like 2400 KB to 2700 KB of video RAM. Since you also need space for any character models, and the scene buffer is double buffered, you'd actually need over double that space, and there'd be no room left for textures left after the frame buffer gets factored in.
The estimate is worst case, though, when the entire map is visible. Only on screen polygons are stored by the hardware. If you're in the middle of the room, and you can't see the entire room at once, you wouldn't need nearly as much space. The problem would be when you begin to enter the room or stand in a corner, and pretty much the entire room model is in the screen boundaries at the same time.
If the engine had a good culling system to avoid submitting and storing geometry that can't be seen, it could still be possible. Like portal culling, so if you're entering the room, and parts of the map that are in the view frustum but can't be seen through the door, the parts you can't see are discarded. Another thing that would help would be manual backface culling on chunks of geometry, like if the map has a balcony, and the camera is looking towards it, but is below it, you can skip rendering the floor polygons of the balcony, even though it's in the frustum, since it would be facing away from the camera.
I doubt Sega's PVR driver supported this, but another way to get high per-frame polygons counts without giant scene buffers would be to run would be to macrotile the frame. Instead of storing the entire frame's polygons double buffered, you render part of the screen at a time (like half or a quarter), so you don't need room for the entire thing at once. You'd lose some performance, but save a lot of RAM.
Well it might not look it but soul reaver 2 took the same approach as part 1. Basically they subdivided the stages to make them polygon dense to get the baked in lighting in vertex color to look good. Ill post a wireframe. Well I know your always one dev yourself for answers on the dc hardware so Ill link you to level files for the lion room and the spectral realm so you can see it yourself. And baking the lighting would still allow to use a dynamic lightsource right if they wanted yeah?( i see one of the shots raziel has a point light attached to him)
They made sure their talking point was that this game ran 60 fps on dc so they must have had a very good culling system. You made me curious though so I ran it by the ps2 emulator with the vertex counter( yeah i know emulators arent too reliable) and it showed that it ran about 11k to 25k vertices per frame , so definitely alot of culling but it wasnt affecting the distance as you can see from end to end. I remember the homebrew dev of the lmp3d engine when working on his dreamcast branch mentioned he only double buffered the vertex buffer at 60 fps for optimal performance( which got him around 26k triangles) but at 30 fps he didnt need to and estimated he could comfortably do around 40k triangles per frame. So it isnt always needed isnt it?
Lion room : https://www.mediafire.com/file/yvba204vhic2k3j/airtemple2.7z/file
Spectral realm air temple: https://www.mediafire.com/file/fjhbxqfd9esp3uh/airtempspectral.7z/file
lion room wireframe:
Spectral room wireframe: