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.
You can find the changelog listing all the new features, tweaks and improvements on our forums: https://forum.keenswh.com/threads/7399609
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.
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 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.
|Left: Basic armor palette (2013) / Middle: Prototypes (2017) / Right: Current look (2018)|
Depth-buffer clipping avoidance trick for tools and weapons in first-person mode
Planetary visuals and voxel/asteroid
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.
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.
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 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.
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:
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:
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!
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.
We also worked closely with Nvidia who asked us to implement the support for their Ansel technology.
From Nvidia website:
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.
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.
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.
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.
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!
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.
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.
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.
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!
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:
|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.
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).
Easy Start Earth:
v185 committed memory: 8,9 GB
v186 committed memory: 9,2 GB
v185 sim speed: 1.00
v186 sim speed: 1.00
v185 FPS: 75
v186 FPS: 90
|Easy Start Earth; v185 – v186|
Easy Start Space:
v185 committed memory: 6,6 GB
v186 committed memory: 6,8 GB
v185 sim speed: 1.00
v186 sim speed: 1.00
v185 FPS: 120
v186 FPS: 120
|Easy Start Space; v185 – v186|
v185 committed memory: 6,1 GB
v186 committed memory: 5,6 GB
v185 sim speed: 1.00
v186 sim speed: 1.00
v185 FPS: 83
v186 FPS: 120
|Star System; v185 – v186|
v185 committed memory: 5,2 GB
v186 committed memory: 5,8 GB
v185 sim speed: 1.00
v186 sim speed: 1.02
v185 FPS: 120
v186 FPS: 120
|Empty World; v185 – v186|
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:
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.
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
I am super happy with the work our team has done and super excited to share it with you all!
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.
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
For more news:
Space Engineers: www.SpaceEngineersGame.com
Medieval Engineers: www.MedievalEngineers.com
General AI Challenge: www.General-AI-Challenge.org
AI Roadmap Institute: www.RoadmapInstitute.org
Keen Software House: www.keenswh.com
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.
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.