1 hour ago, Irbis_88 said:

Bullet world space coordinate system is the same as opengl world coordinate system (-z = forward).

Although you didn't specify it, when you refer to Bullet and OpenGL sharing a '-z forward' coordinate system, I'm assuming you mean a right-handed system, perhaps with +y up.

I often point this out, so I feel a little repetitive doing so here, but it's not actually true that the OpenGL world coordinate system is right-handed or '-z forward'. It's a common convention that became ingrained early on, probably partially due to some commonly used utility functions (or at least that's my take on it), but there's nothing in the API that enforces any particular world-space coordinate system. I mention this because if that's a contributing factor here, you might find it useful to know you can use whatever coordinate system convention you want with OpenGL.

However, it sounds like you're saying the conflict isn't between Bullet's coordinate system and OpenGL, but rather between the 'raycast vehicle' class and the Bullet coordinate system.

It's not immediately obvious to me what's going on there, but the first question that comes to mind is how you're visualizing the results, and whether that's a factor. This is a crude example, but if you, say, had a model that was oriented 'backwards' with respect to an associated physics object, it might seem like you were having to apply forces in the wrong direction in order to get the desired results.

Can you describe how you're visualizing the results? If you're using a model of some sort, what's its local coordinate system, and how is it oriented in local space?

I use modern opengl with shaders so the coordinate system is defined by 3 matrices:

- projection matrix, I define it using glm library:

glm::perspective(glm::radians(50.0f), aspect, zNear, zFar); //zNear = 0.1f, zFar = 1000.0f

- view matrix (camera matrix)

- model matrix

For simplification let's assume that view and model matrices that's identity matrices (glm::mat4(1.0f))

Such coordinate system is the same as bullet world coordinate system: -z forward, +y up. Raycast vehicle has for example the following coordinates (wheel connections points):

• front left wheel (-2, 1, -3)
• front right wheel(2, 1, -3)
• rear left wheel (-2, 1, 3)
• rear right wheel (2, 1 ,3)

addWheel function has two parameters which are important here, I set them this way:

btVector3 wheelDirectionCS0(0, -1, 0);
btVector3 wheelAxleCS(-1, 0, 0);

I haven't found any description about that parameters in the documentation. I have just set the same values as in the bullet examples which I have found. Those parameters don't affect values which describe raycast vehicle coordinate system  (forward vector , forward axis , right axis and up axis) so the question about raycast vehicle coordinate system vs bullet coordinate system is still important.

To move vehicle forward (-z) with a correct wheels rotation I have to set wheelDirectionCS0 and wheelAxleCS as above, call setCoordinate system:

raycastVehicle.setCoordinateSystem(0,1,2);

and applyEngineForce with negative value:

applyEngineForce(-2000, 2);

applyEngineForce(-2000, 3);

As I have mentioned before btRaycast vehicle after calling setCoordinateSystem(0,1,2) returns the following parameters:

• forward vector: [0, 0, 1]
• forward axis: 2
• right axis: 0
• up axis: 1

I have a problem with understanding how raycast vehicle transformations with all the above parameters work keeping in my that bullet world space is the same as my opengl world space.

11 minutes ago, Irbis_88 said:

I use modern opengl with shaders so the coordinate system is defined by 3 matrices:

The OpenGL shader system doesn't require that specifically. But I understand what you mean, and it's very common to do things that way.

Quote

For simplification let's assume that view and model matrices that's identity matrices (glm::mat4(1.0f))

Such coordinate system is the same as bullet world coordinate system: -z forward, +y up.

This is what I was saying isn't necessarily true. I'm not that familiar with GLM and don't know the exact details, but I'm pretty sure the handedness of the transform built by glm::perspective() is determined by how the library is configured. And, there are also versions of the function that allow you to specify the handedness directly, so you're not tied to any particular handedness. But I'll assume you have the library configured as right handed, and that therefore you're working with a right-handed system in both Bullet and OpenGL (as you've described).

I'm just speculating here, but I suspect you may be getting thrown off by the '-z forward' thing.

There are some things that could be said here about handedness and coordinate system conventions, but to try to keep this short I'll just focus on the '-z forward' issue. If there's something in the Bullet documentation or API that specifies that -z is forward I'd be interested to see it, but as is, I'm skeptical about that, and wonder if maybe you're just incorrectly carrying that idea over from OpenGL to Bullet. The fact that you're getting [ 0 0 1 ] back for the vehicle forward vector rather than [ 0 0 -1 ] seems to substantiate this.

You mentioned something about wheel rotation in your initial post, and I'll admit I don't fully understand that part of things. Other than that though, I'd ask in what way applying a positive force doesn't give you the results you want. Again, it'd be helpful to know how you're visualizing things, because unless there are factors I'm unaware of or am not thinking of, it's only through some sort of reference or visualization that you could determine the vehicle was going the 'wrong' direction in the first place.

Zakwayda - I have presented all information which are necessary to analyze this topic.

I have analyzed a bullet example - Fork Lift which also uses raycast vehicle - it works the same way as my implementation.

There is only one difference - front of the vehicle is aimed to the +z axis (bullet/opengl world space) so applying a positive force moves it forward -a vehicle in my implementation is aimed to the -z axis so applying a negative force moves it forward. A coordinate system and wheel parameters are also set in the same way:
 

raycastVehicle.setCoordinateSystem(0,1,2);

btVector3 wheelDirectionCS0(0, -1, 0);
btVector3 wheelAxleCS(-1, 0, 0);

It looks like that raycast vehicle forward vector defines forward axis without sign - it is impossible to set the following forward: [0,0,-1]. The engine force is applied according to the bullet/opengl world space. The only thing which is weird that a default raycast vehicle forward vector: [0,1,0].

36 minutes ago, Irbis_88 said:

Zakwayda - I have presented all information which are necessary to analyze this topic.

I have analyzed a bullet example - Fork Lift which also uses raycast vehicle - it works the same way as my implementation.

 

There is only one difference - front of the vehicle is aimed to the +z axis (bullet/opengl world space) so applying a positive force moves it forward -a vehicle in my implementation is aimed to the -z axis so applying a negative force moves it forward. A coordinate system and wheel parameters are also set in the same way:
 

raycastVehicle.setCoordinateSystem(0,1,2);

btVector3 wheelDirectionCS0(0, -1, 0);
btVector3 wheelAxleCS(-1, 0, 0);

It looks like that raycast vehicle forward vector defines forward axis without sign - it is impossible to set the following forward: [0,0,-1]. The engine force is applied according to the bullet/opengl world space. The only thing which is weird that a default raycast vehicle forward vector: [0,1,0].

Ok. Unfortunately I probably can't answer the specific question about Bullet. I'm still curious as to why it's important that -z rather than +z be forward, or why it would seem weird that Bullet uses +z, but I understand now that that's all tangential (or so I gather).

Maybe someone with more Bullet experience will be able to jump in and help out.