About Me

My photo
Bangalore, Karnataka, India
Strategic Senior Producer with over a decade of experience in PC, consoles, and social media game production. Proven track record of managing and delivering projects for both client-side and client-facing companies. Experienced in developing specifications project planning, scheduling and tracking, scalable production processes, scopes, SOWs, budgets, and timelines; good understanding in marketing strategies, emerging trends, analytics, and comparative analyses. Well versed in managing multi-million dollar projects/budgets and art outsourcing to vendors. Skilled in adapting to multiple cultures, and in managing international talent. Deep knowledge industry tracking and scheduling tools including MS Project, JIRA and Hansoft. Good understanding in 2D and 3D art and animation.

Useful Presentations/Docs

Monday, May 31, 2010

Game Model: Asset Complexity Guideline


This documentation explains the importance of defining smoothing groups as well as practically showing how careless unwrapping can increase vertex count in a model which will not be visible in a 3d application like Max or Maya.
The model in this example is a simple pillar (below):
 Vertex count is more important for a mesh because of the simple fact that in any 3d application or game engine the mesh/model is displayed/ rendered based on the position of the vertices. 
No 3d application knows about a face or an edge but creates a face based on the corresponding vertices and their position. 
We cannot define vertex count for a mesh (especially for gaming model) because it depends on many things like smoothing groups, UV-Unwrap and multi-material. Moreover, the smallest face that can be rendered is a triangular face (Connecting 3 vertices), we prefer defining tri count for a model rather than vertex or face count.
 Coming back to our example models:

  1.  First Model is exported to unreal editor with auto smooth applied (each face has its own smoothing group based on the angle defined). Importing the model (Especially for Reich) will give you an error:







What is this error?
Model’s vertex count exported to unreal should not be 125% more than the actual mesh count in 3d application. E.g. If your model has 100 vertices, the exported vertices count should not be more than 125 vertices.
 In unreal engine the actual vertices exported are 66 instead of 17.

 Why this happened?
 Whenever 2 different smoothing groups are applied to 2 adjoining faces, theirs common vertex is split into 2 (each contain information of their face smoothing angle)

2.  This time we import manual smoothing model. This model has less smoothing separations compared to auto smoothing import. Vertex count comes down to 52.


3. Now we import single smoothing group model and definitely it will have least no. of vertex count.

(Check the shading issues with single shading)
Surprised??Vertex count remains the same contradicting out though….No…this is because of the fact that vertex count also depends on unwrap, even though smoothing is single default unwrap islands created so many vertices.
                                                                                                                                                                                                                       

4. Lastly, we import chamfered model and see the count.
Surprised again?? Though tricount has increased but the vertex count got reduced to 49 compared to all previous imports.
Why this happened?? This is because of the simple fact that it all depends on smoothing group and unwrap layout.






In all the above exports we didn’t touch Unwrap….Now we start fiddling with unwrap on the model. All the models has now flattern mapping applied.

(Normal Model)                                   (Chamfered Model)


1. This time we export our very first model (Auto smoothing group) with generic flattern mapping.


See how vertices reduced from our first export with no mapping (60 vertices) to one level of flattern mapping (52 vertices).

This change occurred because in default/no mapping, unwrap was broken at many places while in flattern, it got reduced to lesser UV islands.


2. Now we import manual adjusted smoothing group model with default flattern mapping. 
The vertex count again reduced from 52 to 44 because smoothing groups was same but unwrapping was different.


3. If we import single smoothing group model with flattern mapping: 
 Same result…….Vertex count reduced due to flattern mapping.

4. Last import is of chamfer model with flattern mapping. 
This time vertex count raised significantly because of flattern angle breaks in the mapping. More the number of uv islands, more the vertex count.


We can reduce it more after adjusting the Unwrap. We try to change mapping to our models and see the final count.
                           (Normal Model with adjusted unwrap) (Chamfered Model with adjusted unwrap)

1. Our first import is of auto smooth model with adjusted and fixed Unwrap. 
Vertex count didn’t change. It all depends on the UV layout.


2. Next import is of manual adjusted smoothing group with adjusted unwrap.
Same result…..no change..It must be because wherever there is a shading split there is a UV split. If shading split is on one face while uv split is on another face, then both the split will be taken into consideration.

3. Now, simple models with single smoothing and adjusted unwrap.
Drastic change……decent count but lighting issue is persistent.

4. Lastly, we import our chamfered model with accurate smoothing and adjusted unwrap. 
Again, the count got reduced to a decent level.


As a final not if we compare all the models we have the chart:





















