next »

Try the left and right stick clicks on your controller, if the left sounds the horn and the other buttons are still wrong, then something is just simply all together wrong, (in my code, with your driver, something else, etc.)
But if the right stick sounds the horn, then you are on the PlayStation controller setting.

I tried letting it pick the default, and manually pressing F1 for the Xbox controller and in both cases the right stick click activated the horn. When I pressed F2 for the PS setting, neither stick activated the horn. In fact, none of the buttons on my controller did, so I know the default/F1 is supposed to be the right one for me. I did notice something though...

And as for the mapping, I’m not sure what to say, as far as the code goes, everything is correct.
06 for gear_up
05 for gear_dn
07 for gear_up_ps
06 for gear_dn_ps
And the ps_ctrl property is set to false on startup so… I’m not sure what to say, it sounds like you're on the PS controller setting.
Is there any possibility that you hit your F2 key, or that the key's stuck down?
Also, while you shouldn’t have to, did you try pressing the F1 key while on the track?

Can you explain what the difference is between the gear_up and gear_up_ps? And same for gear_dn. I'm guessing PS means PlayStation, but I meant in terms of the mapping in the demo. I thought it odd that you have button 6 mapped twice (unless that was a typo in the quoted section). Buttons, 6 and 7 are the right bumper and back button respectively on the Xbox controller. So button 7 is corresponding to the gear_up_ps and is the only thing mapped for the button. Button 6 seems to have 2 functions mapped to it, and for whatever reason is choosing to correspond itself to the gear_dn_ps instead of gear_up. So perhaps however you have the mapping set up is causing conflicts with the controller picking the wrong action to do?

When the scene “Track_AT” or “Track_MT” starts, (where you can drive the car.)
A BOOL property called “ps_ctrl” is set to False, pressing F1 sets this property to False if not already so, and F2 sets it to True.

When “ps_ctrl” is False, the control script reads the inputs for the UI sensors named joy_gear_up, joy_gear_dn, and joy_horn.
And when “ps_ctrl” is True, the control script reads the inputs for the UI sensors named joy_gear_up_ps, joy_gear_dn_ps, and joy_horn_ps.

All the other inputs are the same and do no need to be changed for the different controllers.

Also, the buttons are only mapped once for each property state, and the property cannot be True and False at the same time, 06 is for gear up on the Xbox, and 06 is for gear down on the PS.
It may be the same button, but they are in different property states that cannot exists at the same time.  

And reading that you couldn’t activate the horn at all on the PS setting, when I know full well that button 10 will work, I went and did a little digging and I think I found the problem.

On my own PlayStation controller, the horn is mapped to button 10, (according to my code and confirmed by the console readout in blender)…
Now I never questioned this because Blender says 10, and the button that I want to use, worked.
But because of the problem that you're having, I wondered what does the driver config label the buttons as… and as it turns out, they’re different.

the driver for my controller actually says 11 for L3, which in blender is 10, and gear down (07) is 06, and gear up (08) is 07 etc.
They’re all transposed down by one in blender… so when I write the python code in blender to use something like button 09, it’s actually 10, and 10 is 11, etc.
And since 10, (which is the working setting in blender for the PS controller), is actually 11, and there is no 11 on the Xbox 360 controller, hence why no button worked for the horn.

So I should be able to fix it without any problems… (hopefully, without any problems).

I'm going to do (try) a quick revision with various fixes to get this thing to finally work right!
It shouldn't take long, and while I'm not too keen on a version that doesn't really make any progress on new code, I just cant stand knowing that the only version available is a broken one.

Random dude jumping in.  I don't have much to say except that all of this looks way cool!  I'll try to download it in the next few days and try it out.  Keep up the awesome stuff, man

Thank you for the compliment.

Alright, this should be the one, no more broken stuff, I hope.

I took care of the alpha textures, and ground collision issues.
And I fixed the Xbox controls, (I hope)… I also changed the mapping for the Xbox 360 controller to use the Y and B for shifting… *points at Narei*
(No one else mentioned any preferences, and you’ve been taking it upon yourself to host these demos, …so, there you go, (hope it works for you this time))

And the only thing that I did not fix is the issue where the HUD can disappear if close enough to an object, barrier, etc.
I’ll fix that when I build a global property dictionary so I can send data from the scene containing the car, to the scene containing the HUD that is then used as an overlay. (quite simple really)

…Here are the changes for the Driving Physics Demo 0.0.4.4.a…

Increased gravity to match scale, (16.087 u/s²), (32.174 ft/s² equivalent),
Made various suspension adjustments to compensate for new gravity setting,
Fixed controls for Xbox controller,
Fixed Look Controls,
Fixed Camera 2 view distance,
Fixed alpha textures,
Reworked ground mesh,
And added new things to find…

And here are some new screenshots…


[Rolling highway]


[Oops…]


[Super Glue!]

The demo should run on any windows 32bit system or any system capable of win32 emulation.

Minimum system requirements for the demo are…
2.0ghz P4 or 1.5ghz dual core
1gb ram @ 400mhz
128mb Video-ram
(256mb Video-ram with Open GL 2.0 for GLSL version)
100mb Required disc space

Recommended system…
1.8ghz dual core
2gb ram @ 667mhz
256mb Video-ram
(384mb Video-ram with Open GL 2.0 for GLSL version)
100mb Required disc space

File name: DPD_0-0-4-4-a_by_SFS.zip

File Size: 47.7MB (50,025,231 bytes)

File Hash SHA-1: 05D790FD7B2BC8B50FB3983C8FE210EC899B6C4F
File Hash MD5: 6E0EFA74E20030B727AE7D6B0717A4BC

[Download version 0.0.4.4a Here]

Have fun, and let me know what you all think.

Well, it seems that FileDropper is finally willing to actually give me the file for once.

