Really good read, and takes me back to my younger days of feeling around in the dark trying to work out 'the one true way'. A couple of things that went throug

Really good read, and takes me back to my younger days of feeling around in the dark trying to work out 'the one true way'. A couple of things that went through my mind that I don't see mentioned, or is kinda brushed over: * You mention you originally rendered everything, then later moved to breaking into chunks? * How do you decide what's 'in view', do you do any culling? * You don't mention culling polygons that are pointing away from the camera? Sorry if I missed those, but my thoughts were: Use an octree [1] to register the scene blocks, you can then recursively intersect the viewport with the tree to find out what's in-view. There's perhaps even some cunning way you could 'rasterise' the blocks in the viewport using Bresenham's algorithm (tracing the edges of the viewport) [2]. In terms of the polygons facing away from camera, you can get the dot-product of the normal of the polygon and the vector of the camera. If it's negative then it's pointing away, if it's positive it's pointing toward the camera (or vice verse, I can't remember). In a tight loop that can be damn quick, and saves rendering something that can't be seen. Apologies if this is all obvious, and you're already doing it, or if it's all handled automatically. It's been over 10 years since I've had to do any of this stuff, so just dredging it from the depths of my memory ;) [1] http://en.wikipedia.org/wiki/Octree http://en.wikipedia.org/wiki/Octree [2] http://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm http://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm