Ok so at the moment engines send vertices & polygon soups to the gfx card. Is it or will it ever be possible to instead send planes of a brush to a gfx card ? This will make CSG operations very elegant.
That seems unlikely given the current implementations of high-performance hardware. Doing CSG with a large number of planes per fragment wouldn’t be very fast. And if you turn the planes into geometry on the GPU, then that’s not really different from doing it on the CPU; it’s a general-purpose processor at that point. Might as well use the general-purpose processor you already have.
Note that BSP-based geometry representations like you’re talking about are mostly used by Quake derivatives – that’s not the only, or even best, way to represent geometry. Especially when you want to be outdoors.
well the way im thinking of representing my geometry is to model each brush in the world with bounding planes. I am doing this so that i can do CSG subtract ops in real time.
As you just pointed out, ill have to turn the brushes into polygon soups on the CPU.
So what is your better way of representing geometry?
I may be wrong, but I believe that the early PowerVR 3d accelerators were actually using infinite planes, so developers preferred to code in Glide (triangle soup) instead of PowerVR.
IMHO, the best way of representing geometry depends on what you need.
heightfield for outdoors, bsp/portal for simple indoor, triangle soup for detail and furniture, catmull-clark for smooth surfaces, etc.
Originally posted by ZbuffeR:
I may be wrong[…]
no you are not worng. this is absolutely correct. because of this, the poverVR was also capable of doing realtime shadows on the hardware!