Tuesday, July 7, 2020

DAF XF Unity Edition

We love any opportunity to cement our relations with truck manufacturers, especially if it means that we can bring new exclusive content for our #BestCommunityEver. So when DAF Trucks contacted us with an excellent idea to add their recently released Unity Edition paints for DAF XF trucks to the world of Euro Truck Simulator 2, we jumped right on board and started working on it.


Today is the day when we are ready to share the results with you. Get ready to spice up your Super Space Cab DAF XF with one of the fourteen new paint jobs - each of them related to one of the following 14 countries - Netherlands, Belgium, Turkey, Czech Republic, Poland, Germany, Slovakia, Spain, Portugal, France, Hungary, Italy, Austria, and Russia.



Because these in-game paint jobs reflect the unique customization to the specific DAF XF cab just as for DAF Trucks' customers in the real world, we've decided to add them to the XF Tuning Pack as a free update for this DLC. Existing owners of this expansion will receive these new country-based designs for the DAF XF Super Space Cab as additional free content via an automatic update.


As we also wanted to make a bit of a splash about this new content, and show our friends at DAF Trucks how engaged the truck sim community is, together we came up with a special cross-promotional "treasure hunt" mini-event across the web and social media. We are starting a giveaway campaign with 10,000 XF Tuning Pack DLC Steam keys. If you are ready to learn more about DAF and DAF XF Unity, the little Gleam.io widget below gives you access to the Steam key treasure hunt.


It's very easy, just follow the instructions in the special giveaway window below, complete the required steps, choose a few more or all of the optional tasks, and the key is yours!

To make it impossible for any codes-stealing bots, we have created a mandatory Treasure Code task as a kind of "I'm not a robot captcha" challenge. This should be simple to crack for our human players. We've created a few special screenshots which we have placed across the social media profiles of DAF Trucks N.V. (here and here) and SCS Software (here). These screenshots are showing some of the DAF Unity Edition paint jobs, but if you look closer, you will find three parts of the Treasure Code. Combine them, input them into the system on the "Enter Treasure Code" line, and it's done.

DAF XF Unity Edition Campaign
If you are a fan of DAF Trucks, are interested in real truck news, or simply want to help us improve our position in the eyes of the transportation industry, consider hitting the Follow button when visiting the social media profiles for DAF Trucks N.V. When pitching our games to prospective licensing partners, it is always useful to be able to prove that there is a sizable overlap between our player base and their customers.

Once you get your hands on these new paint jobs, make sure to take a screenshot of your new DAF XF truck in ETS2 and share it with the world! If you show us your screenshots and tag them with SCS Software's and DAF Trucks N.V.'s social media profiles under the #DAFUnityEdition hashtag, you have a chance to win some free merch! Our friends at DAF Trucks kindly sent us a few nice original DAF Trucks merchandise items to give away, and we are looking forward to rewarding the author of the best DAF Unity Edition screenshot! We will be monitoring all social media.

Sunday, July 5, 2020

Under the Hood: Explaining SSAO


Today we'd like to explain a new graphical feature that we are introducing to our games with update 1.38. The article is very technical - we have asked our programmers to help out, and the explanation is quite complex. However, we felt that it may actually be interesting for at least some of the people in our audience to be exposed to this material - to see that what is happening under the hood of a game engine involves a lot of research and hard work of our programming team. In addition to the technical details, we thought that providing the context and explaining the performance trade-offs may be useful and important for most of the players.

Jaroslav a.k.a.Cim 
(one of our brave and skilled programmers working on graphics improvements)


The TLDR summary of the text below is that Screen Space Ambient Occlusion is a cool new but performance-heavy technique to enrich the rendering of our game world. You do not have to use it if you feel it lowers performance too much for your liking, or you may like it and can afford to trade a few frames per second for improved shadow and depth perception. The effect may be subtle, it mostly works on subconsciousness level, but once you get used to it, it may be hard to go back. It is another milestone in our lighting/shadowing improvements plan that we are now executing, to be followed by new HDR light processing and introduction of more normal-mapped surfaces in upcoming updates.


The technique has its limitations and quirks. It has been used by several AAA games in recent years, and even if it's not perfect, it helps the human perception system to understand the scene better, and we hope that adding it to the technology mix of our truck sims is beneficial. We will no doubt want to introduce additional ways of shadowing computation that will improve or even supersede it.


We are under constant pressure to improve the looks of our game by a vocal subset of our fan base. At the same time, there is always a desire to make the games run faster. On top of these sometimes competing requests coming from the playerbase, our very own art department is ever eager to get hold of new graphical toys to make our game richer and better. Whenever we introduce a new graphical feature into the game, we try to do it in a way that doesn't hurt the performance for players with older computers, we don't want to make the game incompatible for our existing customers. That's why there is an option to switch SSAO off completely, and several settings for its quality/performance.


