True Rendered Curved Surfaces

[jpr27]

I've been waiting forever for a "real time curved surface entry" into the renderer. With so many ways to get curved surfaces using vertices and the amount of time and bandwidth, AA, AF and many algorhythims it takes to get the results we are looking for (Which still shows jaggies etc). Would it be a good time to start developing "True" curved service rendering that can look better, easier to work with, and takes the load off the Graphic Card? Algorythims have become more complex and the cards themselves have evolved in power to where I think some day soon we will see nice smooth edges and no jaggies and nice curved surfaces. Its time for "True curved surfaces to come of age. Does anyone think that Curved surfaces could be next generation? If not when do you see curved services in the future if at all? Or are we stuck with vertices, AA, AF and the same jaggies only their getting smaller?


Please forgive the mistakes but its a latenight write

P.S. I'm just beggining to learn how rendering services etc works so be gentle


***The is no luck...Only the Will and Desire to Succeed !!! ***

 

[Inane_Dork]

As a first note, we don't need true curved surface definitions. That's one solution. An alternate solution is to have significantly enough polygons to emulate true curvature. This only works because pixels have width and height.

 

[nutball]

Its time for "True curved surfaces to come of age. Does anyone think that Curved surfaces could be next generation? If not when do you see curved services in the future if at all? Or are we stuck with vertices, AA, AF and the same jaggies only their getting smaller?

Curved surfaces have been and gone. They were available several hardware generations ago and weren't used, and have now disappeared due to lack of use.

So you might ask yourself *why* they weren't used. I think ease-of-use was the primary reason.

 

[Ailuros]

Its time for "True curved surfaces to come of age. Does anyone think that Curved surfaces could be next generation? If not when do you see curved services in the future if at all? Or are we stuck with vertices, AA, AF and the same jaggies only their getting smaller?

Curved surfaces have been and gone. They were available several hardware generations ago and weren't used, and have now disappeared due to lack of use.

So you might ask yourself *why* they weren't used. I think ease-of-use was the primary reason.

Sounds extremely shortsighted IMHO considering what future APIs are about to offer.

 

[Goragoth]

True curved surfaces basically require ray-tracing because that can solve the parametric equations directly. Pretty much any other approach will end up tesselating the curved surface geometry at some stage in the pipeline. So until realtime hardware raytracing becomes the reality (and most importantly the standard) we won't see true curved surfaces in games. And the jaggies (aliasing) aren't specific to triangle/polygon rendering, a raytraced image will also have aliasing without AA applied.

 

[Basic]

NV1

 

[nutball]

Sounds extremely shortsighted IMHO considering what future APIs are about to offer.

That's as maybe. Hopefully the new APIs will learn from the lessons of the old.

 

[Colourless]

APIs have nothing to do with it if the Artists have trouble using the surfaces to make things.

 

[nutball]

APIs have nothing to do with it if the Artists have trouble using the surfaces to make things.

Indeedy.

 

[Para]

The usefulness of true curved surfaces directly in GPU:s would be kinda oxymoron. Sure, one could load IGES models and render them in real time in practically infinite resolutions but in real life the benefit of that could've be described by screaming "Yay, smooth ball!" in an empty room. Some sort of tesselation for polygons would be good though, subdivision surfaces are a standard in cg at the moment.

 

[Squeak]

True curved surfaces basically require ray-tracing because that can solve the parametric equations directly. Pretty much any other approach will end up tesselating the curved surface geometry at some stage in the pipeline. So until realtime hardware raytracing becomes the reality (and most importantly the standard) we won't see true curved surfaces in games.

There once was this company called III that had a rendering method called Syntahvison, that relied in on solid 3d primitives (like cones and spheres) for all rendering.
Among other things, it was used to do the graphics in Tron. Tron had pretty good lightning and lots of curved surfaces, but it doesn’t look like raytracing at all.

 

[Ylandro]

True curved surfaces basically require ray-tracing because that can solve the parametric equations directly. Pretty much any other approach will end up tesselating the curved surface geometry at some stage in the pipeline.

Agreed. And this ofcourse raises the question why the power of graphics cards isn't used for better tesselation.

ATI's Trueform seemed a step in the right direction. At the release of the R300, there were DX-9 "demo's" showing 'continuous tesselation', so that you only applied the extra's polygons where needed.

Nevertheless, seems nobody at all is using it. Don't see any further developments either...

Strange, because this could be a great way to have games scale nicely on videocards. Just increase the amount of tessalation, or the distance on which it starts to take place...

There's enought reason... You can do a lot with stuff like normal maps, but it al breaks down at the edges, where you see the low number of polygons. And that start to contrast with the high quality of the rest of the surface.

 

[KimB]

This is the problem: It's sort of a chicken-and-egg thing. No tesellation technique that doesn't have developer input can work very well. Truform, for instance, always had places in games where it would look terrible.

So, to really make use of higher-order surfaces, the artwork has to be designed with higher-order surfaces in mind. But the artwork isn't going to be designed with HOS in mind until the hardware is available to do so.

