Marek Rosa – dev blog: Guest post: Jan Hlousek

SUMMARY:

---

Guest post by Jan Hloušek, VRAGE Engine Lead Programmer at Keen Software House

Hello, Engineers!

In Keen Software House, my team started development of the new engine VRAGE3. It is a new iteration of the Space Engineers engine, with similar goals (sandbox, open world, solar system distances etc.), but very different technology.

We came to the conclusion of writing a new engine after hitting lots of bottlenecks with VRAGE2. First, we investigated other engines, big (Unrealengine5, Unity3d) and small (Unigine, Stride, Flax). But neither of them could support unique use cases without major rewrites.

We started more than a year ago and now I decided to regularly share some of our progress.

So, what changes? The biggest differences are:

• Data Oriented architecture, similar to Unity’s Entity Component System, but with better interoperability with the Object Oriented world.
• GPU driven pipeline – GPU feeding itself with draw calls, freeing CPU significantly (in SE, >3 cores are dedicated to render)
• Adoption of new graphics APIs (DirectX12), modern physics (Havok), AI (Kythera AI) and audio (FMOD)
• Thread safe parallelization – tasks scheduled based on data dependencies
• Dynamic Global Illumination using raytracing
• Multiplatform from the start – with every decision, we are taking other platforms in consideration, so the porting is not an afterthought
• Deeper modding possibilities (i.e. better in combining Mods, modding of materials, clear API etc.)
• Single development tool to author all assets (available to Modders)

Most of the systems are implemented from scratch, with very little code being reused from VRAGE2. And it is shaping up pretty nicely.

Physics Engine Investigations

Before we started with development of VRAGE3, we investigated many 3rd party libraries to save the dev time. First, we started with physics engines. We wanted to improve on issues from Space Engineers Havok2012 which we use in mainly:

• Phantom forces
• Unstable / wobbly constraint chains
• Support for high mass ratios

Below see the footage from our tests with ChaosPhysics, PhysX3, PhysX4, UniginePhysics and Havok 2021. Bear in mind that this is early 2021 footage, some issues may have been improved in the meantime.

Also, PhysX4 can deliver much better simulation stability with articulation joints which we have not used as they do not fit our requirements for various reasons.

Shadows

In the past few months, part of the VRAGE3 team was working on improving direction (sun) shadows. In Space Engineers, we are using shadow cascades supporting planetary scale distances. Let’s have a look at some of the improvements we made.

Having clearly defined contours of shadows was our primary goal. We added an antialiasing step analyzing squares of 4 pixels within a certain radius calculating alignment in 4 different directions. The result is stretching the sampling kernel in the appropriate direction.

VRAGE2 / VRAGE3

We also improved Poisson sampling itself using the Fibonacci spiral. This method has better distribution with a lower number of samples.

VRAGE2 / VRAGE3

When blending between cascades instead of having half of the samples from each cascade as in VRAGE2, we are sampling the whole kernel in each cascade. We can get away with that since new sampling has half of the samples with the same radius.

VRAGE2 / VRAGE3

The moire effect in steep angles is reduced similarly as mipmaps texture sampling. Instead of going to a lower mipmap, it simply increases the minimum radius for the kernel.

VRAGE2 / VRAGE3

Finally, since driving or flying some vehicles is usual activity, we stabilized shadows by subtracting the position of a pivot object (i.e. cockpit) from the shadow origin, instead of the camera origin.

VRAGE2 / VRAGE3

All the comparisons are using the same shadow cascade setup and texture resolutions.

Most of the techniques are well known in the rendering community, except for the antialiasing technique, which was developed by our render engineer Landon Townsend.

Local lights

First of all, spot lights with cookies in the scene with solid and transparent surfaces. Improvement over VRAGE2 is a transparent surface support and better shadow quality:

Internally, we implemented light clustering with sparse representation, allowing us to have more lights per tile and better performance over no tiling for spot lights and tiled rendering for point lights in VRAGE2. Clusters are now used for all types of lights. It is also the reason why we can now support transparent surface lighting, where for every pixel, we have to evaluate all the lights in the cluster (instead of the whole tile).

Another improvement is physically correct attenuation using inverse quadratic formula with range mask.

Point lights benefit from the same improvements as well. Additionally supporting cube map shadows:

Capsule lights will be great for lights from neon tubes. This is a new feature over VRAGE2. No shadow support yet.

Capsule light is emitted in all directions equally along the centerline of the capsule. The capsule light is defined by an attenuation radius and length of the capsule, light intensity and transformation.

Area lights will be used for LCD blocks, reflecting their content. They were not supported in VRAGE2 at all. No shadows yet.

Area lights emit light from 2D geometric shapes (most commonly rectangles) from one of its sides. Rect light is defined by transformation, size, barn (size and angle), light intensity and attenuation radius.

Armor Deformation

Armor deformation test with LOD on. Bones are in a 1 meter grid with blocks of arbitrary size.

Water Physics

You can check out the Volumetric Water guest post by Petr Minařík, Senior Lead Programmer at Keen Software House.

Tiling Methods