The work of our programmers on the new SSAO/HBAO techniques also required changes to our art and art creation pipeline. All the 3D models in our games had to be revisited by the art department, and any instances, where any fake shadows and darkening were already applied to a model by an artist, were changed. For some more complex game models, this was a simplification that actually reduced the number of triangles in them enough to improve rendering performance. To some extent, we have traded a part of tentative future manual effort that would be needed for building individual good-looking 3D models for an algorithmic rendering pass that unifies the shadowing look for the whole scene, helping to "root" objects like buildings, lamp-posts, and vegetation to the terrain.



What SSAO stands for and how it works


Before we start - note that SSAO is a general acronym for "screen space ambient occlusion". The name encompasses all of the various ambient occlusion (AO) techniques and their variants that work in screen space (it means that they obtain all information at runtime from data that are rendered on the computer screen and into related memory buffers). There is SSAO (Crytek 2007 tech that basically gave a general name to all techniques), MSSAO, HBAO, HDAO, GTAO, and many more other techniques each using differently tuned approaches, each having its benefits and downsides. We have based our approach on a horizon-based technique called GTAO that was introduced in a 2016 paper by Activision.

The ambient occlusion (AO) name part means that we evaluate how much of incoming light (predominantly sky light, but sometimes the computed occlusion gets applied also to other lights) gets occluded at a particular place in the game world. Imagine that you are standing on flat ground - you would see the whole sky above, so there is 0% occlusion, the ground gets fully lit by the sky. Now imagine that you are at the bottom of a well - you would see only a small patch of sky, that means sky gets occluded almost 100% and contributes only a little to the ambient lighting in that well, and naturally it is quite dark at the bottom of the well. A specific level of ambient occlusion at a particular place affects lighting computations and creates shadowed areas in creases, holes, and other 'complex' places. It can get anywhere between 0% and 100% based on their surroundings.


Computing the occlusion in high detail and precision is resource-intensive; basically, you would need to shoot rays from any evaluated position in all directions and test whether they hit the sky or not, and then average the result. The more rays you shoot, the better information you get but at a greater computation cost. This process could be possibly processed off-line, like when the game map gets saved by its designer. Some games and engines use this approach. But that way you are only able to bake ambient occlusion information about static non-moving objects because there are no vehicles, no animated objects present at that time.

So instead of baking static information (which would also take a lot of time and storage space given the scale of our world map), we want to compute it on the fly, in run-time. That way we can compute it also for interaction with vehicles, opening bridges, animated objects, and so on. There is a catch though. For such a computation approach, we only have data that are visible on the screen (recall "screen space"), so once some part of the game world gets out of the visible frame, it can't be used for occlusion evaluation. This limitation creates various artifacts such as disappearing occlusion on a wall originally caused by an object that just got behind the edge of the screen and thus became invisible not just for you but also for the algorithm, so it ceased to contribute to occlusion computation.


Ok, now we know what to evaluate (ambient occlusion) and we know what data we have (what we see on screen). What do we do? Well, for each pixel on the screen (that is 2 million pixels in HD resolution, times four(!) in 400% scaling!) our shader code needs to query the z-buffer value of its surrounding pixels trying to get a notion of the geometric shape of the area surrounding it. We can do only a limited number of these "taps" as there is a steeply increasing performance cost with increasing tap count, this is an operation that is really taxing the 3D accelerator. The limit on the number of taps, in turn, affects the ambient occlusion precision (and in certain situations may create inaccuracies and banding). Imagine that you want to evaluate your surroundings on a 2-meter straight line, and are willing to spend 8 taps to approximate it. You query the line every 25 centimeters, and any detail smaller than that may happen to be totally unnoticed unless you are lucky and hit it spot on (or unlucky, because you may miss it the next frame so the surroundings would suddenly appear to change between frames and cause flickering). The further your algorithm probes, the less precise it is. So you need to limit the size of an area you analyze around each game pixel which in turn limits how far the AO 'sees' - that is why it is not suitable for computing occlusion in large spaces like under bridge arches.


We have mentioned that the technique of our choosing is horizon-based. This means that we are not probing the environment by shooting rays in the 3D world, instead, we analyze a hemisphere above/around each pixel to see how far it opens up until it is blocked, how much light is let in by the surrounding geometry using the z-buffer as our proxy. The hemisphere is actually approximated by several runs along a line rotated around the given pixel. If we can follow along this hemisphere in full, there is no occlusion. If the algorithm taps a value in the z-buffer that would block incoming light, it defines the level of occlusion. The algorithm is optimized for performance but its limitation is that once it hits anything, even possibly a small object, it stops probing any further. This may cause an "over occlusion" problem and may be spotted as a visual artifact when some relatively thin object such as a traffic sign post causes strong occlusion on a nearby wall. You can try to detect such small objects and skip them, which in turn may produce "under occlusion" on thin ledges. We have opted for the former.