Okay, I love the fact that the ground now works properly (that's always a positive sign). I also love the room full of random stuff.

But I don't love that whatever you did with the transparent textures didn't actually fix anything.

Well, it seems that FileDropper is finally willing to actually give me the file for once.

Okay, I love the fact that the ground now works properly (that's always a positive sign). I also love the room full of random stuff.

But I don't love that whatever you did with the transparent textures didn't actually fix anything.

Glad to hear that most things are finally starting to work properly…

But I always seem to miss something… *head-desk*

Pending that I have the right area, (looks like the back straightaway?), that’s a group of trees that’s all one object.
I did fix the alpha textures, (unless you found something somewhere else), but the trees that are one object can’t seem to be sorted properly.
Blender just won’t recognize the visual depth of a single object, and I wasn’t sure about making them single objects.
(As the game engine was starting to do funny things with textures as I started to add more trees, I think I hit the limit.)
So this group of trees is a single object that has no collision, and there's another large group on the other side of the road that's the same.

And just for the sake of doing so, I just tried making them individual objects (again), and while everything renders fine with the GLSL preview.
Some trees at seemingly random locations start appearing opaque with the game engine running.

Out of curiosity, I tried loading the scene from within Blender 2.62 and the trees appeared fine, but the cars can’t be driven there yet.
So I’ll eventually be able to fix this problem, but presently, all I can really do to fix these trees would be to remove them.
(Unless I have the completely wrong area here, and if so, then I don’t know what’s causing the problem.)

Does this problem occur anywhere else? (It's just the trees on the back straightaway, correct?)


To all who’ve played this, I'm getting close to the ceiling of what can be done with the current demo, so I am trying to get this to work in the newer versions of Blender that use the Python 3.2 API.
Doing this will require a lot of work, but I’ll be able to do much more and start to make this into a real game.

And to clarify the situation, something like 90% of all object meshes, and 40% of all code will need to be redone.
The code is a required change for everything to work, but the mesh objects are simply a part of refining things into a final version that will be carried into what will be an actual game someday.
Now I haven’t decided on the exact focus of the game yet, (kind of letting my coding abilities decide on where I can take this).
But at the very least, I can make a racing game, but maybe I can make more than that… not completely sure yet.

So in the mean time, I’ve got some specific question for those who've played my demos if you all don’t mind…

1. (The current track) there are a lot of little imperfections in it, but would anyone like to see this track again as a refined, more detailed version?

2. (Easter eggs / hidden places / hidden collectables / shortcuts) what’s your opinion on hidden extras, and some arcade elements here and there? (Reminiscent of San Francisco Rush?)

3. (Game style) Based on the current demo being a bit of a sim / arcade cross, I can really make this go either way, so which way would you prefer such a game to lean based on what you've seen so far?

4. (Buying and customizing in games) Do you like the excessive customizing and part buying that some racing games have?
(For example, being able to buy an adjustable suspension system and change the damper bound and rebound, camber, toe, stabilizer, and ride height for each wheel.)

Or would you prefer a more simpler set of predefined choices to make?
(Such as choosing / buying a soft, medium, or hard suspension.)


Any and all opinions are appreciated, and thanks for your time.

I'll have to write up a more detailed reply later when I have time, but I did just DL the new version and the XBox controller mapping seems perfect now.

[relieved]

I was pretty sure that I had it right this time, but to be fair, I also thought that I had it right the last time as well.
Regardless, I’m glad and relieved to know that the controller finally works for you.

Does this problem occur anywhere else? (It's just the trees on the back straightaway, correct?)

No, it seems to work fine everywhere else, it's just the back straightaway. Though I never noticed a problem anywhere else in the old version either, possibly because the back straightaway is the only place to have a whole bunch of trees in one place (and therefore more chance of trees overlapping).

1. (The current track) there are a lot of little imperfections in it, but would anyone like to see this track again as a refined, more detailed version?

Yes.

2. (Easter eggs / hidden places / hidden collectables / shortcuts) what’s your opinion on hidden extras, and some arcade elements here and there? (Reminiscent of San Francisco Rush?)

That depends on whether this is going to be a "serious" game or not.

3. (Game style) Based on the current demo being a bit of a sim / arcade cross, I can really make this go either way, so which way would you prefer such a game to lean based on what you've seen so far?

To be honest, you've got a long way to go if you intent to make this a serious racing sim, though if you want to go down that road, I'm all for it, and I'll help you every step of the way. An arcade-style game would be easier to do, but probably harder to do well, since in the absence of realism, the game needs to have something else going for it.

4. (Buying and customizing in games) Do you like the excessive customizing and part buying that some racing games have?
(For example, being able to buy an adjustable suspension system and change the damper bound and rebound, camber, toe, stabilizer, and ride height for each wheel.)

Customisation is good, as long as it doesn't lead to dominant strategy, ie, there is one particular configuration which is always the best in all situations. In that case, there are no real decisions to be made at any stage, and you're not really doing anything meaningful.


Time for some more weird physics bugs: the red structure at the starting line will sometimes (but not usually) explode immediately upon loading the level. You're using framerate dependent physics, aren't you? The (not so) great thing about framerate dependent physics is that sometimes floating-point rounding errors go one way, and sometimes they go the other way, depending on what the framerate is. I think what's happening is that sometimes, if the framerate is just right, a rounding error causes the physics engine to think two pieces of the structure are inside each other, a problem which the physics engine decides to fix with explosion.

Another weird issue with the physics involves the normal force, gravity, friction, and what these factors mean when attempting to park a car on a steep slope. Yes, that car really is parked on the side of a cliff. You can even drive around the side of a cliff; the car only slides down when pointing straight up or down the slope, so that the wheels can roll without skidding. If you're sideways, however, the wheels stick like glue, no matter how steep the slope is (though if the slope is steep enough that the centre of gravity is beyond the tipping point, the car will try to roll over and eventually break free of the tyre's grip, at which point the car will suddenly go flying sideways and bounce down the hill in a hilarious fashion).

1. (The current track) there are a lot of little imperfections in it, but would anyone like to see this track again as a refined, more detailed version?

I like keeping my roots around to see how I advance the way things look/work. So I say keep it.

2. (Easter eggs / hidden places / hidden collectables / shortcuts) what’s your opinion on hidden extras, and some arcade elements here and there? (Reminiscent of San Francisco Rush?)

I love Easter eggs, so long as they aren't impossible to find without a walkthrough guiding you to them. I understand they're supposed to be hidden, but some games go too far. And going back to the first question, maybe make one surprise a fully functioning version of this demo, in all it's low polygon, low-def texturing glory! (That is, if you develop this game into something that looks worlds different and advanced compared to what it is now). Just don't make the AI like it is in SF Rush. Fun as it was, no game has frustrated me as much as that one. You could ram on of the AI cars and it would barely veer off its course, yet one of them grazing you would send you spinning out or airborn.

3. (Game style) Based on the current demo being a bit of a sim / arcade cross, I can really make this go either way, so which way would you prefer such a game to lean based on what you've seen so far?

Either way works for me. I like both. Sims are nice if you want to get in to the technical nitty gritty of tunning without worrying about winning races, but arcade is great for when you need to beat everyone into submission and advance to a game ending goal.

4. (Buying and customizing in games) Do you like the excessive customizing and part buying that some racing games have?
(For example, being able to buy an adjustable suspension system and change the damper bound and rebound, camber, toe, stabilizer, and ride height for each wheel.)

Or would you prefer a more simpler set of predefined choices to make?
(Such as choosing / buying a soft, medium, or hard suspension.)

I'm going to pretty much echo what Foxpup said here. Customization is good, as long as it's realistic and needs to be varied to suit the driving conditions at hand.

Another weird issue with the physics involves the normal force, gravity, friction, and what these factors mean when attempting to park a car on a steep slope. Yes, that car really is parked on the side of a cliff. You can even drive around the side of a cliff; the car only slides down when pointing straight up or down the slope, so that the wheels can roll without skidding. If you're sideways, however, the wheels stick like glue, no matter how steep the slope is (though if the slope is steep enough that the centre of gravity is beyond the tipping point, the car will try to roll over and eventually break free of the tyre's grip, at which point the car will suddenly go flying sideways and bounce down the hill in a hilarious fashion).

I thought this at first too, but in my case, the car would slide down the hill. Even when angled sidways like in your pic and the brakes full on, it would slowly slide to the bottom. At first I thought it was just the camera moving about, but before long it was at the bottom. I do think the driving around the circumference of the hill was a little too easy, but go very fast and I was flying off at tangents.

Another weird issue with the physics involves the normal force, gravity, friction, and what these factors mean when attempting to park a car on a steep slope. Yes, that car really is parked on the side of a cliff. You can even drive around the side of a cliff; the car only slides down when pointing straight up or down the slope, so that the wheels can roll without skidding. If you're sideways, however, the wheels stick like glue, no matter how steep the slope is (though if the slope is steep enough that the centre of gravity is beyond the tipping point, the car will try to roll over and eventually break free of the tyre's grip, at which point the car will suddenly go flying sideways and bounce down the hill in a hilarious fashion).

I thought this at first too, but in my case, the car would slide down the hill. Even when angled sidways like in your pic and the brakes full on, it would slowly slide to the bottom. At first I thought it was just the camera moving about, but before long it was at the bottom. I do think the driving around the circumference of the hill was a little too easy, but go very fast and I was flying off at tangents.

Actually, the car was sliding very slowly in that pic, but the car always slides very slowly when parked on any slope at all due to the complete lack of stiction in this sim (Storm Fox, implementing stiction will be your next task after fixing all the other things ). When parked on a steep slope, one would expect it to slide faster, and to increase speed as gravity accelerates it towards the centre of the Earth, but it doesn't.

The reason you go off at a tangent when driving too fast along the side of hill is because gravity, which is what normally keep the tyres on the ground by pulling them downwards, is no longer keeping the tyres on the ground, because it's pulling them sideways, so the tyres have virtually no grip (which is exactly why the car shouldn't just stick to the side of the hill like glue).

