NURBs for Nintendo

[Max]

Nintendo Revolution: New Details?

August 23, 2005

by: Chris Playo

RUMOR: A fury of internet activity is centered around Nintendo's next generation gaming console.

The Internet publication, Computer Games Magazine is reporting that they have the inside scoop regarding Nintendo's next generation console.

The site is saying that the Revolution controller will feature a device that provide "resistance to being tilted". It doesn't sound like much, but to accomplish this, the controller would have to generate a sufficient force of inertia.

For those who haven't taken AP physics, inertia is defined as the tendency of a body to resist acceleration; the tendency of a body at rest to remain at rest or of a body in straight line motion to stay in motion in a straight line unless acted on by an outside force.

A practical application of inertia comes from the simple act of riding a bike. As your bike accelerates it becomes increasingly harder to tilt.

It is still unknown as to how this application could affect the game play of next generation titles. Please note that this has yet to be confirmed by any official source, and that their could be other details regarding the controller of the Revolution.

GC Advanced promises to keep you updated about this developing story as further details are revealed. If necessary the Advanced Media Network will follow this story throughout the night with hourly updates.


--------------------------------------------------------------------------------

UPDATE - 2:30 AM Eastern
by Chris Playo

The Internet forum, Gaming Age is speculating that further details about the Nintendo Revolution will be made available on Wednesday August 24th. For those who do not know the significance of the date, both the GBA and the GameCube were discussed on that day.

However, news regarding the Revolution may have come a little sooner than expected. On the forum, a user posted a French article regarding the graphical capabilities of the console.

Apparently the Revolution will utilize a new form of a polygon currently referred to as a NURB or nonuniform rational B-splines. These NURB's are said to be able to generate very detailed graphics within an enormous scope.

In addition, NURB's are known to be much more efficient than standard polygons. It is much easier on a machine to generate an image in terms of NURB's rather than traditional polygons. This fact regarding the new type of image formatting fits very well into Nintendo's design for the Revolution.
Given the inherent design of NURB curves, the Revolution could be substantially smaller and less powerful than the competition but would still be comparable.

Please remember that this information has not been confirmed by any official source. However, for a detailed history of NURB's check out this page. GC Advanced will keep you updated regarding this developing story.


--------------------------------------------------------------------------------

Updated 3:45PM PST 8-23-05:

Interestingly enough, the Computer Games Online site has been taken offline for unknown reasons. GCA will continue to keep you updated on these intriguing developments. Stay tuned.

Some info for our most elusive console may be on the way. =)

link

[Praxis]

Absolutely not; there's no way a system in this day and age could handle NURBs, right?

[Praxis]

However, info being released on the 24th is very interesting.


From Matt @ IGN's mailbag:

when will more revolution news be announced?

Matt responds: Shortly after the Leipzig Games Convention. I don't have an exact time frame -- it could be a day or a week, but I don't expect it will be much longer.

n your last mailbox you mentioned that there would be more information about the revolution shortly after Leipzig. How educated of a guess is this?

Matt responds: I wouldn't call it a guess.

Hey Matt.

Recently you claimed that Revolution news would be announced very, very soon. I'm not sure where or how it was established but for some reason people think the news would come about within a week or two after this recent event in Germany (thats where it was, right?).

I dont mean to nit-pick, or nag, but I would like you to clarify with all readers what you mean.

If you have no reason to believe the information would be released in that time period, please just say so.

I ask you this because rumors and hype do more harm than good in my opinion. Nintendo fans get worked up over some apparently true release date only to get nothing, resulting in a high level of dissapointment.

So yeah, please just let us readers know what you mean, so we're not guided down the wrong track.

Thanks a heap.

Jarrod

Matt responds: I'd love to clarify with an exact date, but unfortunately I don't know when that it is. What I was told is that nothing would be revealed at the German Games Show, but that Revolution news would be announced "very soon" afterward. I got the impression that the news would be forthcoming within a week or so of the event and that could very well be the case. Then again, "very soon" is a pretty relative description, I suppose. I can tell you with confidence that in a worst-case scenario, something is going to be announced by the time Tokyo Game Show rolls around in mid-September. But beyond that, your guess is as good as mine.

Remember that GameSpy is doing Nintendo's online, and IGN owns GameSpy.


The 24th would be one week from the conference...

[Max]

So I take it this isn't true?