There is also another interesting and useful property of horizon based techniques. Depending on how much of a hemisphere above a given pixel is occluded, you can compute the direction that is least occluded. The amount of occlusion can be thought of as an ice cream cone with varying apex angle oriented in that direction. This direction is called a "bent normal" and we use it for various light computations like for occluding a reflection on shiny surfaces. The idea is that if you look at the surface and the mirror-reflected direction gets out of this cone, we consider it (at least partially) occluded, tuning down the reflection intensity. The best way to see that effect is to look at bigger and round chrome parts, like the diesel tanks, with SSAO on and off.


So you see, the idea is not that hard, for an expert graphics programmer anyway ;), but there is a lot of computation involved, putting quite some strain on the 3D accelerator. So we have created several performance profiles, each using a mix of optimization techniques:
  • Using less taps per direction - it is faster but lets AO miss bigger objects than with finer sampling.
  • Reprojecting AO results from the previous frame - it lets us hide the artifacts from undersampling, but may create ghosting when reprojection fails (when what you see between frames changes a lot).
  • Rendering in half-resolution - reduces the number of computations to 1/4 but creates less fine AO - the result may be slightly blurry shadowing
We hope that all this info was interesting and useful for you. We're sending you a virtual high-five if you read this article to this point. You deserve a cookie and a big cup of hot chocolate! If you still want to get more details about this topic, feel free to check for example this link.

Thank you for your time and support and we will see you again at some of the next articles from the "Under the Hood" section we bring for our #BestCommunityEver from time to time.

Thursday, July 2, 2020

Colorado: New Industries

Colorado boasts having some of the best wildernesses and mountain ranges in the United States, and from our previous research trip, it's easy to see why. However, while drivers are enjoying the scenery, we need to remember the reason for our journey! Let's take a closer look at some of the new key industries that will be arriving in our upcoming Colorado DLC for American Truck Simulator.


Being a state that promotes its natural beauty, Colorado is always looking at ways of using clean-energy to protect the environment. One of the many investments the state has made is into using windpower as a main source of energy. In fact, Colorado has one of the largest wind farms in the nation, with over 400 wind turbines generating enough power for 90,000 homes!


So it's no surprise that Colorado is home to the number one wind turbine company in the USA, with a highly trained workforce that builds more towers than any other facility in the world. With unique parts and equipment always on the move from the factory to wind farms across the states, we hope you will be a BIG fan of this industry.


Wind turbines might not cool you down on a hot day, but a cold bottle of soda will! Colorado is also home to a variety of bottling plants, each producing and distributing an assortment of different beverages which drivers can deliver to locations across the states.


Trucking isn't the only form of transportation to handle logistics however, on any given day more than 2,000 cargo flights are in the skies above America. Denver International Airport is the 20th-busiest airport and sees millions of passengers, packages, mail, and more, pass through its terminals and hubs every year. Drivers will play an important role in the transport of cargo to and from the airport, and with new arrivals everyday, you never know what you might be hauling next!


We are excited for you to check out these new industries in the future, but until then, if you like what you see, make sure to add Colorado to your Steam Wishlist! You can also check out our InstagramTwitter, and Facebook profiles for more exclusive pictures.

Tuesday, June 30, 2020

BIG In Idaho!

From wide open roads to larger sized trucks, everything in the American Truck Simulator world does appear to be a little bigger when compared with its European counterpart. However, one thing that does stay consistently large no matter where you are, is the size of our Special Transport loads!


In the upcoming state of Idaho for American Truck Simulator, owners of the Special Transport DLC will have 3 new routes to drive with the assistance of local law enforcement and escort vehicles. These routes are:

Boise to Grangeville
Idaho Falls to the Challis (near Salmon City)
Twin Falls to Nampa 


Each journey will come with its own challenges. So make sure to adhere to the GPS advisor and speed limit which have been set-out for you before your departure, as there is no room for mistakes!


If you are not an owner of the Special Transport DLC, be sure to pick it up whilst the Steam Summer Sale is still ongoing. You can find a wide range of our products from both our ETS2 & ATS catalog at a discounted price.


Also, if your excitement for Idaho is BIGGER than these loads, make sure to add it your Steam Wishlist! We thank you for your continued support and we can't wait for you to drive the roads of Idaho for yourself.