To Poly or not to Poly... That is the question...

Miscellaneous Forums/General Discussion/To Poly or not to Poly... That is the question...

OK... Fun debate time for all the family.

With poly counts going through the roof there's the theory that each poly will actually be no bigger than a pixel... So what's the point? Why not just raytrace the whole shebang.

Direct X and OGL have been cheats to get raytraced effects, pixels shaders, soft shadows, volumetric lighting etc are simply to trying to produce what raytracers have been doing for years.

Historically this was necessary, but computer power has got to a point where maybe cheating isn't necessary anymore?

CPU speeds are getting faster and faster. Multi core processors are more and more common, Multi processor motherboards are more common.

Realism in games is fast approaching 'uncanny valley'.

NVidia have aquired Ageia which suggests maybe they're branching out to prepare for the raytrace wars and when the GPU is simply hardware raytrace CPU.

Your thoughts please.

I just want to make a game that works, who knows, if we can see the future, a (proper) set of lottery number is more helpful.

Not much time right now, so only a short one: If i remember it correctly we already discussed about this here before. I think the first step will be better performing integrated chips like the Fusion from AMD (2/3 CPU cores with one GPU core) and then we'll see chips like the Larrabee with more and more cores on the die. Realtime Engines will start to replace polygon engines in the future but it will take some years to make this common hardware and they also have to sort some software issues out, for example the animation issues. I think that in the end the raytracing engines will be better than the polygon engines and most important they are likely to work more reliable and also offer a more consistent look on different systems due to less propritary issues. So i welcome them.

The absolute ideal would be that CPU's get fast enough that you can do everything you want in software, but that's a long way off.

Raytracing the whole shebang is still not realistic at the moment, and I don't think it will be for some time. Presumably, even if you're raytracing, your models will be poly-based, and even with high end kit, realtime raytracing is not possible even for something like the original Quake. I'm sure it will come one day, but could be a few years off yet, especially with the current cpu frequency barrier.

Presumably, even if you're raytracing, your models will be poly-based
Not necessarily.
http://en.wikipedia.org/wiki/NURBS

And real time raytracing:
http://www.openrt.de/
http://www.realstorm.com/

they could have released ray-tracing hardware for gaming a while back,
maybe they would not have made as much money as normal GPU's because you still need lots of processing power and videoram

What if you don't want to make a realistic looking game? How will raytracing help with that? At least the current model allows for games like TeamFortress2, and fantastical/unrealistic effects.

Also, do end users want realism? I was under the impression that only a small minority of gamers actually care about anything approaching realism. I suppose if we are only talking about lighting, then maybe it can't do any harm as an option.

At least the current model allows for games like TeamFortress2, and fantastical/unrealistic effects
Why would raytracing rule out effects like that? Take a look at any of the CG movies, they're all raytraced, from Finding Nemo to Final Fantasy.

Some interesting links, Rob. I didn't investigate long enough to see if their solutions were fast enough for games yet.

I'm the first one to say, graphics aren't the be all and end all in games, but all things being equal, I would rather have raytracing than not.

I don't see raytracing ever becoming the mainstream for games. People have been predicting it for well over a decade and it's never gained any traction. For 3D Visualization, sure, but it would be a step backwards from where we are today to move to raytracing. The current generation of videocards have much more power than the last generation, like the ability to create geometry on the fly. It wouldn't make sense to tear that all down and start again. It wouldn't make sense to retrain every artist and programmer from scratch.

Ultimately though it will depend what the big players like EA and Ubisoft want. If they want change, they'll probably get it and if they don't, they almost certainly won't. Now how often do you see EA in favour of major change?

Some interesting links, Rob. I didn't investigate long enough to see if their solutions were fast enough for games yet.
It's not, it's certainly not as fast as poly based rendering, but that's largely due to there being no dedicated hardware like we have now.

The argument is if you tried to render a high poly scene by comparison using nothing but software the raytrace would out perform it.

The point of this post is looking to the future rather than what is available now.

but it would be a step backwards from where we are today to move to raytracing.
Explain? Correct me if I'm wrong but there's nothing that can be done with polygon based graphics that can't be done with raytraced poly free graphics. Pixel shaders etc are simply attempting to emulate what raytracing has done for years.

