Space Engineers

[Drax]

DAT planetary teaser...

 

[Hellraiser]

DAT planetary teaser...

Better look at this week's planetary teaser:



KSP could use some of that.

 

[Drax]

Yeah it's looking better each week.
I wonder, tho, how much of an impact on performance will we suffer to have dem planetoids.

 

[Drax]

PLANETSPLANETSPLANETSPLANETS

 

[ERYFKRAD]

Aw yiss.

 

[Turjan]

Cool. It's only missing some red, orange and yellow dinosaurs now.

 

[Tabs]

Used to play this quite a bit. Now my PC cannot run it at all. I'm talking <5fps even at lowest of the low settings. Really too bad since planets seem fun.

 

[Perkel]

Well since they added planets i considered to finally play it...

Who the fuck designed that UI ? Dwarf Fortress compard to this is best UI ever.

You have i for inventory which seems nice but you need to use second hand to get to it (wtf ?)
Then you have T which does things
Then you have K which also access inventory but things not yours
Then you have G which is whole ui to customize toolbar and apperently i need to use it to build anything
And that is just 15 minutes of first tutorial.

I have things in toolbar which i can't even choose for some reason.

Gonna try that again in hour. I need to walk out and steam off.

 

[Drax]

Bro, forget the tutorial, just open a default scenario and start trying out shit, you'l learn the basics way faster.
The UI is awkward in parts but once you get use to it is pretty practical.

 

[someone else]

70% off should I get this fanboys and haters? I'm a singleplayer.

 

[Drax]

Yes.
(If you like sandbox and making yer own space stations and ships and landers and rovers and killing space bugs)

 

[Zewp]

Does it have enemies in now? I haven't played in a while. Would be pretty cool if they put in randomly generated aliens. They'd be offering more than No Man's Sky and actually be a fun game.

 

[Quigs]

Used to play this quite a bit. Now my PC cannot run it at all. I'm talking <5fps even at lowest of the low settings. Really too bad since planets seem fun.

Yeah, they did that free weekend a few months back and I gave it a shot. Unplayable slowdowns, though flying full speed into a planet was kinda cool.

 

[Kev Inkline]

Used to play this quite a bit. Now my PC cannot run it at all. I'm talking <5fps even at lowest of the low settings. Really too bad since planets seem fun.

Yeah, they did that free weekend a few months back and I gave it a shot. Unplayable slowdowns, though flying full speed into a planet was kinda cool.

The cpu demands of the game are, if you run a multiple planet system, well, astronomical.

 

[Quigs]

Used to play this quite a bit. Now my PC cannot run it at all. I'm talking <5fps even at lowest of the low settings. Really too bad since planets seem fun.

Yeah, they did that free weekend a few months back and I gave it a shot. Unplayable slowdowns, though flying full speed into a planet was kinda cool.

The cpu demands of the game are, if you run a multiple planet system, well, astronomical.

It's just a design mistake. Everyone would prefer an occasional zone load to not playing the game at all. I was hoping for a 3d Captain Forever, and got derpy space minecraft.

 

[Drax]

You can setup the scenario to have very few or none planets if those are killing yer pc. Although they are slowly improving the performance and efficiency of the engine with each release.

 

[Xor]

I bought this the other day and spent most of last night playing it with a friend. It's pretty fun so far, we built a mining and welding ship and are in the process of setting up a mountain fortress to hide from meteor showers after one took out our first refinery.

 

[Volrath]

Got it through the steam sale, thank you Codex

 

[Drax]

I bought this the other day and spent most of last night playing it with a friend. It's pretty fun so far, we built a mining and welding ship and are in the process of setting up a mountain fortress to hide from meteor showers after one took out our first refinery.

Nothing like that first time you see your shinny station get blown by a comet.

 

[ERYFKRAD]

Thing just keeps loading forever.

 

[Runciter]

This has just had a major update which reportedly fixes physics-related issues which have hounded the game for years.

Space Engineers: Major Physics Overhaul


SUMMARY:

• Massive physics overhaul
• Pistons, rotors, landing gears and more
• Grid deformations - Improved, optimized, tweaked and balanced
• Optimizations - Less lag, more fun
• Improved subgrid behavior and fragility
• Stronger constraints for mechanical blocks so they don’t break so easily
• Less Clang, more engineering