Toward this end, the first thing that we need is a robust, flexible HOS technique available in hardware. Apparently IHV's have decided for each recent generation that to implement HOS will cost too many transistors to be worth it. They've decided instead to use transistors for techniques that could be applied directly. For example, pixel shader improvements can be seen, to some extent, just through recompiling shaders (nVidia's normalize instruction, available on the NV4x, is an example of this: with a simple recompile of the shaders this command can be made use of).

Now, back around the time ATI had Truform, nVidia did have a HOS offering, too. But, it turned out that their implementation had significant performance implications, and thus never got off the ground, and support for it has since been dropped.

 

[Ailuros]

Sounds extremely shortsighted IMHO considering what future APIs are about to offer.

That's as maybe. Hopefully the new APIs will learn from the lessons of the old.

It'll be a combination of HW and API support for advanced HOS in the end, as it seems.

http://www.beyond3d.com/articles/directxnext/

The article is bit dated, yet still holds it's relevance. It'll be called WGF (see LONGHORN).

More specifically:

Higher-order surfaces were first introduced to DirectX in version 8, and at first a lot of hardware supported them (nVidia in the form of RT-Patches, ATI in the form of N-Patches), but they were so limited and such a pain to use that very few developers took any interest in them at all. Consequently, all the major hardware vendors dropped support for higher-order surfaces and all was right in the world; until, that is, DirectX 9 came about with adaptive tessellation and displacement mapping. Higher-order surfaces were still a real pain to use, and were still very limited, but displacement mapping was cool enough to overlook those problems, and several developers started taking interest. Unfortunately, hardware vendors had already dropped support for higher-order surfaces so even those developers that took interest in displacement mapping were forced to abandon it due to a lack of hardware support. To be fair, the initial implementation of displacement mapping was a bit Matrox centric, so it is really of no great surprise that there isn’t too much hardware out there that supports it (even Matrox dropped support). With pixel and vertex shader 3.0 hardware on its way, hopefully things will start to pick back up in the higher-order surface and displacement mapping realm, but there’s still the problem of all current DirectX higher-order surface formulations limitations.

It’d be great if hardware would simply directly support all the common higher-order surface formulations, such as Catmull-Rom, Bezier, and B-Splines, subdivision surfaces, all the conics, and the rational versions of everything. It’d be even better if all of these could be adaptively tessellated. If DirectX supported all of these higher-order surfaces, there wouldn’t be much left in the way to stop them from being used – you could import higher-order surface meshes directly from your favorite digital content creation application without all the problems of the current system. Thankfully, this is exactly what Microsoft is doing for DirectX Next. Combined with displacement mapping, and the new topology processor, and there’s no longer any real reason not to use these features (assuming, of course, that the hardware supports it).

http://www.beyond3d.com/articles/directxnext/index.php?p=4#top

 

[bloodbob]

If your calling that True rendered curved surfaces then Quake 3 already has it.

 

[KimB]

If your calling that True rendered curved surfaces then Quake 3 already has it.

Quake 3 used a very poor curved surface implementation. Well, I should say, they used the built-in OpenGL curved surfaces, which are very poor. Specifically, they're hard to develop artwork for because they tend to have cracks. They are only supported in software by pretty much everybody. Curved surface implementations are only interesting when they are supported in hardware, because only then can the performance be good enough for them to be a win over static geometry.

 

[Simon F]

True curved surfaces basically require ray-tracing because that can solve the parametric equations directly. Pretty much any other approach will end up tesselating the curved surface geometry at some stage in the pipeline. .

I'd just like to point out that, apart from some simpler curved surfaces (e.g. spheres), general parametric surfaces are not going to be solved directly but probably by Newton-Rhapson iteration, in which case, for all intents and purposes, you end up approximating the surface by flat segments.....

ATI's Trueform seemed a step in the right direction.

Technically speaking, it was developed by researchers from ATI, Microsoft and the University of Florida. It was an attempt to do cheap subdivision surfaces but, IMHO, there were too many flaws in the scheme (eg creases and no control over other parameters).

 

[Ylandro]

Thanks for the PDF.
Not sure if I agree that there were too many flaws in the scheme. At least, from what I've seen in Morrowind.

I played Morrowind with and without the N-patches patch, and the result was truly remarkable. (Especially considering that it was developed without the system in mind...)

Heads, helmets were really round. Rocks and boulders, and those giant mushrooms looked very convincing. (Even some lighting got better because the flat walls got devided into more polygons).
Some things, like small branches of trees however, got blown up, and looked worse.

Stilll... for the a first try, with a quick patch, it was a remarkable achievement. I thought that the overall quality was drastically improved.

Now, I'm not a programmer, but it seemed that all that was needed to remove the few bad spots, was a flag telling the engine what to handle, and what to leave alone. Didn't see any big problems occur with seams and stuff... (Maybe just lucky...)

Might not be perfect at once, but you did wonder what it could look like, when you develope a game from the onset with this technology in mind. Especially, when the technology is further developed, i.e this continuous tesselation.


I wonder, do you actually need special hardware support for it? Or can you 'just' program it using the vertex shaders. It seems to be part of DX-9, so hardware really shouldn't be a big problem...
And if I understand correctly, most modern games are easy on the vertex shaders.

 

[Simon F]

Thanks for the PDF.
Not sure if I agree that there were too many flaws in the scheme. At least, from what I've seen in Morrowind.

There were a number of technical issues (relative to, say, Subdivision surfaces) that can occur with the scheme - I doubt I've still got the email I sent to MS regarding these as it was several years ago.

 

[KimB]

Some things, like small branches of trees however, got blown up, and looked worse.

That's the point. The technique is prone to some objects just not looking good.

I wonder, do you actually need special hardware support for it? Or can you 'just' program it using the vertex shaders. It seems to be part of DX-9, so hardware really shouldn't be a big problem...
And if I understand correctly, most modern games are easy on the vertex shaders.

Vertex shaders don't offer the capability to generate new vertices.