True Rendered Curved Surfaces

[Rolf N]

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.

I don't think so. There are no curved surfaces in core OpenGL, and there are no related extensions exposed by my current graphics card driver. But I see the curves in Quake 3 just fine.

GLU (PDF) has some support for subdivision of quadrics and nurbs, but these functions aren't imported by Quake 3. I've searched the Quake 3 folder for "Nurb" and "Quadric" (contained in the GLU function names) and came up empty. And these functions are exported/imported by name, not by ordinal, so I'd say this is pretty conclusive evidence.

Quake 3 must have its own curve subdivision then.
Not saying they are not poor. I personally didn't think they were poor, but you probably have your reasons. I only played the game, and never "worked" with it.

 

[Rolf N]

TruForm has a significant issue with "barrel-like" shapes. The rim of the object is what you really want to have smoothed out by subdivision, but the problem is that the "bottom" and "top" parts of the barrel will not have their vertices pulled out to match. So you get ugly gaps in an originally perfectly closed model. You can counter that somewhat by inserting filler geometry, but then
a)you're losing the intended hard edge
b)you're getting issues with texcoord continuity

It's ... bad.

 

[arjan de lumens]

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.

I don't think so. There are no curved surfaces in core OpenGL, and there are no related extensions exposed by my current graphics card driver. But I see the curves in Quake 3 just fine.

There IS curved surface support in core OpenGL (see chapter 5.1 of the OpenGL spec), has been for practically forever (since at least version 1.1, which is quite old), but usually not hardware accelerated and not very widely used.

 

[Rolf N]

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.

I don't think so. There are no curved surfaces in core OpenGL, and there are no related extensions exposed by my current graphics card driver. But I see the curves in Quake 3 just fine.

There IS curved surface support in core OpenGL (see chapter 5.1 of the OpenGL spec), has been for practically forever (since at least version 1.1, which is quite old), but usually not hardware accelerated and not very widely used.

Ah crap ... evaluators. You're right. I was wrong.
And Chalnoth was right, too. Quake3.exe does import the functions

 

[KimB]

Yeah, evaluators....sorry, forgot what the name was, and was too lazy to look 'em up...

 

[bloodbob]

Quake 3 does it internally ( It does the tesselation ) it doesn't use the Nurbs in OpenGl thats why I said quake 3 and not opengl cause M$ codes the nurbs support for opengl and its rather crap. ( I'm pretty sure its done internally cause carmack didn't like the API to restrict his curved surfaces and he complaned about stuff APIs were doing with curved surfaces ).

 

[Ylandro]

TruForm has a significant issue with "barrel-like" shapes. The rim of the object is what you really want to have smoothed out by subdivision, but the problem is that the "bottom" and "top" parts of the barrel will not have their vertices pulled out to match.

That's a problem allright...

Still, it doesn't seem unsolvable. Actually, the paper mentioned an option, adding a few vertixes. Might be a small price to pay, for a big gain of the rest. Is there a lower limit on the vertex resolution? That would define the best sharpness an edge can have...

And this assumes that the tesselation algorithme has no knowledge about the object. Neccessary for old games. But that doesn't neccessarily hold for the future.... I can imagine that you tell the system in some way (I mean that in the broadest sense), that it should smooth out the top and bottom parts of the barrel.

Anyway, nobody says you need to use it on ALL objects...
I don't think you'll actually find very much of these 'barrel' objects. Most are either smooth (pretty much all natural things), or completely made from flat surfaces (Buildings and stuff). In real life, barrels, where some smooting of the rim is unwanted, are pretty rare.

The tree branches in Morrowind are really the only thing that I remember where things went wrong. The NPC's actually all looked fine. (There's probably a few more... Only played for a while on my brother Radeon 8500... Had to do with a 64 myself... )
The thickening of the braches would have been be easily solved with a few additional vertices at the tips. (like the axe example in the PDF). Compared to the complete rest of the tree, that did look way better, that would be a very small price to pay... (Ofcourse a bit too much to ask for a patch afterwards, but for a newly designed game....)

 

[Goragoth]

When I was looking into Bezier patch generation a while ago I also looked into how QuakeIII does it and I read somewhere that it doesn't do any real time tesselation at all but rather precomputes LOD models from the control points.

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.

The Morrowind FPS Optimizer lets you choose different tesselation values for different game objects so you simply tell it not to smooth trees and anything else that might be a problem.

 

[KimB]

Quake 3 does it internally ( It does the tesselation ) it doesn't use the Nurbs in OpenGl thats why I said quake 3 and not opengl cause M$ codes the nurbs support for opengl and its rather crap. ( I'm pretty sure its done internally cause carmack didn't like the API to restrict his curved surfaces and he complaned about stuff APIs were doing with curved surfaces ).