It wouldn't make sense to tear that all down and start again.
Frequently it does make sense to tear stuff down and start again.
As I said, the reason for polygon based graphics is purely historic, if real time raytracing was feasible when 3D games first started to come out it would have been used. Since then poly counts have increased, and more effects have been added to make poly based graphics more like raytraced graphics.

It wouldn't make sense to retrain every artist and programmer from scratch.
I'm not in the business but I'm pretty sure a lot of modelling is done using splines and nurbs already, it's just that it's rendered into polygons rather than kept as is. Mustang will know!

Correct me if I'm wrong but there's nothing that can be done with polygon based graphics that can't be done with raytraced poly free graphics. Pixel shaders etc are simply attempting to emulate what raytracing has done for years.

Here's the main advantage polygon/shader rendering has over raytraced rendering: Speed.

For the same amount of perceived visual quality, polygons/shaders will always be faster than raytracing (unless some entirely revolutionary technology is created). This means that for the same frame rate, the visual quality of polygons/shaders will always be better than raytracing.

As technology gets faster and faster, this will still continue to be true - raytracing will lag behind polygons/shaders. For example, even though a raytraced version of "Crysis" might be possible at 50 FPS in several years from now, something 10x more realistic will be already out using traditional methods.

I'm not in the business but I'm pretty sure a lot of modelling is done using splines and nurbs already, it's just that it's rendered into polygons rather than kept as is. Mustang will know!

Just how do nurbs give you the extreme level of detail that polygons do? If you want super-realistic, teletubbies-like graphics, then raytraced nurbs and splines should work great. But for realism, smooth mathematical shapes just don't apply:

I'd like to see you render that with nurbs.

John, I think you're missing the point slightly with Nurbs, you still have textures and normal maps in the same way as you would with poly based. Polygons give you less detail than nurbs as it's straight lines joining them up, with a nurb surface you can have a bendy line. Likewise a sphere is round in the raytrace world rather than a faceted approximation in the poly world. Nurbs can be as soft as you like or hard like poly modelling.

You still have a level of detail, the more control points on a surface is like having higher polygon count.

After a quick google of Nurb Dragon I found this...
http://www.keongputer.com/tutor/texturing/NurbDragon/

I'm sure it's not the best example, but it is an example.

graphics in modern games arent that high res, its mostly just the shaders and textures that make it that way, Patch and nurbs modeling would be ideal especially when it lends itself well to LOD since its easy to iterate the meshes to a higher detail.

Most smoothing algorithms used for box modeling use nurbs algorithms of some kind. And when you make high res meshes for normal mapping onto a 5-6k mesh, its mostly a regular low poly mesh with small chamfers to double up the edges in detail areas and a smoothing/tesselation modifier applied to make the high res version.

Hey, Rob...

No one stopping you from doing this, or making game with this tech, I think there're something like Pix-Omatic etc that you can use right now.

Real-time ray tracing is absolutely the wave of the future. It will happen, sooner than later.

John, I think you're missing the point slightly with Nurbs, you still have textures and normal maps in the same way as you would with poly based.

The model I posted doesn't use normal maps. It's all polygons and vertex colors.

I guess we'll have to wait until someone like Mustang posts, but I'm pretty sure nurbs are only used as a starting point when modeling (to add any real detail, they are converted to polygons first). Also, representing models with detail identical to the dragon model above without normal maps would be impossible with nurbs. With normal maps, it would be very hard to get it looking correct since the low-poly mesh on which a normal map is applied has to approximate the model very closely, while being very low-poly. As far as I know nurbs aren't very good for this (unless you want your model to look like bumps-on-a-balloon).

Here's another example of what you can do with polygonal modeling / rendering. Notice the beak, feet, sagging crown, and bone/muscle shapes. Do you think this could be done in nurbs?

John... A polygon mesh could simply a nurb surface where each vertex is a control point and every line is straight. Nurbs don't have to have straight lines joining them up therefore you could have more detail for the same amount of control points.

I can't see how a nurb model could possibly be less detailed than polygon. And generally I would suggest for the same amount of control points (vertices) you'd have more detail.

Not betting my life on this though!

Raytracing doesn't rule out using poly meshes anyway!

Would be nice to have a real time lightmapper :D

Nurbs don't have to have straight lines joining them up therefore you could have more detail for the same amount of control points


This is absolutely correct. 3d Nurbs work on the same principle as 2d splines. The image below shows 2 shapes I created in MS Word...

The lower shape contains just straight lines (like a 3d polygon). The upper shape is made up of spline curves.

