Posts made by Pavel
posted in MudRunner read more

@unster said in American Wilds Update 27/12/2018:

  • Force feedback is still dead unless the wheel is turned off and on in the controls menu.

Hello!
It just got to our attention that force feedback was indeed completely broken, hehe!
Thank you for bearing this, next patch will fix that! (and improve force feedback behaviour in general too)

Next patch will further improve light vehicles performance, which I think is one of the most important things patches can do at this point, given the amout of said vehicles in workshop.

Best regards,
Pavel

posted in MudRunner read more

@knight25 It is true that we originally planned to include tracked vehicles into one of the updates to Mudrunner - it was not a lie. But plans have changed 🙂
So thank you for buying MR - but as many people have contributed a lot to this game - me included - I really don't feel ashamed by its quality (especially given the discount to original Mudrunner owners) 🙂 In fact I'm pretty proud of what we with Saber and Focus were able to accomplish!

@ewgenij84 Working mirrors are technically challenging - and it doesnt really add much value to the game itself because you use third-person view most of the time (I've seen many players agree with that and even here we can see some people have never used first person view!)

posted in MudRunner read more

Hello guys!
Thank you for continued interest in the game! 🙂

I've seen some people mentioning that there is nothing new in this DLC.
I can understand that, but read this - we finally had a big team or artists working on new trucks and maps - some 15 people or more (all the old maps and content was done by maybe 5 people), plus a lot of people working on securing the license deals for the brands - which I'm sure people familiar with the vehicles will appreciate.
So while it is true that new DLC doesn't bring new features like tracked vehicles, the quality and detalisation is not something we could afford before.
On the other hand, thanks to lots of talented and dedicated mod-makers on PC, new content is not something players can be easily impressed with 🙂

So we've taken time to tune the maps so they are played differently compared to the old maps, giving a bit of a new flavour to the game.

After all, like I've written here before, when I look at Mudrunner, game seems pretty well-rounded and complete to me, so its really time to focus on the next big thing!
I agree that multiplayer part needs a lot of polishing (lights/sounds sync etc) but please understand - it is not a trivial thing to do, and it is much more efficient to do those improvements along with other improvements to the principal gameplay. In the end that would make you recieve new cool game sooner!

Best regards,
Pavel

posted in MudRunner - Off-Topic read more

Spintires started back in 2008, for Havok Physics Innovation Contest, and here is the first screenshot:
0_1521481888790_screen.jpg

It was originally using OpenGL instead of DirectX, and PhysX instead of Havok!
And original game idea was something like Besiege (which didn't exist back then obviously).

The next idea was aircraft simulator:
0_1521482006162_screen4.jpg

But eventually it evolved into offroad truck simulator:
0_1521482282559__vk2.png

But the codebase started developing even before that! Have a look at one of the first versions of the Level Editor:
0_1521482775204_x.bmp

Thats a pendulum movement research that I had fun with in Institute! 🙂

Best regards,
Pavel

posted in MudRunner - Modding read more

@sodoma Hello again!
Thank you for the analysis!
Like I said, I'm sure there are better ways to simulate the gearbox in the game - but I've never even researched that - because the vehicle in Mudrunner is driven by the wheels (physics bodies) - not the engine! And wheels don't interact "mathematically correctly" with the ground.
So before changing the math of the gearbox, we need to change the math of the wheels - that's a planned improvement! When the vehicle starts to move fast, physics bodies of the wheels need to be replaced by the procedural wheels (their positions computed mathematically, and this allows you to compute everything else mathematically) - without player noticing of course.
Thats the easy way 🙂

The hard way is to do our own physics of the wheels instead of Havok - and this is actually planned too, because I want the wheels to be truly soft! Stay tuned!

Best regards!
Pavel.

posted in MudRunner - Modding read more

@sodoma said in truck lua object:

@Pavel
May I ask you for some kind of presentation how physics of trucks, more specificaly propelling of trucks (engine+gearbox) works? Something as it was there for mud and water. This could be very helpful in here...
Pretty please...😇

Hello! There is not too much to tell, and gearbox physics is not something I'm particularly proud of. So just let me know what exactly you need!

Overview:
Choose number of gears and "optimal wheels angular velocity" (fGearAngVel) for each gear ("Gear/AngVel" XML file parameter).
And engine power (fEngineTorque, "Motor/Torque" XML file parameter)

For each gear, game operates with following parameters:
fGearAngVelMin = fGearAngVel * 0.25 - 2.0
fGearAngVelOpt = fGearAngVel
fGearAngVelMax = fGearAngVel * 2.0 + 5.0
fGearEngineTorque = fEngineTorque / pow(max(fGearAngVel / 2.0, 1.0), 0.5)

"High" (1+) gear:
fGearAngVelMin = 0.4
fGearAngVelOpt = fGearAngVel
fGearAngVelMax = fGearAngVel + 2.0
fGearEngineTorque = fEngineTorque * 1.25

Game computes "engine force multiplier" (engineCoef), based on
minAngVel,maxAngVel - minimum/maximum angular velocity of any wheel (that has torque)

float engineAngVel = lerp(maxAngVel, minAngVel, .5f);
float engineCoef;
if (engineAngVel < fGearAngVelMin) {
engineCoef = 0;
} else if (engineAngVel < fGearAngVelOpt) {
engineCoef = (engineAngVel - fGearAngVelMin) / (fGearAngVelOpt - fGearAngVelMin);
} else if (engineAngVel < fGearAngVelMax) {
engineCoef = (engineAngVel - fGearAngVelOpt) / (fGearAngVelMax - fGearAngVelOpt);
} else {
engineCoef = 0;
}

(lerp - linear interpolation of 2 parameters)
So the actual force that is applied to the wheel is computed like that:

wheelForceMultiplier = engineCoef * fGearEngineTorque * fAngVelSlowdownMult * pWheel->fCurrentTorqueRatio;
(I dropped some of parameters for simplicity)

fAngVelSlowdownMult is a parameter that prevents the vehicle from accelerating too fast (it compensates for lack of real-world inertia of mechanical parts of the engine), computed like that:

fAngVelSlowdownMult = saturate(0.0 - pWheel->fDeltaAngVel / fMaxDeltaAngVel * 2.0);
fAngVelSlowdownMult = saturate(fAngVelSlowdownMult +
max(pWheel->fWheelLinVel - 2.0, 0.0) / 10.0 +
1.0 - saturate((fabs(pWheel->fWheelAngVel) - 1.0) / 2.0));

Here fMaxDeltaAngVel is XML file parameter "Motor/MaxDeltaAngVel".

pWheel->fCurrentTorqueRatio is computed for each wheel based on diff lock mode. Let me know if you need documentation for that (It's a lot of hardcoded math too).

Hope this helps,
Best regards!

posted in MudRunner - General Discussion read more

@8up-local said in Gameplay Content and the Future:

i would not say these things are dumb or silly, but more a bit of a long stretch for the way the game is designed really imo. after all this began as a school project about deformable terrain and that needed something to show it off. hence the trucks and has morphed into what it is today to make a sellable product.

@Pavel care to comment and correct me if i am wrong on this?

Hello sir!
Yes, you get it 100% correctly!

Really most of the game design comes from the "Left 4 Dead" - quick game sessions with very simple objectives, stressless. From that point of view, I'm personally quite happy with the current state of the game - and I play it a lot myself, hehe. It doesn't mean there is no room for improvement of course! So stay positive, stay tuned, there are great plans for Spintires/Mudrunner!

posted in MudRunner read more

@knight25 What you mentioned is more related to graphics than simulation. But of course there will be improvements to both.
In terms of graphics, as I already mentioned, the most important improvement is "wet" mud and increased view distance.
As for the simulation - it's tied to the gameplay. The one can't change without the other 🙂 But there is a lot of room for improvement too - one of the main ideas is making the truck to be an interconnected combination of parts, unlike a static mesh it is now!

posted in MudRunner read more

@lazerlee Hello Lazerlee!
Thank you for your interest in the game!
Keep in mind - we were focused on improving the quality of simulation instead of depth of the gameplay, because we couldn't do both unfortunately. MudRunner is like a game of chess - with no opponent 🙂
But don't worry - all will come, so if you enjoyed the game, stick around!
Best regards!

posted in MudRunner read more

Hello, players!
So it's been two months since the release of the game!

On one hand, it was hard to predict if the console players will like the game.
On another hand, since the game is very similar to the old Spintires, we knew some PC players will be upset.
But it was a very successful release, and that means we will be improving and updating the game a lot – a big thanks to everyone who helped to make it, and everyone who bought it! Remember – the purpose of this game is for you to have fun!

We receive a lot of feedback and improvements suggestions – thanks for that too!
There is a lot of room for improvements, and with our colleagues from Saber and Focus we will now be able to speed up the development, to make players 100% satisfied!

Thanks again for support!
Happy New Year!

posted in MudRunner read more

@tattoo said in Spintires: MudRunner - Second Update:

@pavel said in Spintires: MudRunner - Second Update:

Q: How to make custom wheel tracks for your mods?
A: We have just dispatched a editor update that will propely pack wheel XMLs like that:
<_templates Include="trucks" />
<TruckWheel
...
>
<WheelTracks TextureAlpha="[texture path]" TextureHeight="[texture path]" />
...
</TruckWheel>

Do we still need to add these to our own textures or do we name them differently? - alpha__s_d and height__s_d - you did not explain what extensions we need to add to our textures.

Can you please clarify this for us?

Thank you.

Hello!
Just put new textures in your mod folder and follow the same pattern for naming and texture content as the default track textures!
Both TextureAlpha and TextureHeight are single-channel uncompressed textures with mipmaps (thats what "__s_d" is for).

EDIT: I see this in the trucks.xml _template folder so I'm guessing we do it like this?

<_templates>
	<WheelTracks>
		<Offroad TextureAlpha="tracks/offroad_alpha__s_d.tga" TextureHeight="tracks/offroad_height__s_d.tga" />
		<DefaultDouble TextureAlpha="tracks/default_double_alpha__s_d.tga" TextureHeight="tracks/default_double_height__s_d.tga" />
		<Default TextureAlpha="tracks/default_alpha__s_d.tga" TextureHeight="tracks/default_height__s_d.tga" />
	</WheelTracks>

When you use "templates" from "trucks.xml", you essentially substitute a part of "trucks.xml" file into your file.
If you'll have a look at default wheel XMLs,

<_templates Include="trucks" />
<TruckWheel
...
/>
<WheelTracks _template="Offroad" />
...
</TruckWheel>

So when the game loads that file, it inserts "template" in it, and gets this:

<_templates Include="trucks" />
<TruckWheel
...
/>
<WheelTracks TextureAlpha="tracks/offroad_alpha__s_d.tga" TextureHeight="tracks/offroad_height__s_d.tga" />
...
</TruckWheel>

Hope this helps!

posted in MudRunner read more

@knight25 Hello dear knight 🙂 Everything is possible to code! It's just a matter of time and effort. But rest assured, we will not stop working on the game until rain and snow are part of it 🙂

posted in MudRunner read more

@mizogin Hello mister, thank you for your feedback!
Yes, glossy/wet looks of the mud is one of most important shading improvements for the future. However, it's not a trivial improvement, that's why you don't see it in the game currently.

posted in MudRunner read more

@dmitriygds said in Spintires: MudRunner - Second Update:

Не нашел раздел по редактору, написал здесь.
Решил добавить собственный рисунок протектора, но после загрузки модификации в воркшоп, имена текстур зашифровываются, а в прописке колеса новое имя не присваивается... Получается мод без протектора.

Только что загрузили обновление редактора в котором работает прописка своих следов (см. ниже)

Q: How to make custom wheel tracks for your mods?
A: We have just dispatched a editor update that will propely pack wheel XMLs like that:
<_templates Include="trucks" />
<TruckWheel
...
>
<WheelTracks TextureAlpha="[texture path]" TextureHeight="[texture path]" />
...
</TruckWheel>

posted in MudRunner - Welcome Area read more

@alexsandr Hello!
We are doing our best to deliver features you are waiting for asap. Tracked vehicles is one of the top priorities. Thank you for your patience!
Александр, мы стараемся делать новые интересные функции в игре как можно быстрее. Гусеничная техника это один из основных приоритетов! Спасибо за терпение!

posted in MudRunner - Welcome Area read more

@ryan-lindner said in Few words from developers!:

Hello I preordered the game for console and have been having a blast with it since the release. I believe most of us on console understand that pc is the main focus atm which makes sense. We are just hoping down the road months from now we will get some dlc vehicles although I'm sure as always easier said than done. Anyways just want to say thank you for bringing this game to console and ask do you have any plans to eventually bring any dlc vehicles aka the modded trucks to console?

Thank you for your support!
Don't worry, Console version is getting no less support than PC version!
And yes, more content is coming to consoles soon.

posted in MudRunner - Off-Topic read more

Hey guys!
Thats a delightful thread to read! 🙂
I enjoyed comparisons against COD 🙂
And I'm really happy that you are enjoying the game, thats the ultimate purpose of it: to keep it relaxing and make you have some fun with it!
That kind of support is all we need to keep on developing the game, so stay tuned for cool updates!
Thank you!

posted in MudRunner read more

MudRunner is the ultimate version of Spintires, released on PC, and for the first time on consoles.

Like Spintires before it, MudRunner will put players in the driver’s seat of a variety of incredible all-terrain vehicles, venturing across extreme Siberian landscapes with only a map and compass as their guides.

In this blog, we'll be discussing how we render and simulate water in MudRunner. Previously, we discussed how MudRunner renders mud here.

Let’s take an in-game screenshot and deconstruct it:

alt text

Disable SSAO, FXAA, DOF, Sharpen Effect, Color Correction, Motion Blur and Bloom Effect:

alt text

Taking away the layers in the reverse order they are applied:

  1. Particles
    Probably any game has that kind of effect. Particles in MudRunner can be of two types:
  • “billboard” particles: a quad with spray texture, oriented towards the camera
  • “subparticles”: small bits of substance that collide with water, terrain and vehicle wheels. Spawned in large quantities (about 14000 on that screenshot!) and are heavily optimized (spawned and deleted in chunks of 16)

alt text

LUA scripts are used to spawn the particles. Given wheel and chassis positions, velocities, sizes, current water penetration depth and other parameters, scripts compute initial position and velocity for each particle. The advantage of this approach is that it is very customizable – you can tune particles dynamics in any way you want on the fly. The disadvantage is that this process is very technical.

2. Geometric Water Waves

alt text

This layer actually consists of two different effects, have a look at their wireframes:

alt text

Both meshes are generated on the CPU, with a lot of empirical constants involved, and have a very vague connection with the real-world physics of the water.

3. Terrain Wet Decals (will get back to it later)
alt text

And now we are left with the water surface itself:
alt text

Have a look at its wireframe:
alt text

WATER SHADER

Water in MudRunner can flow in different directions, with varying speed, at any angle, it can have different colour and transparency, and it can get foamy (when vehicles strike it or simply due to its flow intensity). So how does it work?
Any water shader in any game needs to simulate the water waves. There are many different ways to do this. In MudRunner, as you’ve seen above, the water mesh has relatively high tessellation, so our waves are actually geometric. Most simple way (but far from the most realistic) to render the water waves is to mix several instances of texture like this (MudRunner mixes 5 layers while applying different texture coordinates scale and offset):

0_1510391294005__water_texture__.bmp
This texture is actually a procedural noise that you can generate in Photoshop. But different character of that texture yields different character of water surface in a game.

But as will be explained later, if you want your water to flow in any direction at any speed, you will actually need to do the above-mentioned arithmetic 4 times. And if you want your water to be foamy, you will need to do the whole thing with the foam texture too! And that sums down to a lot of shader arithmetic that just won’t work in a real-world scenario. MudRunner’s solution is to pre-mix water waves and water foam texture:

0_1510391884770__water_texture_anim__.jpg
Animated water texture. The only small trick is to make sure those textures can be seamlessly tiled which is easily achieved with some shader math. In the same way, we generate ANIMATED CAUSTICS TEXTURE which we will reference later.

So how do you make your water actually flow? Simple – you scroll the texture coordinates over time. But in which direction, and at what pace? Obviously, that depends on the water direction and water flow speed. In MudRunner, to define water direction and flow speed, map author places “water rivers” in the Level Editor:

0_1510337450913_editor_curves.jpg
Each “river” is a curve with varying width.

When building a level (preparing it for the game), Level Editor generates continuous water surface by mixing all “water rivers” together:

0_1510338520731_editor_water.jpg
Vertices that define water surface. “Rivers” are not used by the game itself.

Map author uses a brush to paint water flow intensity. So in the end, additionally to the water surface, Level Editor generates that A8R8G8B8 texture for the game to use when it renders water:

0_1510338552552_editor_water_tex.jpg
Water data per terrain block (terrain blocks are described in the MUD OF MUDRUNNER paper).

So water shader knows water direction and flow intensity (speed), which is actually merely a 2d vector, let’s call it “flowDir”. They key concept to understanding next step is discretization. It means that we pick one of let’s say 16 possible water directions, a direction that is closest to “flowDir” (let’s call it “flowDir1”), and its “neighbor” direction (“flowDir2”), so that
(here and later HLSL code is used)
flowDir = lerp(flowDir1, flowDir2, flowT);

Where “flowT“ is the interpolation parameter of the two directions.
Having “worldPos” as a world position, water shader can now compute texture coordinates for each direction:
float2 angTC1 = float2(
dot(float2(+flowDir1.x, +flowDir1.y), worldPos.xz),
dot(float2(-flowDir1.y, +flowDir1.x), worldPos.xz));
float2 angTC2 = float2(
dot(float2(+flowDir2.x, +flowDir2.y), worldPos.xz),
dot(float2(-flowDir2.y, +flowDir2.x), worldPos.xz));

Which can actually be used to sample animated water texture (having “g_fTime” as animation time, “tcScale” and “tcScrollSpeed” – arbitrary constants):

float2 tcScroll = float2(g_fTime, 0) * tcScrollSpeed;
float4 waves = lerp(
tex2D(g_samWaves, (angTC1 + tcScroll) * tcScale),
tex2D(g_samWaves, (angTC2 + tcScroll) * tcScale), flowT);

We have omitted the water flow speed discretization for simplicity here, but it follows the same idea, and thus you need the 4 samples to the animated water texture (“g_samWaves” sampler in the code above) which were mentioned earlier.

But the water waves need to be shaded. The recipe for that is pretty common, and it basically involves two components: Reflections and Refractions.

alt text
Refractions: objects seen through water. Notice caustics effect that we will get back to later.

alt text
Reflections: objects that are mirrored by the water surface. To render reflections, you can put the camera below the water surface and point it upwards (“reflect the camera”), then use a technique called “oblique clipping plane”. But that only works well if your water surface is “planar” – which is not the case for MudRunner. MudRunner uses a technique called “Screen Space Reflections” (SSR - this technique is well documented in a multitude of sources). MudRunner uses SSR only for water reflections, so its version is highly optimized and very lightweight. One of the optimizations is, we render the “water reflections mesh” (see picture) instead of full-screen quad, so we know the position of the shaded fragment from vertex shader instead of having to do z-unprojection, and don’t need to do SSR pixel shader for the entire screen.

WATER SIMULATION

MudRunner uses a very simple algorithm to compute water simulation, it involves two A8R8G8B8 textures. In the same fashion as mud simulation, we build and draw special primitives into a render target texture:

alt text
With a knowledge of wheels and chassis positions, their size and velocities, their current water penetration depth, and water speed and direction, CPU forms various “primitives” and draws them into render target textures, which is then read back by GPU. That is pure empirics, and have very vague connection to real-world physics of the water!

The first texture with simulation data looks like this:
alt text
After the primitives are drawn into that texture, MudRunner performs a “GPU simulation shader” that does a simple propagation of foam, water, height and mud parameters to neighbour texture samples. So two instances of each texture are involved: one for read-back, one for output, and they are swapped each frame.

The second texture only stores “WATER MUD”. Note – there are algorithms that simulate much more realistic water dynamics, but they all require floating point textures for the data, which makes algorithm somewhat more resources-heavy.

Let’s have a look at another peculiar effect. For the water render pass, we generate special low-res texture, which we call “water domain texture”:

alt text
Water domain texture uses a concept, similar to parallax effect, and allows mud (not seen at above picture) and foam to be seen “through” the water. It also stores “water flow speed” that we use to pick the mip level of the “animated caustics texture”. The caustics themselves are simply z-projected when water is drawn. Note that water caustics in MudRunner cannot be seen above the water – drawing the caustics above the water would be a nice improvement in the future!

WATER DECALS

As referenced in the “MUD OF MUDRUNNER”, there are 4 types of decals in MudRunner:

  • Mud decals, produced by “mud” particles and applied to the terrain.
  • Wet decals, produced by “water” particles and applied to the terrain AND water.
  • Oil slick decals – produced by working vehicle engine and emulates slick on the water surface, applied to water only.
  • Dry oil decals – same as oil decals, but emulates oil marks on dry surfaces, so applied to terrain only.

Let’s have a look at oil decals:

alt text

The render process is similar to rendering mud decals:

alt text
Water needs to output a mask when it’s rendered, so decals can distinguish the surface type they are applied to. Water also writes screen normals that decals use for shading.

Thank you for reading!
09/11/2017
Pavel.