PhysX-3.4 -
Hi, I am using PhysX-3.4 wrote c# wrapper for PhysX vehicle sample with chassis as cube collider and tyres as sphere collider, and all other setup and dimensions values are same as physX vehicle sample values, then able to observe following error: "PhysX: Raycasts must generate blocking hits". To solve this can I just use convex collider(car2.raw in vehicle sample)? If yes do I need to write separate importer to load car2.raw in c# project as I couldn't open it in blender? Any help would be really great,Thanks!
Hi,

I am using PhysX-3.4 wrote c# wrapper for PhysX vehicle sample with chassis as cube collider and tyres as sphere collider, and all other setup and dimensions values are same as physX vehicle sample values, then able to observe following error: "PhysX: Raycasts must generate blocking hits".
To solve this can I just use convex collider(car2.raw in vehicle sample)? If yes do I need to write separate importer to load car2.raw in c# project as I couldn't open it in blender?

Any help would be really great,Thanks!

#1
Posted 02/01/2018 06:40 PM   
Blocking hits are a special type of raycast that return only the hit closest to the start point of the raycast. Another type of raycast would be to return all the hit points encountered between the start and end of the raycast. It sounds like you need to configure your vehicle raycasts so that they works as a blocking hit.
Blocking hits are a special type of raycast that return only the hit closest to the start point of the raycast. Another type of raycast would be to return all the hit points encountered between the start and end of the raycast.

It sounds like you need to configure your vehicle raycasts so that they works as a blocking hit.

#2
Posted 02/02/2018 02:29 PM   
Hi gyeoman, Thanks for your response! For raycast problem looked into PxVehicleSuspensionRaycasts() in vehicle sample but couldn't find more info about what is causing this error? We are calling PxVehicleSuspensionRaycasts() every frame similar to sample but is there anyway to find out where the problem is? Thanks!
Hi gyeoman,

Thanks for your response!

For raycast problem looked into PxVehicleSuspensionRaycasts() in vehicle sample but couldn't find more info about what is causing this error? We are calling PxVehicleSuspensionRaycasts() every frame similar to sample but is there anyway to find out where the problem is?

Thanks!