Each shape has the same number of control points (5) but as you can see you can clearly get far more detail out of the spline shape, and you can still have sharp edges if required.



John... A polygon mesh could simply a nurb surface where each vertex is a control point and every line is straight.

This is exactly my point - the only way you can achieve high detail with nurbs is to have the same number of control points as there would be vertexes in a polygon version of the same thing, in which case nurbs would be much much slower than simply using polygons (and with no increase in perceived detail).

The advantage to something like nurbs would be when you want to raytrace a perfect sphere, or other smooth mathematical shapes. If you had hardware nurbs raytracing support, this would provide excellent performance for simple blobby objects. But unfortunately for nurbs, the world isn't perfectly smooth and blobby, and the fact is that polygonal representations are much much more efficient than nurbs for anything but the smoothest of surfaces.

Explain? Correct me if I'm wrong but there's nothing that can be done with polygon based graphics that can't be done with raytraced poly free graphics. Pixel shaders etc are simply attempting to emulate what raytracing has done for years.

They're not emulating anything. Pixel shaders are just code. You can have them do whatever you want. If you want them to raytrace, they can. If you want them to do something else, they can do that too. So it would be going backwards in my estimation, to go from a system which can already raytrace ( among other things ) to one which can only raytrace.

Frequently it does make sense to tear stuff down and start again.

Perhaps, but I don't see any argument for it here. What's the payoff? You say that pixel shaders are only "emulating" ( although I don't understand what this means ) so presumably you want to get rid of them in favour of a hardcoded solution. Hardcoded solutions are necessarily less flexible. If I accept that a flexibility loss too is necessary sometimes, what's my payoff? What do I get to make up for the loss of flexibility?

I can't see how a nurb model could possibly be less detailed than polygon.

Because you no longer model polygon by polygon, that's why. These days the highest resolution models are painted with brushes in programs like MudBox, ZBrush and 3DBrush. You can literally take a texture and paint it onto a mid-res model and have the program generate the polygons to represent it. Creating a nurbs surface to approximate that would be like painting a picture and then blurring it. You lose a little detail.

As JohnJ says, Nurbs are a great way of modelling, but they're for smooth curve, not sharp detail. For sharp detail, you either need texture maps or geometry created from them.

Raytracing doesn't rule out using poly meshes anyway!

Well now I'm really confused, because I don't know what you're left with. You already stepped back away from pure raytracing in reponse to previous comments about non-photo-realism and normal mapping, etc. Although since you also dismissed pixel shaders, I'm not sure how you think you're going to get all these features which are currently only possible with pixel shaders. But anyway, now you're stepping back from ditching polygons too. If you take away the painting of the pixels and the creation of the geometry, what exactly are you suggesting is going to change? And what to?

The bottom line is you already can raytrace, if you want to. I'm sure a quick google will show up a bunch of raytracers written in pixel shaders. The current architecture not only permits it, it excels at it. You don't have to multithread anything because multithreading on GPU's is automatic with pixel shaders. Each pixel is considered separately and bears no relation to any other pixel. So this means that the shader for each pixel can be run in parallel. 2,4,8,16,32.. however many shaders your videocard can run in parallel, it does. There's no room for error, and no need to debug because there is zero concurrency. Possibly fortuitously, but they just happen to have made a hardware architecture which is ideal for raytracing and where dozens of cores as CPU's get more complex just makes things better and better.

Ray traced shadows have been about for ages. They're called stencil volumes and John Carmack is a big fan. They're pretty slow though, even more so if you try to generate soft shadows with them, and they're pretty error prone, so they've been phased out in favour of more reliable and faster methods. But still, it's perfectly possible and even more so in DX10 where nothing needs to be done on the CPU.

Realtime lightmapping is already around too. There's Precomputed radiance transfer via spherical harmonics, essentially realtime global illumination. There's ambient occlusion mapping, which I think someone did a demo of around here. Might have been Halo?

All the effects are already possible, even if some of them have taken a backseat as better methods have cropped up.

If computing power doubles every 2 years, in 10 years we will have some semi-usable realtime raytracing.

CPU's havent got much faster in the last couple of years though. GPU's are leading the way. If realtime raytracing is going to happen, it's not going to be Intel or AMD facilitating it with their CPU's.

Raytracing is a massively parallel problem, leanding itself to the ethos of GPU's, as they are already solving massively parallel problems. The same design ethos will apply to any usable hardware that does realtime raytracing.

The rendering part of the problem (in hardware) is perhaps not the most difficult obstacle in releasing something to market. Deciding on standards and having a common API in place is the bigger hurdle. OpenGL is all well and good, but doesn't provide a rich enough set of methods to control all the variables a developer would want to see in a raytraced project.

Microsoft would have to step up with a DirectX upgrade (or add-on) and the OpenGL camp would have to reorganise a little. OpenGL does have a lot of features imagined of raytracing, from perhaps 10 years ago, but advances in raytracing technology haven't been catered for (or even imagined to be needed!).

I can forsee a new player coming to market with bold claims of wonderful new hardware capable of realtime raytracing. Probably with either a proprietary API or a kludge of OpenGL. Not within the next couple of years, but somewhere down the line. They will, of course, be snapped up by Nvidia ;)

