Polygon soup, Jarrod?
by Erik Madison · in Torque Game Engine · 08/25/2003 (1:03 pm) · 2 replies
Reading old posts, I've noticed many times the entire BSP system referred to as polygon soup, and statements on how its on the way out. Care to elaborate? Whats the next method?
After playing around with unrealEd for the first time, I fell in love with the idea of damn near everything being models/static meshes and overlaying a very basic bsp interior, so I've begun to build my Torque projects in this manner. Is this where you see everything headed, or am I still missing the point?
After playing around with unrealEd for the first time, I fell in love with the idea of damn near everything being models/static meshes and overlaying a very basic bsp interior, so I've begun to build my Torque projects in this manner. Is this where you see everything headed, or am I still missing the point?
About the author
#2
The problem with BSP implemenations in say Quake and every Quake engine derived game ( regardless of the version of Quake ) is the interiors are 100% static because they are compiled and lots of optomizations could be made because of the static requirement.
Lots of modern games are allowing for fully destructable environments ( Red Faction ) was the first main stream game I know that did this on a interiors, and TreadMarks has awesome real time deformable terrain using a modified ROAM 1 implemneation.
When I say BSP I mean compiled static BSP implementations, BSP Trees as a generic algorithm will always be used in visiblity and collision code, but the static pre-compiled BSP implementaions for "maps" is dead . . .
I have a Radeon 9500 ( softmodded and clocked up to a 9700 Pro class output ) and my experiments show that the cards are actually faster in lots of cases than games like Half-Life which actually chokes on bigger maps and has a frame per second limit that is obvisoulsy not a ceiling the card is imposing but the BSP implementation is imposing.
08/25/2003 (8:08 pm)
Ben is right, BSP is the opposite of a polygon soup renderer. Since modern graphics cards are so fast now, lots of new techniques for treating everything as equal is gettting more and more popular. All the new 3D graphics books are downplaying BSP implemenations in favor of polygon soup ROAM type implemenations with continous level of detail.The problem with BSP implemenations in say Quake and every Quake engine derived game ( regardless of the version of Quake ) is the interiors are 100% static because they are compiled and lots of optomizations could be made because of the static requirement.
Lots of modern games are allowing for fully destructable environments ( Red Faction ) was the first main stream game I know that did this on a interiors, and TreadMarks has awesome real time deformable terrain using a modified ROAM 1 implemneation.
When I say BSP I mean compiled static BSP implementations, BSP Trees as a generic algorithm will always be used in visiblity and collision code, but the static pre-compiled BSP implementaions for "maps" is dead . . .
I have a Radeon 9500 ( softmodded and clocked up to a 9700 Pro class output ) and my experiments show that the cards are actually faster in lots of cases than games like Half-Life which actually chokes on bigger maps and has a frame per second limit that is obvisoulsy not a ceiling the card is imposing but the BSP implementation is imposing.
Associate Ben Garney
BSP is going to be used anytime a static mesh needs to be rendered and queried efficiently. We may be able to move to the luxury of an undifferentiated polygon mass - ie, polygon soup - but only at a significant overhead.
I personally like the idea of reusing components, both in the worldcraft side (for instance, to create standard hallways) and in-game (interactive things like lightbulbs), but I'm no level designer. :)