#3
Posted 02/06/2018 02:10 PM   
I suspect the issue is in the filter shader used for the raycasts. At some point you need to create a PxBatchQuery instance so that you can pass it each time to PxVehicleSuspensionRaycasts. When you create the PxBatchQuery you need to specify a pre-filter shader. The pre-filter shader should be configured to return a blocking hit. It might look something like this PxQueryHitType::Enum WheelSceneQueryPreFilterBlocking (PxFilterData filterData0, PxFilterData filterData1, const void* constantBlock, PxU32 constantBlockSize, PxHitFlags& queryFlags) { //filterData0 is the vehicle suspension query. //filterData1 is the shape potentially hit by the query. PX_UNUSED(filterData0); PX_UNUSED(constantBlock); PX_UNUSED(constantBlockSize); PX_UNUSED(queryFlags); return ((0 == (filterData1.word3 & DRIVABLE_SURFACE)) ? PxQueryHitType::eNONE : PxQueryHitType::eBLOCK); } Can you take a look at your filter shader and confirm that it returns a blocking hit?
I suspect the issue is in the filter shader used for the raycasts.

At some point you need to create a PxBatchQuery instance so that you can pass it each time to PxVehicleSuspensionRaycasts. When you create the PxBatchQuery you need to specify a pre-filter shader. The pre-filter shader should be configured to return a blocking hit.

It might look something like this

PxQueryHitType::Enum WheelSceneQueryPreFilterBlocking
(PxFilterData filterData0, PxFilterData filterData1,
const void* constantBlock, PxU32 constantBlockSize,
PxHitFlags& queryFlags)
{
//filterData0 is the vehicle suspension query.
//filterData1 is the shape potentially hit by the query.
PX_UNUSED(filterData0);
PX_UNUSED(constantBlock);
PX_UNUSED(constantBlockSize);
PX_UNUSED(queryFlags);
return ((0 == (filterData1.word3 & DRIVABLE_SURFACE)) ? PxQueryHitType::eNONE : PxQueryHitType::eBLOCK);
}

Can you take a look at your filter shader and confirm that it returns a blocking hit?

#4
Posted 02/06/2018 02:21 PM   
It looks like filter shader is returning eBLOCK and eNONE alternatively(eBLOCK, eNONE, eBLOCK, eNONE....) But observed that sceneQueryResults doesn't update block(u and v) in PxVehicleSuspensionRaycasts() where as it updates in vehicle sample example, wondering if this could be related to same?
It looks like filter shader is returning eBLOCK and eNONE alternatively(eBLOCK, eNONE, eBLOCK, eNONE....)
But observed that sceneQueryResults doesn't update block(u and v) in PxVehicleSuspensionRaycasts() where as it updates in vehicle sample example, wondering if this could be related to same?

#5
Posted 02/06/2018 02:58 PM   
That is a bit of a mystery. The structure that contains the raycast results has a user-provided buffer for non-blocking hits and a single fixed-size data block for a blocking hit. If a blocking hit is issued the result will be stored in the blocking hit rather than in the buffer. If a non-blocking hit is issued it will store the hits in the user-provided buffer and store the number of hits in nbTouches. If a non-blocking raycast finds three hits along the raycast it will store 3 hits in the buffer and store a value of 3 in nbTouches. A blocking raycast will always result in nbTouches having value zero because it stores the single hit in the fixed-size data block. In addition to raycasts, physx vehicles also support sweeps. For raycasts we are only interested in the hit that is closes to the start point of the raycast. There is no point in having any more information so there is an assumption that vehicle raycasts will be blocking. Sweeps are a bit different. We might want to look at all the hits encountered along the sweep and decide which ones to ignore and which one to accept by looking at the normal of the hit. Sweeps can be blocking or non-blocking. The warning is issued from this line of code in PxVehicleUpdate.cpp PX_CHECK_AND_RETURN(!raycastResults || (0 == raycastResults[i].nbTouches), "Raycasts must generate blocking hits"); It says that if we are doing a raycast then it must be a blocking raycast. It doesn't enforce any rule on sweeps because they can be blocking or non-blocking. Can you find out the value of raycastResults and raycastResults[i].nbTouches?
That is a bit of a mystery.

The structure that contains the raycast results has a user-provided buffer for non-blocking hits and a single fixed-size data block for a blocking hit. If a blocking hit is issued the result will be stored in the blocking hit rather than in the buffer. If a non-blocking hit is issued it will store the hits in the user-provided buffer and store the number of hits in nbTouches. If a non-blocking raycast finds three hits along the raycast it will store 3 hits in the buffer and store a value of 3 in nbTouches. A blocking raycast will always result in nbTouches having value zero because it stores the single hit in the fixed-size data block.

In addition to raycasts, physx vehicles also support sweeps. For raycasts we are only interested in the hit that is closes to the start point of the raycast. There is no point in having any more information so there is an assumption that vehicle raycasts will be blocking. Sweeps are a bit different. We might want to look at all the hits encountered along the sweep and decide which ones to ignore and which one to accept by looking at the normal of the hit. Sweeps can be blocking or non-blocking.

The warning is issued from this line of code in PxVehicleUpdate.cpp

PX_CHECK_AND_RETURN(!raycastResults || (0 == raycastResults[i].nbTouches), "Raycasts must generate blocking hits");

It says that if we are doing a raycast then it must be a blocking raycast. It doesn't enforce any rule on sweeps because they can be blocking or non-blocking.

Can you find out the value of raycastResults and raycastResults[i].nbTouches?

#6
Posted 02/06/2018 04:21 PM   
Thanks for your detailed explanation! With little modification to .net wrapper code for PhysX couldn't see this error "PhysX: Raycasts must generate blocking hits", but with respect to your point inside PxVehicleSuspensionRaycasts() observed the following: block u and v is 0, nbTouches is 0, touches u and v is -431602080., touches PxLocationHit flags is 52685, position and distance is -431602080., queryStatus is '\x1', hasBlock is true, pad is 52685 Currently able to see tire movement depending on key press, but couldn't see vehicle move forward though created ground object(with filter COLLISION_FLAG_GROUND and COLLISION_FLAG_GROUND_AGAINST), just wondering if this problem could be due to raycast (or) anything else? Thanks again!
Thanks for your detailed explanation!
With little modification to .net wrapper code for PhysX couldn't see this error "PhysX: Raycasts must generate blocking hits", but with respect to your point inside PxVehicleSuspensionRaycasts() observed the following:
block u and v is 0, nbTouches is 0, touches u and v is -431602080., touches PxLocationHit flags is 52685, position and distance is -431602080., queryStatus is '\x1', hasBlock is true, pad is 52685

Currently able to see tire movement depending on key press, but couldn't see vehicle move forward though created ground object(with filter COLLISION_FLAG_GROUND and COLLISION_FLAG_GROUND_AGAINST), just wondering if this problem could be due to raycast (or) anything else?

Thanks again!

#7
Posted 02/07/2018 12:09 PM   
That looks like uninitialised memory. Are you sure you have called PxVehicleSuspensionRaycasts before calling PxVehicleUpdates?
That looks like uninitialised memory. Are you sure you have called PxVehicleSuspensionRaycasts before calling PxVehicleUpdates?

#8
Posted 02/07/2018 01:26 PM   
Yes PxVehicleSuspensionRaycasts was called before calling PxVehicleUpdates() In PxVehicleSuspensionRaycasts () method, observed that hasBlock was false in my project whereas it was true in the vehicle sample, wondering if there can be any other reason apart from filter for hasBlock not set to true? Thanks!
Yes PxVehicleSuspensionRaycasts was called before calling PxVehicleUpdates()
In PxVehicleSuspensionRaycasts () method, observed that hasBlock was false in my project whereas it was true in the vehicle sample, wondering if there can be any other reason apart from filter for hasBlock not set to true?

Thanks!

#9
Posted 02/07/2018 01:47 PM   
hasBlock indicates a blocking hit. If hasBlock is false then the raycast has not hit anything. This is almost certainly related to the filter data of the raycast, the filter data of the geometry under the car, and the filter shader itself.
hasBlock indicates a blocking hit. If hasBlock is false then the raycast has not hit anything. This is almost certainly related to the filter data of the raycast, the filter data of the geometry under the car, and the filter shader itself.

#10
Posted 02/08/2018 09:47 AM   
Hi geyoman, Thanks for your response! I believe when we have window active then able to observe hasBlock to be true now, but block still looks to have(u=0.0, v=0.0), please find herewith filter data of the geometry under the car: //ground object shape is plane //shape.SetQueryFilterData(filterData) where filterData is (0,0,0,4294901760) //shape.SetSimulationFilterData(filterData) where filterData is (1,28,0,0) //from i = 0 to 3 //wheelSimData.SetSceneQueryFilterData(i, vehQryFilterData) where vehQryFilterData is (0,0,0,65535) //wheelSimData.SetWheelShapeMapping(i, i) // Also PxBatchQueryPreFilterShader mPreFilterShader is linked to SampleVehicleWheelRaycastPreFilter method that checks if drivable surface and returns NONE or eBLOCK Wondering if you can throw some light based on above data? Thank you very much!
Hi geyoman,

Thanks for your response!
I believe when we have window active then able to observe hasBlock to be true now, but block still looks to have(u=0.0, v=0.0), please find herewith filter data of the geometry under the car:
//ground object shape is plane
//shape.SetQueryFilterData(filterData) where filterData is (0,0,0,4294901760)
//shape.SetSimulationFilterData(filterData) where filterData is (1,28,0,0)

//from i = 0 to 3
//wheelSimData.SetSceneQueryFilterData(i, vehQryFilterData) where vehQryFilterData is (0,0,0,65535)
//wheelSimData.SetWheelShapeMapping(i, i)

// Also PxBatchQueryPreFilterShader mPreFilterShader is linked to SampleVehicleWheelRaycastPreFilter method that checks if drivable surface and returns NONE or eBLOCK

Wondering if you can throw some light based on above data?

Thank you very much!

#11
Posted 02/08/2018 11:13 AM   
The u-v coordinates are not important. The important thing is that you get a hit and it has a valid normal and position.
The u-v coordinates are not important. The important thing is that you get a hit and it has a valid normal and position.

#12
Posted 02/08/2018 02:22 PM   
Able to observe hit and can find valid block's position, normal and distance though couldn't find valid value for touches's position, normal and distance. If this is valid, just wondering about the reason for vehicle not moving forward though tyres rotate on acceleration in 1st gear? Please find herewith values from block hit: block position:{x=5.51724243 y=-6.55651093e-07 z=-14.1894169 } block normal:{x=1.19209290e-07 y=1.00000012 z=0.000000000 } block distance:0.794236600 Thank you very much!
Able to observe hit and can find valid block's position, normal and distance though couldn't find valid value for touches's position, normal and distance. If this is valid, just wondering about the reason for vehicle not moving forward though tyres rotate on acceleration in 1st gear?

Please find herewith values from block hit:
block position:{x=5.51724243 y=-6.55651093e-07 z=-14.1894169 }
block normal:{x=1.19209290e-07 y=1.00000012 z=0.000000000 }
block distance:0.794236600

Thank you very much!

#13
Posted 02/08/2018 04:48 PM   
That looks perfect. The normal is pointing along the y-vector. Sounds good. If the car isn't moving then the fauls is not the raycast. The fault could be a few things. 1. It might be the tyre friction 2. Or rigid body collision might be interfering with the suspension force and tyre load. Maybe take a look in pvd to see if the wheels are colliding with the ground.
That looks perfect.

The normal is pointing along the y-vector. Sounds good.

If the car isn't moving then the fauls is not the raycast.

The fault could be a few things.

1. It might be the tyre friction
2. Or rigid body collision might be interfering with the suspension force and tyre load.

Maybe take a look in pvd to see if the wheels are colliding with the ground.

#14
Posted 02/08/2018 05:27 PM   
Thank you for the confirmation! Please find herewith wheelQueryResults data after call to PxVehicleUpdates: 1st tyre: IsInAir true bool LateralSlip 0 float + LocalPose {{ {M11:0.9999995 M12:0.0009999999 M13:0 M14:0} {M21:-0.0009999999 M22:0.9999995 M23:0 M24:0} {M31:0 M32:0 M33:1 M34:0} {M41:-0.4826 M42:-0.7301 M43:0.8129 M44:1} }} System::Numerics::Matrix4x4 LongitudinalSlip 0 float SteerAngle 0 float SuspensionJounce -0.1 float + SuspensionLineDirection {<0, -1, 0>} System::Numerics::Vector3 SuspensionLineLength 0.985 float + SuspensionLineStart {<5.5174, 0.8614308, -14.1871>} System::Numerics::Vector3 SuspensionSpringForce 0 float TireContactActor nullptr PhysX::Actor^ + TireContactNormal {<0, 0, 0>} System::Numerics::Vector3 + TireContactPoint {<0, 0, 0>} System::Numerics::Vector3 TireContactShape nullptr PhysX::Shape^ TireFriction 0 float + TireLateralDirection {<0, 0, 0>} System::Numerics::Vector3 + TireLongitudinalDirection {<0, 0, 0>} System::Numerics::Vector3 TireSurfaceMaterial nullptr PhysX::Material^ TireSurfaceType -1 int IsInAir true bool LateralSlip 0 float + LocalPose {{ {M11:0.9999995 M12:0.0009999999 M13:0 M14:0} {M21:-0.0009999999 M22:0.9999995 M23:0 M24:0} {M31:0 M32:0 M33:1 M34:0} {M41:-0.4826 M42:-0.7301 M43:0.8129 M44:1} }} System::Numerics::Matrix4x4 LongitudinalSlip 0 float SteerAngle 0 float SuspensionJounce -0.1 float + SuspensionLineDirection {<0, -1, 0>} System::Numerics::Vector3 SuspensionLineLength 0.985 float + SuspensionLineStart {<5.5174, 0.8614308, -14.1871>} System::Numerics::Vector3 SuspensionSpringForce 0 float TireContactActor nullptr PhysX::Actor^ + TireContactNormal {<0, 0, 0>} System::Numerics::Vector3 + TireContactPoint {<0, 0, 0>} System::Numerics::Vector3 TireContactShape nullptr PhysX::Shape^ TireFriction 0 float + TireLateralDirection {<0, 0, 0>} System::Numerics::Vector3 + TireLongitudinalDirection {<0, 0, 0>} System::Numerics::Vector3 TireSurfaceMaterial nullptr PhysX::Material^ TireSurfaceType -1 int There looks to be problem with tire data updated, can you please confirm if this is problem? If yes wondering about the cause of this problem?
Thank you for the confirmation!

Please find herewith wheelQueryResults data after call to PxVehicleUpdates:
1st tyre:
IsInAir true bool
LateralSlip 0 float
+ LocalPose {{ {M11:0.9999995 M12:0.0009999999 M13:0 M14:0} {M21:-0.0009999999 M22:0.9999995 M23:0 M24:0} {M31:0 M32:0 M33:1 M34:0} {M41:-0.4826 M42:-0.7301 M43:0.8129 M44:1} }} System::Numerics::Matrix4x4
LongitudinalSlip 0 float
SteerAngle 0 float
SuspensionJounce -0.1 float
+ SuspensionLineDirection {<0, -1, 0>} System::Numerics::Vector3
SuspensionLineLength 0.985 float
+ SuspensionLineStart {<5.5174, 0.8614308, -14.1871>} System::Numerics::Vector3
SuspensionSpringForce 0 float
TireContactActor nullptr PhysX::Actor^
+ TireContactNormal {<0, 0, 0>} System::Numerics::Vector3
+ TireContactPoint {<0, 0, 0>} System::Numerics::Vector3
TireContactShape nullptr PhysX::Shape^
TireFriction 0 float
+ TireLateralDirection {<0, 0, 0>} System::Numerics::Vector3
+ TireLongitudinalDirection {<0, 0, 0>} System::Numerics::Vector3
TireSurfaceMaterial nullptr PhysX::Material^
TireSurfaceType -1 int

IsInAir true bool
LateralSlip 0 float
+ LocalPose {{ {M11:0.9999995 M12:0.0009999999 M13:0 M14:0} {M21:-0.0009999999 M22:0.9999995 M23:0 M24:0} {M31:0 M32:0 M33:1 M34:0} {M41:-0.4826 M42:-0.7301 M43:0.8129 M44:1} }} System::Numerics::Matrix4x4
LongitudinalSlip 0 float
SteerAngle 0 float
SuspensionJounce -0.1 float
+ SuspensionLineDirection {<0, -1, 0>} System::Numerics::Vector3
SuspensionLineLength 0.985 float
+ SuspensionLineStart {<5.5174, 0.8614308, -14.1871>} System::Numerics::Vector3
SuspensionSpringForce 0 float
TireContactActor nullptr PhysX::Actor^
+ TireContactNormal {<0, 0, 0>} System::Numerics::Vector3
+ TireContactPoint {<0, 0, 0>} System::Numerics::Vector3
TireContactShape nullptr PhysX::Shape^
TireFriction 0 float
+ TireLateralDirection {<0, 0, 0>} System::Numerics::Vector3
+ TireLongitudinalDirection {<0, 0, 0>} System::Numerics::Vector3
TireSurfaceMaterial nullptr PhysX::Material^
TireSurfaceType -1 int

There looks to be problem with tire data updated, can you please confirm if this is problem? If yes wondering about the cause of this problem?

#15
Posted 02/09/2018 09:20 AM   
Scroll To Top

Add Reply