It's not nurbs. The curved surface that Quake3 uses is sort of an RT-patch curved surface implementation, only more prone to problems. Microsoft codes nothing on supporting the various OpenGL functions. It's entirely up to the graphics card manufacturers to code these things. No, it's the OpenGL evaluators that Quake 3 uses.

 

[jpr27]

I do remember Truform and although it had its flaws, do you think if ATI had continued to evolve the technology developers might of possibly standardized it? I mean yes it did have it problems but dont most new technologies have growing pains? From what i saw of Truform it showed promise. So why was Truform abandoned? Was it just too difficult to include or were the developers having to "compromise" with developing for ATI and Nvidia based products. The result being, the time to focus on Truform didnt justify the time and cost for a technology that only benefited one party at the time (ATI)?


Thanks for the feedback...


***There is no luck...Only the will and desire to succeed !!! ***

 

[Simon F]

I do remember Truform and although it had its flaws, do you think if ATI had continued to evolve the technology developers might of possibly standardized it? I mean yes it did have it problems but dont most new technologies have growing pains?

I think someone suggested adding vertices/more data to the surfaces, but if you're going to add vertices, why not just go to Catmull-Clark subdivision surfaces (see here and here)? They're straightforward to use, bypass the failings of NURBS, convert (almost always) to Bicubic patches (so can be rendered in numerous ways) and have obviously proved themselves as the (primary?) modelling tool of Pixar (see the 2nd link above).

 

[Unknown Soldier]

Didn't TrueForm die a slow death because Nvidia Hardware didn't support it? Also, isn't this the same that might happen with 3Dc which Nvidia again doesn't support?

Only way TrueForm/2 and 3Dc can stay alive is if software developers cater for it.

US

 

[Coriolis]

I think I can settle the issue with curved surfaces in Quake3, since I've shipped two titles using that engine. Q3 implements 2D Bezier patches with 9 control points. There is a lot of code to stitch the edges between adjacent patches that does a fairly good job of preventing cracks and forcing contacting patches to subdivide simultaneously. It doesn't use any OpenGL code for tesselation.

 

[Ostsol]

I think the issue with TruForm was silly artists not giving their models proper normal vectors. That's what TruForm relied on, after all, to generate the curvature. If you have a cylinder, for example, and all the normals are simply pointing outward from the centre of the volume, TruForm will give you a dildo. However, if the normals are done properly (the end caps' normals are facing along the axis of the cylinder, and the sides' normals radiate outward perpendicular to the axis), you'll simply have a more rounded cylinder.

EDIT: Basically, the technology was limited, but not flawed. What was flawed was the artists.

 

[ERP]

Truform was more at the level of gimick than useful modelling tool, it was predominantly designed to allow existing polygon models to work.

N Patches (Truform) are only guaranteed to be C0 continuos and are dependant on both Normal and Position at edge verts which means cracks along hard edges in the model.

Subdivision surfaces are probably the way it will end up going, but until we get efficient hardware implementations, the majority of developers will continue to develop for good old fashioned Polygons. Even with good curved surface rendering a lot of surfaces in games are flat.

 

[KimB]

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.

 

[flf]

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.

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


Please don't say, "But X is the basic building block of matter... it must have a cuved surface because there is nothing smaller," because you can bet that once we find a way to detect sub-X structures that we'll find that they are, indeed, composed of smaller structures.

 

[KimB]

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.

Um, there are no smooth surfaces in the universe if you want to look that closely. But if you really want to look that closely, you're far out of the realm of realtime computing, so it's pointless to consider.

And, by the way, it is fundamentally possible to make a surface that differs in height by no more than the size of a single atom. But then the atoms themselves perturb the flatness of the surface.

Please don't say, "But X is the basic building block of matter... it must have a cuved surface because there is nothing smaller," because you can bet that once we find a way to detect sub-X structures that we'll find that they are, indeed, composed of smaller structures.

Well, except that the "surface" of anything that we see is determined by electrons only. Any structure that the electrons may have (to date there is no convincing experimental evidence of electron structure) is irrelevant to the surfaces of macroscopic objects, since it's the electromagnetic force (and at low energies) that determines interactions with the surface.

 

[Ostsol]

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.

 

[Cryect]

Please don't say, "But X is the basic building block of matter... it must have a cuved surface because there is nothing smaller," because you can bet that once we find a way to detect sub-X structures that we'll find that they are, indeed, composed of smaller structures.

Goodness if you want to be so picky about things like that you should at least know that items such as electrons aren't defined to have a shape.