Time for some more weird physics bugs: the red structure at the starting line will sometimes (but not usually) explode immediately upon loading the level. You're using framerate dependent physics, aren't you? The (not so) great thing about framerate dependent physics is that sometimes floating-point rounding errors go one way, and sometimes they go the other way, depending on what the framerate is. I think what's happening is that sometimes, if the framerate is just right, a rounding error causes the physics engine to think two pieces of the structure are inside each other, a problem which the physics engine decides to fix with explosion.

Yea it's framerate based… and I’ve seen that happen too, but only something like 1 in 100 starts, so I just left it instead of making it worse… (which I did, and choose not to save the changes).
The cause of the problem (I assume), is that the frame rate is a little unstable at the very start of the scene, and it takes a couple of seconds to stabilize / normalize, causing the event that you described to occur.

Once I start to build the permanent game structure, I may try to write some sort of frame control script, (perhaps sync it to the computer clock).
Another idea I had is to change the dynamic state of movable objects when another objects is near, (like a cars collision bounds).
Or at the very least, do a delayed state change after the frame rate stabilizes, something like 5 seconds after the scene starts, so that these objects are static during the initial start up, and then switch to rigid body dynamics soon after.

Another weird issue with the physics involves the normal force, gravity, friction, and what these factors mean when attempting to park a car on a steep slope. Yes, that car really is parked on the side of a cliff. You can even drive around the side of a cliff; the car only slides down when pointing straight up or down the slope, so that the wheels can roll without skidding. If you're sideways, however, the wheels stick like glue, no matter how steep the slope is (though if the slope is steep enough that the centre of gravity is beyond the tipping point, the car will try to roll over and eventually break free of the tyre's grip, at which point the car will suddenly go flying sideways and bounce down the hill in a hilarious fashion).

That’s one of the problems with the vehicle wrapper, each wheel has a ray and it tracks the movement along an objects surface.
And to allow the car to drive and turn properly, the ray has limited slip in the X direction, (Left and Right).
The only problem with this is that it always has limited slip, so making the car slide is difficult.
If I had full access to the BT raycast vehicle script that the wrapper ties into, then I would be able to better define actions like loss of traction, power slides, and to stop the car from sticking to the side of hills, while still allowing the car to accelerate, brake, and turn.

However, there's only a grip function that can be applied for each wheel, which defines "grip", and not much else.
What I really need is a way to define anisotropic friction for each wheel, so I can better define the X friction without changing the Y friction.
Another issue I'm having is to try and define different frictions for different surfaces, as this may help fix the problem by making the ground not hold the car, as opposed to the other way around.
But presently, if I try to emit a ray to detect ground properties or materials, the car will fall through the ground as soon as a ray hit is detected.
I'm hoping that this will not happen in the newer version of Blender, but I haven't tested it yet.

These are just some of the reasons that I’m a little lost on how to take this further…
Because with the vehicle wrapper, everything I do is anchored into it, so making the car do something by adding forces or changing dynamics during game play does not work very well.

