Sign in to follow this  
LittleFreak

Real-Time NURBS rending for games?

Recommended Posts

First has it ever been done. For example: A model file is saved of nothing but the nurbs and skeleton then a game engine loads this infomation and calculates the polygon vertex based on level of detail and renders the model. I'm curious to know how this would work. It would definatly give you amazing Level of detail control because you could render as low poly count (nerbs nodes = vertexs) to a infinite poly model. Also I beleive nurb data is alot smaller then vertex data. Im curious to know if this has ever been done or attempted. And if not does anyone know why not. I dont know alot about NURBS just the general ideas. I might try to implement this system but Id like to see if there is more infomation on the topic.

Share this post


Link to post
Share on other sites
It's been done experimentally, but never in the context of a game. Real-time procedural geometry became practical with vertex shaders. A long time ago I thought real-time NURBS was the next step in video hardware. I was wrong; pixel and vertex shaders took the limelight. We may be coming to a point where fragment shaders are reaching their apex, and now that video hardware can pump out triangles like it's nobody's business, real-time NURBS may be on the horizon. I'm not good at predicting these things.

Share this post


Link to post
Share on other sites
hi,

maybe not in the context of games, but my boss has written a paper about it

http://cg.cs.uni-bonn.de/docs/publications/2006/guthe-2006-gpu-based.pdf

in fact, I think it was his phD thesis and he showed me a real-time demo of this stuff, too.

Share this post


Link to post
Share on other sites
Theres a good article on gamasutra about modeling with curves and the problems it causes: http://www.gamasutra.com/features/20020626/hargreaves_01.htm

Share this post


Link to post
Share on other sites
Quote:
Original post by LittleFreak
First has it ever been done. For example: A model file is saved of nothing but the nurbs and skeleton then a game engine loads this infomation and calculates the polygon vertex based on level of detail and renders the model.


yes, MotoGP on the xbox 1.

Quote:
I'm curious to know how this would work.


Cache the results of the CoxDeBoor and you cut out most of the heavy work needed to be done. The resulting surface always falls into nice triangle strips to render. There are a few papers on gamasutra about it, and there are a few examples to get you started on my website.

Quote:
It would definatly give you amazing Level of detail control because you could render as low poly count (nerbs nodes = vertexs) to a infinite poly model.


Lies i tell you;) the problem is that unless you use a complex tesselation scheme that adds detail where you need it (which is *way* too slow for real time games), you tend to end up with high poly counts in all the wrong areas. A normal poly model that would look amazing at 15,000 verts, would need about 10x times that amount if modelled in nurbs to look as good (if you used a decent real time tesselator). GLUnurbs is a really good example of how *not* to do it. Putting the NURBS computation as a hardware function is definetly the wrong thing to do (anyone remember NV_evaluators? they got silently dropped from the nvidia drivers....)

Quote:
Also I beleive nurb data is alot smaller then vertex data.


ish, but not really. Whilst in theory this is true, it's not that true after an artist has set up a character. Quite often you'll find that you have as many patches as you would have had polygons. ATI's PN-triangles is a far better approach imho.

Quote:
Im curious to know if this has ever been done or attempted. And if not does anyone know why not. I dont know alot about NURBS just the general ideas. I might try to implement this system but Id like to see if there is more infomation on the topic.


The big problems with NURBS are :

1. artists do not find them easy to work with. It typically will take a good NURBS modeller about 3 to 4 times the amount of time to do a nurbs model compared to an artist who's good with poly's.

2. There are very few artists who are good with NURBS.

3. Hard edges and corners are a near impossibility when modelling in NURBS. Maya has some nice tricks and fillet types to get around this, but they are impossible to use realtime.

4. texturing NURBS is a PITA. Polygonal models are much easier to texture, and as such the texture usage is considerably smaller (At a rough guess, I'd say there is between a 1:10 -> 1:20 ratio between poly texture usage v.s. Nurbs texture usage). With polys, it's relatively eay to work within a constrained texture amount; i.e. 1 128x128 RGB texture per character. Ok, it might not look great, but at least you *can* do it if needed. No such luck with nurbs. If texture memory is at a premium, don't use NURBS. (as an example, take a look at all the wasted texture usage in the tga's in my uni project).

