• Register

In a militaristic future where mankind has conquered the farthest reaches of space, the crew of a lone research vessel called Antares lies dormant near an off-world mining colony until it receives a distress signal and executes a surveillance mission. Upon descent on the planet you discover that the colony defenses have turned against you. There you must battle the war machines of humanity, now controlled by a sentient entity of unknown origins. As the player, you are the pilot of a space fighter, the only one trained and capable to fend of the enemy forces and defend Antares.

Post news Report RSS DEV BLOG ENTRY 2: MODELING FOR GAMES

Read about our 3D creation process and the things you need to look out for in 3D modeling for games in general

Posted by on

It's time to talk about the art creation process in EXCUBITOR.

In our development pipeline, and I am pretty sure the same goes for all other game studios as well, artistic design is the first step in the content creation process.

At the beginning, when the initial team of Aleksandar and Ivan started to make their first game they didn't have the knowledge to create complex soft meshes such as humans, creatures or any other organic surfaces for that matter. In contrast hard surface modeling proved to be much easier, at least for them, as it is something our 3D artist Aleksandar is most comfortable with.


Because, as mentioned above, the team started out as just a couple of friends with the desire to create a game, and Ivan was the developer all of the asset creation came down to Aleksandar. Hard surface modeling for him was, and still is, much easier so we can point to this as one of the pivotal points in making the decision to make the kind of game we're making, where the majority of the content is composed of sci-fi vehicles, spacecrafts, buildings and other non-organic objects.

LOW-POLY VS. HIGH-POLY

Because games are rendered in real time, meshes should have a relatively low polygon count. The term polygon budget is used to determine the number of polygons art designers can use when creating new models. The constraint of the polygon budget varies depending on many factors (game engine, optimization algorithms, type of game and game content, platforms intended and so on). AAA games have high-end game engines capable of processing large number of polygons through various optimizations, so the limitations there are rather loose. The most widely used method to create an asset is to sculpt it first in high-res and then downscale it to a low number of polygons but not before the normal, and the other needed maps, are baked. So basically the high-res information of the model is applied to the low polygon version. A software like zBrush is excellent for this kind of work.

In our case the number of polygons are somewhere between 3000 and 4000 in most cases, but sometimes we make exceptions when greater detail is required, as in when we create a more important model that is generally featured in most of the game. Also if the object is not important in the scene, or is really small in scale, we reduce the poly count even further.


PROBLEMS

Of course in the start we didn't have a clue and all the models had so much polygons that as soon as we had a level editor and started building our test level the frame rate started to plummet because the GPU couldn't handle the number of polys. We created spacecrafts with something like 7000 poly yet they were so small on screen so all that detail was not even visible. At some points we even had spacecrafts with polygon counts as high as tens of thousands. So we had to recreate and scrap some of our early models. We started to pay attention to the polyCount and we started using a polygon budget.

FURTHER OPTIMIZATIONS

There are a few methods that can be applied to further optimize the models so they can be used in games:

  • Deleting of polygons that can’t be seen in game - Occluded faces
  • Deleting polygons below the height map
  • Deleting or reducing poly count on meshes that are far away from the camera or are not important enough to have great detail (balance between important and non-important elements)

Many of our in- game assets are a large number of big rock and stone meshes that populate the playable area. Because these meshes are packed together tightly they occupy each others space, so many of the faces of one object are entirely inside another object and they will never be visible in the game, but they hinder the game performance. So we had to find a way to delete all these faces without too much trouble, if possible.


So Ivan created our custom Mel script for selecting occluded vertices that solved this issue:

string $polyName[] = `ls -sl`;
string $vertexID;
float $bias = 0.02;
float $redValue[], $greenValue[], $blueValue[];
int $vertNum[] = `polyEvaluate -v $polyName[0]`;

for($i = 0; $i < $vertNum[0]; $i++){
$vertexID = $polyName[0] + ".vtx[" + $i + "]";

$redValue = `polyColorPerVertex -q -r $vertexID`;
if( !($redValue[0] > $bias))
select -add $vertexID;
};
hilite $polyName[0];

Next week we will show the final steps in the asset creation process, how to create an UV layout and apply a texture to the 3D model. Stay tuned for further updates and feel free to ask any questions regarding this topic or the game in general.

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: