So while discussing this topic with a friend, we came across some disagreements. How long have commercial game engines been supporting curved surfaces? Which well-known engines (past and present) support them, and which ones don't? Thanks. [Edited by - HalcyonX on January 20, 2006 9:50:56 PM]

It was a 'big deal' of sorts when Q3 came out with curved surfaces, and that was about 6 years ago (I think there was one or two other engines that implemented the functionality at about the same time). Even then though, the technology wasn't particularly mysterious; the method used (biquadratic Bezier patches) is very straightforward.

Other games have used bicubic patches (e.g. for terrain). There are also NURBS and subdivision surfaces, but I don't know how commonly those are used in practice, nor what engines today are doing in general. I would assume though that most current engines at least offer support for Bezier patches.

Quote:Original post by Toji
As the above poster said, it was a big deal in Q3, because at that point triangles were still precious resources. You skimped wherever you could.

Any more, though, the number of triangles are not a big deal. It more a matter of how many passes you can render, and keeping everything grouped in big batches. As such. most modern curved surfaces in games (Doom 3, for example) are pre-calculated and stuck in as static geometry. Dynamic curves still have their place, but it's become impractical and unnessicary in games.

The way the Q3 engine was designed didn't allow for a shape to have shared normals and smoothed lighting. If you made a rounded wall or a cylinger out of rectangles you would always see the edges. The curved surfaces of Q3 provided a way to do that.
If you design your engine a different way, or if you use meshes with shared normals you can make perfectly smooth looking structures, the Q3 way is no longer neccesary.
Cards like the ATI radeon 8500 added hardware support for splines and surfaces, but I don't know if games ever used those, or if they are still supported on modern hardware.

To me the issue comes down to when curved surfaces become a hardware accelerated primitive. Otherwise tri's will always be faster. Basically when you send the curve to the GPU (which btw is tons faster than vertex and index data), the GPU would have to tesselate the surface into tri's. It's my understanding that ton of optimizations are made at the driver level with the assumption that the vert buffer is a fixed size. With that assumption, the driver can manipulate the vert buffer and arrange it to a native format or whatever. With modern HW, we would basically get the situation where we have to write the new verts INTO a previously submitted (and optimized) vertex buffer (which previously had only contained the the control points of the curve). This completely blows out the vertex cache coherency on the card and we lose a ton of optimizations. I'm not a hw guy but this is my understanding why we don't have accelrated curves and why p-curves went beta-max on us and died on the early version of the geforce cards.

Yooooo...I have crazy visions of HW-accelerated sub-D surfaces....someday!!!! :)

Quote:
Not true! That was actually one of the big plusses of the system, that curves only used a lot of triangles when viewed up close. Back then, dynamically using less triangles when needed was faster than a static array with more geometry. This is simply no longer the case. In any case, however, the curves were indeed dynamic UNLESS you had the curve detail cranked all the way up.

I don't believe that your are right here. I just loaded up Q3 enabled cheat mode and used the console command "r_showtris 1" to render triangles in wireframe. The tesselation of bezier patches does not change based on viewing distance. You can however set a global tesselation level using the "r_subdivisions" command.

Quote:Original post by DonnieDarko
I don't believe that your are right here. I just loaded up Q3 enabled cheat mode and used the console command "r_showtris 1" to render triangles in wireframe. The tesselation of bezier patches does not change based on viewing distance.

Actually it does, but you may have to have things set a certain way. Interestingly though the lod algorithm does not take field of view into account, so if you zoom in on a curved patch it will retain the lod corresponding to the viewing distance (and therefore not look very smooth).

Quote:Original post by jyk
[Actually it does, but you may have to have things set a certain way. Interestingly though the lod algorithm does not take field of view into account, so if you zoom in on a curved patch it will retain the lod corresponding to the viewing distance (and therefore not look very smooth).

I just rechecked and you are absolutely correct. I had r_subdivision set too high and hence it was hardly possible to see any difference in the dynamic subdiv levels. [embarrass]