#9 Vehicle physics behaviour when not contacting ground

open
nobody
None
5
2017-05-26
2012-08-15
Farrer
No

One thing that bother me a lot in Trigger-Rally is that when the car loss its contact with the ground (ie. none of the 4 wheels are contacting it) it seems like it's not a heavy mass of steel, but a child's baloom...

This patch is an attempt to fix this. The idea is to apply a force to the car mass center when all wheels are not contacting the ground (the force intensity could be changed by the constant FORCE_WHEN_LOSS_CONTACT). The side effect of it is that the car will be more glued to the ground (I liked it, but maybe you won't). Some adjusts to the constant make this "glue" less or more effective (the current value on the patch is what suits me best, but should be changed depending on the feel of the trigger-rally developers).

I hope it's usefull.

Discussion

1 2 > >> (Page 1 of 2)
  • Farrer

    Farrer - 2012-08-15

    The patch which does the behaviour explained above

     
  • Iwan Gabovitch (qubodup)

    This feels very strange after I got used to TR's moon-flight physics :)

    Videos of driving straight on Smallswirl:
    without patch http://youtu.be/Hh82utIaLbg
    with patch http://youtu.be/O8lrpxeV9MA

    Are there different physics depending on whether the car has contact to the ground or not?

     
  • Farrer

    Farrer - 2012-08-17

    There's no change (unless the car loss often contact with the ground when running, which maybe happen).

    The only thing the patch do is to apply a down force ("gravity"-like) everytime the car is fully not touching the ground (ie: when none of the 4 wheels are in contact with it), besides the normal physics behaviour which is always done.

     
  • Iwan Gabovitch (qubodup)

    It's interesting to try but I don't see how having the physics change depending on contact to floor can be accepted by players in a (more or less) realistic-looking racing game.

    The changes to solve the "flight" problem would probably have to apply to any state the car is in to be acceptable to players.

     
  • Farrer

    Farrer - 2012-08-19

    The patch was just a quick try to work around the problem, so no need to worry about it too much...

    Anyway, if the force was applied as a real gravity, affecting the car all the time (to do it, just comment the "if(noContactCount == 4)" at "src/psim/vehicle.cpp" patched file), the car will enter the ground, acting as if it is of water and the car a boat, which is yet less desirable for a car game (maybe an anphibyous game? =^D )

     
  • Onsemeliot

    Onsemeliot - 2015-08-01

    It sounds reasonable to me to apply the gravity all the time. So the real question seems to be: Why does the car enter the ground when it does actually weight something. Is the physics calculated only by the wheels contact to the ground or is there actually some gravity calculated already?

    What bothers me the most about Trigger Rallys still remarkable physics is the behaviour it is showing when ever two wheels loose contact with the ground since its reacting like on soap then and its nearly impossible to get the car under control again. It's bouncing from one side to the other like it could never happen in real life. I don't understand the logic behind this but the "flying car effect" does bother me much less.

     
  • Am Ma

    Am Ma - 2017-05-03

    What do I have to do with .diff file?(how to install it?)

     
  • Onsemeliot

    Onsemeliot - 2017-05-03

    You would have to apply the difference to the relevant game files. (To the code directly.) But I wouldn't recommend doing that since the result is worse than the present behaviour. And I'm not even sure if this diff is still correct since the code was altered afterwards and I can't tell for certain if it doesn't affect parts of what the patch would touch.

    Maybe Andrei can give a definitive answer. But so far nobody has actually had the impression that the patch has the desired effect.

    In the mean time there have been other attempts to solve this issue, but unfortunately none so far was satisfactory.

     
    Last edit: Onsemeliot 2017-05-03
  • Andrei

    Andrei - 2017-05-03

    That patch is outdated and cannot be applied to the current 0.6.5 code as-is.

    However if there is interest, I could incorporate that patch into 0.6.6 and add configuration parameters for it in trigger-rally.config.

    On the topic of physics, since I am unable to fix them, and since they're pretty bad (e.g. the first jump in "Jumpy" always crashes my car) maybe we should look into arcade handling to get ourselves unstuck and make some progress.

     
  • Onsemeliot

    Onsemeliot - 2017-05-03

    Sorry, but I don't get what "arcade handling" stands for. Do you mean unrealistic but comfortable physics instead of real (but wonky) physics like right now in Trigger Rally?

     
  • Andrei

    Andrei - 2017-05-03

    Sorry, but I don't get what "arcade handling" stands for. Do you mean unrealistic but comfortable physics instead of real (but wonky) physics like right now in Trigger Rally?

    Yes, that is what I mean.

     
  • Farrer

    Farrer - 2017-05-03

    If is desirable, I could also update it to the current code. But, as mentioned early, this is just a quick try to workaround the 'fly-behavior' and it seems very strange for most people who played trigger over on these years.
    A better approach (if there's time for it), could be using Bullet Physics vehicle or adapt Stunt Rally implemented physics to Trigger. But it will be a huge task.

     
  • Farrer

    Farrer - 2017-05-04

    Updated the original patch (file: not_contacting_ground_patch_updated.diff) to current svn code, if anyone is interested on it.

    Also, by the suggestion of always applying the gravity to the vehicle, i've created another patch (file: fixed_gravity_patch.diff), which applyes a fixed gravity value to the vehicle every time (instead of only when it loss contact with the ground, as was the original patch). The car seems too much glued to the ground, but maybe with a change to the gravity constant (GRAVITY_FORCE -9600) could get a better result (beware that too big values, for example -96000, and the car will be inner the ground, acting like a boat on water instead). Maybe some value between -3000 and -6000 could be better than the (real-world?) one I tested.

     
  • Andrei

    Andrei - 2017-05-04

    Hello Farrer, I will test your patches soon, and with Onsemeliot's vote in favor, I will try to add them to the code (configurable/disableable from the game .CONFIG).

    Would you be willing to help us further with the physics code? In my opinion the physics is one of the greatest issues (the other one being the outdated graphics).

     
  • Farrer

    Farrer - 2017-05-05

    Not sure about applying the patch. Better would be a definitive fix to the physics.

    I'll try to look deeper on the physics code.

    Edit: ignore, forgot that the force was, ideally, multiplied by mass when defined.

    Edit2: What seems to be causing the strage behaviour when losing contact with ground (and, obviously, on curves too) is the tensor-like approximation implementation. The sollution, I believe, is either reinvent the wheel and implement another rigid-body tensor to Trigger or use an existing physics engine. As I've used Bullet Physics on another project before (unfortunally not a racing one), I'll try to integrate it to Trigger and post a patch here when I got something stable.

     
    Last edit: Farrer 2017-05-05
  • Andrei

    Andrei - 2017-05-06

    I'm looking forward to your patches.

    The ultimate test should be the map "Jumpy": if you can take the first jump without an unrealistic crash, then you've probably succeeded in fixing the physics.

     
  • Farrer

    Farrer - 2017-05-07

    I've started working on it. So far I have the terrain fully implemented as a bullet triangle mesh (sharing the vertices data with Trigger renderer - which led me to remove the use of old terrain's hmap to avoid duplicate resources of same data) and changed the building system to use CMake (instead of hardcoding libraries path to the current GNUMakefile... there'll be no need for you to accept that, it's just that I feel more confortable using CMake to locate the libraries than editing the current script).

    Now I'll try the real beast: implement the vehicle. Not sure when I'll got this finished and if it will be satisfactory and how much free time I'll have to do this, but...

    Anyway, as it is a large task (and time consuming), I forked the current Trigger code, so I can work without losing things (and easily reversing bad approaches when those happen... and they always happens), keep commits for small tasks and don't affect current Trigger repository with that (which could or could not be usable when done). When done, the commits' log could even make easier the task to select what should and can be merged on Trigger code (for example, CMake could be easily ignored on the merge, etc).

    And, if I couldn't finish it, or if it just became something worst than current physics, the repository could be a starting point to anyone else with better ideas to integrate, etc. I hope I can finish, but let's see. The repository is located at https://github.com/farrer/trigger-rally-bullet . My current task is start car implementation and remove some of the old physics code. When it's usable (and testable), I'll post here (for now, you shouldn't bother with that).

     
    Last edit: Farrer 2017-05-07
  • Onsemeliot

    Onsemeliot - 2017-05-08

    Hi Farrer. This sounds exiting. I hope you will be able to get through with your plans. It's nice also that you didn't abandon Trigger Rally and came back again for contributing more. At the moment I try to get different well known distributions to add a recent version of the game to their repositories. (Some did not include Trigger Rally in the past because of the proprietary textures and images the game had used.)

     
  • Andrei

    Andrei - 2017-05-08

    (for example, CMake could be easily ignored on the merge, etc).

    Thank you for bringing this up; I do intend to keep GNUmakefile when importing your changes, at least until I'm convinced that CMake is a better choice.

    Speaking of CMake, what system do you build Trigger Rally on? I ask because the Windows version uses FMOD, while the Linux version uses OpenAL+ALUT. Also in Windows there will be further complications, such as statically linking libwinpthread, libgcc and libstdc++6, besides copying the DLL next to the executable.

    Having said that, I absolutely do not want you to change your important focus from Physics to Build scripts. Instead I'm trying to get a general feel for the suitability of CMake. So far, I consider it to be a glorified GNU Autotools with a GUI on top and I'm unsure if it is worth using.

     
  • Farrer

    Farrer - 2017-05-08

    @Onsemeliot Sometimes I like to put my ownFLOSS projects at a side and contribute to other ones. Trigger codebase is small enough to be somewhat easy to understand (although sometimes with few code comments and with some unnecessary optimizations that obfuscate the code at first sight). It's fun to work with it anyway.

    @Andrei Don't worry, I just made the compile with CMake to feel more confortable compiling the code (I never used its gui, btw), and i've made it very quick and with a lot of TODOs that I'll probably won't touch. I'm developing it on Linux and I don't have any windows install to check. The static linking, searching for different libraries at each platform and gluing files is trivial with CMake (I've done that on DNT), but I don't plan to do it, at last for now (although I'm currently static linking with bullet here).

     
  • Andrei

    Andrei - 2017-05-09

    @Farrer: I have tested your fixed_gravity_patch.diff and I am very pleased with how the cars handle, however some maps will probably need to have their jumps revised. Onsemeliot do you have an opinion on this patch?

    Of course, I'm still looking forward to the Bullet physics patch, it will be interesting to see the new car behavior.

     
  • Onsemeliot

    Onsemeliot - 2017-05-09

    Onsemeliot do you have an opinion on this patch?

    I had to figure out how to apply the patch first ... Farrer, you obviously know what you are doing. This patch is by far the best yet. It works well for Jumpy but this isn't a good reference case. To me the cars feel now like glued to the ground via magnetism. They are to responsive and the weight doesn't have enough effect. Therefore, one of the in my opinion core qualities of Trigger Rally gets lost with this patch: The great drifting experience. For sure it's much easier to finish all races in time with the patch but it's less fun also - at least for me.

    In my experience the patch does overcompensate the original problem. It probably would be better to alter the physics not as much.

     
  • Andrei

    Andrei - 2017-05-09

    Therefore, one of the in my opinion core qualities of Trigger Rally gets lost with this patch: The great drifting experience.

    From what I tested, the only difference is that the car falls faster during a jump.

    Personally I enjoy this "easier" driving more: in all rally games I've played so far, my favorite surface was always tarmac/asphalt because I enjoy precise control more than drifting.

    In my experience the patch does overcompensate the original problem. It probably would be better to alter the physics not as much.

    Maybe so. Farrer used a hard-coded default of 9600 for "extra" gravity. It should be easy to make this into a .CONFIG setting named "extragravity" set by default to 0 (the current behavior) and with helper comments, for example:

    <config>
        <parameters
            extragravity="0"
            />
    </config>
    

    That said, maybe we should wait some more before changing our SVN code, to see how he progresses with the Bullet library.

     
  • Onsemeliot

    Onsemeliot - 2017-05-10

    Farrer used a hard-coded default of 9600 for "extra" gravity.

    This explains why my test to change the weight value in the vehicle file was unseccessful. I wanted to compensate the effect a little but changing the value didn't have any effect. I will test it with a different extra gravity value for testing purposes.

    It should be easy to make this into a .CONFIG setting

    In principle this is a good idea but since it has a huge effect on how easy time limits can be met I suspect this might take away most of the challenge.

    maybe we should wait some more before changing our SVN code, to see how he progresses with the Bullet library.

    Yes, since Farrer seems to be quite competent with the physics code this could really lead to a major improvement. I hope he can devote enough time to actually do so. :)

    Thank you for your very valued help, Farrer!

     
  • Andrei

    Andrei - 2017-05-10

    In principle this is a good idea but since it has a huge effect on how easy time limits can be met I suspect this might take away most of the challenge.

    It would make the game more fun to play at the expense of making "best times" meaningless.

     
1 2 > >> (Page 1 of 2)

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks