Hmm, I was asking because F1 is very much a not drifting race, thats also why I don´t like F1.

It´s like watching snails. The same movement, just faster.

Rally racing is for me much more exciting because it´s going up and down and drifting here and there. That´s fun.

The first time I see a F1 car doing a power drift... that´s cool.

well

Maybe today, F1 cars runs as they are on trails... who played GP4 or GP3 knows what I mean.

But I remember when F1 cars drift a lot. That was really interesting. Viva Gilles....

This car I show in my Project is more suited to a F3 or Formula Renault. Anyway, tyres pressure, suspension stiffness and wings angle contribute to a drift / grip behaviour, in my code, everything can be configured in the "pits" of the game.

There are major parameters hard coded, limiting this setup options to each car type, to avoid a karting behaviour from using a F3 engine power.

Technically its not drifting in that pic.. just power sliding

Also you can drift a F1 car.. you just don't see it happen really because the drivers don't try to drift.
The fact that the drivers don't drift, doesn't mean its not possible

any ways your project sounds very interesting, I really want to see how the physics react.

Question though, you say your not using any physics engine? Does that mean every thing is done with c script? isn't this a little less efficient, and less realisitc (and a lot harder) then an actual physics engine?

VPrime :

Yes, its power slidding at the pic. But it also drifts. Anyway the physical causes are related.

Everything is done with c-script. It´s a lot harder, but far more realistic, at least for racing games that dont want to "be arcade". ( IMO )

Considering c_move() allows for both absolute movement and relative movement, I can't really think of a reason why not to use it(alongside c_rotate()) in absolute. C_move() just translates your mathematical movement while adding collision.

For suspension, I use 5 c_traces. One for each wheel, and one for the chassis. The chassis is rotated according to the avergae of the wheel traces. The chassis trace is to detect things like turbo boosts ect. The suspension is limited so it cannot go to far up or down.

I set up my kart as 2 entities. One contains the chassis and wheels. The wheels and chassis all have bone joints. This entity is passable. The second entity is the collision entity, it's basically a cube. This entity does all my physics work(movement ect.). The level is passable, as I've set up invisible collision walls. This keeps things simple. For kart-kart collision, I keep the karts moving into eachother as passable. By using a scan, I detect karts, then use math to "bounce" the kart in the proper direction.

While my game is arcade racing(think Mario Kart), perhaps some of this might help you in your realistic racing. I applaud you for developing your own physics system, it's quite an undertaking to do right(drifting, gravity mechanics, ect.), but well worth it in the end(one of the best things I did was ditch the physics engine).

Thankyou for your considerations, William, and thankyou again for share your workaround with your kart racing game.In fact, I decided to start developing my own physics reading your posts from some time ago. Thanks for your inspiration lol. Was really a good thing to do.

I use almost the same approach as you, but my wheels are free, dont use bones, and I have suspension arms between the chassis and the wheels, one for each wheel. The suspension arms are still a little unstable, but they almost ready to go, maybe just need a little more work.

I had several problems using glidded c_move, with the car finishing in weird places, due to my math mistakes, probably.

I also implemented my collision with a cube, but I´m still unable to detect its collision with the environment properly.

I dont have a invisible collision mesh, that would be almost impossible in my case, because of the track slopes, ups downs and so on. So I c_trace directly to the track surface. I want the car being able to collide with every poly in the track, and dont want to make invisible walls around all the track and obstacles.

I also tryed to use scan without success, also because of my lack of ability to use it.

My last approach to this was stablish c_traces from extreme positions in the chassis ( front_left, front_right, rear_left,Rear_right ) and look for something that could penetrate the chassis boundaries to evaluate the collision. I had relative success on it, but still need to integrate it in the centripetal / longitudinal forces, and this is being a nightmare.

I´m working a new physics simulation panel to facilitate some aspects of the development, and also have already a system that I call "bricker" , that is something like a in-game WED, to place objects in the game at run time, save the obects position to a file, and retrieve them when loading a level. This system is already working, altought is yet very unintuitive, but make positioning of objects far more easy, as I can see them is theyr place and correct positioning in real time. Maybe I can release this as a stand alone product, as a user contribution, if someone shows interest.

This system is able to place objects right beside another one, to build, for example, fences around the track, or objects alone, like a building or anything else.

i show interest in that ingame object placer! also your game looks good so far.. the cars look good and the physics sounds like it works well.

Thanx bot190 !

Ok.

As soon as I release a demo of my project, I will also release the object placer as a user contribution.

The source code of the physics will be encrypted, but the object placer will be open and free for use, even commercial.