• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

bmarci

Members
  • Content count

    138
  • Joined

  • Last visited

Community Reputation

786 Good

About bmarci

  • Rank
    Member

Personal Information

  1. Hi, Great, meanwhile I found your other post regarding this issue, and managed to bring it to live in my code :) It has a bit of oscillation, but with reasonable threshold that can be "neglected".   thanks for the hint!
  2. Hello, It might have been asked earlier, but the question is not answered yet. I have a hobby vehicle simulation I've been doing in my free time and now I have some spare time to work with that again.   The main situation: My simulation is running at 1000Hz I use a custom swept-box collision with the environment, that is not satisfactory, sometimes inaccurate and not fast, it's ok for one car though.     I started playing around with bullet (again) and wondering if it could be used for collision and simulating other rigid bodies. My concerns: The bullet (and all other physics engines) run on low frequency 60Hz usually. My suspension and tire simulation needs higher frequency therefore the car's body must also be updated 1000times a second. And the problem is, it needs to collide with the environment, the other cars, and occasionally dynamic environment objects.     I tried setting the internal timestep of bullet to 1000Hz, but that way a bunch of boxes and convex hulls ate up most of my cpu time, so that's not an option. I also tried having a "dummy" dynamic object with no gravity that is updated according to my simulation (setting transform, linear and angular velocity that I calculated) It worked "somehow" but the collision response was weird and also sometimes it sank into static geoms and occasionally went through them. The kinetic body works "perfectly", but it doesn't collide with the environment also the dynamic bodies are just pushed away regardless of their mass. So, also useless.     I'm also thinking of not modifying the bullet's body directly  but adding forces/impulses to translate it to the position that I calculated. I'm not sure if it could work.     So, does anybody here have any experience with this kind of issue? I read about ghost objects, but it's quite hard to find usefull info on how to use them for this kind of purpose.   thanks in advance for any help or idea.
  3. More problems there:   The spring speed is not only the difference of the the last and current position. You should multiply it with the timestep. (1/60 if your simulation runs at 60Hz)     This one seems to be a hack because of this:       The 0.4 stiffness is too small, unless you are making RC cars, this value should be between 8000-10000 for street car, 30000-50000 for sports cars and around 200000 for a F1 car. Also the damping should be much smaller than stiffness, maybe 10-20% could be a good start. Later, if you want to be more fancy, real dampers have different characretistics with compressing (bump) and expanding (rebound). The bump should be smaller. an example: when you drive over a bump, the wheel should react much quicker than when you drive into a hole.   Also what Mike wrote about the signs are correct, and you should check the signs of contactDepth and contactSpeed. The depth should be negative when the car is on the ground, and the speed should be negative then the spring is compressing.
  4. Hi, I remember this was the most mysterious part in my sim. I couldn't find any usefull info on the topic, not even here, only foggy and misleading docs everywhere, like it had been the most difficult problem of life, or something. It was very frustrating. I also remember trying what you did, just spinning the rear wheels (fake it) and managed to achieve quite believable result. And finally I god enlighted by myself :) I strpiped down the problem to a simple acceleration test in 2d (side view) having only one wheel. It was much easier to follow what the heck is going on.   First forget about the differentials, they make your problem even more difficult to get it right. Do a fixed axle for first.   So, in a nutshell; You have to differentiate two major cases, when the clutch is locked and when it's "slipping".   When locked, the whole stuffs rotates together and can be handled together. You can indeed derive the rpm from speed, but instead of using linear speed use the wheels angular velocity. Calculate the torque from the engine, through the gearbox to the wheels and accelerate only the wheel usng (torque_drive + torque_road) / effective_inertia As you accelerate the wheel calculate the rotation speed of gearbox and engine back from the wheel rotation. Pretty simple. When the clucth is not locked, you have to separate the engine and the rest of the driveline. Use the engine torque to accelerate the engine only, and do the same as in (1) to the gearbox to wheel acceleration with the difference of using a portion of engine torque. The "portion" is the amount that the clutch can transfer depending on the pedal position. Here is an extra torque created by the clutch that accelerates and decelerates these two to synchronize their speed. And the same as above calculate the gearbox rotation speed from wheel speed (the engine is calculated separately) And you are done. The only thing you have to take care of is when to open and close the clutch, and its only a relation between the pedal position and the amount of torque going through it.   I hope it was clear somehow. You'll need this: http://www.racer.nl/tech/effinertia.htm to calculate the inertia of the whole driveline or just part of it.   Regarding transmission efficiency, I didn't have an idea where to "put" it, so I just left it out. It looked cool without it, though. My guess would be, it's enough to use the efficiency "loss" once, when the torque is calculated that accelerates the wheel. The reaction is handled at the wheel too, it's "not going back" to the engine that way.
  5.   Yes, it's my recreational hobby stuff that I make if I don't have anything else to do :D Doubles are 64bit !!! Racer is using 32bit floats and also 1000Hz update rate, so it should be fine too. I sent you the integrator docs in PM.
  6.   1000N/m is almost nothing, that's suspicious indeed. My stiff suspension has 200000N/m and seems very stable. Here is an example for an F1-car: ?https://www.youtube.com/watch?v=-zhmOuBhNwA   I saw a car demo (source) that used RK4, and seemed too much overkill in the source. Some components are yet too complex with euler, I don't even dare to think of how would it look with RK4 :)     No, only explicit Euler, no inner-loops. acc = F / m vel += acc * dt pos += vel * dt that's it.   My update looks something like this; 1. For every component: Stuff->CalculateForces(); // This only calculates force values like normal load, traction, air resistance...etc 2. For every component: Stuff->Integrate(); // Advance in time (1ms delta-time in my case) calculating acceleration and position change...etc 3. Apply forces wherever they needed.   as a second note: I use double precision, because of the above mentioned small numbers and precision issues
  7.   So, I did, and my results are not realistic at all.   The Fx looks ok, but the Fy is totally off, I tried to figure out, and double-checked the formulas, but can't see anything.   with these inputs, only slip angle: Fz = 2500 s = 0 alpha = 10degrees (in radian) camber = 0 (gamma maybe) The magic parameters are taken from the 3rd column (P185/70R13)   Fy is ~69.9
  8.   It would! :)   A couple of years ago I found an other tutorial from Marco Monster, "Achieving a stable simulator" or something similar it was called. It described the very same thing you are looking for; RK4 vs Euler, and why it becomes unstable, and what to do to achieve RK4's precision with Euler's simplicity.? I tried to find it on the net but no success, I might dig up my old stuffs, maybe I saved it somewhere. Even if it won't help, you will surely understand why springs are unstable with Euler at high delta-time.   I only use explicit Euler everywhere and it works like a dream, the key thing is frequency. Somewhere I read about Grand Prix Legends (1998) they used 330Hz update rate. I use 1000Hz. With the standard 50-60Hz that physics engines provide, you won't go too far with Euler :( ?You can try RK4, but as someone mentioned earlier, you don't want to, EVER!!! :)     If you have high-profile super realistic simulator in mind, you may consider switching to C++ or other native languages, you'll be glad later ;)
  9.   Great, did it work for you? I already found this tire model somewhere else, but that one didn't give any of the magic tire constants. Without those it was just a pile of useless math :) I'm curious about its combined slip behavior.   This paper also forgets to mention about the Ygamma at camber calculations :) I'll check when I have some time.
  10. you can't do that, or you can but no use. Observe that the curve falls back after the peak, so at least two slip value belong to the same F. the best method is (I used it too) what Edy mentioned. It becomes tricky if you use load sensitivity, because the curve changes shape. I came up with a simple solution: I sampled the max F's and corresponding slips at every 100N of Fz. That means 100slip values for the 0..10000N load. In the sim I just interpollated between them and it gave a very good approximation. For lateral slip it's more fun because the camber also affects the max Fy, but if you think of the bilinear filtering, yo'll be fine :)
  11. you will probably not find any of those data. you'd better start with a free/open source sim, like racer and check the available car datas. you'll find a pile of cars for racer and for rfactor, both of them have car setups in text files. very good starting point, and just experiment, experiment, experiment! tweak those params in your sim as long as you don't have the result you want.
  12. unfortunatelly some of these things are beyond math or physics. you have to learn how things work and figure out some logic that mimics the real thing. you can write accurate simulation, but many times it's just overkill and no visible difference anyway. apart from some basic math there are no universal equations that fit all sims. this is why it's difficult, and this is why we like it :D you may already found this site: http://www.racer.nl lots of technical info and the source of an early version is still available. you may also want to check out the rec.autos.simulators google group. around 2000-2003 search for [car physics] you'll find posts from people who later made test drive unlimited, assetto corsa and such games :)
  13.   Actually they can sync when the clutch is not 100% locked. And in extreme cases it can slip when you don't even touch the pedal, but usually this doesn't happen :) In the 3rd case when the clutch is not locked there are two possible cases. The torque is (1) limited to the amount that the clutch can transfer  or (2) just apply the current clutch torque. For some mystical reason I did the second one. I just found the first one commented out in the code, don't ask why :D   for example: the maximum clutch torque is 400Nm the engine is producing 200Nm and the pedal is at 25%, so the current clutch torque is 100Nm in case of linear clutch. In this case the actual torque that goes to the gearbox and accelerates the wheels is 100Nm In an other example the pedal is not pressed and the clutch is at 100% the max torque is 400Nm In this case I add all the 400Nm to the gearbox, even if the engine produces only 200Nm   First this seems odd, but this only happens for only one iteration and the clutch gets locked instantly and the angular velocities are fixed together. Handling the clutch lock/unlock scenario is very important in this case. The slipage of the clutch is not related to the pedal position but the torque that goes through it. So with little amount of throttle the clutch can handle all the torques from the engine even if the pedal is only half way down. And as you start pressing the pedal so decreasing the clutch torque it only gets unlocked when the transferred torque exceeds it (in any direction).   Detecting lock is simple, just check if the angular velocity difference changes sign :) simplier: when the wheel starts turning faster that the engine (after applying the torque) - or slower in case of engine braking.       The friction model also seems to be reasonable, but harder to find that "scaling parameter", and without proper damping the wheels will always over accelerate and will never sync just oscillate back and forth like a suspension without damper. Also the clucth will never lock instantly and you'll probably have a nice lag. I never tried this one so I'm not sure ;)
  14. I think the traction control has nothing to do with physics and there is no equation, it's just a "programmed" logic that handles the "too-much-slip" situation. As said above applying brake and cut-off throttle are both used. I've been only using the last one so far and quite happy with that. The main difference is when you are applying brake, different torques can apply on each wheel, while when cutting off throttle will affect both wheels.     That's something different. You should be able to drive with keys without traction control. Seems more like low-speed-slip situation, when you divide with ground speed in your slip ratio calculation. Try capping the value between -1..1 or -1..10 maybe :)
  15. sure, every physics lib that handles forces and torques has it :) the weight transfer is a derived figure that you can calculate from the simulation, and not something that you have to do yourself. it's like the engine power (horsepowers)