Friday, 7 December 2012

FMP 01

I've left the FMP alone for a few weeks, as I already had a pretty solid idea of what I wanted to achieve from the project or enough of an idea to present to the tutors. But as December draws on there is much need for me to research and plan an in depth document, with information on my technical specification, detail and full project outline, assets lists and aspects to research and understand. Rather than produce a lengthy document straight off the bat, I'm going to produce a series of blog posts that can be stitched together to create an in-depth project brief. These post would be broken down as following;

Platform -                           Both Console/PC and Engine.
Technical Specification-      What Limitation I will set myself and budgets for textures/models.
Project Outline-                  What am I creating for what purpose and set a back story.
Assets List-                         Research what is needed, what is viable, extended scope.
Tools & Software-              Research on what programs and plugin's I can use to develop and showcase my                                                              .                                          work.

I will also aim to complete one piece of concept art for each of these post as this can develop the amount of visual material I have as reference.


Realistically because of the equipment that we have available to this course my only limitation is the power of the labs machines and the engine we use. We do not have capabilities to port our levels onto consoles so there isn't much I can do to change that. But if I had the option which would I pick, I did some research and the results are surprising. For what I can actually interpret. Below are the specifications for both of the consoles;

I was surprised, both are easily capable of running on screen hundreds of millions of triangles and billions of shader operations. But I assume that is the limit of what the machines are capable of and with running other aspects of software and running systems this would be reduced somewhat. The articles are also quite old, although from their respective companies. Rather than pick a specific machine I opted for a PC standard game. Computer graphics have improved and it is now the high end PC market that is on top. With the limitations of an engine I'm sure I could run my level on all three quite easily. I will use my computer as my base as it is slightly less powerful than what the lab machines are supposed to run. However coming back and forth from Uni I will have to be able to run these both and this is probably for the best. 

As this project will only be displayed and run on a PC that it the platform I am opting for.

I will aim to have a realistic budget and on screen triangle count for a Next-gen game (Current) and to the upper limit of what each engine can handle. This is because I want to make the most of what I've got and make it the best of what I can. I want to showcase my work and that is my ultimate goal for this project.

With this in mind I have researched what game engines I will be using to run my level. Firstly looking as performance.
















FP Character




There is an around 60k limit per model for each engine, so having my ship as one object may not be possible, but it would probably be better to break it into chunks anyway. 
One thing to point out is that triangle counts do not effect F.R. (frame rate) as drastically as Draw calls, Draw calls are when multiple meshes are overlapping and the engine has to render each one of these, slowing down performance. So as above shows a million poly's is a safe maximum guideline for Cry engine 3 and from play UDK I know it can handle this amount safely as well. To keep my FPS below an acceptable level it would come down whether I can keep the draw calls below 2000, which at this point in the project wouldn't seem to be a massive problem but I might have to look at this again later. My decision on which engine to use would rely on other more personal preferences between the engines.

UDK has the advantages that I have already used this program before and I'm quite able and capable of using it right from the offset. It is a stable platform and has a very easy to use interface. You are able to create material shaders easily with a node based system and importing and creating assets is very easy . However it does have some disadvantages, you have to 'build' lighting which takes a long amount of time and means that any changes you make to the level then has to be re-computed. 

Cry Engine has the advantages that its post effects and time of day settings are easily changed and everything is shown in real time without the need for pre-computed lighting. However this does effect computing with multiple light sources. Cry also doesn't have the ability to edit shaders which means it can be difficult to get the exact effect that you were looking for that might be relatively easy in UDK. Cry does look very nice and interactive and for the water based scene I am producing it is probably the right choice. However having to set up plugin's and having to be on-line to work is another issue that might be a problem, however these aren't significant issues once the project is under way.

Below is a comparison between the two engines, There are differences between them but a lot of the setting can be mirrored and achieved on the opposing engine anyway.

I think based on the fact that I am showcasing asset and level creation rather than particular shaders and I want dynamic lights regardless in my scene. As well as the engines are otherwise vary similar in capabilities and that I want to understand and learn a new engine, I am opting for using the Cry Engine 3. I feel this will showcase my work the best. As long as i respect the amount of draw calls and don't go overboard with my texturing and budgets and stick to respectable current gen limit, this project should be successful. 

No comments:

Post a Comment