Curved surfaces, why not?

jpr27

Regular
I just have a quick question regarding curved surfaces in gaming.

Why are they not integrated into our 3d games in some for say per pixel etc? Im not a 3d graphic engine expert by no means but i just wondered why curved surfaces cannot be per pixel "or something close" to defeat the jaggies? Although current and future generations of graphics cards are able to push millions of polygons wouldnt it be feasable to use a form using pixels or other means to form curves? If you figure in AF and AA that even takes more power and bandwidth to the process.

I was told awhile back that it took to much computational power to do but at this stage shouldnt we start playing with the idea of using something such as curved surfaces using pixels or other methods?

Do you think we will ever come to a point of using curved surfaces and if so when?

Thoughts?
 
Well it is possible to use nurbs and true cruved surfaces, many well almost all raytracing engines use this technique, but gfx cards today are all polygon base as you well know, so this technique has to be done for the most part on the cpu, well it can be done on the GPU as well, but results are still pretty much unplayable. Maybe in 5 or 10 years it will be, but for now just not enough processing power. I don't see gfx card companies making raytrace chips and dropping polygon base so its going to be a while. It would be nice though, there are a couple companies out there that I've heard about that are making raytrace gfx cards, but they won't be ready for a while plus most likley will be targetting VR and other markets, not paticular to gaming.
 
If I recall Nvidia's first GPU could do quadratic interpolation, and thus render curved surfaces. However, at the time it was a pain to work with, athough I doubt that would be such a problem if they were to re-introduce it today. Although, they're probably better off just going with raytracing hardware with geometry shaders (i.e. a shader that determines intersection points for cast rays and assists with culling).
 
jpr27 said:
I just have a quick question regarding curved surfaces in gaming.

Why are they not integrated into our 3d games in some for say per pixel etc? Im not a 3d graphic engine expert by no means but i just wondered why curved surfaces cannot be per pixel "or something close" to defeat the jaggies?
If you mean "jaggies" in the usual sense of the word, i.e. aliasing, then curved surfaces will not eliminate the problem. If you just mean that objects look angular, then, yes, there may be a modelling problem.

Although current and future generations of graphics cards are able to push millions of polygons wouldnt it be feasable to use a form using pixels or other means to form curves?
The usual approach to handle curved surfaces is to first tesellate the curves into polygons and then render them. Once the triangles get down to a certain size, you can't tell the difference anyway. It works quite well - even a handheld device can do this. In that link, if you look at the top row of images of the "Utah teapot", somewhere between the 2nd and 3rd column of images the tessellated version will be indistinguishable from the bezier definition.

If you figure in AF and AA that even takes more power and bandwidth to the process.
Why is texture filtering relevant to this?
 
Tessellation to tiny triangles really brings down the efficiency of today's quad-based architectures relying on framebuffer compression.
 
IMHO the biggest problem with curved surfaces is that a paradigm change is necessary to make use of them. And this won't be easy for programmers who dealt with triangles all the time. Another problem is that there is no standard curved surface, but a multitude of different types. So curved surfaces need to be standardized before any HW or API implementation. (IMHO Bézier triangles of 2nd (or maybe 3rd) order are the most flexible for this purpose.)

BTW they would cause a great performance impact on transform-limited apps.

Razor1 said:
Well it is possible to use nurbs and true cruved surfaces, many well almost all raytracing engines use this technique, but gfx cards today are all polygon base as you well know, so this technique has to be done for the most part on the cpu, well it can be done on the GPU as well, but results are still pretty much unplayable. Maybe in 5 or 10 years it will be, but for now just not enough processing power. I don't see gfx card companies making raytrace chips and dropping polygon base so its going to be a while. It would be nice though, there are a couple companies out there that I've heard about that are making raytrace gfx cards, but they won't be ready for a while plus most likley will be targetting VR and other markets, not paticular to gaming.
@Razor1: I think you're mixing up raytracing and curved surfaces. Raytracing isn't necessary for curved surfaces. They can be rasterized the same way as polygons (triangles).
 
