Mosport turn 2 ramp.

[alex25]

Have you tried using opcode but setting opcode to 0?

Anyway, ODE is being pretty annoying -- I'm getting really odd behavior with some other projects where I'm using it, too. Maybe this is a good reason to take a good hard look at using the bullet physics engine. The physics library interface is totally abstracted so switching shouldn't be that tough....

using opcode there are no more problems with mosport. so it looks like the problem is with gimpact. between gimpact not working on 64-bit machines and now this i think i'll stick with opcode for now. not sure why we switched to gimpact in the first place anyway...

--alex--

[cotharyus]

Have you tried using opcode but setting opcode to 0?

Anyway, ODE is being pretty annoying -- I'm getting really odd behavior with some other projects where I'm using it, too. Maybe this is a good reason to take a good hard look at using the bullet physics engine. The physics library interface is totally abstracted so switching shouldn't be that tough....

As I stated previously - I'm all for stepping up to anything that will utilize more than one core. Even if it only offloads part of the computations, it's still better than only using one core. Seems like it might be a worth while switch at this point.

[joevenzon]

not sure why we switched to gimpact in the first place anyway...

Unfortunately, it's the default for ODE now.

[alex25]

not sure why we switched to gimpact in the first place anyway...

Unfortunately, it's the default for ODE now.

huh? when i run ode configure by default i get opcode. i have to explicitly run it with --with-trimesh=gimpact to get gimpact support. this would seem (at least to me) to suggest that opcode is the default.

--alex--

[joevenzon]

Huh, you're right. I wonder where I heard otherwise.

[xTs]

Well, i noticed the bug here, too. But on the left side of the third turn. Like a hole in the street.

I'm using opcode, because I've got a 64bit machine