5. Skinning (and other deformations) are quick to compute if you just modify control points. But (and it's a *big* BUT), big deformation problems around the knees and elbows are bound to appear. Maya and XSI get around this problem by interpolating things such as skin weights across the surface using the Cox De Boor. This is very slow! In the case of FFD's, things are worse, since Maya for example will actually perform the deformation on the finally evaluated points. So no speed gain will appear there. (My uni project just skins the CV's).

some simple examples.
my uni thesis project from a few years back. I've got a faster implementation now, but the principle of how i'm doing remains similar. The big problem is actually finding modellers who like to do stuff in NURBS (there are *very* few of those people about i can assure you....)

Share this post


Link to post
Share on other sites
Quote:
Original post by LittleFreak
RobTheBloke perty much answered everything. Thats what my thought were. So until video cards are made to do nurbs i think ill stick to vertex.

NURBs don't have any real advantages over subdivision surfaces, that I can see at any rate. I worked with NURBs a bit (needed compatibility with an elderly CAD system), but they were a right PITA from an implementation point of view, and not at all intuitive to model with.

Share this post


Link to post
Share on other sites
Quote:
Original post by LittleFreakSo until video cards are made to do nurbs i think ill stick to vertex.


It has already been done (NV-evaluators, gl-evaluators - afaik, only one graphics card ever supported HW accelerated gl evaluators). The problem is that the most expensive part of the computation (namely the cox-de-boor) should really be cached to get decent frame-rates. This is something that you can't do as a HW function, and as such your own cached implementations will always be faster. I don't ever see a need to introduce HW nurbs onto graphics cards, it's simply not a good idea, which is why Nvidia dropped their NV evaluator extension.....

Quote:
Original post by switfcoder
NURBs don't have any real advantages over subdivision surfaces


Not strictly true. NURBS form a pure mathematical description, subdivs do not. CAD packages and things such as 3D printers require input as NURBS since they allow you to have real world surface descriptions that can be turned into machined parts. Mind you, boolean geometry also gives you that ability.


Quote:
Original post by switfcoder
but they were a right PITA from an implementation point of view


Handling the data sets for Nurbs tends to be much nicer than handling polygons, at least in my experiance. Admittedly it starts to get harder when you deal with non-uniform tesselations, fillet surfaces, and trim curves. If you understand how the math relates to code, they are not *too* bad.

Quote:
Original post by switfcoder
and not at all intuitive to model with.


I would say that this is the biggest problem by far.... I used to hate modelling with Nurbs, that is until i actually figured out what the math was all about, then it did get easier. If I told an artist to use NURBS these days i'd be lynched... ;)

Share this post


Link to post
Share on other sites
Quote:
Original post by RobTheBloke
Quote:
Original post by switfcoder
NURBs don't have any real advantages over subdivision surfaces

Not strictly true. NURBS form a pure mathematical description, subdivs do not. CAD packages and things such as 3D printers require input as NURBS since they allow you to have real world surface descriptions that can be turned into machined parts. Mind you, boolean geometry also gives you that ability.

That would be why I was using them [smile]

Quote:
Quote:
Original post by switfcoder
but they were a right PITA from an implementation point of view

Handling the data sets for Nurbs tends to be much nicer than handling polygons, at least in my experiance. Admittedly it starts to get harder when you deal with non-uniform tesselations, fillet surfaces, and trim curves. If you understand how the math relates to code, they are not *too* bad.

Well, that aspect was no fun, but understanding the math behind the fairly well, it wasn't too painful. However, performance was a large problem - tessellation cost increases with the square of the size of your control point grid, even for uniform tessellation. In addition, a manipulation of even a single control point can affect the *entire* tessellated surface, which limits caching possibilities.

Quote:
Quote:
Original post by switfcoder
and not at all intuitive to model with.

I would say that this is the biggest problem by far.... I used to hate modelling with Nurbs, that is until i actually figured out what the math was all about, then it did get easier. If I told an artist to use NURBS these days i'd be lynched... ;)

Ja, and for good reason. As I said, the math is within my reach, but still... the machinations necessary to model a sphere...

Share this post


Link to post
Share on other sites
Quote:
Original post by swiftcoder
Well, that aspect was no fun, but understanding the math behind the fairly well, it wasn't too painful. However, performance was a large problem - tessellation cost increases with the square of the size of your control point grid, even for uniform tessellation. In addition, a manipulation of even a single control point can affect the *entire* tessellated surface, which limits caching possibilities.


when the LOD changes, uv's, vtx colours, indices, and the results of the cox-de-boor can all be cached. (indices, uv's and colours can all be uploaded into a static VBO or buffer). It's not that often that you need to change lod's though.

When the points change poisition you only need perform a sum of mults between the cached cox de boor output and the current control points & then calculate the normals. It's not *that* expensive. The work when the LOD changes is far more computationally expensive.

This is actually one of the big wins that NURBS have over subdivs. Whilst the subdiv can still cache the UV's, vtx colours and indicies. The computation of the points can't really be cached that much. A subdiv has to perform the full computation to recaluate itself when a point moves, whereas you can cache the result of the most expensive part of the computation for a NURBS surface.....

Mind you, artists prefer subdivs and polys ;)

(Oh, and for any nurbs model you typically end up using some polygonal parts anyway. Some items are just to complicated to model in NURBS, so you just do it in polys).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this