True Rendered Curved Surfaces

[Simon F]

I'd just like to point out that there are no curved surfaces known in the universe. Under sufficient scrutiny (and magnification) you will find that every surface is composed of smaller non-curved surfaces, and the flat plane becomes the mountainous jumble of ridges under an electron microscope.

It's irrelevant - the microfacets are taken account of by such things as diffuse shading and the ^N term in Phong's specular shading. If you tried to model them directly, the aliasing would be horrendous.

Below that everything just become fields of quantum probability. You can go ahead and render your scene at that resolution if you like - come back in 1000 years time when you've rendered your quake scene to let us know how you've got on.

Anyway, back to sanity, I'd say at least 90% of the objects around my desk would be modelled efficiently by curved surface patches of some form or another.

Reminds me of a little poem from a sci-fi book I read a while back:

Bigger fleas have little fleas
upon their back to bite them
and little fleas have lesser fleas
and so on ad infinitum

The original is actually:
"So, the naturalists observe, the flea,
Hath smaller fleas that on him prey;
And these have smaller still to bite 'em;
And so proceed, ad infinitum"
Jonathon Swift (1667–1745)

 

[Ylandro]

Well... if you want to into details.... You might actually claims to all surfaces are curved, and nothing is flat. It's all made up from atoms, the electron orbitals of which are typically roundish. Al these round atoms, can align nicely in a crystal structure, to make a flat surface. Do I need to post some STM/AFM images?

Anyway, that's ofcourse all irrelevant. Everyone knows that you see object using visible light. As long as your surface roughness is way below the wavelength of the light (<300 nm) then it will look smooth. Thus, for rendering visible objects, curved surface clearly exist.

 

[no_way]

adaptive tessellation .. nice .. it should tessellate close-up surfaces to smaller polygons .. alrite .. eventually we'll reach the point where each rendered triangle covers a couple of pixels only .. so .. why not handle everything as micropolygons from the get-go ?

 

[KimB]

alrite .. eventually we'll reach the point where each rendered triangle covers a couple of pixels only .. so .. why not handle everything as micropolygons from the get-go ?

Well, we need to get to adaptive tesellation first. Anyway, there's no guarantee that you'll have enough power to push enough polygons for pixel-sized polygons for every possible scene arrangement. In some instances, the vertex shaders may be too long for hardware of the time to do it. In other instances, there may be too much overdraw. In still other cases you may have a viable amount of geometry for rendering micropolygons, but your pixel processing is minimal to none, and thus there's a significant hit from using micropolygons.

So no, I don't think micropolygons are the answer. They make sense in offline rendering, but for realtime rendering you really want to try to make the processing requirements feasible for every conceivable scene anybody would try to run in realtime. Maybe once we get adaptive tesellation, we can start thinking about moving towards micropolygons, but not until.

 

[Simon F]

adaptive tessellation .. nice .. it should tessellate close-up surfaces to smaller polygons .. alrite .. eventually we'll reach the point where each rendered triangle covers a couple of pixels only .. so .. why not handle everything as micropolygons from the get-go ?

Because it doesn't really offer efficiency - subpixel polys may be of use for some antialiasing approaches but they're really expensive.

In practice, you can stop at multi-pixel polygons and you wouldn't spot the diffence.

 

[Maverick]

I think the issue with TruForm was silly artists not giving their models proper normal vectors.

Nope. With many types of surfaces, the proper normal vectors would not give the proper curvature with truform. An easy example is a cylinder. After truform is applied, a cylinder will look like it has mild lobes.

Have you tried it? Making the end-caps for a cylinder flat surfaces will result in no changes to the "roundness", but the rest of the cylinder is tesselated correctly. I'd post a screenshot, but I can't seem connect to my webspace.

EDIT: Screenshot added.

Yes, the problems with Truform aren't caused directly by the shape of the object, but by incorrect normals. Basically, most 3d models games have vertex normals, which is fine for smooth objects, but completely wrong for anything with a hard edge, where it causes incorrect lighting.

Take the simplest example of a cube. There's no way for that to have normals at it's vertices that are correct for the three faces that contain each vertex. Lighting it will give a smooth gradient where it should be flat shaded. Truform simply makes errors like these much more visible.

 

[KimB]

EDIT: Screenshot added.

Ostol, that screenshot isn't interesting to me, for the primary reason that it doesn't show what the original mesh is, and isn't taken from an angle that properly shows the shape of the curvature.

 

[Ostsol]

Ostsol, that screenshot isn't interesting to me, for the primary reason that it doesn't show what the original mesh is, and isn't taken from an angle that properly shows the shape of the curvature.

Here's some new screens.


If you like I could send you the program.

 

[KimB]

Does it do the tesellation in software as well as hardware? Because I no longer have a Radeon.

 

[Ostsol]

Does it do the tesellation in software as well as hardware? Because I no longer have a Radeon.

It's in OpenGL and therefore uses ATI's extension. As such. . . no software emulation unless you decide to use something like Mesa (though it's probably not worth it unless you already have it installed and working).

 

[bloodbob]

Does it do the tesellation in software as well as hardware? Because I no longer have a Radeon.

It's in OpenGL and therefore uses ATI's extension. As such. . . no software emulation unless you decide to use something like Mesa (though it's probably not worth it unless you already have it installed and working).

Ummm its done in software on the R3XX/R4XX

 

[KimB]

That's not relevant, Bloodbob. The question was basically whether or not I could run the software package on an nVidia card (i.e. whether or not it had an alternate pure software path).

 

[no_way]

.. why not handle everything as micropolygons from the get-go ?

Because it doesn't really offer efficiency - subpixel polys may be of use for some antialiasing approaches but they're really expensive.
[/quote]

Well, its a qestion of computational frequencies, right ? Currently we have world->object->primitive->vertex->fragment, with three of them done on CPU, and "primitive" often doesnt require any computation at all, being a triangle.
Why not have world->object->primitive->micropoly with adaptive tessellation and GPU doing both primitive and micropoly stages ? Some of the stuff that was traditionally done per vertex like lighting has basically moved to per pixel anyway, and other parts should belong to primitive processor.

As for adaptive tessellation, i remember there were presentations about truform2 at r300 launch, which claimed that r300 was capable of it. Was it outright misinformation or was the functionality simply disabled ?

 

[Ostsol]

As for adaptive tessellation, i remember there were presentations about truform2 at r300 launch, which claimed that r300 was capable of it. Was it outright misinformation or was the functionality simply disabled ?

TruForm 2 was the combination of N-Patches and displacement mapping. Unfortunately the latter seems to be missing-in-action on all cards that are supposed to support it.

 

[MfA]

View dependent tesselation of anything more complex than a quadric is not something sm-3.0 hardware is capable off, because the tesselation has to be recursive.

 

[Simon F]

View dependent tesselation of anything more complex than a quadric is not something sm-3.0 hardware is capable off, because the tesselation has to be recursive.

I can't see that it has to be recursive, though that probably is the easiest approach for software.

For example, IIRC, someone published an adaptive forward differencing approach (quite clever... and patented). AFAICS, you could evaluate in a left->right, top->bottom order with adaptive evaluation of vertices, though, to be honest, I think that estimating the required LOD at the start is a nicer approach.

 

[no_way]

http://www.beyond3d.com/reviews/ati/radeon9700pro/index.php?page=page2.inc

Also, TRUFORM 2.0 supports adaptive tessellation to dynamically adjust the level of tessellation that occur dependent on Z positioning;

Of course, that never seemed to materialize