TranslationI never tried it on mobile yet, i haven't really developed for mobile before and i'm not really updated on how mobile CPU's have evolved either, the softbody physics and terrain physics is very heavy on the CPU and memory, but in theory it should work on both IOS and Android if i scaled down the detail physics detail on the vehicles and terrain.
No eta on asset store version unfortunately, an asset store version will only maybe be available some time in the future it's not decided yet, i want to use it to create my own game first, meanwhile i'll try to explore some options for using it in simulation software, i've already had a few interesting offers but it's not ready for sale/licensing yet.
Realistic Vehicle Physics - Made with Unity
-
AndersOrum
- Level 2 - Grain of sand
- Posts: 26
- Joined: 05 Jan 2015, 03:52
- Location: Denmark, Aalborg
-
AndersOrum
- Level 2 - Grain of sand
- Posts: 26
- Joined: 05 Jan 2015, 03:52
- Location: Denmark, Aalborg
Re: Realistic Vehicle Physics - Made with Unity
Back with another update on the terrain system, i've made a bunch of improvements since yesterday:
- Improved terrain physics model, earlier only weight/load on the terrain would affect the deformation, now weight, velocity, lateral & longitudinal slip affects the deformation.
- Fixed many visual bugs on the generated terrain mesh( specially light and shadows).
- Small optimizations.
Hardware specs:
CPU: Intel i7 4790k
GPU: Nvidia GTX 970
RAM: 16 Gb
- Improved terrain physics model, earlier only weight/load on the terrain would affect the deformation, now weight, velocity, lateral & longitudinal slip affects the deformation.
- Fixed many visual bugs on the generated terrain mesh( specially light and shadows).
- Small optimizations.
Hardware specs:
CPU: Intel i7 4790k
GPU: Nvidia GTX 970
RAM: 16 Gb
Last edited by AndersOrum on 14 Feb 2020, 21:19, edited 1 time in total.
-
AndersOrum
- Level 2 - Grain of sand
- Posts: 26
- Joined: 05 Jan 2015, 03:52
- Location: Denmark, Aalborg
Re: Realistic Vehicle Physics - Made with Unity
Yet another update on the terrain system, i've made a few improvements to the soil model and added a few debugger views.
- Deformation is now calculated on all contact/collision points, before it would only use the average position of all the points and calculate deformation from that position.
- Added new variable to the soil model "surfaceStrength", this controls how much force it takes to break through the surface layer.
- The soil now becomes harder as it gets more compressed, this is currently a linear scale but will be tweakable later.
- Tire friction is now accounted for in the deformation calculation, so now a heavy threaded offroad tire will carve up more of the terrain when is spins than a highway tire would.
- Fixed a bug which caused the tires to continue compressing the terrain if the vehicle wasn't moving or tires rolling.
- Added 2 new debugger modes:
1). Wireframe View.
2). Tile Activation View - Green = Active, Red = Disabled, this shows you which terrain tiles currently is active and being deformed.
- Deformation is now calculated on all contact/collision points, before it would only use the average position of all the points and calculate deformation from that position.
- Added new variable to the soil model "surfaceStrength", this controls how much force it takes to break through the surface layer.
- The soil now becomes harder as it gets more compressed, this is currently a linear scale but will be tweakable later.
- Tire friction is now accounted for in the deformation calculation, so now a heavy threaded offroad tire will carve up more of the terrain when is spins than a highway tire would.
- Fixed a bug which caused the tires to continue compressing the terrain if the vehicle wasn't moving or tires rolling.
- Added 2 new debugger modes:
1). Wireframe View.
2). Tile Activation View - Green = Active, Red = Disabled, this shows you which terrain tiles currently is active and being deformed.
Last edited by AndersOrum on 14 Feb 2020, 21:20, edited 1 time in total.
-
Jesper Nielsen
- Level 7 - Spellcaster
- Posts: 71
- Joined: 31 Oct 2013, 11:31
Re: Realistic Vehicle Physics - Made with Unity
Very impressive work! I watched some of the first videos in this thread and I found it quite hard to concentrate on getting any of my own work done. I especially enjoyed the little accidents. If I understand it correctly they're a consequence of the physics rules you've encoded and the behaviour of the vehicles - and not directly scripted as such?
-
AndersOrum
- Level 2 - Grain of sand
- Posts: 26
- Joined: 05 Jan 2015, 03:52
- Location: Denmark, Aalborg
Re: Realistic Vehicle Physics - Made with Unity
Thank you Jesper i'm glad you like it 
Yes that's correct, the deformation and much of the vehicle behavior naturally occurs and aren't directly scripted as you suggest. The vehicles is simulated with softbody physics (Truss Physics Engine), the way softbodies work is that you create a bunch of points(nodes) in 3d space forming a shape the hull of the model/part you want to create(wheels, chassis frame, cabin etc.), you set a mass variable on each individual node and connect them with links(2 nodes pr. link) each link acts as spring with damping, actually like a real coil spring you typically see on cars, , a link will not constrain the rotation of a node it will only try to keep a distance between it's 2 nodes so you also have to create extra nodes and links inside the hull to give the structure support and make it rigid, on each link you also set how much it's allowed to compress before it's permanently deformed. So basically you're creating a structure made of springs connected to points of masses, this gives you almost endless combinations of ways you can setup vehicles and how they deform and behave, almost only limited by performance and how well you can setup good working structure. Another exciting thing about this technique is that it scales great with the progress on hardware specifically Cpu's, in a few years i will be able to have double node & link density which will make the simulation even more realistic.
If you are not already familiar with BeamNG then i suggest you take a look at their game, they are a great example of what this technique is capable of and they are also the source of inspiration for when i changed to softbody simulation.
Yes that's correct, the deformation and much of the vehicle behavior naturally occurs and aren't directly scripted as you suggest. The vehicles is simulated with softbody physics (Truss Physics Engine), the way softbodies work is that you create a bunch of points(nodes) in 3d space forming a shape the hull of the model/part you want to create(wheels, chassis frame, cabin etc.), you set a mass variable on each individual node and connect them with links(2 nodes pr. link) each link acts as spring with damping, actually like a real coil spring you typically see on cars, , a link will not constrain the rotation of a node it will only try to keep a distance between it's 2 nodes so you also have to create extra nodes and links inside the hull to give the structure support and make it rigid, on each link you also set how much it's allowed to compress before it's permanently deformed. So basically you're creating a structure made of springs connected to points of masses, this gives you almost endless combinations of ways you can setup vehicles and how they deform and behave, almost only limited by performance and how well you can setup good working structure. Another exciting thing about this technique is that it scales great with the progress on hardware specifically Cpu's, in a few years i will be able to have double node & link density which will make the simulation even more realistic.
If you are not already familiar with BeamNG then i suggest you take a look at their game, they are a great example of what this technique is capable of and they are also the source of inspiration for when i changed to softbody simulation.
Last edited by AndersOrum on 14 Feb 2020, 21:23, edited 2 times in total.
-
AndersOrum
- Level 2 - Grain of sand
- Posts: 26
- Joined: 05 Jan 2015, 03:52
- Location: Denmark, Aalborg
Re: Realistic Vehicle Physics - Made with Unity
Terrain System Update 5:
So the last couple of weeks i've worked on a couple of things but the biggest new feature is implementing MegaSplat, a new texture/shader system by Jason Booth, with this system i can now paint up to 256 different textures per terrain tile without affecting performance(not showed in video) where before i could only do 1 texture per terrain tile, the idea is to have all these different textures act as different soils, so each texture will make the terrain behave different based on the soil type connected to that texture.
- Implemented MegaSplat.
- Implemented runtime terrain texture painting(Although MegaSplat already includes a well optimized system for runtime painting, it wasn't quite fast enough, so i've made a simplified and optimized version, the result is about 10 times faster so painting 1 tile only takes about 0.005ms(see hardware specs below), the biggest factor for this optimization is the fact that i already know the positions of all vertices, so by converting collisionPoints world positions into terrain/heightmap positions i can then use those positions as indexes in my arrays instead of looping through all the vertices in the mesh, this saves me of several thousands calculations per tile per frame.
- Started adding support for multiple soil types per terrain tile, it will be possible to have a different soil type per texture/heightfield coordinate( 1 heightfield is ~12x12 cm, each tile is ~4x4 m and have about 1000 heightfields).
- Many optimizations to the physical deformation, especially big optimization to multiple deforming bodies, meaning i can now have 2 active trucks deforming terrain at about 150-200 fps up from about 100 fps before, and 3 active trucks at about 50-80 fps up from 5-20 fps before.
Hardware specs:
CPU: Intel i7 4790k
GPU: Nvidia GTX 970
RAM: 16 Gb
So the last couple of weeks i've worked on a couple of things but the biggest new feature is implementing MegaSplat, a new texture/shader system by Jason Booth, with this system i can now paint up to 256 different textures per terrain tile without affecting performance(not showed in video) where before i could only do 1 texture per terrain tile, the idea is to have all these different textures act as different soils, so each texture will make the terrain behave different based on the soil type connected to that texture.
- Implemented MegaSplat.
- Implemented runtime terrain texture painting(Although MegaSplat already includes a well optimized system for runtime painting, it wasn't quite fast enough, so i've made a simplified and optimized version, the result is about 10 times faster so painting 1 tile only takes about 0.005ms(see hardware specs below), the biggest factor for this optimization is the fact that i already know the positions of all vertices, so by converting collisionPoints world positions into terrain/heightmap positions i can then use those positions as indexes in my arrays instead of looping through all the vertices in the mesh, this saves me of several thousands calculations per tile per frame.
- Started adding support for multiple soil types per terrain tile, it will be possible to have a different soil type per texture/heightfield coordinate( 1 heightfield is ~12x12 cm, each tile is ~4x4 m and have about 1000 heightfields).
- Many optimizations to the physical deformation, especially big optimization to multiple deforming bodies, meaning i can now have 2 active trucks deforming terrain at about 150-200 fps up from about 100 fps before, and 3 active trucks at about 50-80 fps up from 5-20 fps before.
Hardware specs:
CPU: Intel i7 4790k
GPU: Nvidia GTX 970
RAM: 16 Gb
Last edited by AndersOrum on 14 Feb 2020, 21:23, edited 3 times in total.
-
AndersOrum
- Level 2 - Grain of sand
- Posts: 26
- Joined: 05 Jan 2015, 03:52
- Location: Denmark, Aalborg
Re: Realistic Vehicle Physics - Made with Unity
So a lot of people have asked me about my terrain physics if it's softbody based like my vehicles are or how i do it, so i'd like to clear up some misunderstandings and add a little info.
The terrain physics is not based on softbody physics, it's actually based on a technique called Heightmap/Heightfield Deformation, the way this works is that you take heightmap based terrain, which is commonly used in most game engines for terrains(this is also what Unity and UE4 uses as terrains), to put it simple you could say i've just created a runtime terrain brush. You might wonder why a heightmap based terrain is used for collision instead of a mesh collider based terrain, the reason for this is very simple if create 2 identical terrains one heightmap based the other mesh based, the heightmap based terrain will only use about half the data to store the positions of the vertices compared to a mesh, this is very important when you are updating/recreating the collision mesh of in my case ~1000 heightfields/vertices per tile 200 times per sec.
The above only applies to the collision mesh of the terrain, for rendering i actually do the exact opposite, but this choice is kind of forced on me since Unity don't allow a lot of freedom when it comes to heightmap deformation, the problem is Unity's terrain component being extremely slow compared to a normal mesh, even worse is i can't update the visual mesh of the terrain without also updating the collider, even if there's no collider connected to the terrain Unity will still internally update as if there was a collider, so when i'm using Truss physics i can get rid of all of Unity's terrain system and roll out my own solution which is about 10-15 times faster.
But even after these steps described above you wouldn't be able to deform a normal sized terrain like a 500m x 500m while getting the high detail needed to create tire tracks, you could increase the heightmap resolution to get the detail needed, for a 500x500 m terrain you would have to use a heightmap resolution of 4096(maximum) that would give you a heightfield/vertex pr 500m/4096 = ~12 cm which is enough, but that also means you would be updating 4096x4096 = ~16.8 million heightfields/vertices pr physics step(collider) and each frame(visual) which is a crazy high number. So to get the high detail needed i scaled down the terrain to ~ 4x4m with a heightmap resolution of 33(minimum) which gives me about the same heightfield/vertex density 4m/33 = ~12 cm but now with only 33x33 = 1089 heightfields/vertices per terrain huge optimization, so i take many small pieces of terrain and tile them together into one big, in my lastest video(see post above) i have a total of 1089 terrain tiles 33 tiles in X and Z directions, which gives me a total size 4*33 = ~130m x 130m terrain, currently i can't go much bigger because of the memory usage of all these pieces of terrain, but i'm working on a couple of things do reduce the memory usage.
Here's a few stats on the performance of the terrain deformation:
Physical deformation time pr frame ~0.04ms pr active body.
Visual deformation time pr frame ~0.01ms pr active terrain tile(optimization in the works which will bring it down to ~0.005ms).
Visual texture painting time pr frame ~ 0.005ms pr active terrain tile.
Hardware specs:
CPU: Intel i7 4790k
GPU: Nvidia GTX 970
RAM: 16 Gb
I'm pretty happy with these numbers but i still believe i should be able to cut of half the time of the physical deformation, i can't do much more optimization to the visuals since about 90% of the cost of those is the internal calls of Unity for mesh modifications, but i don't think more optimization is needed on that anyway.
As mentioned earlier my project is inspired by Spintires in many ways, and the terrain system is not an exception Spintires uses the very same type of terrain system, the developer Pavel Zagrebelnyy of Spintires actually wrote a nice article a few years back about many of the special features you see in Spintires, i suggest you take a look if you are interested in learning more about the subject, there's also another article worth looking at written by Gordon Yeoman the main developer of Nvidia PhysX's vehicle physics(atleast at the time the article was written) my system is loosely based on a mix of these two articles.
PhysX Dynamic Heightfield Modifications - Gordon Yeoman:
https://developer.nvidia.com/content/ph ... ifications
Rendering and simulation in offroad driving game - Pavel Zagrebelnyy: http://www.gamasutra.com/blogs/PavelZag ... g_game.php
The terrain physics is not based on softbody physics, it's actually based on a technique called Heightmap/Heightfield Deformation, the way this works is that you take heightmap based terrain, which is commonly used in most game engines for terrains(this is also what Unity and UE4 uses as terrains), to put it simple you could say i've just created a runtime terrain brush. You might wonder why a heightmap based terrain is used for collision instead of a mesh collider based terrain, the reason for this is very simple if create 2 identical terrains one heightmap based the other mesh based, the heightmap based terrain will only use about half the data to store the positions of the vertices compared to a mesh, this is very important when you are updating/recreating the collision mesh of in my case ~1000 heightfields/vertices per tile 200 times per sec.
The above only applies to the collision mesh of the terrain, for rendering i actually do the exact opposite, but this choice is kind of forced on me since Unity don't allow a lot of freedom when it comes to heightmap deformation, the problem is Unity's terrain component being extremely slow compared to a normal mesh, even worse is i can't update the visual mesh of the terrain without also updating the collider, even if there's no collider connected to the terrain Unity will still internally update as if there was a collider, so when i'm using Truss physics i can get rid of all of Unity's terrain system and roll out my own solution which is about 10-15 times faster.
But even after these steps described above you wouldn't be able to deform a normal sized terrain like a 500m x 500m while getting the high detail needed to create tire tracks, you could increase the heightmap resolution to get the detail needed, for a 500x500 m terrain you would have to use a heightmap resolution of 4096(maximum) that would give you a heightfield/vertex pr 500m/4096 = ~12 cm which is enough, but that also means you would be updating 4096x4096 = ~16.8 million heightfields/vertices pr physics step(collider) and each frame(visual) which is a crazy high number. So to get the high detail needed i scaled down the terrain to ~ 4x4m with a heightmap resolution of 33(minimum) which gives me about the same heightfield/vertex density 4m/33 = ~12 cm but now with only 33x33 = 1089 heightfields/vertices per terrain huge optimization, so i take many small pieces of terrain and tile them together into one big, in my lastest video(see post above) i have a total of 1089 terrain tiles 33 tiles in X and Z directions, which gives me a total size 4*33 = ~130m x 130m terrain, currently i can't go much bigger because of the memory usage of all these pieces of terrain, but i'm working on a couple of things do reduce the memory usage.
Here's a few stats on the performance of the terrain deformation:
Physical deformation time pr frame ~0.04ms pr active body.
Visual deformation time pr frame ~0.01ms pr active terrain tile(optimization in the works which will bring it down to ~0.005ms).
Visual texture painting time pr frame ~ 0.005ms pr active terrain tile.
Hardware specs:
CPU: Intel i7 4790k
GPU: Nvidia GTX 970
RAM: 16 Gb
I'm pretty happy with these numbers but i still believe i should be able to cut of half the time of the physical deformation, i can't do much more optimization to the visuals since about 90% of the cost of those is the internal calls of Unity for mesh modifications, but i don't think more optimization is needed on that anyway.
As mentioned earlier my project is inspired by Spintires in many ways, and the terrain system is not an exception Spintires uses the very same type of terrain system, the developer Pavel Zagrebelnyy of Spintires actually wrote a nice article a few years back about many of the special features you see in Spintires, i suggest you take a look if you are interested in learning more about the subject, there's also another article worth looking at written by Gordon Yeoman the main developer of Nvidia PhysX's vehicle physics(atleast at the time the article was written) my system is loosely based on a mix of these two articles.
PhysX Dynamic Heightfield Modifications - Gordon Yeoman:
https://developer.nvidia.com/content/ph ... ifications
Rendering and simulation in offroad driving game - Pavel Zagrebelnyy: http://www.gamasutra.com/blogs/PavelZag ... g_game.php
Last edited by AndersOrum on 14 Feb 2020, 21:27, edited 2 times in total.
Re: Realistic Vehicle Physics - Made with Unity
This is such a fantastic project! Well done to you and thank you for the technical explanation. 
... and all the videos of course, but I take that goes without saying
... and all the videos of course, but I take that goes without saying
-
AndersOrum
- Level 2 - Grain of sand
- Posts: 26
- Joined: 05 Jan 2015, 03:52
- Location: Denmark, Aalborg
Re: Realistic Vehicle Physics - Made with Unity
Thank you very much
By the way i remember you asked about a way to try it out yourself some time ago, to which i yet again gave a totally unrealistic date for a demo release(i'm about 6 month late for that date now...), anyway without promising an exact date i will promise a release of a free tech demo sometime within the next 2-4 months, however this is not an early demo of a game it's simply a demonstration of my vehicle and terrain systems, after the release i will start working on creating a game based on these systems while also further developing the systems.
By the way i remember you asked about a way to try it out yourself some time ago, to which i yet again gave a totally unrealistic date for a demo release(i'm about 6 month late for that date now...), anyway without promising an exact date i will promise a release of a free tech demo sometime within the next 2-4 months, however this is not an early demo of a game it's simply a demonstration of my vehicle and terrain systems, after the release i will start working on creating a game based on these systems while also further developing the systems.
-
AndersOrum
- Level 2 - Grain of sand
- Posts: 26
- Joined: 05 Jan 2015, 03:52
- Location: Denmark, Aalborg
Re: Realistic Vehicle Physics - Made with Unity
Terrain System Update 6:
This week brings a small but important update to the terrain system. The most important new feature is "Terrain Tile Stitching" you've probably already noticed in my earlier videos the gaps that appears between terrain tiles after deformation have happened near the edges of the tile, this was a very serious issue because it wasn't just a visual bug the same thing happened to the collision mesh, the new stitching feature fixes this issue on the collision mesh which automatically fixes the visual mesh as well.
- Implemented terrain tile stitching. See first 30 seconds of the video i'm driving at the edge of a tile, earlier this would have caused big gaps to appear.
- Reduced GC allocations from an average of 2 kb per frame down to an average of 80 bytes per frame.
- Improved texture painting, this is now based on depth of compression, which means the second layer(dirt) becomes more visible as you dig deeper.
This week brings a small but important update to the terrain system. The most important new feature is "Terrain Tile Stitching" you've probably already noticed in my earlier videos the gaps that appears between terrain tiles after deformation have happened near the edges of the tile, this was a very serious issue because it wasn't just a visual bug the same thing happened to the collision mesh, the new stitching feature fixes this issue on the collision mesh which automatically fixes the visual mesh as well.
- Implemented terrain tile stitching. See first 30 seconds of the video i'm driving at the edge of a tile, earlier this would have caused big gaps to appear.
- Reduced GC allocations from an average of 2 kb per frame down to an average of 80 bytes per frame.
- Improved texture painting, this is now based on depth of compression, which means the second layer(dirt) becomes more visible as you dig deeper.
Last edited by AndersOrum on 14 Feb 2020, 21:30, edited 1 time in total.
Re: Realistic Vehicle Physics - Made with Unity
Soo much looking forward to that tech demo
-
AndersOrum
- Level 2 - Grain of sand
- Posts: 26
- Joined: 05 Jan 2015, 03:52
- Location: Denmark, Aalborg
Re: Realistic Vehicle Physics - Made with Unity
Terrain System Update 7:
I've been working on a lot of changes the last couple of days, but let me start by giving a big thanks to Viktor (aka Heartbroken) the developer of Truss Physics for the outstanding support he's been giving me lately on feature requests and bug reports. This week he made a very important update which i'm currently testing; friction material based on the terrain alphamap layer, this feature allows you to set different friction materials to be used for each texture. It's very flexible so it was easy for me to convert my mesh based terrain data into a format readable by Truss.
This feature is also what i've been waiting for to implement my per vertex/texture soil type system i've been preparing.
So to sum up, i can now have up to 256 different textures per 4x4m terrain tile, each texture with unique friction and soil settings connected to it.
- Per vertex/texture friction material.
- Per vertex/texture soil material.
And also while testing some different tire sizes, i realized i've unintentionally already roughly accounted for surface area of a contact in the deformation calculations, which means a narrow tire will sink more into soft ground than a wide tire would because the wider tire spreads out the load to a larger area, i'll try to make some improvements to this and soon do a update on this.
I've been working on a lot of changes the last couple of days, but let me start by giving a big thanks to Viktor (aka Heartbroken) the developer of Truss Physics for the outstanding support he's been giving me lately on feature requests and bug reports. This week he made a very important update which i'm currently testing; friction material based on the terrain alphamap layer, this feature allows you to set different friction materials to be used for each texture. It's very flexible so it was easy for me to convert my mesh based terrain data into a format readable by Truss.
This feature is also what i've been waiting for to implement my per vertex/texture soil type system i've been preparing.
So to sum up, i can now have up to 256 different textures per 4x4m terrain tile, each texture with unique friction and soil settings connected to it.
- Per vertex/texture friction material.
- Per vertex/texture soil material.
And also while testing some different tire sizes, i realized i've unintentionally already roughly accounted for surface area of a contact in the deformation calculations, which means a narrow tire will sink more into soft ground than a wide tire would because the wider tire spreads out the load to a larger area, i'll try to make some improvements to this and soon do a update on this.
Last edited by AndersOrum on 14 Feb 2020, 21:31, edited 1 time in total.
Re: Realistic Vehicle Physics - Made with Unity
Once again well done, it has been interesting to see variety of terrains.
Just a thought... will we ever get to see a truck plough it's way through a thick layer of wet mud (perhaps on a on a rainy day) by any chance?
By the look of it, you are in the direction of making this happening.
Thumbs up!
Just a thought... will we ever get to see a truck plough it's way through a thick layer of wet mud (perhaps on a on a rainy day) by any chance?
By the look of it, you are in the direction of making this happening.
Thumbs up!
Re: Realistic Vehicle Physics - Made with Unity
Also, since the physics and the mechanics of the vehicle in general seems to be in place, perhaps it is time to push more in the direction of creating a matching realistic physics for advanced dynamic terrains. Perhaps it could be a terrain generator that could generate anything from a lush meadow to a sandy beach. Think it could be very impressive (and useful if you want to make a game based on this technology) to create the environment equally realistic as you have made the vehicles. An example would be to drive a truck into a tree or rock in high speed and see the damage inflicted by the collision on the vehicle as well as the blockage.
-
AndersOrum
- Level 2 - Grain of sand
- Posts: 26
- Joined: 05 Jan 2015, 03:52
- Location: Denmark, Aalborg
Re: Realistic Vehicle Physics - Made with Unity
Yes i already have plans to have weather affect the terrains behavior both visually and physically, MegaSplat already comes with some nice features which allow snow and water puddles to form/accumulate and nice interaction between them, but i want the physics effects/interaction with these features to be in place before i start using them.
But i agree with you i think it's about time to start working on the environment, i already made a simple tree physics test(see video below) about 2 years ago using rigidbodies and constraints to make the tree intractable, it's the same method used in Spintires for it's tree physics(not the small breakable trees or bushes), the only problem i have with this i'd like the trees to be able to be knocked over or pulled out of the ground, but since it's based on PhysX engine i'd have to use PhysX colliders as well and deform that too which isn't worth the cost just to achieve interaction between terrain and trees. But i could start with trees similar to Spintires which will bend but stay rooted.
Terrain generation is something i've been thinking about a lot, since i'm by no means an artist and especially bad when it comes to level design, an automated system would be great, but i fear i'll end up putting too much time into the terrain generation with all the visual and physical details available, i think it'll need a lot of work to make it generate realistic and varied terrains?
Thanks for the feedback
But i agree with you i think it's about time to start working on the environment, i already made a simple tree physics test(see video below) about 2 years ago using rigidbodies and constraints to make the tree intractable, it's the same method used in Spintires for it's tree physics(not the small breakable trees or bushes), the only problem i have with this i'd like the trees to be able to be knocked over or pulled out of the ground, but since it's based on PhysX engine i'd have to use PhysX colliders as well and deform that too which isn't worth the cost just to achieve interaction between terrain and trees. But i could start with trees similar to Spintires which will bend but stay rooted.
Terrain generation is something i've been thinking about a lot, since i'm by no means an artist and especially bad when it comes to level design, an automated system would be great, but i fear i'll end up putting too much time into the terrain generation with all the visual and physical details available, i think it'll need a lot of work to make it generate realistic and varied terrains?
Thanks for the feedback
Last edited by AndersOrum on 14 Feb 2020, 21:32, edited 1 time in total.
-
AndersOrum
- Level 2 - Grain of sand
- Posts: 26
- Joined: 05 Jan 2015, 03:52
- Location: Denmark, Aalborg
Re: Realistic Vehicle Physics - Made with Unity
Terrain System Update 8:
So, just a quick little preview of a cool new feature i've been working on today, this started with me trying out MegaSplat's Tessellation Displacement and Parallax, these features lets you displace the heights of your meshes using a heightmap texture based on the diffuse texture (as far as i understand), however the problem with these techniques is that they run on the GPU which means i can't access the modified mesh data on the CPU, this is a problem because i need access to that data in order to modify my terrain collider based on the mesh.
So i've come up with a new feature that does pretty much the same as parallax or tessellation displacement(displacing heights based on a texture), but instead this runs on the CPU which means i can take the modified mesh data and turn into a collider and make all the changes permanent on all terrain tiles from. There's still a few challenges with this currently it only works with 1 texture per tile and with a fixed uv scale, but with time i'm sure i'll figure out how to make it work seamless with the rest of the system.
The visual mesh and collider stays 100% the same and there's no effect on performance for a complex shaped collider vs a flat one.
I've also worked a little on memory usage and i've managed to reduce memory usage per terrain tile by ~35%, but there's still a long way to go here.
Vehicle System:
- Fixed a bug in the "Open Differential Lock" it will now calculate resistance on each halfshaft/wheel as intended.
Hardware specs:
CPU: Intel i7 4790k
GPU: Nvidia GTX 970
RAM: 16 Gb
So, just a quick little preview of a cool new feature i've been working on today, this started with me trying out MegaSplat's Tessellation Displacement and Parallax, these features lets you displace the heights of your meshes using a heightmap texture based on the diffuse texture (as far as i understand), however the problem with these techniques is that they run on the GPU which means i can't access the modified mesh data on the CPU, this is a problem because i need access to that data in order to modify my terrain collider based on the mesh.
So i've come up with a new feature that does pretty much the same as parallax or tessellation displacement(displacing heights based on a texture), but instead this runs on the CPU which means i can take the modified mesh data and turn into a collider and make all the changes permanent on all terrain tiles from. There's still a few challenges with this currently it only works with 1 texture per tile and with a fixed uv scale, but with time i'm sure i'll figure out how to make it work seamless with the rest of the system.
The visual mesh and collider stays 100% the same and there's no effect on performance for a complex shaped collider vs a flat one.
I've also worked a little on memory usage and i've managed to reduce memory usage per terrain tile by ~35%, but there's still a long way to go here.
Vehicle System:
- Fixed a bug in the "Open Differential Lock" it will now calculate resistance on each halfshaft/wheel as intended.
Hardware specs:
CPU: Intel i7 4790k
GPU: Nvidia GTX 970
RAM: 16 Gb
Last edited by AndersOrum on 14 Feb 2020, 21:32, edited 1 time in total.
-
AndersOrum
- Level 2 - Grain of sand
- Posts: 26
- Joined: 05 Jan 2015, 03:52
- Location: Denmark, Aalborg
Re: Realistic Vehicle Physics - Made with Unity
A small preview of a new powerful feature i'm working on, this will turn boring flat terrains into nicely detailed terrains with heights based on the texture used on each vertex, this gives me detail in the terrain which i never would be able to achieve doing it manually no matter the hours i'd put into it, but with this just a few minutes work gives you incredible results. At the startup of the application/game a heightmap based terrain collider is created from the mesh as a 100% precise copy.
New Features:
- Per vertex heights painting based on texture on the vertex.
- Per Texture Displacement Multiplier
- Per Tile Global Displace Multiplier
- Per Tile Global UV1 & UV2 Scaling
Planned Features:
- Per Vertex Displacement Multiplier
- Per Texture UV Scaling
New Features:
- Per vertex heights painting based on texture on the vertex.
- Per Texture Displacement Multiplier
- Per Tile Global Displace Multiplier
- Per Tile Global UV1 & UV2 Scaling
Planned Features:
- Per Vertex Displacement Multiplier
- Per Texture UV Scaling