I can forsee a new player coming to market with bold claims of wonderful new hardware capable of realtime raytracing. Probably with either a proprietary API or a kludge of OpenGL. Not within the next couple of years, but somewhere down the line. They will, of course, be snapped up by Nvidia ;)

Exactly! Nvidia didn't buy Ageia because they want to branch out, they bought Ageia to stifle competition. Goodbye Ageia PPU, hello Nvidia GPU with new PhysicsPower™ technology*.

* Some arbitrary hacked on API which ATI cards can't use which enables programmers to get treble performance by using the PhysX physics engine with Nvidia cards.

My point with pixel shaders and modern tech being cheats is simply this; Water, reflections, mirrors, lighting, shadow volumes etc. It's all work arounds on the limits of technology.

Water, shadows, visible light, reflections etc has always been something that raytracers have shown off, and something that poly based 3D graphics cards has always struggled with and only now are doing estimations of this.

As I said this isn't a I'm right you're wrong, it's a debate and I'm curious what people have to say on the subject.

I'm really just playing devils advocate here trying to stimulate debate.

Intel is on-board for ray tracing technology, as their multi-core processors excel at the task, so I predict we'll see something useable for real-time / games five to ten years from now.

This is the most recent article (17 Jan 2008) I've read on the issue (written by an Intel researcher):

http://www.pcper.com/article.php?aid=506&type=expert&pid=1

Sounds really good, IMO.

Water, shadows, visible light, reflections etc has always been something that raytracers have shown off, and something that poly based 3D graphics cards has always struggled with and only now are doing estimations of this.

By their very nature, estimations will always be faster than mathematically correct versions of the same thing. If you can get the estimation to look as good (or better in some cases) than the "correct" version, then it would be foolish to choose the slower version.

And regarding shader vs. raytracing - here's a raytraced version of water:


And here's a pixel shader version of water:


"Correct" isn't always "better" in computers. The real world is so extraordinarily complex, the only truly "realistic" way to render something would be to simulate every photon and it's effect on every atom. Until that's possible, shaders are not only faster, but in some cases more visually realistic than raytraced objects.

I have little to contribute to the real point of the thread, which is whether or not raytrace renderers should be used for realtime graphics, but I do have a response to both the thread title and a significant tangent within the thread.

I am mightily confused by people making a distinction between polygons and raytracing. Polygons are simply how the geometry is represented in the computer's memory. Raytracing is a method for rendering an image based on that geometry. The two are completely separate considerations.

Just look at how they make computer movie imagery and you'll understand that the 3D technology we're using for realtime is no where near that. There is such a long way to go. Shaders are used in raytracing, you can have crappy water in any rendering method. Labelling raytracing unrealistic imagery is extremely backwards thinking and is in itself biased from the point where a lot of people didn't do enough research into the subject to actually discredit that belief.

http://www.imagico.de/pov/gallery.html
http://www.shipbrook.com/jeff/raytrace/index.html
http://en.wikipedia.org/wiki/Image:Glasses_800_edit.png
http://www.ignorancia.org/en/index.php?page=Raining


http://hof.povray.org/

This image was made using nurbs only and it took 8:02 mins to render using the maya software renderer on highest quality. The low quality render would have been good enough for games though and it took only 25 secs to render on my silly laptop.

As for the dragon you can convert poly to nurbs very easy and it usually looks better as a nurbs.

As for the dragon you can convert poly to nurbs very easy and it usually looks better as a nurbs.