In addition, NURB's are known to be much more efficient than standard polygons. It is much easier on a machine to generate an image in terms of NURB's rather than traditional polygons. This fact regarding the new type of image formatting fits very well into Nintendo's design for the Revolution.
Given the inherent design of NURB curves, the Revolution could be substantially smaller and less powerful than the competition but would still be comparable.

I've never heard of NURBs...although I did find an interesting Star Wars reference:

The reason you've heard of NURBS dates back to Rogue Squadron for the 'Cube. When the first screenshots were handed out from the game, the collective internet claimed that the X-Wings from the opening scene must have been the exact models used in the Special Edition of the Original Trilogy. The fury of excitement was so high that LucasArts had to come out and explain exactly this- the X-Wings from the movies were made from NURBS, and that the GCN models were polygon based. So there ya go. The Revolution will be capable of at least the same model capacity as freaking Star Wars. Where do I pre-order again?

[Praxis]

Yeah, I was gonna mention that about Star Wars.

Exactly. There's no way the Revolution, or ANY console coming out next year for that matter, will be capable of that. It took clusters HOURS to render those scenes.

EDIT:

In addition, NURB's are known to be much more efficient than standard polygons. It is much easier on a machine to generate an image in terms of NURB's rather than traditional polygons. This fact regarding the new type of image formatting fits very well into Nintendo's design for the Revolution.
Given the inherent design of NURB curves, the Revolution could be substantially smaller and less powerful than the competition but would still be comparable.

Huh. Dunno. EVERY time I've heard of NURBs being done, it involved huge supercomputer clusters. I've never heard of it being more efficient than polygons; just that it produces better results (mathematical curves are better than polygons).

Could someone with more knowledge confirm whether NURBs takes more or less power than polygons?

It seems to me that if NURBs were supposedly better games would already be using it, as it is open...

[The Kernel]

NURBs support has been included in GPU's dating back to 2001 and the NV20 core (which had support for Higher Order Surfaces and B-Splines). The trouble with implementing it today is that it puts too much stress on the geometry engine for what it gives you. The best aspect of using NURBs is that you can do tessalation and rounder, more realistic looking curves, but it's still a generation of consoles away.

What is being concentrated on far more heavily this generation is High Dynamic Range lighting and even radiosity, NURBs isn't going to be realistic on the Revolution even though I'm sure it supports it (as does the PS3 and X360 no doubt).

[The Kernel]

Yeah, I was gonna mention that about Star Wars.

Exactly. There's no way the Revolution, or ANY console coming out next year for that matter, will be capable of that. It took clusters HOURS to render those scenes.

Yes, but render clusters use software CPU rendering, while a game engine uses hardware GPU rendering which can be thousands of times faster. This cannot be overstated; radiosity is also very intensive on render farms, yet there are experimental game engines which use radiosity for lighting, and many developers have said that they could make a game using radiosity lighting using today's technology.

Huh. Dunno. EVERY time I've heard of NURBs being done, it involved huge supercomputer clusters. I've never heard of it being more efficient than polygons; just that it produces better results (mathematical curves are better than polygons).

Could someone with more knowledge confirm whether NURBs takes more or less power than polygons?

It seems to me that if NURBs were supposedly better games would already be using it, as it is open...

NURBs takes a lot more geometry power to process, this is part of the reason they are not used but not all of it. NURBs doesn't offer any obvious benefits beyond tessalation and curves, so it's not worth the effort most of the time. That's why there hasn't been a big push for using it yet.

[Darth Wong]

All major 3D CAD/CAM programs use NURBS, and have done so for at least 10 years. Of course, they don't have to render in real-time, but I find it strange to hear that NURBS is considered some strange new concept in computer graphics.

[The Kernel]

All major 3D CAD/CAM programs use NURBS, and have done so for at least 10 years. Of course, they don't have to render in real-time, but I find it strange to hear that NURBS is considered some strange new concept in computer graphics.

I don't see anyone suggesting that, it's just new to games.

[Praxis]

All major 3D CAD/CAM programs use NURBS, and have done so for at least 10 years. Of course, they don't have to render in real-time, but I find it strange to hear that NURBS is considered some strange new concept in computer graphics.

I don't see anyone suggesting that, it's just new to games.

To the contrary; the quote in the original post states,
"Apparently the Revolution will utilize a new form of a polygon currently referred to as a NURB or nonuniform rational B-splines. These NURB's are said to be able to generate very detailed graphics within an enormous scope."

NURBs takes a lot more geometry power to process, this is part of the reason they are not used but not all of it.

