Well, I've personally recieved e-mails from students asking for help from the UK, US, Spain and pakistan to name but a few. I actually submitted some of the funnier ones here
Maya and 3DS max definately rule the Games world, followed closely by MotionBuilder and then XSI.
Blender is probably used a lot in indy development, but i suspect that a far greater number use pirated copies of Max and Maya. (they may claim the assets were created in blender for I don't want to get sued reasons....)
You're history of 3DS Max is slightly off. Max was published by Autodesk, but developed by Yost. Discreet Bought Yost, and max was then published by Kinetix. Discreet was evetually bought by Autodesk.
Autodesk already had owned discreet for quite a few years before it bought alias/wavefront a couple of years ago. So Autodesk never really made any mistakes - they never owned Max until about version 2 ish.
I appreciate you seem to be a fan of Truespace, but in all honesty it's not as serious a contender in the games industry as you seem to believe. (What about Xsi? Modo? Endorphin? Motionbuilder?).
Ok so it has python scripting, but then so does max, maya, xsi and motionbuilder.
I also doubt it's anywhere near as customisable as Maya. And i'd also that calgari's marketing bumpf is a load of rubbish. see this.
Max does not have a fully customisable interface, however you can completely re-write the maya interface - so why do they say you can't customise it? deleteUI $gMainWindow if you really want to...
They claim XSI, Max and Maya don't have generalised node editors? Are they taking the piss?
XSI doesn't support multiple rendering engines? You've got to be joking right? Renderman / mental ray ???
Physics based characters only in Truespace? Pardon? XSI has awesome physics support (with multiple engines), and Maya/Max has the freely available nima plugins to do ragdolls.
It allows for shadows and reflections that surpass anything we see today from a typical real-time renderer Ray tracing isn't actually that great at shadows. Typically, even in FilmFX, shadows are done with shadow maps. Current games are somewhat limited by the resources that we can throw at the shadowing, which in current game titles can lead to jittery shadows (because the shadow maps are too low res). Over the next few years I suspect we will see that slowly improve and eventually become a thing of the past.
Reflections on the other hand could be improved by Ray tracing, but not by such a great margin as everyone seems to think.
I, for one, am looking forward to crawling through the next generation of highly realistic battlefields, noticing how the grass sways in the wind and the smoke follows it. I want to see the land permanently scarred by an earlier battle, and I want to wonder if that shadow on the wall up ahead is a soldier around the next corner, or just a flag caught by the breeze. And none of that will be delivered by ray tracing...
Despite their efforts to force game devels to adopt multi-threaded game engines the uptake hasn't been what they need to drive sales of newer multi-core chips. Yes they have. I've been working on multi-threaded engines for the past 3 to 4 years on the 360 and PS3 - as has every other programmer in the industry.
With PC games however it's a different ball game entirely. For example, here is a list of games i found being used as a benchmark for a recent processor and the dates they were released:
2006: Warhammer Mark of Chaos
2007: Supreme Commander
2004: Unreal Tournament 2004
2005: Serious Sam 2
2005: Quake 4
2006: Prey
2004: Far Cry
2007: Crysis
And in the article they claimed that Crysis was one of the only games that used multiple cores. Well, out of that list, it's the only game to be less than a year old....
You claim that it's our fault (the dev's) for not multi-threading our game code, but in reality most of the PC games you'll end up playing (a bit of UT2004 after work maybe?) are actually a few years old.... In addition, because the rendering stage is by far the bottleneck, a fully parrallelised game engine may only see a 10 to 20% frame rate increase because of that.
Instead of a video card you would just need a faster cpu, which if we base off of moore's law won't be much longer. You'd actually need faster ram first. Current 800/1066Mhz ram can't compete with the 1900Mhz+ ram available on the GPU - it simply can't feed the data to the CPU core's quick enough. To speed up execution times of each core you'd need to limit the amount of Ram it can access to minimise cache misses. At that point, you suddenly have a stream processor that's pretty damn similar to the current GPU model.
The biggest time (and of course money) sink in this process is art and level development. This more or less hits the nail on the head. Raytracing isn't going to reduce this burden - you still have to write shaders for mental ray for example. The biggest problem is that as the complexity of the required art assets increases linearly (with moores law), the amount of time taken to model, rig and animate those models increases exponentially.
To put it bluntly, at the moment the industry has to invest in better tools to simplify the asset creation stage.
This is a somewhat rose tinted view of ray tracing. You can't simply throw each pixel onto a different stream processor and expect it to work. Whilst this works for throwing a different pixel at a different CPU core, this does not work with the stream processors we currently have available to us.
The problem we have both in the cell, and in stream processors on a GPU is that you can't arbritrarily access large data sets. So, it is impossible to write any code for a triangle that allows it to fire off rays into the rest of the scene. End of story.
Now, these things are possible, but, it requires a hell of a lot of hacking - i.e. using indices into textures, writing output data back into textures, copying that data to a vertex array.. etc etc etc.
But, you have the exact same problems to overcome to get ray tracing to work on a stream processor, as you do with rasterisation. Those 800 stream processors you talk about, have to be running exactly the same code, have only a small amount of memory available to them, and are generally a PITA to get even the simplest code running.
You talk about distributing frames across seperate PC nodes, but we've been doing that for years in renderman - using the exact same system you describe (via alfred typically). 99% of the filmFX houses use renderman for their rendering, however renderman is not a ray traced renderer.
The simple reason why is that 99% of filmFX shots do not require raytracing....
The same is also true of Games. I'm willing to bet that in my lifetime I will never see a AAA game released that is 100% raytraced. Some games may use it for 2 to 5% of the effects, but that will be about it.... much like it is in the film industry.....
As someone who's had a teaching job in the UK (lecturing graphics programming at the NCCA), i can say with some certainty that it's not a bad graduate job. But...
When the 3k top up fees were being introduced, all courses were dropped by a funding band. This lead to large redundencies across the board. Not fun.
Whilst teaching is rewarding, it's incredably draining. It was uncommon for me to spend all of my weekends and evenings preparing lectures and other resource material (I now work back in the games industry, and there are far fewer hours!).
Teaching jobs don't pay that much in the UK. It's certainly quite comparible when you are of graduate age (i.e. 25k in education, vs 20k in industry). The pay rises are however small, so within a couple of years you are 5k worse off than someone in industry.
Lecturers don't get the cushy holidays that people imagine they do - Masters students will typically still be studying over the summer months.
The worst part of lecturing however, is the behind the scenes bickering that goes on. You could be Jon Carmack, but your suggestions will always be over-ruled unless you have a Phd. You also have the constant fights with those 'other' university staff - the people who control the cash flow (who are never academics).
The long and short of it is, if you go to work in a UK university, it can often feel like you've walked into a battleground.
I've since realised I have more power over what the courses teach having left academia - with all those buzzwords like knowledge transfer and outreach programs - it's pretty straightforward to approach a university course and say "I'm from industry, can you please teach X and I'm happy to help you to do it".
99.99% of the time, they will say yes. Movements such as "Games Up?" will therefore be heard by academia - it's just whether the members of that group are willing to put forward their time and resources to actually make it a reality.
A list I made from a couple of years ago. This excludes all the animation house and post-production houses i know about (which would add another 100+ companies).
But in seriousness it is a big problem. At NaturalMotion we started an Academic partners program for just this very reason. It is getting harder and harder to find good graduates so in response we've taken a fairly pro-active stance on the matter. i.e. Starting internship programs providing assistance to university courses in terms of software libs code examples lectures workshops etc etc. I'd happily advise any UK companies to do the same - it does pay off....
--[ Aberystwyth ]
Broad Sword (Games)
--[ Bath ]
Pivotal Games (Games)
--[ Birmingham ]
Blue Sphere (Mobile Games)
Swordfish Studios (Games)
--[ Bradford ]
Four door lemon (Games/Software)
PineApple (Games)
Simula (Mocap)
--[ Brighton ]
animazoo (Mocap),
Climax (Games),
EuroGamer (Web Site),
Kuju (Games),
Relentless (Games)
--[ Bristol ]
HotHouse (Games)
--[ Bournemouth ]
Access Mocap (Mocap),
GamesTM (Magazine),
Runtimegames (games)
--[ Cambridge ]
Creature Labs (Games),
Frontier (Games),
Nicely Crafted (Games),
Ninja Theory (Games),
Sony (Games),
Zoonami (Games)
--[ Cheshire ]
StrangeLite (Games),
Team 3 (Games)
--[ Chertsey ]
EA
--[ Derby ]
Core Soft (Games),
EuroCom (Games),
Straw Dog Studios (Games)
--[ Edinburgh ]
Rockstar North (Games)
--[ Gateshead ]
Eutechnyx (Games)
--[ Glasgow ]
EM Studios (Games)
--[ Guildford ]
Kuju (Games)
Lionhead (Games),
Criterion (Games)
--[ Isle Of White ]
Stainlessgames (Games)
--[ Leamington Spa ]
blitz games (games),
CodeMasters (games),
Rare (games),
Volatile Games (Games)
--[ Leeds ]
Code Monkeys (Games),
Rockstar (Games)
--[ Liverpool ]
Jester Interactive (Games),
Magenta (Games),
Sony (Games)
--[ London ]
124 (Post Production),
Artem Digital (Mocap),
Asylum Entertainment (Games),
Atomic Powered (Games),
Bastion (Games),
Bits Studio (Games),
Blue 52 (Games),
BlueSunflower (Anim),
Capcom (Games),
Climax (Games),
Deibus (Games),
Enlight (Games),
Firefly (Games),
Imaginery (Games/Animation),
Intelligent (Games),
Midway (Games),
Morpheme (Games),
Sony (Games),
Sports Interactive (Games)
--[ Manchester ]
Bitmap Brothers (Games),
Bizarre Creations (Games),
TravellersTales (Games),
--[ Middlesbrough ]
Atomic Planet (games)
--[ Newcastle ]
Magenta (Games/Post Production)
--[ Newport ]
Mad Dog Games (Games)
--[ Nottingham ]
Bull Dog (Games)
Free Radical (Games),
NuGeneration (Games)
--[ Oxford ]
Audio Motion (Mocap),
Exient (Games),
Fuse (Games),
Gusto (Games),
Icon Games,
NaturalMotion (Middleware),
Rebellion (Games),
Razor Works (Games),
Vicon (Mocap)
--[ Portsmouth ]
Climax (Games),
Vulcan Software (Games)
--[ Sheffield ]
Sumo Digital (Games)
--[ Sutton Coalfield ]
Head First (Games)
--[ York ]
Revolution (Games)
--[ Warrington ]
EA
--[ Warwick ]
Data Design (Games)
Ireland
--[ Dublin ]
Havok (MiddleWare),
PurpleNose (Games)
--[ Muff (and i'm not even joking...)
TorcInteractive (Middleware)
no it won't. As your data set increases, you become increasingly memory bound. You can have 4 cores pumping away at 100%, but if they are sitting there generating page faults and cache misses all over the place, you are going to see some pretty bad frame-rates.
Simply put, a GPU is fast because it can stream data at speeds > 1900Mhz. In comparison, a quad core intel machine with memory speeds of 800Mhz can't feed the cores with data fast enough. In my own tests, if you can keep the data requirements per-frame to approximately the size of the CPU cache, you can see some playable frame rates. As you go over that size, frame rates start to drop exponetially.
Ultimately though, i don't really buy into this 'raytracing is going to revolutionise game graphics' point of view. It's never really revolutionised the film FX world, where even now after 25+ years since Tron, the most commonly used techniques are based around REYES and global illumination models that do not rely on raytracing. Certainly renderers such as renderman have added raytracing extensions, which can be useful in certain situations, but ultimately the majority of FX shots don't really require them.
> I wonder if anyone tried to do hardware acceleration with, say, splines or something other than triangles.
yes, but only 2 graphics cards to date. The glu nurbs interface, and openGL evaluators have been around for years, but only one card ever implemented them in hardware (can't recall which one).
Then came NV evaluators which were launched with a big fanfare for the Geforce 3, but was then the support was quietly dropped from the drivers a couple of revisions later.
The problem is that hardware support for spline tessellation is basically pointless. The heavy part of the computation is in generating the blending co-efficients for the curve computation, and in both of the above extensions you have to compute those every frame. A simple caching scheme for the co-efficients will always beat any hardware accelerated spline implementation. (i.e. cache the co-efficients periodically so that surface LOD does not change every frame. The remainder of the computation can generally then be put in a vertex/geometry shader).
Of course, there are bigger problems with splines.
1) Artists really don't like modelling in them.
2) They add detail into the wrong places, which ends up generating magnitudes more polys than if you'd just modelled everything in polygons.
Subdiv surfaces are imho a better way to add detail into geometry, but caching is far harder to do when compared with splines. Dynamic surfaces such as character skins are basically out of the question as a result.
The best approach i've seen to date are ATI's PN triangles, which subdivides individual triangles and quads using the face normals and vertex positions. This is pretty trivial to insert into a geometry shader, and gives decent (read: occasionally odd) results. So far this is one of the better ways to deal with the fact that a GPU can only really operate on a triangle at a time (without resorting to horrible hacks like passing data in the form of textures, and nasty render output data to texture approaches).
Slashdot Mirror
Well, I've personally recieved e-mails from students asking for help from the UK, US, Spain and pakistan to name but a few. I actually submitted some of the funnier ones here
Maya and 3DS max definately rule the Games world, followed closely by MotionBuilder and then XSI.
Blender is probably used a lot in indy development, but i suspect that a far greater number use pirated copies of Max and Maya. (they may claim the assets were created in blender for I don't want to get sued reasons....)
You're history of 3DS Max is slightly off. Max was published by Autodesk, but developed by Yost. Discreet Bought Yost, and max was then published by Kinetix. Discreet was evetually bought by Autodesk.
Autodesk already had owned discreet for quite a few years before it bought alias/wavefront a couple of years ago. So Autodesk never really made any mistakes - they never owned Max until about version 2 ish.
I appreciate you seem to be a fan of Truespace, but in all honesty it's not as serious a contender in the games industry as you seem to believe. (What about Xsi? Modo? Endorphin? Motionbuilder?).
Ok so it has python scripting, but then so does max, maya, xsi and motionbuilder.
I also doubt it's anywhere near as customisable as Maya. And i'd also that calgari's marketing bumpf is a load of rubbish. see this.
Max does not have a fully customisable interface, however you can completely re-write the maya interface - so why do they say you can't customise it? deleteUI $gMainWindow if you really want to...
They claim XSI, Max and Maya don't have generalised node editors? Are they taking the piss?
XSI doesn't support multiple rendering engines? You've got to be joking right? Renderman / mental ray ???
Physics based characters only in Truespace? Pardon? XSI has awesome physics support (with multiple engines), and Maya/Max has the freely available nima plugins to do ragdolls.
and i could go on....
And why's that not valid? They are aspiring to work on AAA titles eventually are they not?
Reflections on the other hand could be improved by Ray tracing, but not by such a great margin as everyone seems to think.
I, for one, am looking forward to crawling through the next generation of highly realistic battlefields, noticing how the grass sways in the wind and the smoke follows it. I want to see the land permanently scarred by an earlier battle, and I want to wonder if that shadow on the wall up ahead is a soldier around the next corner, or just a flag caught by the breeze. And none of that will be delivered by ray tracing...
2006: Warhammer Mark of Chaos
2007: Supreme Commander
2004: Unreal Tournament 2004
2005: Serious Sam 2
2005: Quake 4
2006: Prey
2004: Far Cry
2007: Crysis
And in the article they claimed that Crysis was one of the only games that used multiple cores. Well, out of that list, it's the only game to be less than a year old....
You claim that it's our fault (the dev's) for not multi-threading our game code, but in reality most of the PC games you'll end up playing (a bit of UT2004 after work maybe?) are actually a few years old.... In addition, because the rendering stage is by far the bottleneck, a fully parrallelised game engine may only see a 10 to 20% frame rate increase because of that.
I'd rather see decent GI algorithms implemented before raytracing. Most of the objects i see around me are not chrome or glass.....
To put it bluntly, at the moment the industry has to invest in better tools to simplify the asset creation stage.
This is a somewhat rose tinted view of ray tracing. You can't simply throw each pixel onto a different stream processor and expect it to work. Whilst this works for throwing a different pixel at a different CPU core, this does not work with the stream processors we currently have available to us.
The problem we have both in the cell, and in stream processors on a GPU is that you can't arbritrarily access large data sets. So, it is impossible to write any code for a triangle that allows it to fire off rays into the rest of the scene. End of story.
Now, these things are possible, but, it requires a hell of a lot of hacking - i.e. using indices into textures, writing output data back into textures, copying that data to a vertex array.. etc etc etc.
But, you have the exact same problems to overcome to get ray tracing to work on a stream processor, as you do with rasterisation. Those 800 stream processors you talk about, have to be running exactly the same code, have only a small amount of memory available to them, and are generally a PITA to get even the simplest code running.
You talk about distributing frames across seperate PC nodes, but we've been doing that for years in renderman - using the exact same system you describe (via alfred typically). 99% of the filmFX houses use renderman for their rendering, however renderman is not a ray traced renderer.
The simple reason why is that 99% of filmFX shots do not require raytracing....
The same is also true of Games. I'm willing to bet that in my lifetime I will never see a AAA game released that is 100% raytraced. Some games may use it for 2 to 5% of the effects, but that will be about it.... much like it is in the film industry.....
if you don't count all the games released for 360 and PS3...
It's really not that difficult to write the software. I managed to follow this paper and get it working in a few evenings....
http://www1.cs.columbia.edu/~ravir/cvpr07.pdf
I only had a go after seeing that a guy on CG talk managed to do it (and he's an artist - not a programmer).... http://forums.cgsociety.org/showthread.php?f=109&t=636851
As someone who's had a teaching job in the UK (lecturing graphics programming at the NCCA), i can say with some certainty that it's not a bad graduate job. But...
When the 3k top up fees were being introduced, all courses were dropped by a funding band. This lead to large redundencies across the board. Not fun.
Whilst teaching is rewarding, it's incredably draining. It was uncommon for me to spend all of my weekends and evenings preparing lectures and other resource material (I now work back in the games industry, and there are far fewer hours!).
Teaching jobs don't pay that much in the UK. It's certainly quite comparible when you are of graduate age (i.e. 25k in education, vs 20k in industry). The pay rises are however small, so within a couple of years you are 5k worse off than someone in industry.
Lecturers don't get the cushy holidays that people imagine they do - Masters students will typically still be studying over the summer months.
The worst part of lecturing however, is the behind the scenes bickering that goes on. You could be Jon Carmack, but your suggestions will always be over-ruled unless you have a Phd. You also have the constant fights with those 'other' university staff - the people who control the cash flow (who are never academics).
The long and short of it is, if you go to work in a UK university, it can often feel like you've walked into a battleground.
I've since realised I have more power over what the courses teach having left academia - with all those buzzwords like knowledge transfer and outreach programs - it's pretty straightforward to approach a university course and say "I'm from industry, can you please teach X and I'm happy to help you to do it".
99.99% of the time, they will say yes. Movements such as "Games Up?" will therefore be heard by academia - it's just whether the members of that group are willing to put forward their time and resources to actually make it a reality.
A list I made from a couple of years ago. This excludes all the animation house and post-production houses i know about (which would add another 100+ companies).
But in seriousness it is a big problem. At NaturalMotion we started an Academic partners program for just this very reason. It is getting harder and harder to find good graduates so in response we've taken a fairly pro-active stance on the matter. i.e. Starting internship programs providing assistance to university courses in terms of software libs code examples lectures workshops etc etc. I'd happily advise any UK companies to do the same - it does pay off....
--[ Aberystwyth ]
Broad Sword (Games)
--[ Bath ]
Pivotal Games (Games)
--[ Birmingham ]
Blue Sphere (Mobile Games) Swordfish Studios (Games)
--[ Bradford ]
Four door lemon (Games/Software) PineApple (Games) Simula (Mocap)
--[ Brighton ]
animazoo (Mocap), Climax (Games), EuroGamer (Web Site), Kuju (Games), Relentless (Games)
--[ Bristol ]
HotHouse (Games)
--[ Bournemouth ]
Access Mocap (Mocap), GamesTM (Magazine), Runtimegames (games)
--[ Cambridge ]
Creature Labs (Games), Frontier (Games), Nicely Crafted (Games), Ninja Theory (Games), Sony (Games), Zoonami (Games)
--[ Cheshire ]
StrangeLite (Games), Team 3 (Games)
--[ Chertsey ]
EA
--[ Derby ]
Core Soft (Games), EuroCom (Games), Straw Dog Studios (Games)
--[ Edinburgh ]
Rockstar North (Games)
--[ Gateshead ]
Eutechnyx (Games)
--[ Glasgow ]
EM Studios (Games)
--[ Guildford ]
Kuju (Games) Lionhead (Games), Criterion (Games)
--[ Isle Of White ]
Stainlessgames (Games)
--[ Leamington Spa ]
blitz games (games), CodeMasters (games), Rare (games), Volatile Games (Games)
--[ Leeds ]
Code Monkeys (Games), Rockstar (Games)
--[ Liverpool ]
Jester Interactive (Games), Magenta (Games), Sony (Games)
--[ London ]
124 (Post Production), Artem Digital (Mocap), Asylum Entertainment (Games), Atomic Powered (Games), Bastion (Games), Bits Studio (Games), Blue 52 (Games), BlueSunflower (Anim), Capcom (Games), Climax (Games), Deibus (Games), Enlight (Games), Firefly (Games), Imaginery (Games/Animation), Intelligent (Games), Midway (Games), Morpheme (Games), Sony (Games), Sports Interactive (Games)
--[ Manchester ]
Bitmap Brothers (Games), Bizarre Creations (Games), TravellersTales (Games),
--[ Middlesbrough ]
Atomic Planet (games)
--[ Newcastle ]
Magenta (Games/Post Production)
--[ Newport ]
Mad Dog Games (Games)
--[ Nottingham ]
Bull Dog (Games) Free Radical (Games), NuGeneration (Games)
--[ Oxford ]
Audio Motion (Mocap), Exient (Games), Fuse (Games), Gusto (Games), Icon Games, NaturalMotion (Middleware), Rebellion (Games), Razor Works (Games), Vicon (Mocap)
--[ Portsmouth ]
Climax (Games), Vulcan Software (Games)
--[ Sheffield ]
Sumo Digital (Games)
--[ Sutton Coalfield ]
Head First (Games)
--[ York ]
Revolution (Games)
--[ Warrington ]
EA
--[ Warwick ]
Data Design (Games)
Ireland
--[ Dublin ]
Havok (MiddleWare), PurpleNose (Games)
--[ Muff (and i'm not even joking...)
TorcInteractive (Middleware)
no it won't. As your data set increases, you become increasingly memory bound. You can have 4 cores pumping away at 100%, but if they are sitting there generating page faults and cache misses all over the place, you are going to see some pretty bad frame-rates.
Simply put, a GPU is fast because it can stream data at speeds > 1900Mhz. In comparison, a quad core intel machine with memory speeds of 800Mhz can't feed the cores with data fast enough. In my own tests, if you can keep the data requirements per-frame to approximately the size of the CPU cache, you can see some playable frame rates. As you go over that size, frame rates start to drop exponetially.
Ultimately though, i don't really buy into this 'raytracing is going to revolutionise game graphics' point of view. It's never really revolutionised the film FX world, where even now after 25+ years since Tron, the most commonly used techniques are based around REYES and global illumination models that do not rely on raytracing. Certainly renderers such as renderman have added raytracing extensions, which can be useful in certain situations, but ultimately the majority of FX shots don't really require them.
> I wonder if anyone tried to do hardware acceleration with, say, splines or something other than triangles.
yes, but only 2 graphics cards to date. The glu nurbs interface, and openGL evaluators have been around for years, but only one card ever implemented them in hardware (can't recall which one).
Then came NV evaluators which were launched with a big fanfare for the Geforce 3, but was then the support was quietly dropped from the drivers a couple of revisions later.
The problem is that hardware support for spline tessellation is basically pointless. The heavy part of the computation is in generating the blending co-efficients for the curve computation, and in both of the above extensions you have to compute those every frame. A simple caching scheme for the co-efficients will always beat any hardware accelerated spline implementation. (i.e. cache the co-efficients periodically so that surface LOD does not change every frame. The remainder of the computation can generally then be put in a vertex/geometry shader).
Of course, there are bigger problems with splines.
1) Artists really don't like modelling in them. 2) They add detail into the wrong places, which ends up generating magnitudes more polys than if you'd just modelled everything in polygons.
Subdiv surfaces are imho a better way to add detail into geometry, but caching is far harder to do when compared with splines. Dynamic surfaces such as character skins are basically out of the question as a result.
The best approach i've seen to date are ATI's PN triangles, which subdivides individual triangles and quads using the face normals and vertex positions. This is pretty trivial to insert into a geometry shader, and gives decent (read: occasionally odd) results. So far this is one of the better ways to deal with the fact that a GPU can only really operate on a triangle at a time (without resorting to horrible hacks like passing data in the form of textures, and nasty render output data to texture approaches).