Games and game technology are worth billions, so a lot of money is spent developing tools to create realistic environments and simulations. some of these tools can be developed into real-world commercial applications.
Star Citizen is making it possible to look inside their game development process including music, audio, modelling and the software infrastructure.
- 1 Face Over IP
- 2 Motion Capture (MoCap)
- 3 MoCap Procedural Enhancement
- 4 Habitation Modelling
- 5 Modelling with Substance Designer
- 6 Ship Development
- 7 Object Containers (OCs)
- 8 Object Container Streaming (OCS)
- 9 Mega Maps
- 10 Bind Culling
- 11 OCS Testing
- 12 Modelling Tech
- 13 Related Posts
Face Over IP
This game technology feature will provide the means for an in-game character’s facial expression to display those of the player. This technique has been given the name Face Over IP (FOIP) because the player’s avatar will be controlled by its user over IP.
An image of the avatars face will eventually be transmitted over IP in-game as well but this isn’t the primary reason for the name. FOIP works using standard webcams and doesn’t require preparation such as face markers. For best results, an RSI webcam has been developed with the following features:
- 60 fps for responsive lip synch
- A sensitive CCD for low light environments
- A narrow-angle to focus on the face
- High-resolution glass lens for accuracy
A side effect of having such accurate face tracking is that it supports head orientation tracking. Head orientation can be transferred to your in-game avatar, providing additional realism or allowing you to look off to one side of the game environment. This would help to glance at the information displayed on an off-screen monitor or to see what might be happening outside of different parts of a cockpit without interfering with the ship controls.
Motion Capture (MoCap)
Full body motion capture is used to create realistic animations of people in-game. The animations are cut into segments that can be strung together as required to make up part of a continuous sequence. The game’s artificial intelligence (AI) will choose the necessary elements to correctly navigate an avatar along a path and will modify turning angles and footfall smooth the transition between each segment.
Walking animations are recorded at different speeds so the avatar can also speed up realistically from a walking to running.
MoCap Procedural Enhancement
Walking, running and turning MoCap data has been captured to realistically animate avatars as they follow routes through navigation meshes or are driven by a user.
Ivo Herzog is the lead animation engineer who has been responsible for extending the mocap walking data to handle uneven terrains such as staircases and rock-strewn surfaces.
An avatar has a simple internal skeleton to ensure that the elements of the figure stay in their correct positions when moved. In order to cope with uneven surfaces, the skeletal hips and legs of the avatar are adjusted in real-time. The extents of movement are limited by the joints and the feet will make contact using the ball or flat of the foot as appropriate.
A jump trajectory is used to connect surfaces at with significant height differences, and the posed figure will look natural if the relative heights of the supporting surfaces are less than 1 metre apart.
The habitation environments have lighting, animation, damage and audio attached to them just the same as the ships do. Trigger points and modes can be built in and would be available for programmatic control as well.
Modelling with Substance Designer
Food meshes and landscapes are both created using a commercial tool called Substance Designer. The tool allows the designer to connect together mathematical processes represented visually by boxes and wires. Some of the boxes provide data sources of different types, often driven by random numbers, while subsequent boxes modify, filter, combine and shape the date into useful assets.
The top-centre pane in the designer screenshot shows some of the transformation boxes that combine to describe the final object.
The food types are synthesised from randomly placed coloured objects and effects.
The realism of the moon surfaces is impressive and seems to emerge more from utilising good ideas and the willingness to take the time and money to implement them well rather than by looking for a proprietary software solution.
Their long development schedule and funding reserves allow them to push further into existing tech than traditional funding would support.
Special game elements such as habitations and landscape features are embedded into a landscape visually using POM technology to provide a more realistic contact surface.
At the time of writing, there are 132 ships in the game and there will be more coming. Each ship design goes through a pipeline of processes from design to flight-ready that are checked and signed off at each stage.
The ideas for the ships are germinated by writers and artists who are developing and maintaining the history of the universe in which the game sits. The ship’s appearance is driven in part by its functionality and in part by its internal requirements for such things as habitation modules, weapons and hangers.
Illustrations are created to capture the look and feel from multiple angles.
An unpainted, flyable 3d model is created in minimal time with simple primitive shapes. The exterior appearance and the interior spaces are refined but not modelled in detail.
Builds as close to the final geometry as possible using two tones of grey. Details are improved and library assets such as doors, ramps and chairs are added. The interior and exterior will have been finalised and there have been several passes to reduce poly-count.
Some animations are added to ensure that the ship dimensions are correct for folding of landing gear, ladders, cockpit canopies and anything else that moves on the ship.
Final Art Stage
The final art stage includes animation, visual effects, lighting, audio and the tech art that makes up the cockpit and interior locations. The ship is scrutinised to see that it flies how it was intended to and that it has the correct health and shields.
Ship animations and timings are finalised with character interactions. Graphical details like cut lines gratings and wiring are added using Parallax Occlusion Mapping textures.
Flight Ready Stage
Finally, the gameplay aspects are added, primarily in the structure and animation of the ship damage. The separation points are determined by modellers and the likelihood of different types of damage is expressed in an associated XML file.
Object Containers (OCs)
Object containers are a proprietary game technology developed by CIG. The purpose of the containers is to partition the very large game volume into discardable chunks that will be manageable by a users’ PC. Each container sets the scope on what is visible and what can be interacted with.
A ship is also a container, but one that will move around the hierarchy.
The modular nature of the containers means that each containers’ resources can be loaded and unloaded from memory individually or transferred from one server to another.
It would allow a server to maintain a specific container within the game as desired.
The container outside the one you are in contributes to the background image and containers within yours would be shown by their exterior views.
Object Container Streaming (OCS)
OCS will reduce the number of elements in play at any one time which lightens the load on the CPU and RAM. The Streaming part of the title refers to how an environment is built during the game. Instead of loading all of the details of the game at once, only objects that are big enough that they could be seen will be loaded.
When an object goes beyond its viewable distance, it’s visible assets can be discarded leaving being a lightweight marker object with essential properties such as position and an id to allow it to act as a communications target.
In order for OCS to work correctly, the objects it deals will load asynchronously and be thread-safe. The information required to synchronise computers will be carried by serialised variables.
Normally a game environment (also known as a map in this context) would be loaded into memory in its entirety in order to simplify programming. OCS makes it possible to load parts of a map into memory when required, which includes the user selection screens that are shown before entering the universe. The mega map is the RSI label applied to a game environment that implies the use of OCS. Its purpose is to hide loading times and optimise memory use.
The game server will be making decisions about which entities are fully loaded or represented by markers. A client PCs entities are bound to the server’s entities and will be culled (streamed out) when the server’s version is removed.
The highest risk scenarios occur when entities leave and then come back. The game will also have to work correctly for groups of people that are dispersed across a single Object Container and therefore have different views of the same scenario.
Another game technology improvement that is more to do with attention to detail rather then leaping technical hurdles. When two 3d surfaces meet there can be tell-tale effects such as razor-sharp joins or slight gaps. This effect can be mitigated by two methods: subdivision and POM.
Where more detail is required, a mesh can be subdivided to support it. When edges meet, extra polygons can be added to smooth off the join, which raises the level of realism. The downside is that the polygon count for the model will go up.
Parallax Occlusion Mapping (POM) adds detail without adding to the polygon count. Texture and heightfield information is combined to provide a visual model that is rendered by the GPU. The heightfield information would normally be stored in the alpha channel of an RGB image, but it doesn’t have to be.
Star citizen uses POM to smooth off joins between meshes and to add visual detail like cut lines, rivets and wiring to ships.