Thats what I thought. Thanks.

[Darth Wong]

All major 3D CAD/CAM programs use NURBS, and have done so for at least 10 years. Of course, they don't have to render in real-time, but I find it strange to hear that NURBS is considered some strange new concept in computer graphics.

I don't see anyone suggesting that, it's just new to games.

Well, there were a few people saying that, actually. One person even said he'd never heard of NURBS in his life, even though NURBS curves predate modern graphics entirely and are essentially a mathematics concept. Not everyone follows these matters as closely as you do.

[Praxis]

Yeah, that "OMG TEH REVOLUTION CAN RENDER STAR WARS!" comment was quite funny

[Instant Sunrise]

Remember, the Rev isn't going to go higher than 720*480.

This gives them a bit more leeway than the PS3 and X360 which have to do between 1280x720 and 1080x540 (interlacing, it removes every other line).

My prediction is that revolution games are going to have more effects, but less fine detail. While on on the 360 you have HD, you may still see polygonal edges. They will still be there on the Rev, but MUCH harder to discern.

I'd give it another generation or two before NURBS is picked up in the gaming realm. Graphics in gaming is essentailly CGI from ~10 years back. This gen may have it, but I don't see that many games using it.

[The Kernel]

There are other problems with using NURBs; it requires the developer to completely relearn a number of aspects of graphics programming without the proper tools and techniques developed yet. Movies and CGI may have been using NURBs for years, but the type of code you need to interact in a realtime game environment are far different. Here are a few of the potential pitfalls with using NURBs and parametric surfaces:

I've discussed the math behind parametric surfaces and the basics of rendering them and hopefully made them seem appealing as an alternative to polygonal models. What I haven't addressed are some of the problems that are unique to parametric surfaces and some of the trickier aspects of using parametric surfaces in place of polygonal models.

Some of the more common issues with parametric surfaces are:

1. Texture mapping -- A simple approach to texture mapping a parametric surface is to use the u and v parameter values as texture coordinates (scaled appropriately to the 0 to 1 range). This works fine in some cases (and is what the sample code does), but there may be cases that this won't work for (if the knot vector is very non-uniform, then the texture will be stretched and squashed). To fix this problem, a second parametric surface can be used to generate texture coordinates. This increases overhead substantially, but may be the only solution (and it provides the most flexibility). Many rendering packages allow artists to apply textures to a parametric surface by using a second surface to map the texture coordinates. Keep this in mind as you use parametric surfaces for your applications.

2. Cracking - When two parametric surfaces meet at an edge (or one parametric surface meets a polygonal surface) it's possible for a crack to appear between the surfaces if their degrees of tessellation differ (or it they're just different sizes). This problem can be solved on a per application basis by adding connectivity information to the surfaces. It's not trivial to fix, but it's not impossible.

3. Collision detection - If you're doing collision detection in your application, you have several choices with parametric surfaces:

* Do collision detection on the mesh of control points by treating the mesh as a polygonal mesh - this is approximate and may be too course in some instances.

* Store all the generated triangles and do collision detection on these - while more accurate, it's more memory intensive as well as computationally intensive

* Depending on what types of objects may be colliding, you can solve the parametric surface equations with equations representing the other objects (even lines are difficult, though) and then just plug-and-chug to find collision points

* Use a combination of (a) and (b) by starting with (a) and then refining the surface to triangles to determine an exact hit.

4. Clipping - For surfaces that are partially within the viewing frustum, it can be difficult to clip prior to generating triangles. The problem is that you can't just clip control points because doing so would make the tessellation of the surface difficult to impossible. The easiest solution is to just generate triangles and then clip the triangles - the downside to this is the possibility of generating many more triangles than needed.

5. Back-surface Culling - Aside from clipping, it is also difficult to easily cull back-facing surfaces or portions of surfaces for similar reasons to the clipping problem. For example, a sphere can be defined with one surface but only half of the sphere is ever visible at one time. It would be nice to be able to cull the back-facing portion of the sphere before tessellation, but this is difficult to do.

6. Tessellation - Although a uniform tessellation algorithm is easy to implement and can run fast, in some instances other algorithms may provide better performance/quality. Surfaces that have very curvy areas as well as very flat areas may be better tessellated with a non-uniform tessellation algorithm.

