Totally rigid body physics is reasonably well solved by now. It suffers from the "boink" problem; in impulse-constraint systems, there are instantaneous changes in velocity on collisions. This looks OK for small objects and terrible for large ones. This is the main reason game simulations usually look wrong.
If you make everything soft, that works OK. But everything looks like Jell-O, as some early Pixar devs wrote. That's a soft-body system.
What's hard is doing things which have just a little elasticity. Which is most real-world materials. That's because you have to simulate what's happening on very short time scales, much shorter than a visual frame time. This is possible, but the compute load suddenly jumps by orders of magnitude during some collisions. That's hard for real-time systems. Also, you start to need double precision. If you don't need real time, as for film work, it's not too bad. Integration of stiff systems of differential equations is Not Fun. I used to do that stuff.
Actually, rigid body simulators using impulse based constraint solvers can simulate soft constraints (including soft contact), and you can control the stiffness from very stiff to very soft without becoming totally unstable. See this slide deck by Erin Catto: https://box2d.org/files/ErinCatto_SoftConstraints_GDC2011.pd...
The only issue with iterative constraint solvers is the 'long chain' problem, where it's not possible to solve for longer stiff chains of constraints. Direct solvers can do it, but not with reasonable performance/memory usage.
Indeed, you can add a Featherstone articulated body algorithm implementation for such cases, or direct solver with good performance (see Maciej Mizerkski talk on Roblox solver here: https://youtube.com/watch?v=P-WP1yMOkc4)
How about the modern physics engine for the real world? How much energy would it need to calculate all the effects of collisions of the "little" elastic bodies with infinite precision? And how fast would it need to be to calculate them in such a short period of time?
It's amazing to think about all the objects in the universe which collide, always according to the laws of physics, not requiring any cost/resource/energy to such computing loads, and reliably without any uncaught exceptions.
Edit: I meant the theoretical physics engine operating the real world.
> not requiring any cost/resource/energy to such computing loads, and reliably without any uncaught exceptions.
It is highly distributed, in that every atom in the universe is performing this "calculation", all the time. That is literally an ungodly amount of energy. As for uncaught exceptions, they are also performing "only" this calculation, not much room for exceptions there. But let's not talk about quantum tunneling and other weird things that go on in the even lower level VM ;)
Yeah it is incredibly much more computationally expensive when you consider it's a quantum mechanics universe and not a Newtonian, as all possible updates and combination of updates needs to be calculated and all considered together to generate the output probabilities..
I think it should be safe to assume that you always need a computer that is bigger than the mass you are trying to simulate (in every possible aspect).
Sorry I meant the theoretical physics engine operating the real world. For example if 1N of force is exerted on an atom having 1kg of mass, who is to calculate the resulting acceleration of the atom and update the value of the acceleration state variable of the atom? Atom itself or some kind of the universe OS? And wouldn’t it be necessary some kind of energy to calculate it?
Is there an in-between? A “plastic body system” where something behaves as a rigid body until a certain threshold or conditions and then behaves as a soft body during that condition, later returning to RB simulation using the new shape and altered parameters?
That’s what soft-body tries to encompass. You can’t just freeze and unfreeze a soft-body system to a rigid-body though as you’d end up with odd behaviour and a non-trivial decomposition. How many rigid bodies is this soft body now? How are they constrained relative to one another? And how to decompose the new shape into suitable collision primitives?
Simple mass-spring systems (like this) have issues with really stiff springs and high masses causing unrealistic responses even with a low time step but you can use approaches like XPBD which are stable. Changing the configuration of constraints is what causes the shape change.
Most vehicle sims get really far with just using a rigid-body system and modelling the damage another way. It’s much computationally cheaper, much cheaper in terms of time to setup a vehicle and lets you maintain high fidelity in the driving model which is the bit most players care about.
Engineers have been doing this kind of thing for a very long time. Animators just take lots of shortcuts because they can, but we’re probably at the point (if it doesn’t exist already) where you can animate with the actual properties of real materials with different models appropriate for the specific material.
An engineer designing a product can certainly run it through a simulation that accurately predicts elastic and plastic deformation as well as fracture and other failure modes.
Problem is that artists makes rigid models in other programs they aren't made to have proper structural integrity. Rigid body physics lets you work with those models anyway, with proper physics you'd need to hire real engineers to design the different vehicles and structures and weapons in your games so they don't collapse on themselves.
It's nice to see this on the front page. AFAIK, many years ago the development team split and BeamNG.drive was born. Rigs of Rods stagnated with new features and development, while BeamNG continued improving and adding new content. Today BeamNG is far superior in every aspect: physics, graphics, content.
And tires, beam NG tire simulation is not the best out the but is far superior to ror
With the addition of multilayer trough mods it also filled the last feature gap
My only gripe is that devs have a scant idea of how control input should work for games, and recently introduced a steer limiting system that is all around bad and broke the two previously working mods that did it great, including mine, so racing is now bad again unless you have a steering wheel
I work in the industry and always thought iRacing model was the most detailed but wanted to know if someone knew a better model.
It's a shame they don't license their models for engineering customers (like rFactor does), since it's a single made-up parameter set tuned to make things feel "real".
They recently added experimental Linux support. Performance is way better, but unfortunately it crashes fairly frequently. It has been getting better every update though.
I can't speak for Wine, but my son uses it on Proton regularly and except for a few brief glitches after updates and the inability to use the steering wheel controller, it's worked very well. https://www.protondb.com/app/284160
They have the game BeamNG.drive, and they also have something called BeamNG.tech
> BeamNG.tech is an academia- and industry-oriented fork of BeamNG.drive. In content and features, it largely overlaps with BeamNG.drive, and offers additional functionality to support driver training simulators and the development of advanced driver-assistance systems (ADAS).
> […]
> BeamNG.tech is released under a mix of commercial and open-source licenses by BeamNG GmbH.
But it’s not clear from this page if they provide source code for the commercial parts of BeamNG.tech to customers or not. I guess you’d have to contact them and ask. Contact details are at the above linked page.
And they use Torque which is licensed under MIT https://torque3d.org/ But that’s just the graphics not the physics enginge which haven’t been released. Rigs is using Ogre https://www.ogre3d.org/
From what I recall, RoR was a bit like BeamNG.drive "Lite": something that's nice to play around in, if a bit more barebones and could clearly use a bit more love. Then again, I think that both had slightly awkward UI and keyboard shortcuts, plus RoR is free.
I can't believe this is still around. Back in 2005, I made a "vehicle editorizer" to build vehicles graphical using a VB6 GUI. I even had someone contribute a feature that enabled comments in the output. I was shocked they were able to read my code at that age.
Before my program, you had to plot out your vehicle points manually and type it up in a text editor. There was a lot of scratch paper involved!
That is fantastic. I made an autoit GUI that enabled easy creation of scripted weapons for GMod about a year or two after your tool. It got decompiled and re-claimed by another, and everyone knew what he did. It also flooded the forums and mod content hosters with "low-quality pre-generated SWEPs". :)
I remember playing around with this like 14-16 years ago ha. It was so hard for me to create and import a box for a car chasis. Pretty cool though, there was a 4-engine Antonov on there was hard to start/fly.
A complete noob question (I am not a gamer and not a game developer):
Is this a big thing? I.e. is this enough to start a community-driven effort to create an open source alternative to something like GTA (at least in gameplays I watched transportation seems to play a big role)?
I have been wondering for a while why there is no open-source open world game similar to GTA, considering its poppularity.
Building something like GTA requires significant resources. The vehicle simulator part is a small part of the overall challenge with building something like GTA.
The main challenge for building a game is the content - the art, level design, enemy design, terrain, story, etc. The game engines and coding tend to be (a) more portable between games and (b) have more people interested in contributing relative to the need.
I was part of a game design group in college, as an extra curricular. We had tremendous unmet needs for art and sound design, which really limited the games we could make - maybe one or two game the 6-12 projects each year actually had the skills they needed. Part of that was probably the group running out of ACM and thus just having better ability to attract CS than art types, but I got the sense it was partly the type of people interested in building games for fun.
A central repository for FOSS scenery, vehicles, buildings, graphics/audio content in general, would help a lot the development of new games. Artists could gather on a public forum to discuss and collaborate, then add their creations to the repository rather than support just a single game, so that developers could concentrate on the code itself knowing they could count on a huge library of assets ready to be added. Think of GitHub/GitLab/Codeberg etc. but for art and media content. Not that one of the above couldn't be used for that goal.
There is https://opengameart.org/ . Major limitation to this idea is that for a decent looking game the assets need to be consistent. Not only in terms of art style, but also detail level and technical constraints. For example if you want a modular building parts some random assets created by different artists without targeting a specific game requirements will probably not be compatible with each other or building system in game. Not only 3d model can be too low quality, having too high quality can also be a problem. You don't want some unimportant background prop to consume more triangles than main player character. It may look better to have less and worse quality but consistent assets, than more mixed quality assets.
It might be slightly simpler if you assume realistic 3d art style. But even then what's considered realistic 3d game art has significantly changed over the years.
Maybe this would work better if the repository served not only dumb file storage but tried to establish set of target requirements (updated once every few years) to improve the compatibility assets. Something like opengame-3drealistic-2020 or opengame-2dtopdown-pixelart-v3. Where each category means very specific rules and maybe some reference pieces meant to ensure compatibility. Downside is that it significantly raises the entry barrier and reduces amount of artists willing to make something which fits very specific requirements, instead of making whatever they want and then sharing their work. I am also somewhat concerned about loosing creativity.
Communities like Sketchfab [1] serve some of these needs. Although not 100% FOSS, ‘content hubs’ like this can be a fun place for creators/artists to share their work — and to potentially get paid — and for others to hunt for high quality assets. Sketchfab was acquired by Epic Games in 2021. [2]
Maintaining stylistic consistency from one asset to another is a challenge, however, but maybe upcoming advancements in AI-powered tools like Point-E [3] will enable assets of one style to be re-envisioned en masse into another style. E.g., a text prompt could be “I want all assets from artist X and artist Y to be stylized like the game GTA: Vice City.”
It's about typical for modern physics engines.
Totally rigid body physics is reasonably well solved by now. It suffers from the "boink" problem; in impulse-constraint systems, there are instantaneous changes in velocity on collisions. This looks OK for small objects and terrible for large ones. This is the main reason game simulations usually look wrong.
If you make everything soft, that works OK. But everything looks like Jell-O, as some early Pixar devs wrote. That's a soft-body system.
What's hard is doing things which have just a little elasticity. Which is most real-world materials. That's because you have to simulate what's happening on very short time scales, much shorter than a visual frame time. This is possible, but the compute load suddenly jumps by orders of magnitude during some collisions. That's hard for real-time systems. Also, you start to need double precision. If you don't need real time, as for film work, it's not too bad. Integration of stiff systems of differential equations is Not Fun. I used to do that stuff.
Note, in the video, how soft the suspensions are.