With today’s major update, 1.185.0, we are releasing a large overhaul to the physics in Space Engineers. The update is primarily focusing on pistons, rotors, landing gears, and grid deformations.




The original vision of Space Engineers was to build a game where physics behave exactly as in the real world. We wanted players to be able to transfer their intuition from the real world to the game world. Things in Space Engineers should behave exactly as one would expect them to behave in real world. There shouldn’t be things that look like they can do something but actually cannot and are there just for visual effect. We wanted to create a game where there are no limits in what players can create.

Just as an illustration: in Space Engineers we have practically infinite worlds, players can seamlessly travel from planets to moons to asteroids, they can build and destroy everything that’s in the world, they can dig through the entire planet which are huge -- up to 120 km, players can build kilometer-long ships while being completely destructible. Ships and stations have their own mechanics - pistons, rotors, thrusters, gravity generator, conveyors, programmable computers and many more.

On top of that, everything is destructible, deformable, recalculated in real time, different blocks have different strength, gravity and other forces push on objects, ships crashes and collisions feel like in real world. We consider these to be the core elements of Space Engineers.



This has been a top priority for me and the SE team during the last year - to have these things be as robust, stable, and intuitive as possible.

The game’s physics are now more stable and creations shouldn't break, explode or
do uncontrollable things under normal conditions with default settings. But if players override safe parameters (via mods or in-game sliders) and really push our engine, things may get uncontrollable. However in general, the physics will now remain stable even under much more stressful conditions than before.

In other words, Space Engineers physics are now very stable and robust.

What is the worst case scenario that can still happen in game?

Setting max piston forces to very high values can cause clanging, as well as connecting grids with multiple constraints like a square array of connectors or a long chain of pistons.

I am very proud of what my team has achieved in this major update!

Honestly, I don’t think any other group has done more in the realm of real time large scale interactive physics volumetric simulations. No other game or software project is facing these kind of challenges on this scale.

We are pushing the frontier and defining the limits. It's a hard and painful process, but occasionally there are days like today, where we are happy to present our latest iteration!

Because Space Engineers is still under 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 to fix any issue as fast as possible.

Disclaimer: This major update focuses on physics, not multiplayer. Although, the latter has received huge improvements as well. There are still situations in multiplayer where players can push physics to the limit and break the game. Our next focus will be these edge cases.




Teaser of future physics/multiplayer improvements: This video shows the Sacrificial Offering for Almighty Lord Clang in multi-player, with 500ms simulated ping, proper predictions, no cheating.
However, the game should be stable under default conditions, both in single-player and multiplayer.


This is a big day for all space engineers!

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.

Marek Rosa
CEO, Founder Keen Software House
CEO, CTO, Founder GoodAI


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
GoodAI: www.GoodAI.com
Keen Software House: www.keenswh.com


Personal bio:

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.

----------



The following technical post goes into great depth about the changes that were made to Space Engineers for this update. 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 physics iteration.

Physics Improvements
by: Martin Pavlicek

Motivation

More stable simulation and better user experience, while keeping the overall simulation as realistic as possible, have always been major goals of programmers in the Space Engineers team. We wanted to reduce (or rather remove) any chance of random explosions, glitching subgrids (which impact their parent grid and cause massive damage), or anything else that could upset players. During the multi-year development, Keen programmers have worked on many iterations to find a solution.


Welding (aka safety locking)

One solution that we tried using to resolve physics issues in general simulation was welding, also known as safety locking but it turned out to be not a sufficient solution. In theory, making one single rigid body out of multiple connected bodies may sound like a good idea, but in practice, it brings more problems than it really solves.

Let's take a look on one of the main cases that welding should solve.
In a following video, we can see interesting ship made out of multiple connected sub-grids. Welding should protect it from breaking up and make sure that sub grids don't disconnect at high speeds. What we get though is not really what we expected



(Note: Continue reading to see “After” version)

At its core, welding is a nasty trick achieved by dynamic swapping of rigid bodies at the core physics simulation level. Unfortunately, this doesn't come for free and introduces many side effects, like performance issues (Keen eye might notice simulation lag in previous video at 22s), simulation flaws like rigid bodies warping through each other when safety lock is enabled/disabled each frame...



... and risk of random disconnections of landing gears, wheels, rotors or pistons every time the grid is welded/unwelded and rigid bodies are hot-swapped ...



… and last but not least, ugly simulation where every rotor, piston or wheel freezes at high speeds.