(In all the modes above, chamfered model is perfect in terms of specular highlight and shading)

 AUTO: Such smoothing is rarely used since it increases unnecessary vertex count. Though smoothing angle can be adjusted to get more appropriate smoothing result. Drawback is there will be razor sharp edges with no specular highlight so the model looks bad visually. It is always recommended to manually adjust the smoothing.

Manual: Manual adjustment of smoothing is always necessary to reduce smoothing groups wherever possible and thus keep vertex count in limit. Try to keep, wherever possible,different shading only at those face where UV gets split. In this process, try to get as few smoothing groups as possible (while not hampering lighting/shading information) so as to minimize smoothing splits. 

Single: It really helps to get the model with least vertex count in the engine at the cost of lighting issue if the model is less complex (At times). Such smoothing can be used where the mesh count is enough to support pooper lighting. Since this is a very basic model (example above) lighting is not so much accurate but a complicated model with single smoothing group is best way to create gaming models. 

Chamfer Corners/Edges: Rather than setting different smoothing groups for a cornered surface, it is always better to chamfer the models and assign single smoothing. Though it increases the mesh count a bit but it is far better way to reduce vertex count and get lighting/shading perfect on the surface.

Another Example:

Texture Memory Table

Here are the two images that show the texture memory (in Kb) used when we convert or create an image in Dx1,3,5 format (with and without Mip-maps).

Thursday, May 27, 2010

CGtantra Award Nomination

My Game Model got nominated(best 5) for CGtantra award for Best Game Model.

Here is the link: http://www.cgtantra.com/forums/showthread.php?t=23126

Game Engine Survey

This is one good article I read on Gamasutra (by Mark DeLoura) which describes the changing trends in Game engine usage and acceptability.It presents few eye openers.