I've never seen a tool that can convert polygons to NURBS, and I've been doing 3D modeling for a long time. NURBS to polygons is easy enough, but polygons to NURBS is basically impossible.

Well, you can convert subdivision surfaces to NURBS, because SubDs are basically treating vertices as if they are NURBS control points, but that's not going to give you great results. And anyway why bother? The modeling is already done, the texturing will be totally different (NURBS are a lot less flexible about texture mapping,) and the end result looks exactly the same. Which leads into the other point...

I also don't see why you say the model would look better as NURBS. Not that polygons look better than NURBS either; my point is they look the same. It's just two different ways for the computer to store geometry data. Either way the geometry is drawn using the exact same renderer.

[qoute]It's just two different ways for the computer to store geometry data. Either way the geometry is drawn using the exact same renderer.[/quote]
thats mostly true, however the nurbs is considerably better at L.O.D. because thats what it is. in maya, the modeler i use, if you create a nurbs surface and look carefully it will look slightly faceted thats because the comp calculates how many polys of a certain size can fit on the surface. as for it looking better you can have the same size object with the same amount of points on it but the nurbs will look more detailed because theres more polys. personaly though I don't like modeling in nurbs.

I believe that things will definately go the way of raytracing in time. History has taught me that each technique has a time to dominate.

I remember back to the days of Wing Commander I & II. The ships were 2D images which were rotated and scaled in real time to give the impression of 3D. There was no way that level of detail could have been done with real time polygons at that time! The same was true of the 2D perspective blocks of Dungeon Master. The fact is, with screen shots it looked fantastic, but once things were moving, it showed up the limitations of the technology.

Not long after that Ultima Underworld and Doom came along, in 'real' 3D (atually doom and Ultima Underworld used both, rasterisation for environment and 2D scaled for characters), people were just starting to see the potential in the 3D games market and GPU '3D' accelerators began their rise to world domination.

In reality, though, rasterisation is as much of an 'Effect' of 3D as was the Wing Commander I & II ships. Your models cease being 3D geometry and become 2D triangles long before you see them, hence the long held problems with transparency sorting, reflection, refraction and shadows. These all have to be simulated in some way since the stuff is no longer 3D. There are a myriad ways to do each of these, and if done well in the right scene, they each have a place and the results are impressive. on the other hand..

Raytracing is true 3D in the sense that your models stay in 3D for the entire lifetime of the render and are not 'transformed' into 2D at any point. The practical upshot of this is, with ray tracing, naturally occuring pixel perfect transparency, Reflections, Refraction and Shadowing are all very simple to create using the same technique, it's just more rays.

Where will it go? The pieces are falling into place. The march of shaders is moving GPUs to a many-core design. With tweaking this could begin to support ray tracing at increasing speeds. All it would need are hardware based acceration structures / traversal & intersection and you're heading in the right direction.

Ultimately I believe that GPUs will become a kind of scene simulator (much like lightwave / 3D Studio), where we upload geometry and information about material \ surface properties and they will be simulated both visually and physically. Using a new Scene-graph-like API, GPU manufacturers will then be able to compete on speed of rendering and realism in their simulation. Shaders could exist still as Surface Shaders, Polygon Shaders & Physics Shaders. As processors become even more powerful then new effects could be added. Global illumination effects such as Radiosity and caustic effects will begin to make their way in. Wouldn't it be great to have new effects made possible for older (RT) games just by upgrading the GPU?! If we think this is impossible, we should consider, it would have been near impossible to forsee the Geforce 8800 level of rasterisation power back in the days of Doom. It would have been possible to do Wing Commander style graphics with huge resampled images with hundreds of frames by now, but why didn't it happen? Because it was replaced by a better technology as the power came along.

It will take its' time and both will exist side by side for a long time, but the limitations of rasterisation will eventually be its undoing, just as it was for the 3D in 2D in games like Wing Commander and Dungeon Master.


Pixel shaders are just code. You can have them do whatever you want. If you want them to raytrace, they can. If you want them to do something else, they can do that too.



Going back to this- from my (limited of course!) experience of shaders, they are very very simplistic code. you *can't* do anything you want with them. they allow you a basic set of features with which you can get some impressive results. but you tell me, is there something i'm missing? Raytraced shader?

I can make them reference a cube texture though X-)

Perhaps a dedicated Raytracing hardware is not that far away....

SaarCOR prototype

but you tell me, is there something i'm missing? Raytraced shader?

