Why are curves so hard in RT?

[Laa-Yosh]

Wheels, manholes, arches, tunnels, pipes, tubes and domes are quite common in games. Unrealistically perfectly smooth is probably the best we could hope for until small little imperfections could be added.

Wheels aren't simple and perfect cylinders; they are also deformed during cornering, and ideally should have elevated track patterns too.
Then there are the actual metal parts which are highly complex hard surface shapes. Building them from NURBS requires a lot of secondary and tertiary surfaces, trims etc. - poly modeling is a straight, simple approach.

I could list similar issues with any of the real world examples you've mentioned.

And we're still not talking about the actual reason: CSG primitives are less then 1% of the common geometry in games. Why develop, debug and optimize a secondary rendering pipeline, complicate the existing triangle based one, mess up the final image with varied edge quality - when the returns are next to insignificant? And when have you ever heard anyone complaining about the lack of perfect curves as the main problem with today's graphics anyway?

 

[Laa-Yosh]

Looking outside nature though I can see mathematical renderings very useful in modeling machines though would you agree?

I disagree. Before CAD/CAM, every curve was hand made and imperfect. After CAD/CAM, everything got way more complex then simple primitives. Have you studied cars, cell phones, furniture and such nowadays? I don't see them made from simple spheres, cylinders and such.

 

[Danalys]

Wheels aren't simple and perfect cylinders; they are also deformed during cornering, and ideally should have elevated track patterns too.
Then there are the actual metal parts which are highly complex hard surface shapes. Building them from NURBS requires a lot of secondary and tertiary surfaces, trims etc. - poly modeling is a straight, simple approach.

I could list similar issues with any of the real world examples you've mentioned.

And we're still not talking about the actual reason: CSG primitives are less then 1% of the common geometry in games. Why develop, debug and optimize a secondary rendering pipeline, complicate the existing triangle based one, mess up the final image with varied edge quality - when the returns are next to insignificant? And when have you ever heard anyone complaining about the lack of perfect curves as the main problem with today's graphics anyway?

Your tangent about NURBs is irrelevant to my point that there is geometry in real life and games which smooth curved surfaces could aid in the approximation of. Your talk of the details of wheels can be solved with displacement maps or by just applying whatever technique to the parts of the wheel that it is suitable for. I don't see how a smooth curved surface makes deformation of geometry impossible.

Personally I have noticed things not being as rounded as they should be. It was part of the reason I could give that many examples. Most of them I'd seen recently in Assassin's Creed 2. While this may not be the biggest problem in computer graphic currently it is still a problem one that could be solved unlike other bigger problems. I also remember people complaining about non smooth wheels for years, so I'm not alone in the noticing of such things. Wasn't there a big hoo haa about Quake 3 using sub division for smoother organic surfaces aswell.

 

[Laa-Yosh]

Look, mathematical approaches have been tried and used extensively in movie VFX. Then the entire industry moved on to subdivision surfaces and tesselation.
You also seem to have very superficial knowledge about the issue which isn't a problem in itself but maybe you should consider listening to the opinions of people with actual experience and not dismiss them immediately.

I've given more then enough reasons, lastly I'd also add in my professional career as a 3D modeler for 10 years in saying again that the approach you suggest is a dead end and should be avoided completely.

 

[Danalys]

I never suggested a mathematical approach or agreed with the OP about anything other than smoother surfaces might be a good thing. I dismiss bad argumentation including strawman and appeal to authority, not any expertise and knowledge you have.

 

[Laa-Yosh]

I have not brought up any appeal to authority for a long, long time, it was my last argument.

Smoother surfaces are going to happen with tesselation. Right now the hardware can't render enough triangles; and any other approach is a complete waste of hardware and engine developer resources.

Believe me, 3D animation packages have plenty of options for smoother surfaces. We haven't used any for many many years though - because they're unnecessary. Polygons, tesselation, displacement are just that much better.

 

[Dungeonscaper]

You're right I have a fairly superficial understanding of this I'm just a senior high school student. I'm tryin to learn as much about rendering as possible right now.

However even with tesselation and extremely beefy hardware, no matter how many polygons you put into your models they'll always have a blocky appearance up very close, I suppose this isn't an issue if you base it on your camera distance.

This sort of reminds me of that dot based 3d engine using millions of little dots and it looks fully antialiased just by the way it works. What was that again?

 

[corduroygt]

We still need more polygons for smooth curves:

 

[3dcgi]

However even with tesselation and extremely beefy hardware, no matter how many polygons you put into your models they'll always have a blocky appearance up very close, I suppose this isn't an issue if you base it on your camera distance.

That's not true. Once triangles are tessellated to smaller than a pixel you won't be able to tell a difference between a triangle and any other rendering method. See Pixar movies as examples.

If developers had been including extremely high poly model options in their games graphics hardware would have developed a little differently, but the focus until now has been pixel processing.

 

[Billy Idol]

I think that the problem is smooth transition!
If you cannot afford the high poly-count all the time (which is probably the case for Pixar, but not for real time gaming), you need some adaptive transition from low to high poly as you approach the object...this could be very distracting when actually playing the game and experiencing many "detail pop in" when you approach objects. Is it possible to get rid of this when using tesselation? This could be an advantage for a mathematical description of geometry: there you could probably implement smooth detail transitions of models?

 

[Laa-Yosh]