And the only other option that I’ve been able to come up with is a 6DoF constraint car, which would allow me more freedom to control things, but has some problems of it’s own.
For example, the car would not have the nice natural body movement that it has now from the suspension, as it would have to be faked.
Another problem is that the wheels will only calculate rotational speed up to about 94 radians per seconds, (given the wheel size and scale, that’s around 64 MPH).
So if the car is driven by the wheels, the car can’t go faster than that, and if the car is pushed by an impulse, I’m not sure what the car wheels will do if they need to spin faster to match the ground, but can't.
(Maybe the friction would make it as if the brakes were on once over 64 MPH, I don't really know.)
And that’s not to mention that 6DoF uses more processing resources than the raycast system.
The only real benefit to the 6DoF method is that I can adjust the anisotropic friction of each wheel, as opposed to the raycast grip system.
I’ve tried many different approaches to this, but most that I’ve tried have yielded less than reliable results.

Based on where I am right now…
If you know anything about, or have any experience with these constraint systems, and have any ideas on the matter, I'm listening.

Otherwise I'm just going to continue with the current raycast system and do the best that I can to fix the problems it has.

2. (Easter eggs / hidden places / hidden collectables / shortcuts) what’s your opinion on hidden extras, and some arcade elements here and there? (Reminiscent of San Francisco Rush?)

That depends on whether this is going to be a "serious" game or not.

I have an idea of what I can make, but I'm curious to know what someone who plays games and demos like this would like to see?
Because as I recall, you said…

I also love the room full of random stuff.

Which is why I'm wondering if you and others would like to see more hidden things like that? (Even if it is a serious game.)

2. (Easter eggs / hidden places / hidden collectables / shortcuts) what’s your opinion on hidden extras, and some arcade elements here and there? (Reminiscent of San Francisco Rush?)

Just don't make the AI like it is in SF Rush. Fun as it was, no game has frustrated me as much as that one. You could ram on of the AI cars and it would barely veer off its course, yet one of them grazing you would send you spinning out or airborn.

I know exactly what you mean, and the one thing that I fully intend on is to keep the AI as equal to the player car as possible.

Once I start to build the permanent game structure, I may try to write some sort of frame control script, (perhaps sync it to the computer clock).
Another idea I had is to change the dynamic state of movable objects when another objects is near, (like a cars collision bounds).
Or at the very least, do a delayed state change after the frame rate stabilizes, something like 5 seconds after the scene starts, so that these objects are static during the initial start up, and then switch to rigid body dynamics soon after.

A better idea would be to use fixed framerate physics integration using interpolation for variable framerate rendering (you don't actually need interpolation, it just makes the animation smoother). Fixed framerate physics integration solves a lot of problems, but I don't know whether your framework allows this; if not, you may need to write own your physics integrator from scratch (shouldn't be too hard as long as long as your framework provides basic collision detection as well as vector and quaternion implementations).

And the only other option that I’ve been able to come up with is a 6DoF constraint car, which would allow me more freedom to control things, but has some problems of it’s own.
For example, the car would not have the nice natural body movement that it has now from the suspension, as it would have to be faked.

I don't understand why. If the impulse is being applied at the wheels*, the force won't be acting through the car's centre of gravity and will therefore create a torque which rotates the entire body of the car in the appropriate direction. This will cause one end of the car to be closer to the ground than the other, and therefore the springs at that end will be more compressed and create more upward force on that end of the car, creating another torque which counteracts the car's rotation and puts it in a state of equilibrium. This is exactly how car suspensions work in real life; there's no fakery required at all.

*This is a key assumption. If the impulse is applied at the car's centre of gravity, then you're never going to be able to get it to work right at all, no matter how much you try to fake it.

Another problem is that the wheels will only calculate rotational speed up to about 94 radians per seconds, (given the wheel size and scale, that’s around 64 MPH).
So if the car is driven by the wheels, the car can’t go faster than that, and if the car is pushed by an impulse, I’m not sure what the car wheels will do if they need to spin faster to match the ground, but can't.
(Maybe the friction would make it as if the brakes were on once over 64 MPH, I don't really know.)

Only the wheel's position really matters, not its rotational speed. You need to know the wheel's position since this is the point where all acceleration, braking, and cornering forces will be applied; you also need to know where the wheel is to calculate the spring force for the suspension. But the rotational speed is only necessary to tell if the wheel is spinning or skidding, and to tell how fast the propshaft is spinning; you can easily fake those things if necessary (in fact, you already are: you're using the wheel's delta position for these things, not the rotational speed).

Based on where I am right now…
If you know anything about, or have any experience with these constraint systems, and have any ideas on the matter, I'm listening.

Sorry, I don't know anything about Blender or whatever specific frameworks you're using. You're on your own. But I do know about physics and programming in general, and that I can help you with.

2. (Easter eggs / hidden places / hidden collectables / shortcuts) what’s your opinion on hidden extras, and some arcade elements here and there? (Reminiscent of San Francisco Rush?)

That depends on whether this is going to be a "serious" game or not.

I have an idea of what I can make, but I'm curious to know what someone who plays games and demos like this would like to see?
Because as I recall, you said…

I also love the room full of random stuff.

Which is why I'm wondering if you and others would like to see more hidden things like that? (Even if it is a serious game.)

Definitely not if it's a serious game. Right now, the game is just a bunch of random stuff thrown together, and the hidden room full of random stuff works well with that. But if you're going to make it a serious game, all the random stuff needs to go, because there's just no place for it and it'll only detract from the seriousness of the rest of the game.

Once I start to build the permanent game structure, I may try to write some sort of frame control script, (perhaps sync it to the computer clock).
Another idea I had is to change the dynamic state of movable objects when another objects is near, (like a cars collision bounds).
Or at the very least, do a delayed state change after the frame rate stabilizes, something like 5 seconds after the scene starts, so that these objects are static during the initial start up, and then switch to rigid body dynamics soon after.

A better idea would be to use fixed framerate physics integration using interpolation for variable framerate rendering (you don't actually need interpolation, it just makes the animation smoother). Fixed framerate physics integration solves a lot of problems, but I don't know whether your framework allows this; if not, you may need to write own your physics integrator from scratch (shouldn't be too hard as long as long as your framework provides basic collision detection as well as vector and quaternion implementations).

I did some reading in the API documentation, and there’s a function to get/set the physics tic rate.

Code:

getPhysicsTicRate()
setPhysicsTicRate(60)

But they don’t seem to work, the get function always returns [0.000000], and the set function seems to have no noticeable effect.
And if I try to get the rate after setting the rate, I still get [0.000000].

And after doing a little reading on the internet, many others have mentioned the same problem, while the API clearly lists the functions, and has done so for many versions.
There is however a game physics panel, and the physics rate is independent from the games visual rate… (at least it sounds like it is separate).

Set the nominal number of game frames per second. Physics fixed timestep = 1/fps, independently of actual frame rate.

That’s what is stated for the game framerate settings.
And presently, the physics rate is set to 5 maximum steps, and 1 substep, at 60 fps, so that means that up to 5 physics steps per frame can be executed.

I also did some tests by changing the game visual/logic framerate, and from what I can tell, the physics are separate.
The only thing that was affected was the transitional loc and rot, (location / rotation), which is a framerate based non physics movement, (it has no inertia factor).
While the physics based force, torque, and impulse were not affected, (those are what I use in the demo).

So as far as I understand, it is framerate based, but only to match the nominal rate and not the current framerate.
And since I cant get the physics rate, I’m not completely sure if a drop in the physics rate is causing the problem.
The one thing that I could get was the processing time and (on the first start only), the physics delay was at 30ms, and would drop to 15ms after about 4 seconds.
But every other time I started the scene after that, the time would climb from about 1ms to idle at 15ms.

And the only other option that I’ve been able to come up with is a 6DoF constraint car, which would allow me more freedom to control things, but has some problems of it’s own.
For example, the car would not have the nice natural body movement that it has now from the suspension, as it would have to be faked.

I don't understand why. If the impulse is being applied at the wheels*, the force won't be acting through the car's centre of gravity and will therefore create a torque which rotates the entire body of the car in the appropriate direction. This will cause one end of the car to be closer to the ground than the other, and therefore the springs at that end will be more compressed and create more upward force on that end of the car, creating another torque which counteracts the car's rotation and puts it in a state of equilibrium. This is exactly how car suspensions work in real life; there's no fakery required at all.

*This is a key assumption. If the impulse is applied at the car's centre of gravity, then you're never going to be able to get it to work right at all, no matter how much you try to fake it.

I know what you mean, and the car as a whole would move similarly…
But 6DoF constraints uses different methods to define spring action, and the car will tend to bounce like a yoyo, and doesn’t have the natural looking body roll that the raycast has.
And if I try to make the springs harder, then everything becomes hard as if there’s no suspension at all, it’s very difficult to get an acceptable middle ground.

Another problem is that the wheels will only calculate rotational speed up to about 94 radians per seconds, (given the wheel size and scale, that’s around 64 MPH).
So if the car is driven by the wheels, the car can’t go faster than that, and if the car is pushed by an impulse, I’m not sure what the car wheels will do if they need to spin faster to match the ground, but can't.
(Maybe the friction would make it as if the brakes were on once over 64 MPH, I don't really know.)

Only the wheel's position really matters, not its rotational speed. You need to know the wheel's position since this is the point where all acceleration, braking, and cornering forces will be applied; you also need to know where the wheel is to calculate the spring force for the suspension. But the rotational speed is only necessary to tell if the wheel is spinning or skidding, and to tell how fast the propshaft is spinning; you can easily fake those things if necessary (in fact, you already are: you're using the wheel's delta position for these things, not the rotational speed).

One of the benefits of the 6DoF setup is that I can use the physical wheels to define and control different friction settings, making the wheels fake, (such as non-collision ghost objects), defeats that purpose.
There's a few things that I can try… perhaps I'll take a couple hours and put together a few test cars in Blender 2.62, though I've played around with the 6DoF cars before, so I'm not expecting too much.
And by faking the wheels, I'm pretty sure that all I'm doing is putting together a more complex version of what I already have, but by a different means.

There is however a game physics panel, and the physics rate is independent from the games visual rate… (at least it sounds like it is separate).

Set the nominal number of game frames per second. Physics fixed timestep = 1/fps, independently of actual frame rate.

That’s what is stated for the game framerate settings.
And presently, the physics rate is set to 5 maximum steps, and 1 substep, at 60 fps, so that means that up to 5 physics steps per frame can be executed.

I also did some tests by changing the game visual/logic framerate, and from what I can tell, the physics are separate.
The only thing that was affected was the transitional loc and rot, (location / rotation), which is a framerate based non physics movement, (it has no inertia factor).
While the physics based force, torque, and impulse were not affected, (those are what I use in the demo).

They aren't affected because these values are multiplied by the physics timestep. eg, If your car is moving at 15 m/s and the timestep is 15 ms, it will move 10 cm in each step. If the timestep is 30 ms, it will move 20 cm in each step, but the physics engine will only perform half as many steps per second, so it all works out the same in the end. That's the theory, anyway. In practice, the magic of floating-point rounding errors means that moving 10 cm twice is not necessarily the same as moving 20 cm once; it might actually be 20.0000000001, or 19.9999999998. You might think this doesn't make a difference, but if two objects are extremely close together, it can cause the physics engine to detect a collision where one doesn't actually exist, resulting in random explosions. Of course, having a fixed framerate doesn't prevent rounding errors, but it does cause rounding errors to always go the same way given the same starting values, so the resulting explosions aren't random.

From the documentation, it seems like it does in fact use a fixed framerate, so there must be some other reason why the red structure explodes sometimes but not all the time (although I can't think of what else could possibly cause that).

But 6DoF constraints uses different methods to define spring action, and the car will tend to bounce like a yoyo, and doesn’t have the natural looking body roll that the raycast has.
And if I try to make the springs harder, then everything becomes hard as if there’s no suspension at all, it’s very difficult to get an acceptable middle ground.

You mean you can't set the damping ratio on those springs? I was kinda assuming you could, since that's the second most basic property a spring has...

One of the benefits of the 6DoF setup is that I can use the physical wheels to define and control different friction settings, making the wheels fake, (such as non-collision ghost objects), defeats that purpose.
There's a few things that I can try… perhaps I'll take a couple hours and put together a few test cars in Blender 2.62, though I've played around with the 6DoF cars before, so I'm not expecting too much.
And by faking the wheels, I'm pretty sure that all I'm doing is putting together a more complex version of what I already have, but by a different means.

Wheels are physically very simple objects, so it would probably not be too difficult to write your own code to handle friction, torque, etc. I'm just saying that if real wheels have a hard 94 radians per second limit, faking it is a viable option (even if it's more complicated).

They aren't affected because these values are multiplied by the physics timestep. eg, If your car is moving at 15 m/s and the timestep is 15 ms, it will move 10 cm in each step. If the timestep is 30 ms, it will move 20 cm in each step, but the physics engine will only perform half as many steps per second, so it all works out the same in the end. That's the theory, anyway. In practice, the magic of floating-point rounding errors means that moving 10 cm twice is not necessarily the same as moving 20 cm once; it might actually be 20.0000000001, or 19.9999999998. You might think this doesn't make a difference, but if two objects are extremely close together, it can cause the physics engine to detect a collision where one doesn't actually exist, resulting in random explosions. Of course, having a fixed framerate doesn't prevent rounding errors, but it does cause rounding errors to always go the same way given the same starting values, so the resulting explosions aren't random.

From the documentation, it seems like it does in fact use a fixed framerate, so there must be some other reason why the red structure explodes sometimes but not all the time (although I can't think of what else could possibly cause that).

I’m familiar with floating point inaccuracies, but I still needed to test and see what the physics did when I artificially turned down the framerate.
Because what the documentation say that Blender will do, and what it actually does, is not always the same thing.

Also, 15 m/s is equal to 1.5 cm/ms, so if the car is moving at 15 m/s and the timestep is 15 ms, the car would travel 22.5 cm per step, not 10, and at 30 ms, the car would move 45 cm per step in order to maintain 1.5 cm/ms.

But more to the point, I'm thinking that it could be how the convex-hull is calculated on start up, and suspending the physics for these objects for a few seconds during the start up should help, (so that everything in the scene is not loading at the same time).

But 6DoF constraints uses different methods to define spring action, and the car will tend to bounce like a yoyo, and doesn’t have the natural looking body roll that the raycast has.
And if I try to make the springs harder, then everything becomes hard as if there’s no suspension at all, it’s very difficult to get an acceptable middle ground.

You mean you can't set the damping ratio on those springs? I was kinda assuming you could, since that's the second most basic property a spring has...

I can with the raycast vehicle wrapper, but not with 6DoF constraint, all I can set is the damping ratio on the physical object, but not through the constraint itself.

For a 6DoF setup, once the constraint is set up, these are the additional parameters used to make a spring…

Code:

#set the vertical linear travel limits (type, min, max)
ConstraintName.setParam(2, -0.5, 0.2)

#set the vertical force motor, it's not required,
#But helps add control to springs that carry weight (type, max velocity and direction, force used to achieve velocity)
ConstraintName.setParam(8, -5.0, 100)

#set the vertical spring (type, stiffness, return to center)
ConstraintName.setParam(14, 100.0, 1)

The only way that I could ever figure out how to get a 6DoF car to drive, (not good, but sort of well), was to make what I guess would be considered a damping script.
What it did was take the current vertical velocity of the spring object that anchored the wheel.
And then define a property as the value of the last detected velocity with a given amount subtracted.
Usually something like Velocity - (Velocity / 10) which was then set as the new velocity for the frame, causing the velocity to slow and come to a stop or (near stop), after a short while.

The only problem with this was getting it to work on a moving car, since the velocity of the object that the spring object was attached to would cause problems.
I probably could have went further with this, but I decided that the raycast method was simply more stable / reliable to use.

Wheels are physically very simple objects, so it would probably not be too difficult to write your own code to handle friction, torque, etc. I'm just saying that if real wheels have a hard 94 radians per second limit, faking it is a viable option (even if it's more complicated).

But if I’m to fake the wheels in any way, then how am I supposed to define something like friction.
If it’s not raycast, I would need an object that can make contact with the ground in order to define friction against another surface.
Beyond that I’m left playing around with global velocities and linear location settings to simulate friction using a damping effect.
And those are methods that don’t effect and are not effected by inertia.

[1]

Also, 15 m/s is equal to 1.5 cm/ms, so if the car is moving at 15 m/s and the timestep is 15 ms, the car would travel 22.5 cm per step, not 10, and at 30 ms, the car would move 45 cm per step in order to maintain 1.5 cm/ms.

I think I need more caffeine.

#set the vertical spring (type, stiffness, return to center)
ConstraintName.setParam(14, 100.0, 1)

Isn't that the damping ratio (admittedly not clearly labelled)? If not, what is it?

The only way that I could ever figure out how to get a 6DoF car to drive, (not good, but sort of well), was to make what I guess would be a damping script.
What it did was take the current vertical velocity of the spring object that anchored the wheel.
And then define a property as the value of the last detected velocity with a given amount subtracted.
Usually something like Velocity - (Velocity / 10) which was then set as the new velocity for the frame, causing the velocity to slow and come to a stop or (near stop), after a short while.

The only problem with this was getting it to work on a moving car, since the velocity of the object that the spring object was attached to would cause problems.

Not if you're using the relative velocity of the spring, it won't. If all you've got is the absolute velocity, then yes, that will make things difficult.

Wheels are physically very simple objects, so it would probably not be too difficult to write your own code to handle friction, torque, etc. I'm just saying that if real wheels have a hard 94 radians per second limit, faking it is a viable option (even if it's more complicated).

But if I’m to fake the wheels in any way, then how am I supposed to define something like friction.
If it’s not raycast, as I would need an object that can make contact with the ground in order to define friction against another surface.
Beyond that I’m left playing around with global velocities and linear location settings to simulate friction, to add a damping effect.
And those are methods that don’t effect and are not effected by inertia.

The amount of traction a wheel has is equal to the upward force applied by the spring multiplied by the coefficient of friction of the surface on which the wheel is rolling.

The friction of a skidding wheel can be approximated by taking the multiplying the dot product of the normalised velocity vector and the wheel's axis of rotation by the amount of traction the wheel has (and the direction of the frictional force is always in the opposite direction to the velocity). If the wheel is rolling freely, the velocity vector will be orthogonal to the axis of rotation and so the dot product (and therefore the force of friction) is zero. You'll need to do some special case handling for when the velocity vector is zero (the car's not moving) and when the axis of rotation is zero (the wheels are locked), remembering that both of these conditions will be present when the car is parked.

Assuming the friction due to skidding is less than the total amount of traction (which will only happen when the car is going completely sideways), the remaining traction is available for acceleration, braking, and cornering forces.

Acceleration and braking forces are directly proportional to the amount of torque being produced by the powertrain and brakes, respectively (brakes create negative torque, as does an overrunning engine). Some of the torque is wasted by imparting rotational energy onto the wheels (the lighter the wheels, the less torque will be wasted), and the rest goes straight to accelerating or braking (up to the limits of available traction, of course).

Cornering forces are more complicated, but are generally proportional to the amount of friction produced by the wheel slip (up to a point), and (unlike friction) the direction is always parallel to the wheel's axis of rotation. Like acceleration and braking, the cornering force is limited by the available traction.

See? I told you it was simple!

[1]

Also, 15 m/s is equal to 1.5 cm/ms, so if the car is moving at 15 m/s and the timestep is 15 ms, the car would travel 22.5 cm per step, not 10, and at 30 ms, the car would move 45 cm per step in order to maintain 1.5 cm/ms.

I think I need more caffeine.

It happens to all of us at some point.

#set the vertical spring (type, stiffness, return to center)
ConstraintName.setParam(14, 100.0, 1)

Isn't that the damping ratio (admittedly not clearly labelled)? If not, what is it?

The spring stiffness defines how the constrained object will act against forces that move it off it’s center.
And that number you highlighted, is a bool that's used to return the spring back to it’s center starting position.

When set to “1” (or True), the spring will try to return to it’s starting position.

When set to “0” (or False), the spring will not return to it’s starting position.

Not if you're using the relative velocity of the spring, it won't. If all you've got is the absolute velocity, then yes, that will make things difficult.

Maybe something like (((spring velocity - car velocity) / 10) + car velocity) and set that as the spring velocity for the frame.

(I don’t have the console in front of me to test and see if there’s a flaw in this.)
Maybe I’ll try it later…

The amount of traction a wheel has is equal to the upward force applied by the spring multiplied by the coefficient of friction of the surface on which the wheel is rolling.

The friction of a skidding wheel can be approximated by taking the multiplying the dot product of the normalised velocity vector and the wheel's axis of rotation by the amount of traction the wheel has (and the direction of the frictional force is always in the opposite direction to the velocity). If the wheel is rolling freely, the velocity vector will be orthogonal to the axis of rotation and so the dot product (and therefore the force of friction) is zero. You'll need to do some special case handling for when the velocity vector is zero (the car's not moving) and when the axis of rotation is zero (the wheels are locked), remembering that both of these conditions will be present when the car is parked.

Assuming the friction due to skidding is less than the total amount of traction (which will only happen when the car is going completely sideways), the remaining traction is available for acceleration, braking, and cornering forces.

Acceleration and braking forces are directly proportional to the amount of torque being produced by the powertrain and brakes, respectively (brakes create negative torque, as does an overrunning engine). Some of the torque is wasted by imparting rotational energy onto the wheels (the lighter the wheels, the less torque will be wasted), and the rest goes straight to accelerating or braking (up to the limits of available traction, of course).

Cornering forces are more complicated, but are generally proportional to the amount of friction produced by the wheel slip (up to a point), and (unlike friction) the direction is always parallel to the wheel's axis of rotation. Like acceleration and braking, the cornering force is limited by the available traction.

See? I told you it was simple!

I get it… (sort of), I understand the principle idea, but I don’t know how to implement something like that.

Would I use a 3x3 orientation Matrix to find the vectors, then multiply the XX axis from that, with the YY axis velocity vector to get the figure to multiply with the target traction? (using the output to define the friction.)

Does that sound right, or have I got this all messed up? (because I'm a little lost on this one.)

Not if you're using the relative velocity of the spring, it won't. If all you've got is the absolute velocity, then yes, that will make things difficult.

Maybe something like (((spring velocity - car velocity) / 10) + car velocity) and set that as the spring velocity for the frame.

(I don’t have the console in front of me to test and see if there’s a flaw in this.)
Maybe I’ll try it later…

The flaw in this is that if the car is rotating, the spring attachment point will be moving at a different speed to the car's centre of gravity. Though I'm surprised that your framework doesn't provide any way to get the relative velocity of an attached object, since the absolute velocity is almost never useful in such cases.

I get it… (sort of), I understand the principle idea, but I don’t know how to implement something like that.

Would I use a 3x3 orientation Matrix to find the vectors, then multiply the XX axis from that, with the YY axis velocity vector to get the figure to multiply with the target traction? (using the output to define the friction.)

Does that sound right, or have I got this all messed up? (because I'm a little lost on this one.)

No, you've got it all messed up. Your framework should provide a 3D vector implementation, which it uses to store position and velocity data. This implementation will also provide standard functions for normalising vectors and calculating the dot product of vectors. The wheels rotation is probably represented internally as a quaternion, but you should have a standard function to get it as a direction vector. The documentation should (hopefully) explain how to use these functions.

Behold, pseudocode: (friction, wheel.velocity, and wheel.angularVelocity.direction() are 3D vectors, traction is a scalar)

Code:

friction = -(dotProduct(normalized(wheel.velocity), wheel.angularVelocity.direction())) * traction * (normalized(wheel.velocity));

The flaw in this is that if the car is rotating, the spring attachment point will be moving at a different speed to the car's centre of gravity. Though I'm surprised that your framework doesn't provide any way to get the relative velocity of an attached object, since the absolute velocity is almost never useful in such cases.

I think the reason that there’s no direct way to get data relative to another object (for most things), is because subtracting the data of one object from another will give the relative difference between the two.
There are some functions that work with relative data, but for more simple things like position, or velocity, most people just subtract the data of one object from the other to find the difference.

But do keep in mind that I’m not an expert of the Blender/Python API, and I’m just getting into the newer version, so it’s likely that there are functions and modules that I’m just not aware of…

No, you've got it all messed up. Your framework should provide a 3D vector implementation, which it uses to store position and velocity data. This implementation will also provide standard functions for normalising vectors and calculating the dot product of vectors. The wheels rotation is probably represented internally as a quaternion, but you should have a standard function to get it as a direction vector. The documentation should (hopefully) explain how to use these functions.

Behold, pseudocode: (friction, wheel.velocity, and wheel.angularVelocity.direction() are 3D vectors, traction is a scalar)

Code:

friction = -(dotProduct(normalized(wheel.velocity), wheel.angularVelocity.direction())) * traction * (normalized(wheel.velocity));

Alright that's a bit clearer and I think I can work with that… and the documentation does cover the functions for the mathutils module, which handles all the advanced math functions.
So I'll see what I can do with all of this, (probably tomorrow after some sleep), and thanks for all the help.

The flaw in this is that if the car is rotating, the spring attachment point will be moving at a different speed to the car's centre of gravity. Though I'm surprised that your framework doesn't provide any way to get the relative velocity of an attached object, since the absolute velocity is almost never useful in such cases.

I think the reason that there’s no direct way to get data relative to another object (for most things), is because subtracting the data of one object from another will give the relative difference between the two.
There are some functions that work with relative data, but for more simple things like position, or velocity, most people just subtract the data of one object from the other to find the difference.

But that doesn't work for rotating objects when the objects are not attached at the centre of gravity. Think about it. If the car is spinning on the spot, it's velocity will be zero, but the springs' velocity will most definitely not be zero. If the car is turning left while driving forwards, the springs on the left will be moving a lower velocity than the car, while the springs on the right will be moving at a faster velocity. You need some way of getting the relative velocity or you're going to have nothing but problems.

Alright that's a bit clearer and I think I can work with that… and the documentation does cover the functions for the mathutils module, which handles all the advanced math functions.
So I'll see what I can do with all of this, (probably tomorrow after some sleep), and thanks for all the help.

After reading that documentation, I think your code should look something like this (assuming wheel.angularVelocity is a quaternion, which it should be):

Code:

friction = -(normalized(wheel.velocity).dot(wheel.angularVelocity.axis)) * traction * normalized(wheel.velocity);

The flaw in this is that if the car is rotating, the spring attachment point will be moving at a different speed to the car's centre of gravity. Though I'm surprised that your framework doesn't provide any way to get the relative velocity of an attached object, since the absolute velocity is almost never useful in such cases.

I think the reason that there’s no direct way to get data relative to another object (for most things), is because subtracting the data of one object from another will give the relative difference between the two.
There are some functions that work with relative data, but for more simple things like position, or velocity, most people just subtract the data of one object from the other to find the difference.

But that doesn't work for rotating objects when the objects are not attached at the centre of gravity. Think about it. If the car is spinning on the spot, it's velocity will be zero, but the springs' velocity will most definitely not be zero. If the car is turning left while driving forwards, the springs on the left will be moving a lower velocity than the car, while the springs on the right will be moving at a faster velocity. You need some way of getting the relative velocity or you're going to have nothing but problems.

It’s situations like these as to why I went with the raycast over the 6DoF constraint.

But just to clarify, in blender, X, Y, and Z, are regarded as width, depth, and height respectively.
And for the springs, I would only get and set the velocity for the local Z direction (object Z, not world Z), I don't modify all directional axes.
So the cars movement along other directions would not have an effect as I don't change anything on those axes, (thus, would follow the cars center with no offset).

There would still be a small offset along local Z that would be affected by local rotation along X and Y, and transitional movement along local Z.
But I’m not sure how to resolve it, (or if it even needs to be resolved since all effects are along the springs intended direction of travel).

Alright that's a bit clearer and I think I can work with that… and the documentation does cover the functions for the mathutils module, which handles all the advanced math functions.
So I'll see what I can do with all of this, (probably tomorrow after some sleep), and thanks for all the help.

After reading that documentation, I think your code should look something like this (assuming wheel.angularVelocity is a quaternion, which it should be):

Code:

friction = -(normalized(wheel.velocity).dot(wheel.angularVelocity.axis)) * traction * normalized(wheel.velocity);

Ok, but the angularVelocity function doesn’t give a quaternion…
Here’s the getAngularVelocity() function which doesn’t give a W element.
But then there’s this for working with Quaternion data, I think it can be used to convert a list into a quaternion, but I'm not sure.

It’s situations like these as to why I went with the raycast over the 6DoF constraint.

But just to clarify, in blender, X, Y, and Z, are regarded as width, depth, and height respectively.
And for the springs, I would only get and set the velocity for the local Z direction (object Z, not world Z), I don't modify all directional axes.
So the cars movement along other directions would not have an effect as I don't change anything on those axes, (thus, would follow the cars center with no offset).

There would still be a small offset along local Z that would be affected by local rotation along X and Y, and transitional movement along local Z.
But I’m not sure how to resolve it, (or if it even needs to be resolved since all effects are along the springs intended direction of travel).

So it is relative, and not absolute... Okay, in that case, you don't need to resolve it at all.

Ok, but the angularVelocity function doesn’t give a quaternion…
Here’s the getAngularVelocity() function which doesn’t give a W element.
But then there’s this for working with Quaternion data, I think it can be used to convert a list into a quaternion, but I'm not sure.

It uses Euler angles to represent angular velocity? How does that even make sense? Anyway, you need to convert it into a unit vector giving the axis of rotation (with respect to the world, not the object), not a quaternion (I only assumed it would be a quaternion because rotation matices are computationally expensive and Euler angles don't make any sense). Yes, you can create a quaternion from a list of Euler angles, and then convert that into a vector, though there ought to be an easier way of doing it.

Anyway, you need to convert it into a unit vector giving the axis of rotation (with respect to the world, not the object)

Wait, I though you were saying to find the rotation of the wheel… hence why you were calling angularVelocity in your pseudocode.

If all I need is the direction the wheel spins around, I should be able to use getAxisVect()

Anyway, you need to convert it into a unit vector giving the axis of rotation (with respect to the world, not the object)

Wait, I though you were saying to find the rotation of the wheel… hence why you were calling angularVelocity in your pseudocode.

If all I need is the direction the wheel spins around, I should be able to use getAxisVect()

Well, that doesn't take into account the fact that the wheel is spinning slightly off-axis when the car is turning (due to the rotation of the car itself), but I guess it's close enough. Note that the parameter of getAxisVect() must be unit vector (as direction vectors normally are).