This led us to conclusion that welding is not the way we should or want to go and decided to remove it entirely.

Max speed limitations

One of the main issues we had to deal with in past was the bullet-through-paper-problem (this is a well-known problem with real time physics simulation).

Limiting the max speed of in-game objects works pretty well for that case but problems come when sub-grids get limited more than base grid due to high angular velocity. See sketch below.



This usually causes sub-grids to disconnect and clang out at high speeds, particularly in space. We solved this issue by strengthening physical constraints and unlocking the subgrids max speed. This allows them to move as fast as needed to keep up with the still limited main/base/central grid.

By further strengthening and stabilizing the physical constraints that keep the sub-grids together, we achieved pretty stable simulation. To demonstrate our solution, lets take a look at the following case study. Combination of rotors, pistons, landing gears and on top of that, each attached fighter is further stressing the connections with enabled inertia dampeners.


Before state



and after

Stronger constraints

By further strengthening the constraints, we can push them to the limits now, without risk of piston parts flying all over the place like they usually ended up before.


Before state


and after

Or, when player wants, constraints can now be configured in a way so they break in predictable manner when stressed too much:




Shared inertia tensor

Another issue we had to solve in this iteration were so called “Jiggling grids”. These are creations with very large inertia tensor and/or mass ratios.

Unfortunately, we hit a wall here. This problem is particularly tricky for computers to correctly detect and resolve. After our experience with auto-safety locking, we decided not to opt for an auto-detection system, but rather give you, the players, full control over it. This will allow you to fine-tune your creations exactly to your needs.

That’s why we introduced so called Shared inertia tensor.

If we take a look at the following sketch: G1, G2, and G3 represent grids connected by physics constraints (blue and red lines), those might be for example rotors.



(User can enable shared inertia tensor option on rotor connecting G1 and G2. Then, these two physical bodies will start to share certain physical properties. Purple boxes illustrate that grouping.)


Now, when G3 gets some external impulse, it will start to move and/or rotate. Red constraint will need to compensate G2 for G3’s displacement to keep their intended relative positions. The question is, how much will the G2 succumb and how much will be the G3’s movement slowed down by G2’s resistance.

The problem becomes more and more obvious the bigger the G1 and G3 are compared to the much smaller G2. Since the Havok constraints are solved one by one, not as an entire system as a whole, G2 will succumb to either G1 or G3 each frame, start to oscillate/jiggle between these two as the G1 and G3 will fight over G2. They’ll never move itself to actually find some common compromise and system will never converge to stable simulation/result.

That’s where the shared inertia tensor comes into the play; to either equalize physical properties across all bodies when enabled on every constraint-- as shown in the example below-- or say which grid will be the master and which one should succumb.

Here is in-game video with before and after.


(Central body is too “light” compared to satellite wings and they’ll start to fight over it’s position.)

It also helps to stabilize piston chains with “heavy endpoints”, as you can see on this example. Before, the scene didn’t even load without being immediately possessed by Clang:



Now, the scene loads just fine and pistons are even able to move at low speeds without any help of shared tensor. Unfortunately, as the speed goes higher, the pistons will start to behave as a bead chain and problems described above will start to show in a big way. After enabling the shared tensor, everything just works.


(Note that second piston chain is not using the shared tensor, yet still behaves naturally. No Clang present here.)

And finally in gravity.


(Note that they’ll bend as expected with disabled tensor sharing. It’s all about setting it up the way you want it.)

Just to not render it as some kind of silver bullet solution to every problem, there are some downsides to this, like simulation inaccuracy compared physical laws, and of course, sometimes we want sub-grids to be submissive as much as possible, for example on tank tracks so they don’t “fight” the main body. That’s why it’s not enabled by default and users should use it wisely and only when need, to achieve more stable creations.

Pistons

In previous iterations, pistons were pretty cheesy (when it came to any physical realism). They were also sometimes a pain to use because of their infinite strength and power to penetrate other solid obstacles.



Simulating some kind of suspension or pneumatic piston is not an easy task in real time physics simulation in general. It’s even worse in a world as dynamic as those Space Engineers can offer.

After some tests we decided to not dive into any kind of complicated piston implementation with strength settings and availability to be pushed back when too much pressure is applied on them. Partially because it would be too complicated and time consuming to make it work “right”, partially because it would ruin some creations that rely on pistons with “infinite force” and no pushback.

