I had a good one, but I moved it to my other monitor and it got cropped because ShareX doesn't know about HDR and blows out white pixel color ranges, but you get the idea https://i.imgur.com/cYbxStI.png
Can we all stop using imgur now? It's been like an hour, one of those images has been flagged as adult content and the other is 404ing. postimages.org is good
not 100% related but is there any good information source on the web to learn how to build a good car simulator ? I've looked around and it's not very helpful. Usually I end up with physics courses which always repeating the same things. But not much about about : pneumatic (especially how they influence the overall speed), independent wheel modelling, suspension, mass shift, frame deformation, ...
I've checked the source code of torcs but it seems quite simple (although the results are very convincing).
I work as a vehicle simulation engineer for a Motorsports team.
What you're looking for is broadly classified as Multibody Dynamics. You can model each part individually and connect them to make a complete simulation. There are two parts to building these types of models:
1. IDE and Language - Modelica, ADAMS, Project Chrono, SimScape etc. There are open source and commercial solutions for this.
2. Libraries - Claytex, Modelon etc. most detailed vehicle models and components are sold separately. These are typically written in Modelica. Some IDEs like MapleSim or Mathworks bundle it in their IDE.
You can build your own components from scratch but it takes time.
I was vehicle physics lead for a couple of games that sold very well, but are not considered racing sims. Happy to answer questions as best I can.
What is missing from Torcs? It looks like a pretty good place to start, it has independent wheel modeling, and suspension, and mass shift of the car (I suspect it can handle mass shift of the driver if that’s what you’re after).
You can probably model frame deformation yourself by building a frame in a physics engine out of flexible parts and/or joints, but I’m skeptical that it’s worth the effort when modeling indoor karts, I’m not sure they flex enough to matter, but it depends on exactly what you’re trying to do.
The car physics my team built was made on top of the Bullet physics engine, so Bullet handled integration and collision dynamics, and we added transmission, braking, suspension, wheels, etc.
It’s definitely worth asking yourself how good you need the simulator to be, and how serious you are about this. It’s a multi-year project to get something “good” and/or better than Torcs. I would tend to agree with their answer to the FAQ question “should I start my own racing sim project?” http://torcs.sourceforge.net/index.php?name=Sections&op=view...
That's a very good answer. Torcs is good but somehow the code is not 100% clear to me (I didn't catch the independent wheels simulation for example).
Flexing frames maybe overkill, you seem better placed than me to estimate that.
The FAQ answer address the difficulty of running an OSS project. It doesn't address the difficulty regarding the physics (which, I understand, maybe even more mindbending).
This is a hobby-level project. Nothing serious. I'm more interested in understanding the maths and physics. Having watched hundreds of races (my kid drives), I've seen behaviors which are pretty specific to karts (I guess). For example :
- driver mass shifts do matter (pilots constantly use them)
- karts jump when taking corners too fast and too tight (they usually slide, but when it's too much, they do jump, and decelerate...)
- turning wheels left/right very fast is used to brake during pit stops.
but you're right, I may be out of my league here :-)
By all means, go for it, just do it with eyes open, it’s a lot of work.
The other thing I’d add is that the physics models is only half the battle. The car and track geometry is critical to making an accurate simulation. It’s easy to get wrapped up in the car physics and forget to deal with the angles and bumps and materials and temperature of the road surface.
Cameras are huge too, if you do anything other than a fixed interior cam. A naive follow can behind a car can totally undo all the physics.
The FAQ answer is the kind if condescending tone that I don't like and some developers of long running OSS projects use after a while. I know that these projects are hard and take lots of effort. I've experienced it myself. Warning people that X is more complicated than it may first seem is perfectly OK. But telling them to just stop is wrong. There are valuable lessons to be learned by starting from scratch. Commanding them to help out others instead denies them this experience. Sometimes the journey itself is the goal.
Speaking personally, it would be safe to say my career successes are defined by ignoring warnings like this and doing something from scratch anyway.
So I completely agree, and I guess this FAQ answer is really meant to talk to the casual developer who doesn't know what they're getting into. The person who does know and does it anyway will (and should) ignore stuff this like. I don't think it was meant to be condescending, I took it more as a joking tone but with a real warning that it's a long road, which is true.
depending on how much you want to cheat, since indoor kart don't jump (aren't supposed to, at least, been at a bad track that ruined my back once) can use a very simplified 2d model using acceleration to estimate weight transfer to render suspension/tires getting loaded.
I wrote an extension for it that handles loss of traction, power drifting and mapped terrain friction that I can share, it's all mit licensed after all, but it's in Java, it's simple enough to port it whatever language you want because it's just math primitives
Hello :-) My kid has been driving indoor karts for 4 years now and he's around 0.5 sec behind top drivers (which is very good and not good at all, depending what you're looking after). I've observed him on hundreds of races and karts do jump :-) They jump when coming too fast in a corner and turning strongly. In that situation, the wheels slides a bit and then regain grip instantly. When that happens the kart starts bumping around the front wheel which stands outside the corner. This costs a few 0.1 of seconds (that's huge in races). This happens to experienced pilots as well but they usually manage to find the limit in the curve and better breaking points to avoid it.
Simulating this is what interests me because it seems absolutely non obvious.
As said by someone else, maybe I'm looking at a problem that his out of my reach (my physics skills are rather weak). That is, I have no idea of how that happens.
I found this article that goes in depth into kart cornering[0]. It talks about chassis flex and briefly mentions wheel hop.
I'm not a physics person either, but wheel hop seems to occur when the force overcomes friction between tire/track, causing an oscillation between grip/no grip. It is a lot worse on vehicles with suspension, because they have more give.
I find it easier to visualize with a car, because it is more pronounced. Although with a car it is usually occurs on a standing start, whereas with karts it is a lateral force thing.
This karting forum suggests high center of gravity contributes to wheel hop.[1]
Cars are pretty complex. Sony spends years modeling various ones in its “grand turisimo” game.
But simpler games model cars pretty well, I’m assuming with a dozen or so parameters (turning radius, acceleration, tire grip, suspension..) you should get something. The “pako ios car simulation” (not open source), has a bunch of cars you drive around that behave more or less like actual cars.
before you venture there I suggest you move the control code outside of the physic code, abstracting car inputs into a throttle, brake, steer structure which is piloted by inputs elsewhere and feed into the physic update tick along with the car state, or it'll make exceptionally hard to build input prediction and lag compensation further on
funny that you give multiplayer to people and they will use any chance they get to display creativity. look at all the pople trying to draw with their tyres!
This is great and inspiring. Every few months I spin up a socket.io server and attempt to make an RPG. I get about as far as having the character move around the screen and then usually give up :D
I do a lot of making games just for the fun of it. Good advice I heard is that you're making a game _or_ a game engine. Pick which you care about most and focus on that.
I found that phaserjs is a good engine but you still have to do a ton of stuff that other engines give for free. Chiefly, the rich game dev UI that Unity, Godot, Unreal, etc. all have. Don't be discouraged by the different languages. Programming is like 15% of game dev and you can easily make a fun first RPG using examples and stack overflow, and get comfy with a new language along the way.
How long would it take to make the whole screen one color (excluding the red car)? And what is the best strategy: driving in circles or fast alternating between gas and brake?
I see that it works on mobile but u can not for the life of me figure it what the control scheme is. I just touch the screen and the car and to randomly move.
I love how instantly hackable this is... clone the repo and serve the directory localy and still connects through websockets, no npm crap in the way. :)
> Looked fun, I was just worried about game performance and server bandwidth usage..
Yes, that turned out to be a legitimate concern... later on I saw people go a step further and write entire sentences out of cars... they probably didn't realize but it was effectively DoSing your server and preventing anyone else's socket emits getting through so all you could see is the text.
I guess it's a difficult balance if you want to allow playful hacking but don't want to be DoSed. (BTW it's easy to bypass the origin restriction by just injecting code into the browser), perhaps a better restriction would be a max sockets per session or IP, that would still allow some hacking but reduce chance of DoS intentional or not.
Anyway I changed tack to try implementing some basic bots in smaller numbers. Was fun to see how people interact with them.
https://imgur.com/a/AIxvWUh