We are experimenting with new tiling methods to be able to increase the resolution of armor textures, but not having patterns apparent and containing the memory footprint.

Voxel Destruction

Let me present to you a few experiments with Voxel destruction in VRAGE3 with different materials. 

This is how crash landing to sand could look like.

And to the rocky surface. Damage to the ship is now disabled, but obviously rock will damage the ship more than sand.

The furrow is created from metaballs (SDFs) composed out of spheres in contact points with radius based on their impulse.

And this guy should lose his pilot license.

This is by no means the final product, we have many ideas how to improve it and will share them soon. 

Block Fracturing

We are experimenting with splitting the block in runtime into multiple fractures using a hybrid approach of Havok fractures and artists authored models.

Any fracture piece becomes a debris and despawns after a while. The area of the block where the piece was removed becomes pass-through for rigidbodies, characters and shooting.

Here is an example of shooting (debug menu action) and thus detaching the hit fractures from the block.

This is an example of destruction on contact with another rigid body. Its impulse is propagated to the fracture debris (missing for shooting yet).

Destruction is applicable in all stages of construction of the block.

Here you can see the block being fractured, then deconstructed (still missing the destructed pieces) and later constructed, where at first the overall shape is restored and then new parts start appearing.

Tool Suite

With VRAGE3 we are developing a complete tool suite in the form of editor (to author content of the game and mods) and HUB (to maintain game and mod projects).

Both are developed using AvaloniaUI.

VRAGE3 HUB

ObjectInspector used to edit game prefab

Game definitions are prepared in component-like fashion. Components having distinct functionalities (like inventories, transforms, model rendering, animation etc.). Composing them together will define the block’s feature set.

Example of Gravity generator block composition:

• ChildTransformComponent
• HierarchyComponent
• PowerableBlockComponent
• GravityGeneratorComponent
• BlockModelComponent
• BlockRenderComponent (client only)

Edits in inspector are applied realtime to running game through Live link.

Project explorer is used to navigate the definitions and assets in the folder like structure. It has quick navigation features and search / filtering.

Project explorer

Any asset can be previewed, including individual LODs, lighting changes. It uses the same renderer setup as the game does, so it is as close as the final product.

Model preview

Previewing (including live editing of parameters) works for any type of asset type like planets and asteroids.

Voxel storage preview

New material system features variants of standard PBR including parallax, alpha cutout, triplanar, transparent etc. Editor can preview materials on predefined models for quick iterations.

Material preview

Materials can be prepared for different types of target assets (models, voxels…). Editor then offers a different preview model set.

Triplanar material preview on voxel storage

The tool suite is very much work in progress. This is just a sneak peak on the current state. There is still much work pending to have a polished experience and full feature set.

Follow our social media to get the latest news!

We are always impressed by the innovation of our modding community! We would like to thank the Space Engineers community for continuing to inspire us through their ideas, suggestions, and hard work.

Hiring

If you’re interested in working on awesome games like Space Engineers or our in-house game engine VRAGE3, and love solving unique challenges, we’d love to hear from you! Check out the open positions at Keen Software House and don’t forget to send us your English CV/resume and cover letter. 

Remote collaboration is possible!

Our team is global.

Finding the best candidates to join Keen Software House means exploring every possible solution, including remote work. While we strive to provide team members with the best possible work-life balance here in Prague at our incredible Oranzerie offices, we understand that it is not always possible to transition, therefore we are very remote-friendly. Here’s a map of where our teammates live.

If you want to let me know your feedback, please get in touch via my personal email address marek.rosa@keenswh.com, or use our Keen Software House support site. I welcome all of the feedback we receive and we will use it to learn and provide better services to our players.

 

Thank you for reading this blog!

 

Best,
Marek Rosa
CEO, Creative Director, Founder at Keen Software House
CEO, CTO, Founder at GoodAI

 

For more news:
Space Engineers: www.SpaceEngineersGame.com
Keen Software House: www.keenswh.com
VRAGE Engine: www.keenswh.com/vrage/
GoodAI: www.GoodAI.com

 

Personal bio:

Marek Rosa is the founder and CEO of GoodAI, a general artificial intelligence R&D company, and Keen Software House, an independent game development studio, started in 2010, and best known for its best-seller Space Engineers (nearing 5 million copies sold). Space Engineers has the 4th largest Workshop on Steam with over 500K mods, ships, stations, worlds, and more!

Marek has been interested in game development and artificial intelligence since childhood. He started his career as a programmer and later transitioned to a leadership role. After the success of Keen Software House titles, Marek was able to fund GoodAI in 2014 with a $10 Million personal investment.

Both companies now have over 100 engineers, researchers, artists, and game developers.

Marek’s primary focus is the development of Space Engineers, VRAGE3 engine, AI Game, and Memetic Badger.

GoodAI’s mission is to develop AGI – as fast as possible – to help humanity and understand the universe. One of the commercial stepping stones is the “AI game,” which features LLM-driven NPCs grounded in the game world with developing personalities and long-term memory. GoodAI also works on autonomous agents that can self-improve and solve any task that a human can.