Thus we decided for compromise that will solve the worst issues players currently face but it will provide the “backwards compatibility” for those who need it at the same time. That is, keyframed piston with limited impulse.

Piston is natively backed by Havok fixed constraint. This is the stiffest constraint we can use now, as opposed to prismatic constraint which is intended for this scenario by Havok and may provide more accurate simulation, but its hold is quite vague under certain scenarios, especially when CoM is far from constraint pivot location.

When a piston is ordered to extend/retract, the constraint is manually positioned each frame and impulse, needed to get the rigid bodies to new desired position is measured. Whenever the impulse starts to grow over certain threshold, specified by player in GUI, the piston advancement is stopped until the constraint catches up again. This usually happens when piston head starts to collide with some other obstacle. It is either light enough so it can be moved away, or it starts to stress the constraint and stops the piston.


Before state



And after


Phantom forces

One of the big topics in the community are the so called phantom forces. The kind of strange behaviour when pasting a grid in space and then it starts to spin or fly away in an uncontrollable manner.

After investigating the issue, and doing some internal tests, we realized that this particular behavior is hard to control in real-time.

Imagine a simple case where there are two pistons connected to the same rigid platforms.

As long as the length of each of these two pistons stays the same as the other one, everything will be fine. The problem comes the moment when one of them changes its length compared to others connected to same rigid body. The inner stresses/tension that will raise inside the system at that moment will result in a fairly complex simulation problem that real-time physics is not able to correctly resolve in any reasonable manner and usually results in a simulation with systems that end up with more energy than they started with in each frame. Usually spinning, flying in different directions and sometimes clanging grids.

In any case, we are not able to differentiate these simulation flaws from normal simulation.

So, when designing your creation, try to avoid “double-connections” like shown on the example above and whenever you encounter the so called phantom forces, double check every connection on your grid and make sure that it doesn’t “fight” with another one. That way, you should never experience these problems.


Rigid body early deactivation and fixing

In order to save the precious CPU time, we decided to early detect and deactivate stationary grids more aggressively and give Havok stronger leads to not simulate these.

As you can see on following profiler dump, just by not simulating stationary rigid bodies that are fixed to either voxel or another station, we can gain massive performance improvements.


(click to zoom the image)

Yellow: Active
Red: Detected stationary
Blue: Force-fixed static




CoM based thrust

I believe that one of the things regular players will really appreciate is CoM-corrected thrust. Before, the attached subgrids would create so called “subgrid drag” which was annoying in space…



... and things-breaking in gravity.



After:








Sub-grid damage

Damage handling caused by subgrids, for example impact damage, was adjusted in a way that it will be ignored between subgrids of the same physical group.
We will trade a little bit of realism for user experience. Nice creations will no longer get destroyed by accident subgrid impact and it will allow users to make even more immersive creations.

This does not apply on damage caused by ship to ship impacts. Only physically connected grids get this resistance.

Displaced sub-grids

Under high angular velocities, subgrids were displacing or entirely disconnecting due to high forces acting upon the construction. This was also fixed in this iteration.


Before state


After

Always have safety fuse

When everything fails and the worst is about to happen from some unexpected reasons, it's always good to have safety fuse. That's why we implemented safety detach on all "mechanical connection blocks" (That means Rotors, Pistons, Wheels for now). This will protect users from experiencing all those unexpected situations, when subgrid gets insane speed when corrected after being displaced from its intended position and killing everything alive in its way and/or damaging it's own sub-grids, once and for all.

Satellite in following video is example of so called "Jiggling structure". When safety detach is correctly configured, it will end up "only" with some broken blocks and some subgrids flying away, instead of possessed grid, flying out of control.



Grid deformations

Crashing ship to the planet were causing split parts of the grid falling through the terrain to the center of the planet. This was happening also in collisions with other types of physical objects, although in smaller scale. The root cause was that creating or changing shape in physics also discards all the contact points, which means that for the next simulation frame grid can phase through other entities, until it regains the contact points again. Given the deformations were performed each frame, the grid was for most of the time without contact points, thus phasing through other grids. We have added reintegration step after each change of physics shape.
We have also tweaked all the deformations carefully according to the original release of Space Engineers.

No more ship-eating planets!

Miscellaneous

Here comes some examples of long occurring bugs that were solved along during the process.



Piston and Merge block combo was reported by users over and over again.



It was fixed and behaves correctly now.

