To the game code, the world is still just a tile map, but for rendering, each map was exported as a general-purpose 3D model, and the artists could then go through it and spend the polygons any way they liked, without the limits of line-of-constant-z software rasterization that we lived with on the mobile phones. You can't render all that many polygons on a DS frame, and you have to keep a healthy reserve to avoid ugly failure in dynamic situations, but the geometric freedom and vertex lighting/colorizing lets it look a heck of a lot better than any cell phone.
High level culling is still done by a front to back walk of a BSP based on the original tile geometry, with a one dimensional occlusion buffer being filled in as segments are processed. This is the thing that is most marginal right now, since if the "prettied up" 3D model diverges too far from the original tile geometry, you can get culling errors. I would do this differently, given a bit more time. An explicitly modeled 2D portal/occluder shell would be faster, more flexible, and slightly smaller in memory, but would require another new element in our production chain. Our next DS title will certainly use code from Orcs&Elves, but there will be significant changes.
