Thursday, 30 May 2013

Urban Galaxy 3D assets - part1:Buildings


Creating 3D assets to populate levels in Urban Galaxy included some really big challenges. In this post we will try to display the whole think and development process that led us to the current assets used in-game.
The 3D assets are comprised of two different parts that we will talk here, those are the actual 3D mesh and the textures applied on that mesh. Those two parts communicate with each other through the UV mapping of the mesh surfaces on the texture. Sorry for the obvious disclaimer but it had to be written!

First come the hard requirements!

Here we are talking about file requirements as well as size and "beauty" requirements. The fact that the game is a browser game implies that we want it to load fast. That translates to:
  • as few polygons in the mesh *
  • as smaller file size for the texture(s) *
(* as possible!)

Apart from the platform specs we wanted the assets to look really beautiful and match at the scale of the game - each level is a city block of approximately 1,2Km by 1.2Km. So here comes an implied requirement, the buildings need to look large and really really tall!! (not to mention great looking from far and closeup).

Then come the soft requirements

Taking the above a step further, since we wanted the whole level to load fast we had to think of a way to reuse as much of the assets as possible, but always in a way that the repeat would not be that obvious.
Since the majority of the assets are mostly fillers, the whole styling of the assets should be unobstructive to the gameplay if the asset does not affect the gameplay, in other words DO NOT F** WITH THE PLAYER'S VISIBILITY OF MOBS, OTHER PLAYERS AND OTHER ACTIVE ELEMENTS!!(mind the caps). In the same category of requirements but reversing the effect, the active assets must popup for the player but not spoil visually the whole setting.

Getting hands dirty

Having setup the requirements we started creating assets, setting off with a simple square building. The challenges of creating the first building ever were:
  • Texture should repeat in order to cover as much mesh space as possible
  • In order to keep the mesh in normal polycounts certain parts of the mesh should have different scaled texture than others
  • A special texture space should be used to add details to the model in player's zone (the zone in which the player can fly in game)
After alot of trial and error we decided that the final texture size for the buildings would be 512x512. The texture space on that was split more or less:
  • 70% texture space for high detailed large chunks (walls with windows)
  • 15% texture space for low detailed large chunks (walls standing at heights and lows outside the player zone)
  • 15% various smaller details used to add closeup details and variation on the final asset.
Breakdown of the first-ever building texture, closeup details got more detailed in the latest building sets
The whole idea was to utilize the final texture to apply it on various building meshes with different shapes.....and that was good!! So far what we have accomplished was to define a set of buildings that share the same texture.
On the front of mesh polycounts we found the balance of simple mesh and complex result standing at 500-700 tris per building. That was due to the fact that we had to add some kind of details in the player zone and also the outline of each building should be as unique as possible.
Finishing our first buildings set and starting to rough out a first level another problem was visible: having only single block buildings was restricting the variations of level layout - plus it was reeeally ugly! -.
So we had to think of a way to add more variety to the level. What we finally came up with is a way to "build" building blocks more or less like Lego, where each building perfectly aligns to the one next to it.
A chunk with the seam shown in red, all building chunks share the exact same seam shape so they perfectly fit with each other.
Going one step further with that idea we adopted a standard for building chunks seams that allows various buildings from various sets to be perfectly aligned and create a large building block. To give more flexibility to the larger blocks we implemented 3 basic building types/variations: a straight building, a corner building and an inverse corner building. Using these we can create a large variety of shapes for building blocks.

Here ends the first post covering the 3D assets, in the second part we will talk about lesser 3D assets aka fillers.

5 comments:

  1. Nice update on he tech of how its built. Whats the average file size for a full building to be downloaded by the clint (including textures?)

    Also are you compressing any of the data passed back to the client?

    ReplyDelete
  2. Hello Aaron, good thing you found some useful information in here!

    The 3D objects file size depends on the complexity but it is always below 150-160KB. We have models of 5-10KB that are really simple fillers and some of the 105-120KB that are large building chunks. The texture is common for each set so you download it once and use it in more than one assets. The texture file size is about 200KB in total.

    So an estimate on the average file size is 100KB for a building 3D asset + 40KB(200/5 for each building chunk in a building set of 5 buildings) = 140KB. Again these are rough estimates applying to the buildings.

    For the fillers this number is way smaller, 10KB for the 3D mesh + 10KB(200KB/20 for 20 fillers in a fillers set) = 20KB, we will talk more about the fillers in the next part of the 3D assets post.

    ReplyDelete
  3. Nice and fast then if they are that small. How are you finding the average FPS for users? Would be great to notch up graphics quality for those who can handle it, or would that be something you look into depending on popularity?

    I always find managing game states, loading and uploading assets a pain, any plans on a post for that in the future?

    ReplyDelete
  4. More detailed graphics translates to bigger assets which translates to increased bandwidth and more waiting time for users. Take for example the HTML5 port of Unreal's WebGL port of Epic Citadel. Superb graphics but it may take forever to download on average ADSL connections.

    The average user will probably get frustrated and leave your website if it takes too long to download. We would never want this to happen, so we compromised detail for that. Also, now that WebGL is coming to tablets, this is getting even more important.

    I always find managing game states, loading and uploading assets a pain, any plans on a post for that in the future?

    More technical posts are on the way, probably with code snippets as well.

    ReplyDelete
  5. Awesome on the more technical posts, looking forward to them ;-)

    ReplyDelete