7. Non-local refinement not supported - When refining a surface (i.e. adding detail), you must add control points in complete rows and columns so the control mesh remains a regular grid of points. This causes excessive control points to be added just to add detail in a small, localized region of a surface. Note that this is not an implementation issue, but rather an issue with NURBS surfaces (and other parametric surfaces).

8. Degenerate Normals - Because it's possible to have control points that are at the same location, it's possible for the derivatives of the surface to vanish (i.e. go to zero). This causes the calculation of surface normals to fail. To solve this, it is necessary to look at surrounding points and derivatives if one of the tangents gets too close to zero.

[The Kernel]

Remember, the Rev isn't going to go higher than 720*480.

This gives them a bit more leeway than the PS3 and X360 which have to do between 1280x720 and 1080x540 (interlacing, it removes every other line).

When is this urban legend going to die? The Revolution is not going to seriously benefit from a reduced resolution in this day and age, especially given the penalty for using less powerful graphics hardware (if they are actually going to meet a sub $300 price point).

And also, interlacing is irrelevent to this issue. All GPU's render internally progressive, GPU's don't support alternate line rendering, so internally it will be rendered progressive, then outputed in interlaced or progressive according to a scaler chip.

My prediction is that revolution games are going to have more effects, but less fine detail. While on on the 360 you have HD, you may still see polygonal edges. They will still be there on the Rev, but MUCH harder to discern.

And what, praytell, are you basing this on? You seem to not only be assuming equivalent hardware (a ridiculous assumption) but also that HD will negatively affect the performance of the X360 in a serious way. This is simply not true. For an example, try cranking the resolution of a modern game up from 640x480 to 1024x768. Then use FRAPS and measure the average frame rate. See any difference? And this is generous to your position as the X360 has an on-package frame buffer to reduce system bandwidth usage which the PC doesn't have.

I'd give it another generation or two before NURBS is picked up in the gaming realm. Graphics in gaming is essentailly CGI from ~10 years back. This gen may have it, but I don't see that many games using it.

It's not just performance, developers have been talking about replacing polygons with NURBS since 1999. It's about the underlying technology and its tradeoffs.

[Darth Wong]

Some of the more common issues with parametric surfaces are:

1. Texture mapping -- A simple approach to texture mapping a parametric surface is to use the u and v parameter values as texture coordinates (scaled appropriately to the 0 to 1 range). This works fine in some cases (and is what the sample code does), but there may be cases that this won't work for (if the knot vector is very non-uniform, then the texture will be stretched and squashed). To fix this problem, a second parametric surface can be used to generate texture coordinates. This increases overhead substantially, but may be the only solution (and it provides the most flexibility). Many rendering packages allow artists to apply textures to a parametric surface by using a second surface to map the texture coordinates. Keep this in mind as you use parametric surfaces for your applications.

Since I've used NURBS modeling programs which can put a texture on a surface with irregular meshing and do not require you to overlay surfaces, I can only imagine that he's complaining about something that would normally be handled at some subsystem layer.

2. Cracking - When two parametric surfaces meet at an edge (or one parametric surface meets a polygonal surface) it's possible for a crack to appear between the surfaces if their degrees of tessellation differ (or it they're just different sizes). This problem can be solved on a per application basis by adding connectivity information to the surfaces. It's not trivial to fix, but it's not impossible.

This is a model quality issue. A good modeler will make seamless models; in fact, "watertightness" is a standard quality control check with 3D models for manufacturing purposes, because they have to be converted into solids for many applications such as finite-element analysis.

3. Collision detection - If you're doing collision detection in your application, you have several choices with parametric surfaces:

* Do collision detection on the mesh of control points by treating the mesh as a polygonal mesh - this is approximate and may be too course in some instances.

* Store all the generated triangles and do collision detection on these - while more accurate, it's more memory intensive as well as computationally intensive

* Depending on what types of objects may be colliding, you can solve the parametric surface equations with equations representing the other objects (even lines are difficult, though) and then just plug-and-chug to find collision points

* Use a combination of (a) and (b) by starting with (a) and then refining the surface to triangles to determine an exact hit.

Simply using the control points is the easiest; while NURBS can theoretically create huge sweeping surfaces with very loosely spaced control points, I can tell you right now that this is almost never done in practice. So worrying about deviations between surfaces and control points is a theoretical concern that will probably never mean anything under realistic conditions. And any modeling program can simply add extra u and v curves. Besides, given the shitty collision modeling that you see in so many polygon-based games, this seems like a strange area of criticism.

4. Clipping - For surfaces that are partially within the viewing frustum, it can be difficult to clip prior to generating triangles. The problem is that you can't just clip control points because doing so would make the tessellation of the surface difficult to impossible. The easiest solution is to just generate triangles and then clip the triangles - the downside to this is the possibility of generating many more triangles than needed.

Yes, you need to generate surfaces out to their full extent, even if they extend beyond the screen. Is this really a big concern though? How often would this cause real problems?

5. Back-surface Culling - Aside from clipping, it is also difficult to easily cull back-facing surfaces or portions of surfaces for similar reasons to the clipping problem. For example, a sphere can be defined with one surface but only half of the sphere is ever visible at one time. It would be nice to be able to cull the back-facing portion of the sphere before tessellation, but this is difficult to do.

That's true, but that's also a modeling issue. Generally speaking, modelers try to avoid using one-piece primitives as-is, and will usually split up a sphere into pieces as they work with it anyway.

6. Tessellation - Although a uniform tessellation algorithm is easy to implement and can run fast, in some instances other algorithms may provide better performance/quality. Surfaces that have very curvy areas as well as very flat areas may be better tessellated with a non-uniform tessellation algorithm.

Once again, while it is possible to create really wild surfaces with NURBS, a careful modeler will usually make multiple surfaces rather than trying to force everything into a single surface.

7. Non-local refinement not supported - When refining a surface (i.e. adding detail), you must add control points in complete rows and columns so the control mesh remains a regular grid of points. This causes excessive control points to be added just to add detail in a small, localized region of a surface. Note that this is not an implementation issue, but rather an issue with NURBS surfaces (and other parametric surfaces).

Yet again, we seem to be encountering a mindset of assuming that people would stretch the NURBS system to the limits of what it can do, just for the hell of it. If a modeler has a big flat surface and wants to add a boss to it, he's not going to try and warp the surface to make the boss; he'll just cut a hole in the surface and use a separate surface to model the buss.

8. Degenerate Normals - Because it's possible to have control points that are at the same location, it's possible for the derivatives of the surface to vanish (i.e. go to zero). This causes the calculation of surface normals to fail. To solve this, it is necessary to look at surrounding points and derivatives if one of the tangents gets too close to zero.

Speaking as someone who spent nearly ten years modeling surfaces, you simply don't make degenerate surfaces if you're a competent modeler.

It seems to me that most of his complaints could be resolved at the modeling stage, and are the result of trying to optimize rendering routines to compensate for sloppy and incompetent modeling.

[The Kernel]

Speaking as someone who spent nearly ten years modeling surfaces, you simply don't make degenerate surfaces if you're a competent modeler.

It seems to me that most of his complaints could be resolved at the modeling stage, and are the result of trying to optimize rendering routines to compensate for sloppy and incompetent modeling.

What you have to understand about game modelers is that they aren't engineers and they don't get paid $100k+ a year for doing modelling work. I'm not qualified in the slightest to analyze your complaints as I'm not a CAD/CAM person, but I can say that anything that would increase the costs of game development for relatively little benefit isn't going to get used. And since most of the costs of games today already stems around creating models and textures, if NURBS requires more compotent model people then it isn't going to look very attractive to most studios.

[The Kernel]

On second thought, I can probably comment on a few of these points:

This is a model quality issue. A good modeler will make seamless models; in fact, "watertightness" is a standard quality control check with 3D models for manufacturing purposes, because they have to be converted into solids for many applications such as finite-element analysis.

I don't think that models in games have to be concerned with manufacturing quality control.

Yes, you need to generate surfaces out to their full extent, even if they extend beyond the screen. Is this really a big concern though? How often would this cause real problems?

If you are generating excess triangles, then that is a realtime performance concern for the geometry engine right?

Once again, while it is possible to create really wild surfaces with NURBS, a careful modeler will usually make multiple surfaces rather than trying to force everything into a single surface.

I'm wondering, is this as easy to do when you have to create many times more models in a given month?

I'm commenting on your comments not because I'm capable of questioning you on it, but because I'm wondering if you are looking at this from the perspective of someone who creates models for manufacturing rather than for games. A game modeller obviously has to create many times more models, and isn't concerned about using them for manufacturing, so wouldn't it be a given that they aren't going to be as careful designing them?

[Instant Sunrise]

Alright, since it appears that the Revolution is not going to benefit from the reduced resolution of NTSC versus HD. Point conceeded.

