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!

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.

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!

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?

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?

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?

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!

That looks like uninitialised memory. Are you sure you have called PxVehicleSuspensionRaycasts before calling PxVehicleUpdates?

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!

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.

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!

The u-v coordinates are not important. The important thing is that you get a hit and it has a valid normal and position.

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!

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.

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?

The wheel isn’t hitting the ground, according to that report. Can you step into the code? This could be any number of things and it is almost impossible to guess. I recommend you take a look at the Troubleshooting guide of the Vehicles section of the PhysX manual. It lists common problems and likely solutions.

All objects Y positions are 0(i.e., chassis, 4 wheels, car) and also as you mentioned gone through the NVIDIA troubleshooting doc but unfortunately couldn’t find clue about why this is happening.

Also found following data in 1st update frame of vehicleWheelQueryResult, things look to be messing up from next frame, please find herewith 1st frame data:

	IsInAir	false	bool
	LateralSlip	-0.400555462	float
  •   LocalPose	{{ {M11:0.9999995 M12:0.0009935612 M13:-7.275958E-12 M14:0} {M21:-0.0009823109 M22:0.9886763 M23:0.1500607 M24:0} {M31:0.0001490945 M32:-0.1500606 M33:0.9886768 M34:0} {M41:-0.3826 M42:-0.09935611 M43:0.5573 M44:1} }}	System.Numerics.Matrix4x4
      LongitudinalSlip	-0.277076125	float
      SteerAngle	0	float
      SuspensionJounce	-0.0993561149	float
    
  •   SuspensionLineDirection	{<0.007235814, -0.9999192, -0.01048993>}	System.Numerics.Vector3
      SuspensionLineLength	0.985	float
    
  •   SuspensionLineStart	{<5.613792, 0.7218314, -14.43695>}	System.Numerics.Vector3
      SuspensionSpringForce	-22123.4648	float
    
  •   TireContactActor	{Ground Plane}	PhysX.Actor {PhysX.RigidStatic}
    
  •   TireContactNormal	{<1.192093E-07, 1, 0>}	System.Numerics.Vector3
    
  •   TireContactPoint	{<5.619015, -5.960464E-07, -14.44452>}	System.Numerics.Vector3
    
  •   TireContactShape	{PhysX.Shape}	PhysX.Shape
      TireFriction	0.95	float
    
  •   TireLateralDirection	{<0.999999, -1.192092E-07, -0.001305028>}	System.Numerics.Vector3
    
  •   TireLongitudinalDirection	{<0.001305028, -1.555714E-10, 0.999999>}	System.Numerics.Vector3
    
  •   TireSurfaceMaterial	{Material. Dynamic Friction: 0.1 Static Friction: 0.1 Restitution: 0.1}	PhysX.Material
      TireSurfaceType	0	int
    

There is an urgency to get this fixed soon, just wondering if I can expect some clue to proceed further? Thank you very much!

I don’t really understand the problem. On frame 1 the wheel is not touching the ground. On frame 2 it is touching the ground. I don’t see anything broken here.