"Sacrificial Offering for Almighty Lord CLANG" is one of those creations made just to stress-test Space Engineers. Some players may be angry that we fixed it (Well, mostly, phantom forces are still there)


Before state


After

There was interesting bug in pistons.
Center/extending part was just broken from physics perspective. It was usually just missing or would fly away after first contact. Astronauts or even ships were able to fly through.




And that’s it, for this iteration. For all those who made it this far, this is how that beautiful creature from first case study looks and behaves now, after all the improvements made in this iteration.


Graceful at all speeds, don’t you think?

---
Best regards,
Martin Pavlicek

 

[Blaine]

Picked this game up again after ages of not playing. The physical, mechanical, and programming possibilities are truly amazing.

Take this mining ship I built, for example. I can toggle the drills and spotlights as a group, toggle and configure the beacon, antenna, and ore scanner with the touch of a button, and even toggle the gyroscopes into manual override so that the ship can only move laterally and not turn (without deliberate control panel tinkering, rather than primary movement controls), allowing for perfectly straight tunnels to be dug through solid rock. I can group all of the thrusters except the fore and aft and turn them off, to ensure I don't accidentally move along the wrong axes while in my tunnel.

Then I can dock with a connector and offload it all in a jiffy, whereupon (depending upon setup) it's automatically whisked to refineries. This is all very simple compared to what is possible.

The mining ship I built (in Survival) is pictured hovering over a connector and cargo crate here because last night I accidentally detached the crate, which contains nearly my entire stockpile, while moving to my new platform/station. When the cargo crate initially detached, I quickly welded a bunch of "scaffolding" around it to hug it and keep it from drifting and spinning away into space. I then built a connector and reactor (to power the connector) onto the cargo crate, brought my mining ship over, magnetically docked and locked, then towed the cargo crate out! I built a third connector on my new platform to receive the cargo crate.

Scaffolding prison:

To the rescue:

Success!

 

[ERYFKRAD]

I see this has made some strides from when I last played.

 

[Blaine]

I see this has made some strides from when I last played.

Cargo also adds to ship mass now, and that includes things towed with magnet-locked connectors as pictured above, although connected mass doesn't display on the mass readout in the bottom-right of the HUD. Standard cargo does, and refreshes the display as it's loaded or offloaded. Small ships are a bit odd; I noticed that they're penalized by only 1/10th of the cargo's actual mass, but I suppose this is somewhat necessary for playability. A single large block for capital ships/stations/etc. is roughly equivalent to 27 small blocks, being the same apparent size as a 3 x 3 x 3 grid of the smalls. If cargo mass were left completely as-is, then either small vessels would be Godawful for hauling almost anything, or capital ships would be particularly stupendous at it.

That cargo container weighed around 2,000,000kg, and when I disconnected the ship from it, it reminded me of taking off a heavy-ass pack after a full day of hiking the AT.

I could write a dissertation about the features in this game. The conveyor system functions much like an electrical conduit or fluid pipe system. Almost every block type having to do with items has sockets to connect to the conveyor "pipes." You can have an entire closed system, several closed systems, several mostly-closed systems that interact with each other in limited ways, etc. Many block types have default behaviors that can be changed/overriden through various means. For example, refineries will pull dropped-off ore if they have room and a connection, reactors will pull refined uranium, etc. Ship drills and the conveyor system will try to fill up storage-type containers first, but if those reach capacity, they'll fill up anything that accepts the item and has a connection to their system: connector tubes, assemblers, refineries, even the fucking cockpit, and finally their own not-inconsiderable internal storages. After that, rocks will start flying everywhere.

There are sorter/filter conveyor blocks that you can place at strategic locations and set to either whitelist or blacklist mode, and add any combination of categories of items or individual items. I'm sure you can use timer and programming blocks to alter filtering behavior based on conditions and variables.

In fact, I'm 95% sure you can set up blueprint projectors (which allow welding directly into the projected blocks of the BP), arc welder blocks, assemblers, refineries, gas tanks, timers, programming blocks, and deep wells of resources to automatically produce pre-made, pre-programmed fighter drones that will find your enemies with antennas and shoot them. This, I'm fairly sure, is how the pirate NPC faction produces drones to attack the player in Survival mode using the normal blocks in the game, as far as I can tell (though probably with infinite resources).

 

[Raapys]

Hopefully they'll turn it into a game one of these days.