Mate Kovacs said:
IMHO the biggest problem with curved surfaces is that a paradigm change is necessary to make use of them. And this won't be easy for programmers who dealt with triangles all the time. Another problem is that there is no standard curved surface, but a multitude of different types. So curved surfaces need to be standardized before any HW or API implementation. (IMHO Bézier triangles of 2nd (or maybe 3rd) order are the most flexible for this purpose.)
Unfortunately, I believe you need 4th order Bezier triangles in order to satisfy some continuity constraints. Off the top of my head, I think 4th order is necessary to just achieve C1/G1 continuity!

I personally think that (rational) bicubic Beziers would be a sensible choice as a base building block as it's easy to map many other forms into this base type.
 
Rational is nice, can do true spherical surfaces ... and if you can combine the division with the perspective transform they aren't really that expensive either.
 
Simon F said:
Off the top of my head, I think 4th order is necessary to just achieve C1/G1 continuity!
Please tell me more about that! I thought that an arbitrary C1-continuous surface can be (*) approximated with quadratic Bézier triangles in such a way that the result is also C1-continuous (with just satisfying some simple constraints when joining them together).

* I edited it, because a sphere came to my mind. :)
 
Mate Kovacs said:
IMHO the biggest problem with curved surfaces is that a paradigm change is necessary to make use of them. And this won't be easy for programmers who dealt with triangles all the time. Another problem is that there is no standard curved surface, but a multitude of different types. So curved surfaces need to be standardized before any HW or API implementation. (IMHO Bézier triangles of 2nd (or maybe 3rd) order are the most flexible for this purpose.)
I don't think it's that difficult. DX9 already supports Bézier, B-Spine and Catmull-Rom patches (up to cubic). However, every single patch requires one draw call.
If you have a programmable unit that can do the tessellation, no standardisation on the type of surface is required. And support for curved surfaces doesn't change the workflow too much IMO. Modellers certainly already know and use curved patches. You need to adjust bounding boxes and other special cases, and maybe do less work like silhouette finding on the CPU.
 
Xmas said:
[..] And support for curved surfaces doesn't change the workflow too much IMO. Modellers certainly already know and use curved patches. You need to adjust bounding boxes and other special cases, and maybe do less work like silhouette finding on the CPU.
What if you want to do per-patch collision detection for physics? It's far more difficult than per-triangle collision detection. Another thing: tessellation doesn't solve the problem of transform-bound apps.
 
physics will not be hurt by tesselation at all, since the animated mesh is sent from the cpu to the GPU, GPU tesselates and then renders, the CPU only has to caculate physics from the non tesselated object.

Also raytracing with polygons is a very bad thing. Raytracing really needs to be done with nurbs. The problem with raytracing with polygons is each polygon has to be calculated as an individual object.

This is why raytracing with polygons is very slow, true cruves are easiest with nurbs, and thats why I mentioned raytracing. And doing lighting the way we are now is pointless on a nurbs surface.
 
MfA said:
Rational is nice, can do true spherical surfaces ... and if you can combine the division with the perspective transform they aren't really that expensive either.
Absolutely. Not just spheres but any conic section.

Mate Kovacs said:
Simon F said:
Off the top of my head, I think 4th order is necessary to just achieve C1/G1 continuity!
Please tell me more about that!
With a quadratic Bezier triangle, you don't have any internal points, so you can't control the cross edge tangents at all.

With a cubic, you have one internal point which still doesn't give you sufficient degrees of freedom to make C1 joints with the neighbouring triangles.


I thought that an arbitrary C1-continuous surface can be (*) approximated with quadratic Bézier triangles in such a way that the result is also C1-continuous (with just satisfying some simple constraints when joining them together).

* I edited it, because a sphere came to my mind. :)
Approximated perhaps, but that's not as interesting :). To get an exact representation of a triangular piece of a sphere with a rational Bezier triangle you again need to go to quartic.

OTOH, you can represent a sphere exactly with 8 rational bi-quadratic patches, but you do need to collapse the top edges to a single point (i.e. North/South pole) . I meant to do a demo of this with the MBX curved surface system but ran out of time.