As I understand it, shaders are increasingly becoming like a general programming language. I don't know much about shader raytracing, but I do know it's possible and has been done (and applied in real-time in certain cases).

as for it looking better you can have the same size object with the same amount of points on it but the nurbs will look more detailed because theres more polys.

Nobody seems to get this, but: Representing a polygon mesh with nurbs can increase (not decrease) the polygon count only. It cannot increase the detail! At best, it will make curved surfaces smoother, but it will have absolutely no advantage for intricate highly detailed meshes like the dragon I posted above.

P.S. I'm not arguing against raytracing - clearly it can produce the more realistic results than rasterization (though with much less work for the computer rasterization can produce nearly identical results). But the idea that nurbs is somehow superior than polygons for anything but the simplest shapes is ridiculous.

Nobody seems to get this, but: Representing a polygon mesh with nurbs can increase (not decrease) the polygon count only. It cannot increase the detail!
Agreed, my point though was that a raytracer doesn't need to convert them to polygons therefore you can represent the same or more detail with the same amount of control points.

An example would be if you had a single quad (2 triangles) it would simply be a flat surface, however, as a nurb surface it could have bends and twists in it.

To represent this in triangles you'd need to have many many quads. the more quads the better the representation.

A bit like a texture, the higher res the texture the closer you can get to it without it pixelating.

So if you have a mathematical curve, you will never lose detail no matter how close you were.

though with much less work for the computer rasterization can produce nearly identical results
This really is only less work because there is a secondary computer doing a lot of the work for you (the GPU) at the moment there isn't a raytrace card.

Although looking at the link above it appears there may be such a thing, and from their claims of "there was a scene of a Boeing with 350 million polygons rendered in realtime" sounds pretty cool, although without seeing any evidence or indeed what they class as 'realtime' it's hard to say.

This really is only less work because there is a secondary computer doing a lot of the work for you (the GPU) at the moment there isn't a raytrace card.

Not true - current GPUs can do raytracing and radiosity in real-time with full hardware support, as mentioned above. I've run demos on my PC, and it's no joke. The reason this isn't being used for games is it's way too slow, even on the latest hardware. YES, ray-tracing is too slow for real-time games currently! This will most likely change, but when that happens there will likely be something 10x better (faster, better looking) in the rasterization technology world.

Agreed, my point though was that a raytracer doesn't need to convert them to polygons therefore you can represent the same or more detail with the same amount of control points.

Again, you're not going to get "more detail with the same amount of control points", unless your definition of "detail" is "smooth, featureless surfaces". Again, the only way it will benefit is with primarily smooth/blobby surfaces, which is, again, not practical to represent real-world objects (again, see dragon example).

Regarding the argument of "nurbs are just as good as polygons or better, because with the same number of control points as vertices, you can get just as good results", again, a nurbs representation of an equivelant polygonal high-detail object would be much slower, thus eliminating the advantage of using it.

A bit like a texture, the higher res the texture the closer you can get to it without it pixelating.

You could say using nurbs for your mesh is like applying a smooth filter to a 2D image. Yeah, it can look nice if that's the intended effect, but 99% of the time you don't want blurry images, and 99% of the time you don't want blobby objects!

i think terabit posted most of what i was thinking. good post.

Intel is on-board for ray tracing technology, as their multi-core processors excel at the task, so I predict we'll see something useable for real-time / games five to ten years from now.


Sorry, I think you're wrong. Intel CPU's max out at 4 cores per CPU. This is functionally equivalent to a GPU with 4 shader units (for arguments sake). Intel (and AMD) CPUs are still best suited to serial code, not parallel. Raytracing is so massively parallel that it takes serial CPU's a very long time to crunch through a render.