If there's a renderer using adaptive transition then it's PRMan
Everything is always tesselated into subpixel sized micropolygons, even if it's a completely flat surface. That's how their shading works.

Edit: and it's even more important in offline rendering because of the high quality antialiasing. Any sudden change would be even more noticeable.

The tesselation demonstrated in AVP was clearly adaptive, too. But they were using displacement mapping as well which is the more desirable solution because of the relative rarity of completely smooth surfaces.

 

[Shifty Geezer]

Just as an interesting point, all offline renderers tesselate down to polygons AFAIK, with one exception which is RealSoft3D. This started as Real3D on the Amiga and used CSGs exclusively which were solved mathematically and raytraced. The result was perfect curves and it was pretty quick for the time too. Currently it still preserves the integrity of surfaces as mathematical functions, even metaballs. However, it only manages this via pure raytracing and is very slow versus the competition who have now equalled RealSoft's quality through lots of optimised steps with their tessellated renderers. So though elegant in its solution, and less demanding with memory, there's no real advantage to mathematical solving versus tesselation and rasterisation, while the solution is dead slow, a problem exaggerated when you try to include GI solutions that are also pure raytracing solutions.

 

[Laa-Yosh]

Now move all this into realtime and combine it with the added unnecessary complexity and gigantic restrictions it introduces to modeling, and all the software/hardware resource allocation issues and I think the entire topic is beaten to death several times.

 

[MfA]

Smoother surfaces are going to happen with tesselation.

Tesselation is just another way of saying you use patches ...

Trying to model something for tesselation with polygons and doing the tesselation in your head to try to guess how it will end up is ass backwards ... regardless you would still not be using polygons as your modeling primitives, the vertices are just control points whether the modeling renderer is in the computer or in your head.

Going with tesselation is letting go of polygons as a modeling primitive ... and good riddance. Although I think subdivision surface modeling with off-line conversion into patches makes a lot more sense.

 

[Laa-Yosh]

Tesselation is just another way of saying you use patches ...

Not really, because patches have a lot of inherent problems and complications.
Pixar's own Catmull-Clark subdiv implementation treats the result of the first subdivision as B-patches but then again they treat everything as B-patches for their micropolygon tesselation.

The point is, however, that the entire content creation pipeline does not have to concern itself with all the stupid issues that patches introduce. They can use poly modeling, UV mapping, texturing, skinning tools and perform simulations and collision detection and so on.
With realtime games there's the added benefit of the existing hw and sw R&D invested in polygons.

Trying to model something for tesselation with polygons and doing the tesselation in your head to try to guess how it will end up is ass backwards ...

It's not true.
Also, you can have tools to show realtime previews while you are modeling the actual object.

Modeling with patches, now that's a real headache.

regardless you would still not be using polygons as your modeling primitives,

Yes we will. The flexibility they offer is still unmatched.

Going with tesselation is letting go of polygons as a modeling primitive ... and good riddance.

It's not true. Going with tesselation builds upon the solid foundation provided by very robust, flexible and well-known polygon based tools.


Honestly, I've been using polygons for a decade and am quite happy with them. NURBS and all the other crap are something I never want to see again, we've moved past them a long time ago.

 

[MfA]

Not really, because patches have a lot of inherent problems and complications.

As far as the rendering algorithm is concerned they are patches.

They can use poly modeling

They can certainly lie to themselves and say they are doing that, but they are modeling a control mesh.

Also, you can have tools to show realtime previews while you are modeling the actual object.

Which is the right way to do it.

Modeling with patches, now that's a real headache.

Just because you can only control 3 or 4 on-surface vertices for a patch, with all the control points being calculated for you, doesn't mean it's not a patch. It just goes to show, it's better for artists to work on higher level. Except you seem to feel better by pretending that's not what is happening.

 

[Dungeonscaper]

That's not true. Once triangles are tessellated to smaller than a pixel you won't be able to tell a difference between a triangle and any other rendering method. See Pixar movies as examples.

If developers had been including extremely high poly model options in their games graphics hardware would have developed a little differently, but the focus until now has been pixel processing.

AFAIK tessellation only goes to a certain distance. Can tessellation of an object go on infinitely or is there always a point where you zoom in far enough that it stops smoothing out with new polygons and things look blocky again?

 

[Sonic]

So what are we talking about here? I thought polygons are just fine for real time rendering. We just need to be able to push enough of them so they are one pixel in size or less. I understand current hardware has a hard time throwing around that much geometry so things need to be scaled back, but given how limited (and powerful) current hardware is I do believe they get the best balance.

Is subdiv the answer for unlimited geometric detail?

 

[Laa-Yosh]

They can certainly lie to themselves and say they are doing that, but they are modeling a control mesh.

Even you call it a mesh.

Except you seem to feel better by pretending that's not what is happening.

Only PRMan converts to patches. The other apps and upcoming DX11+ games won't do that and tesselate the mesh directly.


And how the hell does it all concern my initial point - that CSG primitives and procedural curve rendering are no replacement for polygon based modeling and tesselation for rendering? You're arguing for the argument's sake...

 

[Laa-Yosh]

Is subdiv the answer for unlimited geometric detail?

It is the answer for most offline rendering issues.

There are cases where higher level of proceduralism is required (like L-ssytem based foliage, hair and so) or for most visual effects depicting fluids (smoke fire water etc). But for characters, environments and props, subdiv + displace is doing very well.