Username:
Password:
Remember Me?
   Lost your password?
Search


Frozenbyte

Trine 2: Exklusive technical interview - great art design meets amazing lighting

Although Trine 2 hit the market in last December, PC Games Hardware decided to talk to Frozenbyte, the Finnish developers of this amazing game. Juha Hiekkamäki, Senior Graphics Programmer, shared a lot of exclusive information with us about the technical capabilities of Trine 2.
Trine 2: Exklusive technical interview
 
Trine 2: Exklusive technical interview [Source: view picture gallery]
Three years ago, Frozenbyte released its amazing first Trine: A platformer with great visuals and a lot of physic puzzles combined with a fantastic soundtrack created by Ari Pulkkinen (well know for Angry Birds). By controlling a knight, a thief and a wizard the player has to combine all their abilities like a burning sword, a bow, and conjuring ramps or chests. For example you have to pour water onto the roots of plants which grow up and in the next moment you fight against some goblins or escape them by reaching a higher stage. In last December the successor Trine 2 hit the shelves within a lot of positive reviews. Just lately we had the opportunity to talk to Juha Hiekkamäki, Senior Graphics Programmer at Frozenbyte.

PCGH: Juha, we have no idea what engine Trine 2 is using - so can you please name it and tell us the API? As far as we know Trine 2 is a cross platform title and utilizes DX9, is that the reason why it does not utilize DX10 or DX11?
Juha Hiekkamäki, Frozenbyte: Trine 2 uses our internal engine and we haven't really given it any name. For graphics API we use D3D9 (and OpenGL on the Mac and Linux). We don't support DX10/DX11 because currently we don't really need them feature-wise. Also, we still have players using Windows XP and upgrading to a newer API would only cost us sales and coding effort for very little benefit. So instead we have focused on getting the most out of DX9 :-)
PCGH: If your engine is build in house and no licensed product, what is the reason for that?
Juha Hiekkamäki, Frozenbyte: Modifying an in house engine to suit your needs is always easier, especially as all of the programmers have been involved on some level in creating the engine, and generally speaking everything is much more straightforward, there's no extra features that would just end up being in the way.

On the other hand, with an inhouse engine it is harder to provide easy-to-use tools for the artists and level designers. That's always a challenge and something that needs to be well-planned, because obviously some tools must always exist very early in each project.

One reason for not using any commercial engine is also the simple fact that paying license fees can quickly add up. Trine 2 supports the major platforms - Windows, Mac, Playstation 3, Xbox 360, and Linux also in the future, so there's a big financial aspect also. In a way using an inhouse engine gives us a certain amount of freedom and independence, and we like that. Or someone else could say that we're just stubborn Finns ...
PCGH: We assume your engine features a Deferred Renderer, could you confirm this and could you please list some advanced rendering techniques you are using?
Juha Hiekkamäki, Frozenbyte: Our rendering is indeed based on deferred rendering, and our typical scene has somewhere between 50 and 100 dynamic lights visible. Compared to some AAA games our feature list is obviously smaller. We are using Depth of Field, screen space reflections, wrap lights (approximation of translucency), bloom and color corrections.We also support native stereoscopic rendering on PC.
PCGH: The lighting and art design of Trine 2 is just amazing - so what is your secret?
Juha Hiekkamäki, Frozenbyte: Our renderer allows artists to use a lot of dynamic lights for each frame. We also try to work together and add some features that would benefit the art. Beyond that, the secret is just our talented art team and the art direction they've chosen :-)
PCGH: You are using Nvidia's PhysX middleware for physics, do you already utilize SDK 3.x? If not, what version is used in Trine 2 and have you integrated any APEX modules? What is your option about GPU accelerated physics?
Juha Hiekkamäki, Frozenbyte: We are using 2.8.x version of PhysX and no additional modules. We decided to stick to the 2.8.x because we've been working with it for a long time and we know it very well, so we didn't want to switch to the just-released 3.0 version at the end of the development cycle.

For Trine 2, it makes very little sense to use GPU acceleration for physics, because with every PC configuration our graphics are heavily GPU limited. CPU is mostly idle, so in our case it's ideal to run physics on the CPU.
PCGH: Trine 2 uses FXAA (Fast Approximate Anti-Aliasing) so which version do you implement? Did you rework any parts of the FXAA code maybe improve sharpness, saturation or contrast?
Juha Hiekkamäki, Frozenbyte: We are using FXAA 3.9, we only changed some values to reduce the blurring effect very slightly. On PC, low graphics settings use console version of FXAA while Medium and above uses high quality default implementation (with gamma correction).
PCGH: One of the greatest features is Supersampling-Anti-Aliasing - in case it scales down a higher render resolution to native resolution, right? Did you integrate SSAA because traditional Multisample-AA is quite difficult with deferred rendering? If we apply SSAA and FXAA in which step will FXAA be rendered - before or after image downscaling?
Juha Hiekkamäki, Frozenbyte: Yes, our super sampling will render the frame in higher resolution and then scale it down to actual output resolution. It was implemented because Multisample-AA is not possible with deferred rendering using D3D9. With D3D10/11 it would be possible to use multisampling to generate G-buffers but in any case lighting would still have to be supersampled. Full supersampling will also help fixing shader aliasing, but it is not very efficient with higher sample amounts.

When combining FXAA and SSAA, we first render the supersampled image, apply FXAA and finally do a gamma-correct scaling down to target resolution. For example for 1920x1080 (1080p) resolution:

2xSSAA+FXAA will render 2550 x 1430 image, apply FXAA and scale it back to 1920x1080.
3xSSAA+FXAA will render 3180 x 1790 image, apply FXAA and scale it back to 1920x1080.
4xSSAA+FXAA will render 3840 x 2160 image, apply FXAA and scale it back to 1920x1080.
PCGH: What is about multicore rendering and worker job system? Does Trine 2 benefit from more than two CPU cores?
Juha Hiekkamäki, Frozenbyte: We don't have a real worker/task system in the engine. However, our middleware (PhysX, Wwise, Bink) can use more than 2 cores.

Picture gallery  (enlarge to view source)

--
Author: Marc Sauter (Feb 02, 2012)






Advertisement
Copyright © 2014 by Computec Media GmbH      About/Imprint  •  Terms/Conditions