If you want to see more of the advanced technology behind Final Fantasy XV, you have come to the right place. More videos and screenshots have surfaced from Square Enix's lectures at Siggraph.

First of all, a few spectacular videos have emerged from the Brain & Brawn lecture that we showcased yesterday.

AI Pathing and Attack Patterns

Locomotion System

Environmental Awareness

Inverse Kinematic

Physics Based Animation 

We also get quite a few interesting work-in-progress screenshots and information from the papers of a few lectures that were not livestreamed (1, 2, 3, 4, 5). A couple were shown before, but now we get them at full resolution and with a full explanation.

Development environment

"In addition to improving the quality of our assets, improving de-velopment efficiency was also an important effort for us. To solve this problem, we used a single DCC tool to finish asset creation and

improve development efficiency. To maintain consistency with how things appeared in the Maya Viewport runtime, we implemented a color grading function equal to that of the runtime."

Creating hairstyles

Hair is a major factor in determining a character's quality, and is the part that involves the highest production costs. We will use specific examples to introduce our efforts to efficiently create high quality hair.

While styling actual hair might seem to be a roundabout way to approach this, it is a meaningful process for allowing the artist to understand the structure of hair, and greatly aided our later work.

We use Maya's nHair to create hair. Of course, this will not run on the actual console. It was necessary to reduce the file size while still maintaining nHair's high quality. We created polygons that

were similar in shape to those in nHair and then baked the nHair results to a texture. Doing this allowed us to reduce memory usage while maintaining the desired appearance.

However, this meant that the workload became quite large, resulting in each character's hair taking around a month to finish - so we created a tool to simplify the related processes. Using this tool allowed us to reduce the workload by 60.

Setting supplementary joints

With normal inverse kinematics animation, violently moving ani-mations will result in the collapse of joint shapes. To solve this, we prepared supplementary bones for each joint and used function

control to animate them automatically in order to prevent them from collapsing. (We call this"Kine Driver.") This solution respondsdynamically in the runtime and makes it possible to return to the

correct values for additive animations that cannot be recreated us-ing plotted animations.

Shaderworks for state changes

The more expressive games become, the more we are required to recreate phenomena that occur in the real world. With this game in particular, the reactions of characters when exposed to magic are

one factor that helps to increase immersion in the game, and so this was an important issue for us to tackle.

Cloth-simulation setup

At the preliminary skinning stage, the surface polygons merely follow the motion of the bones. This results in an instant loss of realism. To solve a problem like this, it was necessary to construct a

cloth-simulation setup environment. We will show specific examples while explaining what the authoring looked like.

AI Graph

The users of AI Graph Editor can make graphs composed with hierarchical finite state machines (HFSMs) [Millington and Funge 2009] and behavior trees [Isla 2005]. You can seamlessly assemble those two systems with this novel hybrid architecture to exploit the advantages of each system according to the situations. AI Graph supports the unique concepts of parallel node and interrupt node. Sometimes, natural behavior and thought can be observed as doing multiple things at once: for example, waving a hand during walking, and thinking about the next target while attacking another enemy. We can intuitively implement these behaviors with the nodes.

AnimGraph

The animation system provides a lot of advanced features which contribute to motions adaptive to the environment and help avoid the users feeling a sense of Deja Vu. Various inverse kinematics techniques, physics based animation, secondary bone systems, and parts blending are implemented in the game engine.

Generally speaking, it is strenuous for animators to understand the full functionality of those systems. Moreover, there is the risk of introducing complexity into AnimGraphs due to the complexity of controlling the status and the parameters of the multiple systems concurrently. We added a feature to deal with these issues.

Body Graphs

Body Graphs are usually created with HFSMs. Some of the states in the graphs are driven with procedural systems which require composite character controls such as swimming on the ocean, sliding on a steep slope, mounting onto an animal for transportation, etc. Programmers can implement these in a modular

Data

This is an introduction of the data structure. The terrain is created based on a heightmap. Towns, dungeons and various other assets are created with polygon meshes. For roads, assets are placed ac-

cording to curve data, and trees use data that has been optimized for mass placement. I

In order to construct a high-quality open worldthat is based on physics-based rendering, the assets were created with LOD in mind, and optimized shadow generation and convex collision data were used to find a balance between performance and quality.

Level Editor

The Level Editor is the core game development tool that allows us to manage and edit all of the information about the game. It has a variety of innovations that make it possible for hundreds of

team members to simultaneously perform level design, asset cre-ation, and lighting. As environment artists, we also use the Level Editor for everything from scene construction work to making adjustments to the quality of the final look.

Asset Browser