Apparently, you can also use 6 bi-cubic patches, but I don't know how to do that myself. I certainly know it's impossible to do it with only two patches (after trying to solve many very hairy equations (and that is why I ran out of time :? )).
 
Razor1 said:
Raytracing really needs to be done with nurbs.
Yuck, I wouldn't do it with NURBS. It'd be much better to at least convert these to rational Beziers.
 
Mate Kovacs said:
What if you want to do per-patch collision detection for physics? It's far more difficult than per-triangle collision detection.
It may be more difficult but you would have far fewer patch-patch tests than triangle-triangle tests.

Another thing: tessellation doesn't solve the problem of transform-bound apps.
I raised this with MS some time ago but you could transform your control points then tessellate, thus eliminating much of the work.
 
Razor1 said:
physics will not be hurt by tesselation at all, since the animated mesh is sent from the cpu to the GPU, GPU tesselates and then renders, the CPU only has to caculate physics from the non tesselated object.
Yup, and who said it will? :D

Razor1 said:
The problem with raytracing with polygons is each polygon has to be calculated as an individual object.
[offtopic] Negative, sir! There are efficient algorithms for convex polyhedrons (which terminate early when the intersection-test fails). So only convex parts has to be calculated as individual objects. [/offtopic]

Simon F said:
With a quadratic Bezier triangle, you don't have any internal points, so you can't control the cross edge tangents at all.
What do you mean by "internal point"? Maybe I'm wrong, but what I know under the term "quadratic Bézier triangle" is a surface defined with 6 control points, 3 of them lying on the surface (so its sides are quadratic Bézier curves).

Simon F said:
It may be more difficult but you would have far fewer patch-patch tests than triangle-triangle tests.
Of course! I wrote that to point out that support for curved surfaces does change things, you not only have to "adjust bounding boxes".

I'm not against curved surfaces, they're much more efficient (than triangles) IMO.

EDIT: We could create a sphere with 4 bi-cubic patches, based on a spherical octahedron, couldn't we? I'm maybe wrong, It's just a quick idea. :)
 
Mate Kovacs said:
Simon F said:
With a quadratic Bezier triangle, you don't have any internal points, so you can't control the cross edge tangents at all.
What do you mean by "internal point"? Maybe I'm wrong, but what I know under the term "quadratic Bézier triangle" is a surface defined with 6 control points, 3 of them lying on the surface (so its sides are quadratic Bézier curves).
You are correct about there being 6 control points, but only 3 of those are guaranteed to lie on surface. These are the ones at the corners of the triangle.

The number of control points is a straight forward progression:
Linear == triangle=> 3 points
Quadratic => 6 points
Code:
         *
       *   *
     *   *   *
Cubic => 10 points
Code:
         *
       *   *
     *   *   *
   *   *   *   *

quartic=> 15 points
Code:
         *
       *   *
     *   *   *
   *   *   *   *
 *   *   *   *   *

and so forth. A cubic only has 1 internal (i.e. non edge) point while the quartic has 3 thus allowing C1 continuity across edges
 
What's so great about triangular patches anyway?

The only right way for a tesselation unit in a GPU would be to have a pre and post tesselation vertex shader ... unfortunately that probably wont be the way it will be delivered :(
 
Well I guess my point was why do we limit outselves to using triangles. Now i do understand that in our current graphic generation that is what we are using but I'm saying could we evolve or implement at some point?

I mention per pixel because I'm thinking in terms of connecting pixels to form your curve instead of triangles. Now forgive me for talking in the simplist terms as like I said I am no expert (Simon F: as putting texture filtering in my initial statement because usually AA and AF are use together in general and shows my limited knowledge on this subject :oops: ).

Razor 1 I think has the general idea of what im getting at. If its possible to coordinate triangles in such a manner what is the limiting factor of doing it per pixel or spines etc in place of the triangle to form the curve or edge? would the processing power need be that much more? (Again as a general theory not in the normal methods we use today.)

Thanks
 
Back
Top