On the xbox titles I worked on, we always synchronously loaded sections of the maps to create seamless worlds. Well, up to a point anyway.
You'd normally have some obviously placed dog-legs in the levels.... a.k.a. a section in the map where you make the player go down a twisty passage from which you can't see the next section of the level (that's being loaded), and can't see the part of the level you just came from (which is being unloaded).
If deus Ex 2 has small levels you'd therefore assume one of the following reasons:
1. The dev team was incompetent (highly unlikely)
2. The dev team ran out of time, and so many planned features and maps got dropped.
3. It was an intentional choice by the game designers.
In WW2 the estimated number of dead was in the region of 50 to 70 million, which compares to about 1.5million during the crusades (from the estimates I've seen, summed over a number of centuries). How do you decide that the crusades were worse exactly?
Joe Kitinger's jump from space always impressed me. There are a couple of people attempting to break the record in the next year or two. Those people may qualify as 'heros', or lunatics, depending on your point of view....
I completely agree with you. Personally (as someone involved in the CG industry), I'd say that the computer graphics lab at NYIT, and ILM have a higher geek status than Pixar (which would not have existed if not for Lucas and NYIT).....
I think the previous poster meant Autodesk (and not their CAD product). Autodesk have been swallowing up every single one of the main players in the filmFX / 3D animation arena for the last few years. They've never actually developed their own animation software, but have bought out discreet (devs of 3ds max), alias wavefront (devs of maya), Kaydara (devs of Motionbuilder), Softimage (devs of XSI) to name but a few.
The upshot is that Autodesk now own pretty much every conceivable patent to do with 3D animation. It's effectively impossible to develop any competing product without falling foul of one of their data structure patents (Dependency graphs, modifier stacks, you name it, if it's a data structure used for 3D animation, they've got the patent...). As someone who works on one of the few remaining non-autodesk products, I can assure you it's a minefield! I'm not going to go into details, suffice to say that we normally have a patent lawyer in our code reviews and design meetings......
As for real time re-targetting, yes motionbuilder, maya and xsi can all do this easily, and this stuff has been in use in mocap studios for years. I'm failing to grasp what is actually 'new' here. The only thing I can potentially see, is the use of a motion tracked camera. Mind you, you can be fairly certain that ILM did all of this twenty years ago and never told anyone.....
The first software I saw with a viewport was in about 95 or so. A wireframe only rendering on a HP Unix workstation (@60Mhz!) would take a few seconds to re-draw (longer if you had back face culling on). Mind you, we didn't get mouse input for the camera controls until we switched over to SGI machines a couple of years later. Up until that point (and still integral to the animation pipeline today) you only had control over the scene by executing code. You should try to find a dos version of 3d studio if you want to relive the experience!
I assume you know larrabee has been reborn as knights ferry and knights corner...... ? I for one am looking forward to getting my hands on the final hardware. For my purposes (film FX), it's exactly what we've been screaming out for, for over a decade...
You can go back further than that...... The original 32Mb ATI Rage fury was the first consumer card that supported full 32bit 3D acceleration (and could handle high end graphics apps such as maya). An amazing card in it's time...
p.s. As for CAD/CAM software. They actually don't push the GPU as much as you might expect. They tend to use the simplest single pass shading available, so don't actually need too many GPU cores. What's more important for those apps is lots and lots of fast DDR5 ram....
By now, we should have had a plethora of different applications running on such a card: audio encoding, compression, encryption, gaming AI. I know about CUDA, but why aren't we seeing such applications?
Flash, web based video, Power DVD, and various others at the consumer end of the spectrum (where accuracy is not important). When I first bought an ION based netbook (about 12 months ago), half the websites on the net could not play video on it without dropping a hideous number of frames. Since I've owned it, there has been a gradual stream of updates to various libs/SDK/apps (flash video was the most obvious!) that have made my netbook usable (by utilising the ION GPU).
Are they held back because of lacking OS support? Lacking driver support? Lacking deployment infrastructure? Lacking developer initiative? Is the GPU architecture (disparate memory) unsuitable? Or is CUDA just woefully inadequate to express parallel problems, seeing as it's based on (one of) the most primitive of imperative languages?
Disappointed minds want to know...
It's much simpler than that - it's all about available dev time. For any given app, any new feature has to work on all available systems (and by that I mean, it has an Intel GPU). This means you have to target your code to run on the CPU first. Later, if you have time (or performance is sucky enough to warrant the development effort) you can add in a GPU codepath in places where it makes sense. Sadly, most users don't tend to notice the difference between an app using 30% of the CPU, or one using 5%. As a result, GPU codepaths tend to get dropped down the priority list somewhat.
Writing code for the GPU is not fun (well, it is fun in the hobby project sense, but not so much for a paid job). You have to target your code for GL2.1 Intel, GL2.1 ATI, GL2.1 NVidia, GL3.3 ATI, GL3.3 Nvidia, GL4.0 ATI, GL4.0 Nvidia. At best you've just added an extra week to your QA process. At worst it's batted back and forth between QA and the dev team for a month or more. The bean counting senior management do a quick cost/benefit analysis, and almost always find that the added development time cannot be justified.
Finally..... There were a few features lacking from GPU's (until very recently) that tended to prevent them from being used in any serious environments. (The lack of double precision or ECC memory support spring to mind). That is slowly changing, but until the costs for development on the GPU start to fall, I doubt you'll see too many apps moving to the GPU.....
And of course Pixars little foray into world of computer hardware, the RM1. Not quite a raytraced renderer as such (REYES), but it was actually used for commercial films very briefly (e.g. TinToy, StarTrek2).
These days you fire off renders by invoking the prman executable.... 'p' being short for 'prototype' (it became quickly apparent to Pixar that Sgi's development and performance curve was outpacing their own hardware division. Rather than try to compete, they simply shut down the hardware division, and the original software prototype for the RM1 became what we now, somewhat incorrectly, call renderman).
Although the sound of 3 technicians positioning the 20 mocap cameras around the soldiers in a warzone, followed by the man in black lycra waving the camera calibration wand over the heads of the enemy, followed by the wheeling in of the servers and computer equipment required to capture and analyse the gigs of data generated by the mocap suite may ruin the element of surprise somewhat......
Although the sound of 3 or so technicians mounting 20 mocap cameras around a war zone, followed by a technician waving his magic wand around the soldiers to calibrate the cameras, before finally wheeling in the various servers needed to interpret and analyse motion capture data may ruin the element of surprise somewhat......
BSP's (in the DOOM sense) had to be aligned to polygon planes, and required the splitting of geometry in order to facilitate nice tricks such as front to back rendering (for transparency), not to mention collision detection. It's rare to see BSP used in such restrictive ways anymore (in games at least), and in fact they have largely fallen out of favour. Portals, Kd trees, Oct-trees, AABB-trees, OBB-trees, ABT trees, and Quad trees are more common approaches these days (effectively most of them are axis aligned BSP trees), and it's rare for the spatial nodes to store single triangles anymore (it's more typically used to store whole objects - although triangles from static level geometry may be bucketed into the nodes). Part of this change was driven by the fact the GPU likes batches of data to process (rather than individual triangles), and the other reason was to facilitate dynamically moving objects. Animating a few thousand objects in a loose KD tree, or an ABT tree would not be computationally expensive. However the time spent computing ray intersections would certainly increase.
I could think of ways around the problem however. For a complex non deforming geometry object (eg chandelier), it would be possible to construct a local space KdTree around it, test the ray against the object bounds, transform into local space of the object, before finally testing the ray against the spatial tree. For cases where that doesn't work (eg a deforming mesh), you either have to accept the extra cost of re-building the tree (the performance on which depends on your mesh size), or you can reverse the problem and construct a Kd Tree around the ray itself (which can be more efficient in some very specific cases).
However you look at it though, deforming geometry adds a lot of overhead into any renderer, ray tracing more so.....
Slashdot Mirror
On the xbox titles I worked on, we always synchronously loaded sections of the maps to create seamless worlds. Well, up to a point anyway.
You'd normally have some obviously placed dog-legs in the levels.... a.k.a. a section in the map where you make the player go down a twisty passage from which you can't see the next section of the level (that's being loaded), and can't see the part of the level you just came from (which is being unloaded).
If deus Ex 2 has small levels you'd therefore assume one of the following reasons:
1. The dev team was incompetent (highly unlikely)
2. The dev team ran out of time, and so many planned features and maps got dropped.
3. It was an intentional choice by the game designers.
In WW2 the estimated number of dead was in the region of 50 to 70 million, which compares to about 1.5million during the crusades (from the estimates I've seen, summed over a number of centuries). How do you decide that the crusades were worse exactly?
Joe Kitinger's jump from space always impressed me. There are a couple of people attempting to break the record in the next year or two. Those people may qualify as 'heros', or lunatics, depending on your point of view....
Of course, there's always Bloodhound SSC......
I completely agree with you. Personally (as someone involved in the CG industry), I'd say that the computer graphics lab at NYIT, and ILM have a higher geek status than Pixar (which would not have existed if not for Lucas and NYIT).....
... the first people to be reported will be the lecturers!
I think the previous poster meant Autodesk (and not their CAD product). Autodesk have been swallowing up every single one of the main players in the filmFX / 3D animation arena for the last few years. They've never actually developed their own animation software, but have bought out discreet (devs of 3ds max), alias wavefront (devs of maya), Kaydara (devs of Motionbuilder), Softimage (devs of XSI) to name but a few.
The upshot is that Autodesk now own pretty much every conceivable patent to do with 3D animation. It's effectively impossible to develop any competing product without falling foul of one of their data structure patents (Dependency graphs, modifier stacks, you name it, if it's a data structure used for 3D animation, they've got the patent...). As someone who works on one of the few remaining non-autodesk products, I can assure you it's a minefield! I'm not going to go into details, suffice to say that we normally have a patent lawyer in our code reviews and design meetings......
As for real time re-targetting, yes motionbuilder, maya and xsi can all do this easily, and this stuff has been in use in mocap studios for years. I'm failing to grasp what is actually 'new' here. The only thing I can potentially see, is the use of a motion tracked camera. Mind you, you can be fairly certain that ILM did all of this twenty years ago and never told anyone.....
Young whipper snapper! Get off my lawn!!
The first software I saw with a viewport was in about 95 or so. A wireframe only rendering on a HP Unix workstation (@60Mhz!) would take a few seconds to re-draw (longer if you had back face culling on). Mind you, we didn't get mouse input for the camera controls until we switched over to SGI machines a couple of years later. Up until that point (and still integral to the animation pipeline today) you only had control over the scene by executing code. You should try to find a dos version of 3d studio if you want to relive the experience!
I assume you know larrabee has been reborn as knights ferry and knights corner...... ? I for one am looking forward to getting my hands on the final hardware. For my purposes (film FX), it's exactly what we've been screaming out for, for over a decade...
You can go back further than that...... The original 32Mb ATI Rage fury was the first consumer card that supported full 32bit 3D acceleration (and could handle high end graphics apps such as maya). An amazing card in it's time...
..... although that $50 will leave your pocket instantly when you nee to buy a new SLI capable PSU.
p.s. As for CAD/CAM software. They actually don't push the GPU as much as you might expect. They tend to use the simplest single pass shading available, so don't actually need too many GPU cores. What's more important for those apps is lots and lots of fast DDR5 ram....
By now, we should have had a plethora of different applications running on such a card: audio encoding, compression, encryption, gaming AI. I know about CUDA, but why aren't we seeing such applications?
Flash, web based video, Power DVD, and various others at the consumer end of the spectrum (where accuracy is not important). When I first bought an ION based netbook (about 12 months ago), half the websites on the net could not play video on it without dropping a hideous number of frames. Since I've owned it, there has been a gradual stream of updates to various libs/SDK/apps (flash video was the most obvious!) that have made my netbook usable (by utilising the ION GPU).
Are they held back because of lacking OS support? Lacking driver support? Lacking deployment infrastructure? Lacking developer initiative? Is the GPU architecture (disparate memory) unsuitable? Or is CUDA just woefully inadequate to express parallel problems, seeing as it's based on (one of) the most primitive of imperative languages?
Disappointed minds want to know...
It's much simpler than that - it's all about available dev time. For any given app, any new feature has to work on all available systems (and by that I mean, it has an Intel GPU). This means you have to target your code to run on the CPU first. Later, if you have time (or performance is sucky enough to warrant the development effort) you can add in a GPU codepath in places where it makes sense. Sadly, most users don't tend to notice the difference between an app using 30% of the CPU, or one using 5%. As a result, GPU codepaths tend to get dropped down the priority list somewhat.
Writing code for the GPU is not fun (well, it is fun in the hobby project sense, but not so much for a paid job). You have to target your code for GL2.1 Intel, GL2.1 ATI, GL2.1 NVidia, GL3.3 ATI, GL3.3 Nvidia, GL4.0 ATI, GL4.0 Nvidia. At best you've just added an extra week to your QA process. At worst it's batted back and forth between QA and the dev team for a month or more. The bean counting senior management do a quick cost/benefit analysis, and almost always find that the added development time cannot be justified.
Finally..... There were a few features lacking from GPU's (until very recently) that tended to prevent them from being used in any serious environments. (The lack of double precision or ECC memory support spring to mind). That is slowly changing, but until the costs for development on the GPU start to fall, I doubt you'll see too many apps moving to the GPU.....
.... although during the cold winter months, there's nothing better than roasting marshmallows on a quadro!
And yet this article is tagged with 'England'....
I love the powerglove, it's so bad!
is that baguettes per second, month, year, or lifetime?
1.6018 U.S. dollars
And of course Pixars little foray into world of computer hardware, the RM1. Not quite a raytraced renderer as such (REYES), but it was actually used for commercial films very briefly (e.g. TinToy, StarTrek2).
These days you fire off renders by invoking the prman executable.... 'p' being short for 'prototype' (it became quickly apparent to Pixar that Sgi's development and performance curve was outpacing their own hardware division. Rather than try to compete, they simply shut down the hardware division, and the original software prototype for the RM1 became what we now, somewhat incorrectly, call renderman).
No please don't. We've got enough on our plate with the PS3 as it is.....
Not if you're from the west-country.... Reminds me of the graffiti outside my old school that simply read: "Nirvarnar"
i think you mean: castRelo this!
The leader is after all a portRugese person from portRugal.....
Shooting the mocap technicians should be easy though.....
Although the sound of 3 technicians positioning the 20 mocap cameras around the soldiers in a warzone, followed by the man in black lycra waving the camera calibration wand over the heads of the enemy, followed by the wheeling in of the servers and computer equipment required to capture and analyse the gigs of data generated by the mocap suite may ruin the element of surprise somewhat......
Although the sound of 3 or so technicians mounting 20 mocap cameras around a war zone, followed by a technician waving his magic wand around the soldiers to calibrate the cameras, before finally wheeling in the various servers needed to interpret and analyse motion capture data may ruin the element of surprise somewhat......
BSP's (in the DOOM sense) had to be aligned to polygon planes, and required the splitting of geometry in order to facilitate nice tricks such as front to back rendering (for transparency), not to mention collision detection. It's rare to see BSP used in such restrictive ways anymore (in games at least), and in fact they have largely fallen out of favour. Portals, Kd trees, Oct-trees, AABB-trees, OBB-trees, ABT trees, and Quad trees are more common approaches these days (effectively most of them are axis aligned BSP trees), and it's rare for the spatial nodes to store single triangles anymore (it's more typically used to store whole objects - although triangles from static level geometry may be bucketed into the nodes). Part of this change was driven by the fact the GPU likes batches of data to process (rather than individual triangles), and the other reason was to facilitate dynamically moving objects. Animating a few thousand objects in a loose KD tree, or an ABT tree would not be computationally expensive. However the time spent computing ray intersections would certainly increase.
I could think of ways around the problem however. For a complex non deforming geometry object (eg chandelier), it would be possible to construct a local space KdTree around it, test the ray against the object bounds, transform into local space of the object, before finally testing the ray against the spatial tree. For cases where that doesn't work (eg a deforming mesh), you either have to accept the extra cost of re-building the tree (the performance on which depends on your mesh size), or you can reverse the problem and construct a Kd Tree around the ray itself (which can be more efficient in some very specific cases).
However you look at it though, deforming geometry adds a lot of overhead into any renderer, ray tracing more so.....