I could be wrong, but in most cases, game modelling is a bit closer to special effects modelling than CAD. Albeit game models start with a mesh, and are designed for rendering performance over quality.

[lPeregrine]

Something you're missing here is that NURBS modeling has a huge advantage, the ease of level of detail scaling. Changing the detail of surfaces is a simple matter of changing one number. A curved wall can have 100 segments and appear perfectly smooth when you're right next to it, then scale down to 5 segments when it's in the distance. All with just one simple number change. Compare this to polygon modeling, where you have to manually build every level of detail, and you can only have a few of them.

On second thought, I can probably comment on a few of these points:

This is a model quality issue. A good modeler will make seamless models; in fact, "watertightness" is a standard quality control check with 3D models for manufacturing purposes, because they have to be converted into solids for many applications such as finite-element analysis.

I don't think that models in games have to be concerned with manufacturing quality control.

Fortunately watertightness is just good modeling in general, and doesn't take much extra effort. A competent modeler is going to have no trouble making working NURBS models.

Yes, you need to generate surfaces out to their full extent, even if they extend beyond the screen. Is this really a big concern though? How often would this cause real problems?

If you are generating excess triangles, then that is a realtime performance concern for the geometry engine right?

True, but it's made up for by the ease of level of detail scaling. Sure, you might have to process a few more object-bits, but in exchange, you don't have to do it at full detail. And something to remember is that we aren't stuck in the old days, when 10 extra polygons was a serious issue. Hardware has advanced well past the point where it can accept slight inefficiency.

Once again, while it is possible to create really wild surfaces with NURBS, a careful modeler will usually make multiple surfaces rather than trying to force everything into a single surface.

I'm wondering, is this as easy to do when you have to create many times more models in a given month?

Yes. Breaking a model up into sections actually helps efficiency and lets you work on it in sections without worrying about effects on other parts. And again, we're talking about skilled artists here, this is a pretty trivial bit of extra work.

I'm commenting on your comments not because I'm capable of questioning you on it, but because I'm wondering if you are looking at this from the perspective of someone who creates models for manufacturing rather than for games. A game modeller obviously has to create many times more models, and isn't concerned about using them for manufacturing, so wouldn't it be a given that they aren't going to be as careful designing them?

Perhaps, but careless modeling work isn't professional no matter which method you use. Polygon modeling isn't immune to problems caused by careless design either. Trust me, do a poorly designed polygon model, and you'll create plenty of mesh errors.

[The Kernel]

Something you're missing here is that NURBS modeling has a huge advantage, the ease of level of detail scaling. Changing the detail of surfaces is a simple matter of changing one number. A curved wall can have 100 segments and appear perfectly smooth when you're right next to it, then scale down to 5 segments when it's in the distance. All with just one simple number change. Compare this to polygon modeling, where you have to manually build every level of detail, and you can only have a few of them.

I mentioned tesselation a few posts up.

[Instant Sunrise]

sooooooooooooooo.......

Polygonal modeling is basically 3D raster images.
NURBS would be like a 3D vector image.

[Praxis]

Interesting analogy. That'd be about right.

EDIT: Nevermind. lol

[The Kernel]

sooooooooooooooo.......

Polygonal modeling is basically 3D raster images.
NURBS would be like a 3D vector image.

No, not at all, that's a terrible analogy. What NURBS lets you do is make it easier to create varying level of detail models, something which is much harder to do with polygons. This means that objects which move from far distances to close range have to maintain the exact number of polygons at a distance as they do up close. This is a neat thing to do with NURBS, but it doesn't automatically mean better performance, especially in a scene that isn't geometry limited.

[Darth Wong]

From a modeler's perspective, it's simpler still: NURBS allows you to create real shapes. In other words, a NURBS model is an accurate representation of the real thing. Polygon-based models are not; they're just deemed "good enough" for most purposes. Unless the object in question happens to be polygonal itself, you can't completely model it with polygons.

A curved NURBS surface is smooth no matter how closely you zoom into it. But a polygonal representation is faceted. If you add more polygons, you can get closer before the facets show, but it is always faceted, and you can always see those facets if you get close enough. Worse yet, if you use a huge number of polygons to make it look smooth at close range, it will slow everything down like molasses when you zoom back out again.

To put it in mathematical terms, a NURBS surface is like the equation y=x^2: a perfect curved parabola at any point along its path, and at any precision. A polygon surface, on the other hand, is like a bar graph of that same equation. Not smooth at all.