Tokamak Car Demo
Blitz3D Forums/Blitz3D Programming/Tokamak Car Demo
| ||
| It uses spheres for the wheels and this seems to defy logic to me. For one thing the car won't turn unless you are applying torque to the wheels because with a sphere it doesn't actually matter which direction it's facing with no torque being applied to it ... it will just roll opposite the velocity of the rigid body. Also, the vehicle rolls down hills sideways for obvious reasons. Now I tried throwing some cylinders on there and the car basically just bounces a lot. I tried to adjust all the cylinder parameters to be similar to the spheres etc... has anyone overcome this issue with Tok? One thing I have to say is that using Tok for a networked game is actually very easy. Many people have complained but I'm not sure what all the fuss was about. Anyway, some insight on the cylinder issue would be nice. |
| ||
| > One thing I have to say is that using Tok for a networked game is actually very easy. Jeremy, do you use a single server to run the physics for all cars? Or do you do more of a peer to peer setup and run physics code on each game client? Regarding the latter, it seems hard to adjust the positions and velocities of tok objects - tokrb_setposition seems guaranteed to cause a freak out whenever I use it. |
| ||
| I have tried all possible kind of wheels in Tokamak but the spheres are the only ones that give the car a somewhat good beaviour. Sadly the frictionmodel in tokamak sucks when simulating car-tyres and I think that to get a realistic simulation one has to implement Pacejka's formula or something similar. Regarding using Tokamak with network. Couldn't one run the simulation on both the server and the clients? The server handles the "Master simulation" and send updates to the clients simulation every second or less to keep the simulations in synch. The client's simulation will take care of movements while waiting for the next synchronizationevent. A synchronizationblock could contain: Position , 12 Bytes Rotation , 12 Bytes Body linear velocity, 12 Bytes Body angularmomentum, 12 Bytes ------ 48 Bytes (Is this too big?, I've never done any game network coding before) |
| ||
| I've been doing tokamak networking for a while and it's VERY tricky to get right. 48 bytes isn't too big. I think you can safely send 300-400 bytes 10 times a second. The main problem is recieving, not sending, but luckily most connections recieve far more than they can send. This is where the server has to be very clever and optimise whats sent. |
| ||
| Maybe I should move this thought to the TOK support forum but it's network game related. I like the method that Sweenie describes but I get big instabilities when moving a TOK object that's in motion. And isn't that what you have to do to sync up different clients? I've even tried, with no success, setting them to zero linear and angular velocity and then moving them. Rob, do you do physics sim (tok or ode) on the clients? |
| ||
| the TOKAMAK car demo uses SENSORS I believe. |
| ||
| For networking, I simply send the position and the velocity (via TOKRB_GetVelocityX() Y() and Z()). Then on the other end, TOKRB_SetPosition() and TOKRB_SetVelocity(). It comes out really smooth updating only every 100 millisecs(). The simulation advances the rigid bodies automatically without dividing by the time interval difference. This was with a peer to peer setup. The only tricky thing is going to be collisions but I think that what I'd do is detect the distance and then apply a force via a packet instead of letting the simulation actually work because it isn't completely accurate. Basically, it doesn't have to be spot on because we're not testing air bags with crash test dummies ... we're just trying to get a game to be fun and intuitive. Intuition of course tells you that a crash can happen ;) Anyway, I've just begun toying with this stuff. The first thing I did was throw together a quick network app since that's what I really enjoy making and people seemed to complain the most about ;) I hope to have a simple game done soon, followed by a decent app for vehicle physics, and then a really nice stunt track racer. Just hope to get a simulation using cylinders because spheres are just wrong. Hopefully they'll fix the friction issues for tires. They need a tire object TOKRB_CreateTire() ;) |
| ||
| Well, this doesn't solve the friction issue, but a true tire shape could be achieved with a bunch of box geometries.If you have trouble seeing how this works - imagine a wireframe cylinder. It has a bunch of quads going round in a circle, with a top and a bottom. So, why not just create boxes with one side on the quad, extending out to the other side? I'm not sure exactly how well the physics will work with it (who knows - might go insane), but it's an idea. |
| ||
| Even if you make a wheel that looks like a real tire there are still alot of things that the physicsengine won't handle. Rubber deformation and such. It's like driving a Porche with wooden-tyres. The only solution is to "cheat". Even the Tokamakteam "cheats" by using sensors(as Bradford mentioned above) and some custom friction code. |
| ||
| Are sensors included in the Tokamak dll yet? |
| ||
| Yes, but I need just a little more time before releasing it. A week or two. |
| ||
| ah, great...thanks Sweenie. I'm looking forward to that release - sensors should allow a much simpler suspension model. |
   |