3D Constraints

3D Constraints

This is asmart resource. Use a QR readeror theAurasmaapp to access additional content.

http://goo.gl/kwlJtI

Constraints

When creating 3D art, especially for real time applications such as games, there are a number of constraints that the artist needs to consider. I’m going to discuss the hardware based constraints here which include polygon count, render time and file size.

Polygon Count

As the name suggests, the constraint here is on the number of polygons or faces that can be used to construct a shape. The more polygons that appear within the render view, the longer each frame will take to render. This constraint applies equally to real time applications such as games as well as non real time such as animation or special effects.  This is directly linked to the hardware available. For an example, lets look at games hardware, specifically the xbox 360 and Playstation 3. If all they had to do was calculate polygons and not any of the texture, operating system or game play elements, the xbox 360 could render 500,000,000 polygons per second and the PS3 could manage 275,000,000 per second which sounds like a lot. But if you take into account that games need to render at least 30 frames every second the number of polygons that can be shown on screen drops to 16.6 million for the 360 and 9.1 million for the PS3. Again, this may sound like a lot but the consoles are doing a lot more than simply rendering polygons which also uses a lot of system resources. These examples show how polygon counts have been allowed to increase as hardware has become more advanced.

Half Life (1998). Zombie 844 polygons.

Gears of War (2006). Marcus 15,000 polygons

Lair (2007) 134M polys per second. Dragon and rider 150.000 polygons.

Render time

Again, this has a very descriptive name and concerns the time taken for each frame to render. This is a huge constraint for real time 3D graphics. For a game to run at 30 frames per second (seen as the minimum that games should be achieving) then the hardware needs to render 30 frames every second. This is quite an achievement when you take into consideration how long it can take to render a frame of a 3D animation such as Toy Story 3. The frame below took 16 hours to render. That’s just for one frame! Remember that film runs at at least 24 frames per second so that means that to render just one second of Toy Story 3 would take 384 hours or 16 days!

This means that render time can be costly in two ways. The first way is for games and concerns performance. If the game drops noticeably below 30 frames per second then the player will become aware of the drop in performance which will then have a negative impact on their experience.

The second way in which this can be costly which applies more to pre rendered projects is the actual monetary cost. The longer a project takes to render, the more it will cost in equipment, resources like electricity and in man power.

File size

File size is a constraint for two main reasons. The first is that 3D graphics need to be saved somewhere. This could be onto a disc such as a blu-ray, a hard drive or somewhere in the cloud waiting for a digital download. For these reasons the file sizes need to be kept efficient to make sure that they fit onto the media they are designed for. If the 3D art is not kept efficient then it might have to be split over more than one disc, as with Final fantasy 7 or may take a very long time to download a game over a digital distribution system such as Steam or Xbox Live for those on a slower internet connection.

The second reason that this is a constraint is heavily linked to hardware and performance of real time applications. The hardware this relates to is the amount of ram available to a system. For the xbox 360 this was 256mb. Within this amount of memory everything that might be needed at the point of the game you were playing needed to be read from the disc and stored for very quick access. This includes geometry, textures and shaders, animation, audio, gameplay instruction as well as any information needed for running the underlying operating system. This meant that the polygon count and textures for the 3D art needed to be kept very efficient. If there was not enough space available in the RAM to store enough of the game assets the player might experience very low draw distances or a drop in performance as more assets are loaded in from the disc or other storage media. This was very noticeable in The Elder Scrolls IV: Oblivion when the game would stutter as new geometry was loaded in when moving through the environment. This video shows this happening;

http://goo.gl/lfFMCD

In some cases you can also see assets appearing out of nowhere as the draw distance has had to be reduced to keep the game running at a reasonable frame rate. This is shown here;

http://goo.gl/IzRJzh