4 cores are better than 1, obviously, but the increase in speed is not completely linear (i.e, it's not 4x the speed). GPU's are very good at parallel processing. They used to be very limited, highly simplistic processors capable of very few operations (but they performed them very quickly). GPU's are now programmable and bring a lot of flexibility to the parallel computing arena. This is why they can now be used for real, mission-critical parallel processing applications (scientific research stuff, complex data manipulation and visualisation etc).

With a few more generations of GPU developments, they could greatly accelerate raytracing computation, or even run a raytracing application completely natively.

Everything your 3D card does right now is based on polygons, but the time will come that solid geometry modelling and rendering can be offloaded to a GPU.

a nurbs representation of an equivelant polygonal high-detail object would be much slower, thus eliminating the advantage of using it.
I'm not disagreeing with the speed issue. But saying it eliminates the advantage is like saying only use 500 poly models because 5000 poly models are slower.
You could say using nurbs for your mesh is like applying a smooth filter to a 2D image
No I'm saying it's the difference between a true type font and a bitmap font. Still has sharp accurate edges regardless of the size rather than turning into a blocky or blurred representation.

Hmm. It's frustrating reading this :D I know what Rob is saying and John, i don't think you get what he's saying :D

No I'm saying it's the difference between a true type font and a bitmap font. Still has sharp accurate edges regardless of the size rather than turning into a blocky or blurred representation.

Fonts have a shape with obvious curves, lines, etc. This makes them a perfect candidate for mathematical representation (as in true type fonts).

Similarly nurbs is ideal for mathematically perfect shapes like spheres, and other rounded objects. I'm not arguing that nurbs don't have their place!

What I'm saying is that nurbs are an extremely inefficient way to represent complex organic, realistic objects (like the dragon / bird example above).

For example can you imagine this being done in nurbs? Obviously it can, but to achieve the same level of detail with nurbs, you'd have to use practically the same number of control points as there are vertexes. Maybe I'm missing something, but just how do nurbs provide any kind of advantage in this case?

I know what Rob is saying and John, i don't think you get what he's saying :D

I know he's saying that nurbs can do everything polygons can, and more: they have theoretically infinite detail because they can represent curves perfectly. I'm not disagreeing with this, because it's true, obviously.

I'm simply saying that nurbs as a base for a 3D rendering system would be foolish since the amount of precision they add to curves doesn't make up for the loss in performance for highly detailed objects.

The movies are starting to use some game tech for faster rendering too though, like normal maps.v

Plus theres a GPU shader based renderer thats been around for max and now maya for ages called RTSquare

http://www.rtsquare.eu/index.php?spgmGal=RTSquare_Gallery&option=com_mambospgm&Itemid=31

which can be a good 11x faster than the best CPU's

vinylpusher, re Intel’s multi-core CPUs suitability for ray-tracing:


Intel CPU's max out at 4 cores per CPU.



Perhaps I'm misunderstanding something, but that’s totally not the impression I get after reading the linked article in my earlier post.

Okay let's take a different tack on the polygons vs. NURBS debate. Note that NURBS used to be the favored approach for cinematic modeling or organic characters, but increasingly subdivision surfaces/polygons are taking over. It's a much more flexible approach to doing things and the artists need that; more flexible in the modeling, and more flexible in the texturing. For games to switch from polygons to NURBS is kind of a step backwards; what should happen is perhaps a more advanced way of handling polygons (ie. SubDs,) not switching to NURBS.

i like that idea jhocking. i really don't like nurbs much but they can be sorta fun. we could also use a lattice deformer style control mechanism.

Just wanted to close my paranthesis about the do's of computer generated imagery for movies. I found a neat article on the movie Transformers.

http://www.cgw.com/ME2/dirmod.asp?sid=&nm=&type=Publishing&mod=Publications%3A%3AArticle&mid=8F3A7027421841978F18BE895F87F791&tier=4&id=371827B02DD040BD997F56DA5D4AE927

For rendering, ILM used Mental Images’ Mental Ray for raytracing and Pixar’s RenderMan for scan-line rendering and raytracing. Lighters could switch from raytracing to scan-line rendering using an environment map within a shot.

“We could turn raytracing off and get a decent robot because we had environments that existed as 8k texture maps,” Koch says, “which is far, far higher resolution than anything we’ve done before. Typically we do half a k, so this was 16 times the information. And we needed it for the shiny surfaces.”

When lighters see something in the shot that needs raytracing, they can select that piece, click a button, and it’s raytraced. “Everything else uses the environment maps,” says Koch. “They’re compatible.”

Autobot Totals: Pieces: 35,592 Polygons: 7,435,478 Rig nodes: 95,247 Texture maps: 20,258 Total miles if pieces placed end to end: 3.11
Total for all Robots: Pieces of geometry: 60,217 Polygons: 12,509,502 Rigging nodes: 144,341 Texture maps: 34,215

And for the sake of getting real on the subject, here's a high definition video review of Project Gotham racing 4 on the XBOX 360, which some claim it to have cinematic hollywood like imagery:
http://www.gametrailers.com/player/25840.html