The Game Engines
Certainly there are quite a number of game engines one can license for a game. The ones that are relevant to any particular game vary based on targeted platforms and genre, as well as timeline and budget.
For the purpose of this survey I (Mark DeLoura) focused on these commercial engines, primarily in the “core” market:
There are many more engines available, including many open source engines. Some other notable engines not focused on in this survey include Blitz Games Studios’ BlitzTech, Digini’s Blade3D, and Dassault Systèmes’ 3DVIA Virtools.
Foundation of the Survey Responders
The approximately 100 executives whose data are used for this report are spread across the game industry, but by-and-large focus on the “core” market, PCs, consoles and handhelds, targeting traditional gamers. The casual and mobile markets have different engine demands which in some cases overlap with core, but the results of this survey should not be taken as directly applying to those markets. The core market appears potentially very fertile and lucrative at the moment when compared to others.
So for your reference throughout this data, our survey responders stated that they are currently working on titles for the following platforms:
Development on other platforms (PS2, WiiWare, Mac, Linux, iPhone, other mobile) fell below this rate.
Current development budgets for these titles fell largely into two lobes: under $4M, and over $16M. 42.2% of responders are working on titles costing less than $4 million, and 42.4% were over $16M.
Game Engine Awareness and Use
With so many game engines available now, which of these have game industry members actually heard of? Which have they used? Clearly one of the most important elements for game engine companies is just getting their product in front of the right people, so if executives aren’t even aware of their engine, they’ve got big issues. The game engines with the most awareness from our responders were not a huge surprise, and both the technologists and producers had roughly the same level of awareness on all the engines. These were the top five:
However, asked which of these game engines they’ve actually used, the picture becomes more interesting (I’m leaving off the lower parts of the data purely for brevity):
What is immediately noticeable in this data is the massive awareness and knowledge of Epic’s Unreal Engine. It is the most well-known, and more remarkably, a majority of our responders have used it!
After Unreal Engine, the data drops off a cliff fast – with Torque, Gamebryo, and Source all roughly equivalent as the second most frequently used game engines, with about one out of five people having used each. The distance between Unreal and the rest is interesting.
Even more interesting is the massive awareness of CryENGINE even though there aren’t many games on the market using it. Let’s see how perceptions of these game engines correlates with this.
Perceived Usefulness
Beyond simple awareness of these engines, how useful do the executives think they are for their current projects? Those who have used the engines before (or are using them now) should have a very good idea, as should those who have evaluated them, but these ratings probably mostly belie a simple perception of a game engine’s capabilities. I asked our responders to “opt out” if they didn’t know how valuable each engine actually would be for their projects, or rate them on a scale of one to five, if they did know:
Something that pops out of this data immediately when combined with the previous questions is the belief that CryENGINE is the second most useful game engine middleware available, even though it is also one of the least used!
Also notable is the sudden emergence of idTech and Infernal on this top five list. Does it reflect a belief that game engines made by companies that are using them for their own games must be the most “useful”? Or, keeping in mind that people are responding to how valuable these game engines would be for their current project, it could be that these engines have been seen used for games of similar genres, and on the same platforms. Certainly some of the other game engines pride themselves on being more broadly useful across a variety of genres. This data seems to suggest a belief that genre specialization is valuable. Or, maybe we’re all making a lot of the same types of games. :-) It’s hard to sort the complete answer out of this set of data, but it is interesting to see.
Using Game Engines
Backing up for a moment, why do we believe that people even want to use game engine middleware? If it is true that game engines are becoming more accepted by the industry, it should open up the market for more engine companies. Certainly the leading perception is that engine use is on the rise. But let’s check it out.
When asked if they are using game engine middleware on their project, our responders definitely indicate that engines are popular. 55% noted that they are currently using a licensed game engine on their title – that’s specifically an engine, not middleware libraries.
But when asked if they WANT to use game engines, the opposite results were returned:
Although the majority of our responders are using a middleware game engine, it appears that they would rather not! By this data, it appears that perhaps a thin game engine which adeptly integrates middleware libraries from other companies may find more acceptance in the marketplace than one which tries to do everything on its own.
The Economy
The difference in the percentage of people using game engines versus those who want to is certainly interesting. Could the high level of use have something to do with the economy, or with the increasing cost of development? I asked the producers whether they’ve found themselves with tighter budget constraints due to the economy. 78.6% responded yes. But in the comments many people pointed to tighter control over their budgets, as opposed to diminishing budgets.
Following up, what has been the impact of these rising development costs and a dwindling economy? What concerns have increased most for developers in recent years? The five most popular responses were:
Increasing development cycle length, increasing headcount, trying to create game designs that stand out from the pack... these are fairly consistent game developer challenges. But looking for rapid prototyping and rapid iteration tools? Here we find interesting new news. Rapid prototyping enables a developer to more quickly draft and test game concepts for fun in the early stages of a project, and also use the prototype to acquire funding. Rapid iteration gives one the ability to quickly try out many ideas during development, improving the game through frequent experimentation and fine-tuning.
If rapid prototyping and rapid iteration are weighing heavily on people’s minds, what are they using now? And how many studios have live preview on the target platform in their current content pipelines?
I asked, “what are you using for rapid prototyping?”
Several people noted that are using their previous engine versions to create prototypes for the next game. But what do new studios use? It looks like they probably create one-off C++ applications, sketch things out on paper, or use Flash or Lua. I had suspected that more developers would be using C#/XNA due to the ease of quickly knocking out quick test applications with it, but only 5% of the responders said they are using this for prototype development. (However, 76% of developers are using C#/XNA for tool building.)
If rapid iteration is also a growing concern in game development, how many developers currently have the ability to do live preview on the target platform for their content developers (artists and designers)? According to the results, 62.5% currently have this capability. Several responders noted that they preview on a PC version of their engine and that this is good enough for most work. Certainly using the actual target platform would be even more valuable though!
One useful tool for rapid iteration during development is the use of interpreted scripts; if the designer can write in a script language and immediately execute it on the target platform (as opposed to a long recompile or download), the iteration cycle can become quite fast, enabling many experiments and much more fine-tuning of gameplay ideas. But what script languages are most people using? (This query supported multiple replies.)
It seems that Lua is the hands-down favorite for scripting languages at the moment, although one developer wryly noted: “Lua is a failure - decided before I joined.” Lua is a solution that can work, but people tend to have a love/hate relationship with it. Using Lua on performance-constrained platforms can definitely be a challenge if you don’t understand the ins and outs of Lua’s memory usage.
Making a Decision on Engines
The last thing I wanted to know from both producers and technologists was: What factors do they use in deciding whether to license a game engine, and which one to choose?
The overwhelming favorites were of course cost and time. If we purchase a game engine, we want to spend less money and time than we would have creating the engine on our own. Otherwise why would we bother? (We’ll talk about that question more in the upcoming production-oriented post!) In third position to money and time came genre relevancy, or making sure that the game engine works properly for the type of game you are creating. This emphasizes the importance of doing a thorough evaluation of any game engine you’re looking at, and knowing if a particular engine was already used for a game technologically similar to what you are planning to create (a first-person shooter, for example.) Also highly important to the responders was support and thorough documentation, a good-quality content pipeline, and the ability to easily integrate the game engine into one’s existing technology as well as with other middleware libraries.
Licensing a game engine is an important decision. Clearly many studios are doing it, and you should do a thorough evaluation of each candidate game engine before settling on one. Unfortunately there isn’t enough public information about most engines, so seeing a game similar to your own, or knowing people on other teams who have used a particular game engine for a title can go a long way to helping you with a decision. As we all focus more on rapid prototyping, rapid iteration, and live preview in content tools, we hope that the game engine creators are listening and will continue providing us the excellent tools we need to create amazing games.