The larger the world you are creating, the more important the issue of managing this immense amount of data becomes. Managing the huge number of assets we were creating required a proprietary asset browser. The asset browser has a proprietary filtering feature and proprietary menus for each file type, and we embedded metadata into the files that would allow us to check the data inside.

This made it possible for us to quickly and flexibly access our assets, improving the efficiency of our work.

Continent Design: An Artist's Clay Model

The world of Final Fantasy XV was born from the imaginations of artists, and the continent on which it takes place was no exception. It was created via a clay model made by the art director.

Heightmap Creation: Capture and Optimization

We used PhotoScan to digitize that model, then brought it into Maya and optimized it. After that, we used World Machine to export it as a heightmap.

Continent Data Creation: World Tools

We imported the heightmap into Level Editor and used the cell manager to perform area settings. After that, the sculpt tool was used to adjust the terrain, the curve tool to create roads, and the foliage tool

to place trees. The collisions and attributes necessary for gameplay were also set using Level Editor.

Environmental Settings, Lighting and Post-Processing

Level Editor was used to perform settings for wind, weather, environmental noises, VFX, and so on. Lighting was based on sun and sky settings, as well as the placement of local lights. Post-processing for each situation was then performed to bring it up to the final level of quality.

Specular Light Probes

Lighting results at different times of day. From top-left: noon, afternoon, sunset, and midnight. Note that the color of the wall and table in the background (which are lit dynamically) and

the color of them in the reflection on the chrome ball (which is a probe lookup) match.

Cloud Lighting

The clouds are generated within an altitude layer with user-defined min and max height. The clouds themselves are modeled using a noise function with 7 octaves, where each octave can be animated

independently. To light our clouds, we consider three sources: direct light from the sun, ambient from above (sky), andambient from below (ground).

For the direct lighting component we do a ray march between the known heights of the cloud layer. We do not use a secondary ray march toward the sun but instead use the sun shadow map to determine

how much light reaches the sample [Gautron et al. 2011]. The Mie phase function gives directionality to the lighting (rim lighting).

For ambient lighting, we consider the density of the clouds to be constant within the cloud layer and analytically calculate ambient as an integral over a half-hemisphere of constant color.

Rendering of the procedural sky on screen is done in 3 steps: atmospheric scattering, clouds, and objects and stars. In order to fit within our GPU budget, we amortize the rendering cost across several

frames. The sky box is split into 64 slices, with one slice updated each frame. We use a 2-slice policy for the (cheaper) cloud shadow map, which gets rendered only after all sky slices have been updated. The full sky update cycle therefore takes 66 frames – 64 frames to update the clouds and 2 frames to update the cloud shadow map.

The result of ray marching and lighting the clouds is stored not as a color, but rather as 0-1 scalar data which can be used to reconstruct the color later. This allows us to represent the lit HDR clouds in 8-bit textures. A single cloud texture stores three light color multipliers (which will be multiplied by sun color, top ambient color, and bottom ambient color respectively) and one final extinction value

for blending onto the sky.

After the sky box texture is updated, a similar lazy update process is used to perform BRDF filtering for the global specular cube map. One texture face is updated every frame, for a total cycle length of

48 frames (6 cube faces  8 mip levels). Note that smaller mip levels require more filter kernel samples, so the filtering cost per frame stays roughly constant. This is crucial in order to avoid unstable frame rates.

Cloud animation

The procedural cloud system exposes many parameters to the designers and artists, such as wind direction and speed, altitude, thickness, density, scatter power, as well as several ways to tweak the

color of the clouds. We make the assumption that the clouds are traveling on a virtual horizontal plane at a given fixed height and along a dominant wind speed. We constantly reproject the sky dome taking into consideration the apparent displacement of the sky dome pixels on this virtual horizontal plane. This reprojection also takes into account perspective projection where far pixels on the virtual horizontal plane will seemingly travel at a slower pace than close pixels located just above the viewer.

Once a new cloud texture is fully built, we cross-fade it over time on top of the current cloud dome while simultaneously applying the above mentioned projection. Note that the distortion due to

this reprojection becomes stronger as the animation progresses. In order to avoid loss of quality, the cross-fade is set up such that a cloud dome is in its undistorted state when it is fully opaque, and

the more distorted parts of the animation correspond to when it is fading in or out

Weather effects

Coupled with the above systems which handle the updates of the sky itself is a robust GPU particle engine for handling rain, snow, fog, and other weather-based effects. In addition, weather changes

directly impact the shading of the rest of the scene, such as causing wetness on surfaces ([Lagarde 2012]), generating ponds and ripples and trickling water drops down vertical surfaces, and otherwise affecting the lighting balance and post-processing mood.

Below you can also find some more additional screenshots included in the papers.