"Need to create" - Builder, accelerationist, and Founder/CEO at KeenSWH.com and GoodAI.com - Working on AI People and LTM, Space Engineers, VRAGE3 engine and Resilient Civilization
As you saw and heard during the online award ceremony on Thursday, February 15 on the Keen Software House Community Network on Twitch, which was hosted by Xocliw, we announced four category winners and many others were awarded for their great submissions. They all followed our rules to try to capture the original visual styling and feeling of the Space Engineers, moreover they all added their bit into their work.
Due to the low number of submitted entries, we have decided do not award winners in two categories, “Crash Test” Recreation and “Crash Creations” Recreation. However, the rest of the submissions were awesome. It was really difficult to choose from the total of 51 submitted creations. So with no more delay, here are the winners:
Congratulations to winners and big thanks to all who participated!
Space Engineers is still in development. Everything in the game is subject to change.
If you have any questions or requests, please do not hesitate to contact us, we will do our best to solve your problems.
We
would be also very happy if you can submit your feedback at our Space
Engineers Steam store page and encourage us to do better. We welcome
both positive or negative comments, it helps us to create better game
for you.
Thank you for reading and we look forward to seeing what you can engineer and come up with!
Marek
Rosa is the CEO and CTO of GoodAI, a general artificial intelligence
R&D company, and the CEO and founder of Keen Software House, an
independent game development studio best known for their best-seller
Space Engineers (2.4mil+ copies sold). Both companies are based in
Prague, Czech Republic. Marek has been interested in
artificial intelligence since childhood. Marek started his career as a
programmer but later transitioned to a leadership role. After the
success of the Keen Software House titles, Marek was able to personally
fund GoodAI, his new general AI research company building human-level
artificial intelligence, with $10mil. GoodAI started in January 2014 and has grown to an international team of 20 researchers. At this time, Marek is developing both Space Engineers and Medieval
Engineers as well as daily research and development on recursive
self-improvement based general AI architecture.
Motivation: playing Space Engineers should feel good
What we did: Massive overhaul of visuals, audio, wheels, and tons of other improvements
Replay & Offline rendering (our internal tool for recording ingame videos) used for the first-time
Nvidia Ansel
Render blog post - a guest post from Jan Hlousek, Keen Software House VRAGE Engine Lead
Wheels blog post - a guest post from Martin Pavlicek, Keen Software House Physics programmer
Better immersion => Happier Engineers
Official Russian language translation
With today’s major update, 1.186.0, we are releasing a massive overhaul of visuals, audio and wheels, together with a huge number of additional improvements to the core of Space Engineers.
The following video was all captured in-game, using our new replay and offline rendering tool (currently internal use only).
In this trailer we wanted to illustrate major visual, audio and wheel improvements. On top of that, we felt the need to create a new story-driven video from Space Engineers. This is the trailer I wanted to create since beginning of Space
Engineers idea - crash-landing of a large ship, repairing, and heading
back where it started.
We are encouraging all Space Engineers content creators (youtubers, streamers, modders) to start using these new visuals and to follow our original art style when creating new content, or even consider redoing past creations with these new capabilities.
Why is this important for us? Space Engineers was started with a very particular vision in mind and we want to keep it. It was authentic, unique at its time and made our game stand out. People loved it.
Space Engineers should feel good to play. Therefore, the major goal for this update is to enhance your experience by improving the way our game feels. Our new changes, including improved sound and visuals, make the game more realistic, more rewarding and ultimately more enjoyable.
The last major update brought an overhaul of physics. The current one brings massive improvements to visuals, the rendering engine, animations, audio (arcade and realistic), wheeled simulation, and much more.
Visuals are important, they mediate the first impression. Audio is also important, it’s adding the emotions (feelings, depth) to all interactive works.
Space Engineers was inspired by reality and by the “need to create”. The best way to enable both, is to try to think about how all the components in our game would work in the real world. The answer is: get as close to realism as possible, but not too much, so you don’t jeopardize the intuitive gameplay.
We are aiming for not only realistic physics, but also realistic rendering and audio.
Why now?
We are wrapping up things and the first-minute impression is
important. Polishing visuals and audio are things that you shouldn’t
keep for the finish line.
Moreover, there’s this “broken windows syndrome” where unfinished features signal that it’s OK that the
remaining features will stay unfinished. This is not a feedback loop we
want to encourage - not internally in our team, and not externally to
our community.
Visuals
Our original visual style was particularly designed to help players grasp complex geometries of their creations. For example, a low-frequency high-resolution texturing enables players to understand the surface more intuitively than high-frequency texturing would.
We always aimed for AAA visuals. Not only because they look awesome, but they also help to understand the surrounding in a more intuitive manner.
When we talk about visuals, we mean specifically: the rendering engine and its configuration, art, 3D models, textures, character animations, interaction with the world, particle effects, lighting, shadows, environmental ambience and reflection, the way we build and color template ships, etc. Everything that affects what you see and how you interact with the game.
Things in Space Engineers should look similar to what they would look like in the real life, if they were built with the technology of today. However, we didn’t want to just copy reality. We wanted to add something on top of it using our own artistic license, making it special and unique.
Visuals have been a top priority for me and the Space Engineers team during the last months - but the work on it had already started years ago. It was a long, continuous and gradual process. For example, this picture illustrates how the visuals of armor developed over time:
Left: original from Oct 2013 / Middle: later version / Right: new one from 1/2018
We tried to get back to that original armor look & feel - metalness, the feeling of heavy and strong steel.
The following three pictures illustrate the evolution of the basic color palette.
New GPU particle engine, so the game can render richer particle effects and a higher number of them at the same cost (before there were only CPU particles)
All transparent geometry rendering is now tweaked and aligned with the rest of the visuals
Almost 90 unique particle effects
Particle effects: explosions, thrusters, jetpack, bullet hit, crashes and collisions, damaged and destroyed blocks, meteorites, missile trail, dust from thrusters and many more
Debris after object damage and total destruction
Debris after voxels cut out or missile explosion
Gravity and physics influences particles, e.g. bullet hit sparkles will fall down in gravity, collide with the ground, bump up
Selected particle effects emit a point light (explosion, gun muzzle, bullet impact, etc)
Camera shake
Now there’s a very subtle camera shake whenever there’s a collision, near explosion, crash, player shooting or using a tool, falling or landing on feet, ship acceleration, etc.
It’s a very simple effect, but it adds one more layer of immersion
Armor
New high-quality armor edges, small and large. This is actually very funny because the original (temporary) triangle-like armor edges have been with us for a very long time, longer then I would expect.
Polished color palette - saturation and brightness. Back to original Space Engineers colors.
Glass
Artists designed the glass so that it looks good from both sides, renders proper dynamic reflections and subtle details inform the player that there’s glass present (absolutely translucent glass wouldn’t be visible, players would be hitting it all time)
Window block, ship cockpits
Depth-buffer clipping avoidance trick for tools and weapons in first-person mode
We had this feature in DX9 version of our render, but when we switched to DX11, we didn’t implement it
It’s now back again - basically it means that near objects (tool, weapon) are rendered with closer depth and thus don’t clip with the remaining geometry.
The result is that when you get close to obstacle, your tool or weapon won’t be clipping through it
It really adds depth to drilling, grinding and welding in first-person mode. It just feels so satisfying now!
The best part of this story: we originally estimated it will require 2-5 days of work on our render. But because we didn’t have this much time, Petr Minarik and Jan Hlousek managed to implement it in one hour! I wouldn’t believe if I didn’t see it!
Visual tweaks
Point light with proper attenuation (not so linear, correct specular contribution)
Suit headlight with proper glare, dust cone, correct light settings
Glares for all major light sources - thrusters, interior lights, spot lights, sun, etc
HDR - high dynamic range colors and lights, enabling higher contrast between dark and very bright light sources
Eye adaptation - when you move from dark place to a brightly lit open space location
Tone mapping
Bloom
HBAO - screen space ambient occlusion shader, adding little dark shadows to corners
New Skybox - almost monochromatic, very simple, coming back to our original skybox but without impostor asteroids, with dust and slightly bright to make the space not look so dark (players can change the skybox through mods)
Global illumination and dark in shadows/interiors now working much better
Cinematic feel (can be disabled)
Lens camera dirt
Vignette
Chromatic aberration
3D Models
Cockpit chairs - less rounded, more squared (fitting original art style better)
“Under construction” blocks have more metallic texture, less chrome, more matt, galvanized metal
Overhaul of Particles!
Driller Head metal material is now more metal shiny/scratched
Astronaut boots with proper stripe for magnetic effect
And many more
Gravity
Gravity for character is now more closer to real gravity on Earth. It may feel like the character is now falling faster, but it’s actually correct and also feels better - unlike the moon style gravity that has been in our game for the past year or two.
Original Space Engineers from 2013 had similar gravity as the one present in game in this update and we liked it this way
Character movement
Jetpack has faster acceleration and faster deceleration, the movement doesn’t feel slow and unresponsive. It’s easier to navigate in closer corridors and faster to travel longer distances.
Faster walk/run/sprint, closer to how it was in Space Engineers in 2013, and also how other first-person-games do it. Moving around now feels more responsive and satisfying.
Character animations
Polished all animations to feel more realistic
Character fall and landing animations - now finally with bending knees :-)
Landing from a jump
Landing from a fall (e.g. turn off jetpack)
Holding and using tools in first-person and third-person - now the hold is stabilized and the player feels more in control
Improved interaction between the tool and the environment (lighting, particles, sounds, timing)
Tools engage faster (after key/button press), not a delayed feeling anymore
Rifle shooting is now more precise
Movement cool down animation - when a character suddenly stops (because the player stopped holding the movement key), the character needs to blend from current movement animation to a stand-by pose. This transition needs to be quick, but it must look realistic. Other games usually don't have both first-person and third-person camera, so they can choose only one method to stop a moving character (fast or slow). In our games, both are possible, so we have to make a compromise - the game feels responsive in first-person mode (you don’t see your body), but movements blend nicely in third-person (you see your body).
Voxels
We reused our new voxel engine from Medieval Engineers for Space Engineers
Faster loading times: Easy Start Earth about 60% faster!
Instant changes/damage to voxels (e.g. explosion, voxel hand, etc): more than 400% faster!
Fixed a problem when drilling to the center of planet - discovered thanks to this video from farrell1701
Grass switching when removing voxels fixed
Doors
The basic interior doors open faster and with cooler sound effects
Better feeling opening and closing doors :-)
Other
Configurable LOD (level of detail) distance - for screenshots and offline rendering. Turn the LOD distances to extreme values (almost infinite) in Graphics Options by setting both Model Quality and Voxel Quality to Extreme. IMPORTANT: This setting is only for offline rendering and capturing screenshots and is not recommended for regular gameplay!
Bullet hit decals / bullet holes - now working on all surface with only one exception: deformed armor.
Planetary visuals and voxel/asteroid
This major update focuses on general visuals - mainly in space. We touched the planetary visuals a little, but it wasn't the main objective. In other words - we really didn't focus on planetary visuals. We focused on space things.
Audio
The audio in Space Engineers worked well, but after years of changes in all areas of the game, it was time to tweak and polish it all.
Space Engineers has two audio modes which can be set in world settings - arcade and realistic.
Arcade mode sounds are how they would sound if this was a regular movie, or if space wasn’t a vacuum. It’s the default option.
Realistic mode is how the sound works in real life. Sound waves travel only where there’s a physical connection between a sound source and a listener. The medium can be either the atmosphere or a solid object, and influences how you hear the sound: clearly or muffled / low-passed (through vibrations). The game simulates this property. The end result is that you won’t hear an explosion of a ship nearby if you are not standing on it. However, you will hear a muffled explosion and cracking of your ship if you are standing on its surface. This mode is very realistic and very cool. It is a must “hear” for all Gravity fans - see my older blog post.
What we did:
Small and large ship sounds - emphasizing feel of accelerating by adding additional sounds
HUD voices reenabled (e.g. “low energy” warning)
Footsteps retweeked and aligned with new speed of character movement. It also supports different ground materials (ice, rocks, metal, glass). Now you should hear and feel when you are running.
Footsteps also start sooner
Character landing/fall sounds are now more prominent, you should really feel it, this is very important for immersion and different surface materials
Polished where the sound listener object resides - before it was sometimes in camera and sometimes in the center of a ship. Now it's always in camera and the only exception is when you are piloting a large ship from cockpit - listener is in camera, but you will also hear sound of the ship
New sound when your character dies - very subtle, but giving you important feedback
Magnetic boots, on/off sound, different materials, you should really feel how they stick you to the surface
Character jumping sound - emphasizing the rubbing of textile, making the jumping more satisfying :-)
Ships colliding and crashing (and sliding and scratching)
Small ship cockpit - enter/leave sound - now has heavier sound, feels rewarding. You just want to keep entering a leaving the ship
Bullet impact on rocks has the standard wild west "pew" sound as it had in all our games. Must “hear” feature!
Max sound instances - reworked completely - this is when there are many sound sources close to the listener and it would negatively affect CPU performance to play them all. The game will start prioritizing sounds by distance and slowly turn of less relevant sounds. It is difficult to notice, but it helps with realism and CPU
Sound occlusions - if there’s an object between the sound source and the listener (you), the sound will be tuned down. This feels awesome!
Distance to sound source - this is an older feature but it’s so awesome that I must mention it: when the distance between sound and listener increases over a certain threshold, you will hear it a bit muffled and with “long distance effect” applied on it. Awesome for gunshots, explosions, etc.
Jetpack sound tweaked
Tool sounds tweaked, better timing
Decreased default music volume to 50%, so you can hear the sound effects better, but you can also raise it back to 100% if you want
Wheels
In 2013 we added a first barebone version of wheels. It was just an experiment, we didn’t know if this feature would be relevant for a space game. It proved to be quite important for our community, so we decided to implement fully fledged wheel/vehicle mechanics.
“The cars we drive say a lot about us. The cars we build say even more.”
Wheeled vehicles in Space Engineers should be strong, robust and endure more. They should enable effective off-road transport, be stable on most surfaces, and not slide or flip over unnecessarily. They should be stable under harsh physics conditions and stable in multiplayer.
“We all have a need to race. We also have a need to create.”
We are aiming for a realistic experience, but not to constrain your experimentation when building vehicles of your imagination. This is still a sandbox open-ended vehicular simulation.
What we did:
Changes in Terminal Screen
Reduced number of wheel/suspension settings - the game takes care of the details
Tuned default settings
Simplified for easier usage
Modified contact point response for wheels
No more wild voxel bounce-off and sliding
New wheel static friction simulation
Wheels will maintain expected path in turns, no more sliding
Progressive steering
Max steering angle is automatically adjusted based on car speed at the moment
Naturally reduces chance of car flipping
Dynamic center of mass changing
Center of mass for Wheel-Suspension connection is adjusted to further improve car behavior
Reduces chance of car flipping
Low friction mode for wheels
To maintain backward compatibility for existing creations
Air shock suspensions
Jumping vehicle will extend and strengthen suspensions in mid air to better absorb the shock impact upon landing and prevent damage of the chassis (example video)
Unsticking via jump
When your off-road adventure gets you into rough terrain and your car can’t get out of it (wheels are spinning, the car sits on its belly) - press X and the car will make a small or large jump
Wheels need to be in contact with ground. The car is using the suspension springs to quickly push itself up.
Acceleration / deceleration / stopping / braking
We tweaked the vehicle mechanics and configuration so that you will have the correct experience from your vehicle accelerating and decelerating
Braking and stopping the vehicle now has the right feeling as well as being more responsive, intuitive and enjoyable
Mass of a vehicle influences its inertia - e.g. heavier vehicles continue moving forward with more energy than lighter ones when left unattended with no braking force applied to them.
Cars feel more like real cars!
Different friction on different surface materials.
Fixed Multiplayer support for Wheels.
Increased robustness and endurance of wheel and suspension blocks - so they don’t break after jumps.
Replay & Offline rendering
This is a new internal tool for recording ingame videos. We used it to record footage for the newest update video.
This tool helps us in two areas:
Replay: With this tool we are able to record actions of multiple characters and ships in exactly same way as it was in Miner Wars 2081. You record the first character, then another and another, then a ship and another ship. You can then replay it all together and the final scene seems like multiplayer, or a well prepared cooperation. It is designed for our internal use for trailers for now.
Offline rendering: pre-recorded sequences can now be replayed in offline non real-time mode, where physics tick and render tick go in sync, one after another. Therefore, it’s impossible to get missed frames, lags, stuttering, etc. Because the rendering is offline, you can run it in higher resolution and quality. This is how we are able to get lag-free 4K @ 60 FPS scenes, no matter how complex.
It can be used for staging screenshot scenes with multiple ships and characters.
Offline rendering at 4K @ 60 FPS takes its time. Let’s do some math:
Our experience is that a 10 second shot at 4K @ 60 FPS takes approx 20 minutes to render
A 3 minute long video would then render for about 6 hours
You may be asking: but doesn’t the game run 60 FPS at 4K on my supercomputer? Yes that’s true, but the rendering generates and saves thousands of 4K lossless PNG images. This takes time. Hard drives have their latency and bandwidth (even after we upgraded to high speed SSD)
Just as an illustration:
If the game renders 60 frames per second, a 10 second shot will generate 600 images
4K images have 8,847,360 pixels
There are 4 bytes per pixel
So each 4K image is equal to 35 Mb
Therefore, a 10 second shot equals to 21 Gb of data
Another benefit is that the game can be render on Extreme graphic quality = no LOD switching, with very rich shadows.
The bad news is that this tool is for internal use only - mainly because it’s very hardcore, not user friendly at this moment and not all game features are supported it. We understand that this in the hands of our community creators would be a gold mine of great footage!
Official Russian translation
I am also happy to share with you, that we have added an official Russian translation of Space Engineers into the game. More than two hundred thousand Russian speaking Space Engineers players can now enjoy the game in their mother language. My big thanks goes to our community, but especially to Sergey Leonidov, our Keen Software House developer, who went through more than twenty thousand words in the game and did a proper review and correct translation.
Nvidia Ansel
We also worked closely with Nvidia who asked us to implement the support for their Ansel technology.
From Nvidia website:
NVIDIA® Ansel™ is a powerful in-game camera that lets you take professional-grade photographs of your games. Now, you can capture and share your most brilliant gaming experiences with super-resolution, 360-degree, HDR, and stereo photographs.
FREE CAMERA: Freeze your game for that perfect moment and reposition the camera for just the right angle. Ansel overcomes the limitations of traditional screenshot capture, giving you the power to capture truly unique photographs.
POST-PROCESS FILTERS: Adjust the look, feel, and mood of your screenshot. You can even add filters or manually adjust brightness, contrast, or other options to suit the mood.
What we did:
Using Ansel, players can capture screenshots in default resolution, super resolution (similar to multiplier we already have, but without limitation on GPU memory, as it captures screen in multiple small tiles, so the limit is 64k resolution), stereo screenshots, 360 degrees (up to 8k resolution), and 360 degrees stereo.
Enabling Ansel by pressing Alt+F2 shortcut will pause the whole game (even particles). The player then has the ability to set the camera position / orientation / roll precisely how they want it along with other properties such as field of view (FOV).
Before taking the screenshot, the player can add a filter (b&w, half-tone, retro, sepia), adjust various post-process effects (sketch, color enhancer, vignette, vibrance, contrast, brightness) or enable / disable HUD.
--------
The following technical post goes into great detail about the changes
that were made to wheels. It was written up with diagrams and videos by
Martin Pavlicek, one of our programmers here at Keen Software House who
worked heavily on this iteration.
Wheels
by Martin Pavlicek
You've been asking us over and over again for a long time now, and today we are really proud to bring you entirely new physics for wheels. We've been working extremely hard to make driving of all wheeled designs in Space Engineers a really pleasant experience, and we hope that you'll enjoy the new driving, at least as much as we enjoyed making it.
In next few paragraphs I would like to familiarize you with some of the steps we took to make the driving great again. So without further ado let's jump right on it.
Static friction
One of the main issues you may have immediately noticed when driving old wheels was the fact that they weren’t actually steering the car at all. Even at high friction setting the wheels would slide sideways on rock solid surfaces. Keeping to the track while turning was basically nonexistent. This wasn’t really the behavior one would expect from rubber-tyred wheels, so we focused on this and made steps towards creating tires that better reflect real world behavior.
When working on this issue we found out pretty soon that the reason for this unexpected behavior was missing so called “static friction.” The tires were basically not making any resistance when forced to slide sideways during turning or on steep slopes.
In order to fix this issue, and make the wheels behave more naturally, we introduced a new system that will watch the state of each tire on your car and dynamically simulate the static friction on each wheel, making your car (or any wheeled design) behave more naturally, as one would expect in real world.
Before
Now
Dynamic center of mass
The vision of Space Engineers is to be based on reality, however sometimes we found it necessary to sacrifice elements of realism for improved gameplay. Immediately after making the cars turn by the system described above, we noticed that it's actually quite difficult to drive common designs one can find in our workshop. Blocks in SE are large and quite heavy, which ultimately makes heavy cars with a high center of mass. Combine this with the high speed that you are usually driving in our game and you'll get a car flip in every second turn.
Space Engineers player: "I drove my car only 70m/s on a flat planet surface and my car flipped over while turning. This doesn’t happen when I drive in real world. Literally unplayable."
Keen support: "Sir, can you remember when was the last time you drove your 15 ton truck 250km/h on a field?”
It's really boring to drive at a realistic 20m/s. and while it's perfectly physically accurate to make your car flip when driving faster than that on an uneven surface, it's not a really good user experience and we know it.
For this reason we introduced another system that will dynamically adjust the center of mass of your designs for force impulses that come from wheels to the car chassis. Keep in mind that the behavior of other forces acting upon your grids, for example impacts of other objects, will remain the same. This change will take place only when wheel interaction comes into play.
This will allow you to make more sharp turns in higher speeds, without risking a flip over.
While the system helps, keep in mind that it's intentionally limited, so that your design still matters and the engineering aspect of the game stays preserved. The better you build your car, the more you get out of it in terms on driving properties and gaming fun. See section best practices below for more info on this topic.
Adaptive steering
It's natural for drivers in the real world to adjust the amount of steering they apply based on speed, driving surface and mass distribution of their car. If they miss-judge these, they will end up drifting their car or worse they'll flip it over.
The same applies for our game, so we implemented a system that will take these properties into account and adjust the maximal steering angle based on current conditions. This will further help you avoid accidental flip overs and make your driving experience even better.
Physics surface materials
Another new feature we are introducing to Space Engineers in this update are physical material properties for voxels, like lateral and forward friction. This does not apply to wheels only but it's related to all contact with voxel surfaces. From now on you will notice that ice is much more slippery than grass, which is more slippery than a rock. Physical restitution is also a thing now, so solid rock is more bouncy than grass for example.
Enjoy your ice cold lake drifting!
Surface bounce-off
One might have noticed on old wheels, and it eventually came even more obvious with new wheels, that the voxel surface is actually not really flat. In physics it's represented by a triangular mesh and driving on such surface at high speeds can be quite bumpy as the wheels are hitting different surface triangles.
This made the driving experience quite unpleasant at high speeds and from time to time cars started to unpredictably jump off the surface.
To combat this issue, we are modifying the contact points between the wheel and the driving surface in real time to imitate a “flat surface” and smooth out the driving as a result.
Impact absorption (aka AirShock)
To further improve your driving experience in challenging terrain we are introducing the so called AirShock system. It is designed to automatically detect situations when you are about to land hard after a large jump and temporarily increase the impact absorption properties of suspensions, namelly suspension spring strength, dampening and height offset of wheels. The amount of energy absorbed is obviously proportional to the number of wheels that are in contact with the ground at the moment of impact, so keep that in mind while designing your cars. The more energy that is absorbed into the suspension system, the less chance that you'll strike the ground with your belly.
Braking and Air friction
High speed driving is fun, but sometimes one also needs to slow down, or eventually stop. That's why we simply could not forgot about the braking system. We paid close attention to make braking as responsive and strong as possible, while keeping it within the boundaries of realistic expectations. With a little bit of artificial stabilization, to compensate for higher center of mass, than is usual in real world designs, the overall feeling from this part of driving felt really satisfying to us. We hope you'll feel the same way when you try it for a first time.
Hand in hand with manual braking there is also other force that is usually making cars stop in real life. It's called air friction and we are adding it for the cars in this update too.
One minor issue, but huge quality of life improvement, which we solved along the way is a (parking) brake issue. Wheels will now correctly steer and suspensions will stay functional while the brake is engaged.
Jumping
When it comes to off road you never know what trouble you might encounter on your journeys, so it's better to be prepared for anything. If you get stuck in a deep bank, and can't get out using conventional methods, you'll definitely appreciate the new jumping feature. By using suspension springs as a device for vertical emergency propulsion, you'll be able to get yourself out of any trouble. And if not, well, you are engineer after all, so use your skills and engineer your way out of the trouble.
Simplified terminal
There used to be huge amount of sliders and other settings in terminal for wheel suspension block which were actually used by a small percentage of players. Most of players were probably scared of that wall of sliders :)
We decided to reduce the number of rarely used setting here in favor of a simpler user interface. Some of the setting are now automatically handled by the game in real-time and some of the less important ones are set to good defaults and changed only when needed.
Improved multiplayer (By Sandra Lenardova)
As you know, wheels in multiplayer used to bounce around a lot and never moved straight. This was mostly because wheel position corrections from the server kept putting wheels underground. Our solution was to significantly tighten position corrections for cars, while simultaneously significantly loosening corrections for wheels. In fact, wheels are not corrected from the server at all at high speeds, relying solely on wheel constraints on the client. At lower speeds, we no longer correct wheels on their suspension axis. The result is an experience comparable to driving in singleplayer.
Best practices
In this section I would like to point out a few tips that will help you get the most out of the new driving model.
Low center of mass: When designing your vehicles, keep in mind that overall mass and the center of mass matters. Same as in real life, the lighter your car and lower its center of mass, the shaper the turns you can take without risking a flip over.
The more mass, the more wheels: Wheels are usually the only parts of your car that have contact with the surrounding environment. This means that they are the main contributors to overall vehicle acceleration and braking. The more mass you wish to accelerate quickly or stop, the more surface contact you need to make it happen.
Also the more wheels you have, the more points there are to support all that mass in turns, improving your chances that you will survive the next sharp turn you take in one piece.
Adjust your suspension to your needs: While the game handles a lot of the driving model parameters on its own, there are still some that are dependent on your personal preference and might both improve, or ruin, your driving experience when set up incorrectly.
First of those is suspension strength. This parameter sets the stiffness of the main suspension spring. For general driving we recommend setting it to low, so it correctly leans into the turns and helps the car in natural turns without having the tendency to flip over.
On the other side there are some engineers that will benefit from a stiffer setting when building low profile sports cars or heavy duty trucks. It might be important for them to make the suspension more stiff to improve the behavior in these cases.
Another rather important setting is steering angle. There are basically infinite amounts of configurations that you can use your wheels for in various designs. It is next to impossible to make a software that would correctly recognize all of the configurations and set your wheels to correct steering.
It's in your hands to engineer correct angles for your wheels.
Each and every one of us has different feelings and needs for specific designs, about how fast a car, or any other wheeled design, should drive and how fast it should accelerate. Some like it when wheels squeal when they press the gas, while some like a smooth controlled launch. For this purpose there is a Power slider in terminal which will allow you to tune the power of wheel propulsion to exactly fit your needs and make it feel right.
We know that wheels are used not only for cars but there are a variety of use-cases for them including a role of sliding pad for example. Even though wheel mechanics changed deeply during the process, we wanted to preserve this functionality and make sure all the great creations on our Steam workshop stay intact. That’s why we are keeping the Friction slider in suspension terminal even though it’s functionality has changed quite a bit now. For old blueprints the game will automatically distinguish between wheel and sliding pad functionality and set appropriate friction settings. Default values chosen by the game should work for the vast majority of you, but just in case you need some special setting the slider is available.
Enjoy your new driving experience and remember, safety first!
--------
The following technical post goes into great detail about the changes that were made to render engine, art and visuals. It was written up with diagrams and videos by Jan Hlousek, Keen Software House VRAGE Engine Lead
Visual Tweaks
by Jan Hlousek
Work on this update started a year ago, when we decided to convert the game to full HDR rendering. At first, we had to make sure the lighting pipeline does not clamp the intensities, then we added automatic exposure adjustment (eye adaptation) and HDR bloom effect, which is essential in communicating bright areas of the screen. The result itself blew our minds: exposing details in dark areas, interiors and undergrounds, while keeping bright areas feeling believable.
So we decided to go full production, reworking all parts of the renderer and artworks to HDR, sometimes even adjusting gameplay. And now we are happy to present you the results of this long endeavor. I hope you will appreciate it at least as much as we did the early HDR prototype.
Let me share with you some of the challenges we experienced along the way.
So what does it take to deliver an HDR image to your monitor? As we use deferred rendering, the geometry part of the pipeline filling the g-buffers stays more or less untouched. Once we have g-buffers prepared, we start our lighting pipeline by accumulating results of each light to a so-called light buffer. Unlike in LDR rendering, where all the rendering is bound to the 0-1 range and anything higher will just end up pure white, HDR rendering has a wide range of intensities of all the lighting contributors. Below are the ranges we settled on in the end:
Sun: 150
Atmosphere: 17
Clouds: 17
Emissive textures: 0 - 40
Spot lights: 4 - 40
Interior lights: 1 - 20
Skybox: 5
Fig.1: Various lighting conditions and their histograms
In order to be able to work with such a wide range of values, the lighting buffer has to be in floating point format.
When lighting is done, we can not just send the image to the monitor, as most of the monitors are still operating in 0-1 range (LDR) and most of the image would just be a saturated mess:
Fig.2: HDR image displayed without exposure correction and tone mapping
Therefore, we have to scale the ranges of the HDR image to LDR range. This is done by applying exposure correction, similar to that seen in photography. And as in photography, we have to find out what value of exposure to use, as the image intensities may vary wildly.
Every frame, we start by analyzing the light buffer and creating a histogram. Based on the histogram we can find the optimal exposure, the same as with a real camera, and apply it on the resulting image. This process is actually quite complicated. Imagine having an uber effect in photo editing tool that would help you fix the exposure of any picture to something perceived as aesthetically pleasing, making sure the result is not either under-lit or over-lit and still fits your creative vision. It’s a job worthy of AI. Although at times, we toyed with the idea of employing our GoodAI colleagues’ technology in this task, in the end we improved the exposure detection algorithm to the point where it is giving very good results.
The Histogram consists of the pixel luminance values accumulated into multiple bins (vertical lines), containing the amount of pixels in its luminance range. The Histogram of the scene above looks like this:
Fig.3: Histogram of Easy Start Space
We are prioritizing the pixels in the center of the screen and de-prioritizing the skybox pixels. We find the bin with the highest amount of pixels, ignoring 25% of the darkest and 2% of the brightest pixels. If such a luminance bin is outside of the allowed area (in the histogram visualised as green), we will clamp the resulting exposure. If the picture has most of the pixels in those areas, we clamp the resulting exposure and won’t adapt further (so we won’t make the picture too bright in the dark for example). The actual exposure is animated in time, always converging to the exposure detected from the histogram, with faster adaptation to light and slower to darkness. After applying the exposure the image looks like this:
Fig.4: LDR image after applying exposure correction and tone mapping
Bloom effect is essential in HDR rendering to communicate bright areas on screen on LDR monitor. See this image without bloom, you can not tell the bright spots from the medium ones.
Fig.5: Image without bloom highlights
We had to improve the bloom effect and get it on par with the rest of the game’s visuals. The bloom shader consists of three stages: filtering out the image (bright pass), blurring it, compositing it back to the original image. We had to make the bright pass filtering luminances based on the current value of exposure, as we don’t want for example screens to glow in daylight. We made a new blur pass, which allows us to have much wider kernels. Compositing is later done in tonemapping.
Fig.6: Image with bloom highlights
As the first thing after creating the HDR prototype, we realized we needed to update our global illumination solution. Global illumination is the system responsible for bouncing the light from one surface to another, transferring the intensity of the light and color properties of the material:
Fig.7: Global illumination exercising red color bleeding over white surfaces
There are various systems which can solve global illumination, but most of them need precomputing static data in build time or have a huge impact on performance. In Space Engineers, the environment can change significantly at anytime, so we can not really precompute much data in advance. We also didn’t want to sacrifice high performance for realtime global illumination.
In the end, we settled with the simple trick of rendering the surrounding of the camera to HDR cubemap and using it as a source for global illumination for close proximity pixels.
Fig.8: Environment probe cube map
For distant pixels, we are using just skybox / atmosphere if it is not obscured.
We have also noticed artifacts in the lighting, which were caused by simplistic attenuation. Attenuation is a light decay over the distance travelled. Modelling attenuation properly we ended up with this result:
Fig.9: New attenuation in effect
We chose different attenuation for diffuse and specular lighting. We wanted specular to be visible in most of the range of light and to attenuate diffuse realistically.
Fig.10: Diffuse attenuation with different falloffs and Specular attenuation
Next in line was a transparent pipeline. Most games render transparent geometry in LDR and just compose them with an HDR image after applying exposure. We wanted to have coherent lighting, ambient, emissivity and bloom on particles, as in the rest of the game, so we decided to go HDR. That meant redoing the rendering of all transparent objects.
We started with particles and decided to go all in and rework them from scratch. We recreated all the particle texture atlases (this time in 8K instead of 2K) and particle setups, adding lots of functionality to our particle system along the way, to get it on par with the rest of the game’s quality.
Fig.11: HDR particles
We wanted particles to look believable in all lighting conditions - an underground passage without any light should have bright flames and black smoke. On the other hand, a burning block on a lit platform should have a nice volumetric smoke based on the direction of light. In order to achieve this, we had to rework the lighting of particles and let them use global illumination.
Next we wanted to improve glass shading. We have used same lighting formula as for standard blocks, to achieve the dirt on windows to be accentuated in specular angles, as well as indirect lighting matching the tint of windows dirt to the color of the surroundings.
Fig.12: Glass with lighting and gloss based reflections
For reflections, we use an environment probe cube map for indirect lighting. It is updated every few frames and then blended on top of the previously rendered probe because of performance reasons. For lighting it is perfectly fine and helps smooth out transitions of lighting conditions. For reflections it is not looking perfect (eg: ghosting effect of the blended reflections). We have added a gloss map to achieve variably blurred reflections and hide blending of the probe.
For new effects like vignette and chromatic aberration, we use a subtle barrel distortion applied on each color channel separately (with different distortion) and reduced color intensity the further it is from the center of the screen. Colorization shader was a difficult case to solve. Space Engineers was released in 2013 with a wildly different renderer based on DX9 technology. We switched to DX11 rendering 3 years ago. While converting renderer from DX9 to DX11 multiple design decisions were made, like completely changing the texture layout for models. In DX9 magenta color was used in color texture to let the shader know which parts should be colorized. In DX11, it was changed to a more convenient half-gray color, which removed magenta color bleeding artefacts. This was a good call. As DX11 was a prototype at times, we decided to adjust colorization later, as there were higher priorities. So from the very beginning of using the DX11 renderer, we had inaccurate colorization in place. Not only was it displaying wrong colors of grids created in DX9, it also reduced the ranges of colors that could be used.
Fig.12: Washed out DX11 coloring
Fig.12: Fixed DX11 coloring
And now we got to finalize it. It was a tough call. On one hand, we will have a wider range of colors at our disposal and the original color palette and grids created in DX9 will start to look as intended. On the other hand, carefully selected custom colors used in players creations made on DX11 render may change significantly.
In the end we decided to go with this change as, from a long term perspective, it had many benefits. We hope you will appreciate it.
Last but not least we integrated nVidia Ansel technology, which is essentially a spectator camera in paused world able to capture stereo, 360, HDR and multi-res screenshots.
Fig.12: Ansel 360° capture
Once Ansel is started, it takes over the controls. It lets us know the camera properties and we can override the in game camera with them. Capture itself separates the image into a grid, then tells our renderer to render each cell of such a grid separately. Later Ansel stitches all the rendered images into one huge image. Rendering of each cell needs to preserve the projection of the original image using an asymmetric projection matrix. All render systems had to be revisited and made compatible with such a rendering approach. In the end, we support all the features Ansel has to offer and you can take images up to 64K.
---------
Comparison - before & after this update
For those who are curious about the comparison of the state before and after this update (v186), we are sharing some data in following text. The testing have been performed using following setting: High (16GB DDR4, GTX 1070: 8 GB VRAM, 1080p). The pictures on left represent v185 (previous build), the pictures on right represent v186 (newset/current build).
To express our value of our community and players we added a Welcome screen for everyone who runs Space Engineers for the first time. There is a message directly from me.
Quotes and reactions from our community:
“It feels so good to be able to drive around a crater on the moon and have the wheels actually work over hills, and get realistic suspension response. Not only that, but you don't have to fear clang when you catch some air.” - Phoenix84
“If you're KEEN on some hot new deals, come look at our shiny new wheels” - NikolasMarch
“The new suspension wheels are great, just don't try to jump to the moon. For your own safety and sanity don't try jumping with a trailer attached.” - GrindyGears
“I'm not the most advanced vehicle builder out there, but it was such a pleasure to finally be able to make a truck and have it just work as I'd expect it to. Now I need to learn not to drive my vehicle into a ditch.” - Malware
“No longer being shackled to flat plains and slight hills I have been able to explore and discover new locations that were previously unreachable if you were stuck on the ground”- DoctorOctonagopus
Questions and Answers
Q: Does this mean you've polished all visuals, fixed all the bugs, optimized every use-case and the game is finished? A: Not just yet. We have made very good progress in the last couple of months, but there is still more to come! Stay tuned for more updates!
Q: I liked the visuals from before this update A: We are upholding the original visuals from the Space Engineers launch, circa 2013. These new visuals are just pushing it more towards triple-A quality where the game belongs.
Q: Are these new visuals taking up more performance? Did the game become slower? A: No. There were actually performance improvements during this visual update. On top of that, our QA (quality assurance) process is doing both manual and automated comparison of the game performance in selected scenes. We would know if the performance gets slower (CPU, GPU, memory).
Q: I really hate the bloom / vignette / flares / chromatic aberration etc. Can I disable them? A: Yes. There are options in the Graphics settings screen called "Enable PostProcessing" that let you decrease flares intensity or disable post processing effects like bloom etc.
Q: I want to disable eye adaptation / have more saturated colors / have darker shadows. Can I mod the game’s look? A: Yes. All settings are data-driven. You can tweak the settings in the Environment.sbc file and upload it as a mod to share it with other players! You can even use debug build from MOD SDK to tweak the settings in real-time through debug screens.
Q: I am used to the old blueish skybox. Can I have it back? A: Not in vanilla steam game as the current skybox is part of the game’s original vision. But you can use custom skyboxes through workshop as a mod. We released old blueish skybox to workshop as well: http://steamcommunity.com/sharedfiles/filedetails/?id=1286315367
Q: Can nVidia owners use Ansel to cheat in multiplayer? (i.e. observe interiors of my base) A: No, we implemented similar restrictions as to spectator camera. When spectator camera is disabled, you won’t be able to move with camera in Ansel. But you can still acquire Ansel captures from anywhere you get to with your character.
Feedback
If you have any questions or requests, please do not hesitate to contact us, we will do our best to solve your problems.
We
would be also very happy if you can submit your feedback at our Space
Engineers Steam store page and encourage us to do better. We welcome
both positive or negative comments, it helps us to create better game
for you!
Conclusion
I am super happy with the work our team has done and super excited to share it with you all!
Space Engineers now looks and feels the way we have always envisioned.
As Space Engineers is still under major development, there may be bugs (our testers spent hundreds of hours testing, but this is nothing compared to tens of thousands of hours played by our community immediately after every update). Nevertheless, we will do everything we can to fix any issue as fast as possible.
I truly enjoyed working on this update, it took a lot of hard work and determination, the whole process consisted of over 600 tickets (work tasks) for me and my team! It has been been my main priority over the last few months and the whole process been an absolute pleasure.
Space Engineers is still in development. Everything in the game is subject to change.
Thank you for reading and we look forward to hearing your feedback on this update. For full list of new features and improvements continue to https://forum.keenswh.com/threads/7399609
Marek
Rosa is the CEO and CTO of GoodAI, a general artificial intelligence
R&D company, and the CEO and founder of Keen Software House, an
independent game development studio best known for their best-seller
Space Engineers (2.4mil+ copies sold). Both companies are based in
Prague, Czech Republic. Marek has been
interested in artificial intelligence since childhood. He started his
career as a programmer but later transitioned to a leadership role.
After the success of the Keen Software House titles, Marek was able to
personally fund GoodAI, his new general AI research company building
human-level artificial intelligence, with $10mil. GoodAI started in January 2014 and has grown to an international team of 20 researchers. At
this time, Marek is developing both Space Engineers and Medieval
Engineers as well as daily research and development on recursive
self-improvement based general AI architecture.
