## tuxracer-devel — Mailing list for Tux Racer developers

You can subscribe to this list here.

 2000 2001 Jan Feb (7) Mar (90) Apr (39) May (9) Jun (2) Jul (3) Aug (10) Sep Oct (8) Nov (2) Dec Jan Feb Mar Apr May (2) Jun Jul Aug Sep Oct Nov Dec
S M T W T F S

1

2
(1)
3

4

5

6
(1)
7

8

9

10

11

12

13

14

15

16

17

18
(5)
19

20

21

22

23

24

25

26

27

28
(1)
29
(1)
30

31

Showing 1 results of 1

 Re: [tuxracer-devel] Keyboard From: Jasmin Patry - 2000-05-29 17:15:38 ```On Sun, May 28, 2000 at 04:25:13PM +0100, Peter Allen wrote: > I am not sure on the physics yet (I've only done first year 'A' level > physics so far...) (Please comment and say thats not going to work etc) > 1. Tux could stick a leg hard into the snow, and use it a as a pivot. > For practical reasons I think the pivot would need to be a lot further > out that tux's leg, so this wouldn't look 100% realistic. The physics > of this are fine, but I was planning on making it so the pivot could > only take a certain force, so if tux was going faster than that > the pivot would slip, and tux would lose velocity (due to friction). > I can't quite work out the physics of this, despite my best efforts > with the ascii art. It's not easy to do this "correctly" because of the model that's being used. For physics purposes, Tux is modelled as a single particle. This means that torsion on Tux can't be modelled, since the particle is infinitesimally small. A better model would take into account the fact that when Tux's left arm (or foot) is sticking into the ground, the drag on his left side is greater than on his right side; as a result he would turn in that direction. As I see it, there are a couple of options. You could just copy and modify the current turning code so that the magnitude of the frictional force was increased when doing a sharp turn; this probably won't do exactly what you want, but with sufficient tweaking it might come close. The other would be to forgot about implementing this with forces and manually manipulate Tux's velocity and/or position (instead of having it automatically updated by the ODE solver). There might be some gotchas there, though -- I haven't looked at that code in a while so I'm not sure what problems might crop up. (There is also a third option -- implement a better physical model that takes into account angular momentum, etc. -- but that's probably more work than you had in mind. :) Hope this helps, Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jfpatry@... http://www.cgl.uwaterloo.ca/~jfpatry/ ```

Showing 1 results of 1