Problems with Hit Normals

  • UPDATE 2015-06-12: See bottom of post for footage of the bug described.
  • UPDATE 2015-06-13: This “sudden inexplicable forward collision component” issue also happens when moving directly downwards onto Basic Cylinder, but not under any other circumstances on the Cylinder or the Cube (even when pressing downwards onto one of its edges). Also, added a list of things that Do Not Work at the end of the post.
  • UPDATE 2015-06-21: Tried using different Normals that UE4 offers me. Same issues.

Hello everyone,

I am having an issue with collision in my UE4 project. I am using the Flying template and while I have added things to it, the general sweeping behaviour remains. I added in “strafing” (ie, moving laterally without rotating the ship) and I am testing collision by grinding against walls (perpendicularly) using this strafing. The strafing relies on Sweeps, much like the default “thrust” motion, and on collisions the ship’s Hit Normal redirects the plane (ie, it bounces off of walls) and player input is disabled momentarily (to prevent players from sticking themselves to solid walls). My “bounce” calculation is from this page, and uses the Hit Normal returned from Event Hits: c# - How to calculate bounce angle? - Stack Overflow I am printing Hit Normals on collision to the screen to help me debug.

On collisions with UE4 “default” objects (ie, left side of the screen → Basic → Cube or Cylinder), collision works perfectly. I can increase my speed, decrease my speed, whatever, and the bounces I get from the collision I have written is visually acceptable and results in a sensible Hit Normal. (I have Physics disabled, as is default.)

However, on collisions with BSPs, BSPs-turned-Static-Meshes, or imported Static Meshes (with UCXs or with in-engine-generated collision meshes), things get wacky. The issue seems to be specifically with what the engine determines to be the Hit Normal; it’s less precise than with the “default” objects, and is inconsistent enough that it will deliver a Hit Normal of 0.14 or higher in X (the player’s direction of travel), when the Default objects all play nice and give me 0.001X at most. (Again, the impacts should be perpendicular, with no Hit Normal in the direction of the player’s travel; 0.001X is acceptable and probably just float imprecision.)

I suspect that my issue lies somewhere in the collision settings for the non-default objects, but there are simply too many different variables that could potentially be interacting with one another for me to simply sort this out through trial and error. (That doesn’t mean that I haven’t tried, of course; I’m also here because the IRC channel has no idea, either.) Some things I’ve tried:

  • Colliding with a BSP (first time I noticed this issue)
  • Colliding with a BSP turned into a static mesh (same issue, even if I then removed the generated Collision and generated my own collisions; same issue even if I made the player object’s collision mesh more or less simple)
  • Making my own UCX for imported Blender meshes (UCX is recognized but the collision still behaves in the same, wrong way as the previous two attempts)
  • A myriad of object settings that either made the issue worse or had no effect on collision behaviour

I will record some .webms and post screenshots of my code/physics settings if this is not enough information. I will respond to all questions asking me whether or not I have tried some given solution yet, and will list my responses in the Question itself as I answer these questions, if possible. (I am working in Blueprints, but I am almost certain that the issue here is not with the code I have made, but with the settings I am using for the collision objects in question.)

Thank you very much for your time and thank you again if you have any help to offer.

Things that do not work:
Changing collision settings on the custom mesh (both Enabled and Disabled do not change the collision behaviour):

  • changing the material to DefaultPhysicalMaterial
  • changing Simulation Generates Collision
  • changing Generate Overlap Events
  • changing CollisionPresets from BlockAll to BlockAllDynamic
  • changing Use CCD
  • changing Always create Physics State
  • changing Multi Body Overlap
  • changing Check Async Scene on Move
  • changing Trace Complex on Move
  • changing Can Ever Effect Navigation
  • Flipping the player model’s collision mesh does not change the collision problem at all. Moving downward onto the Cylinder still functions in the same (wrong) way.

Changing settings on the player Mesh:

  • Changing Enable Collision
  • Changing Recompute Normals
  • Changing Use Full Precision UVs
  • Collision Complexity settings: Default, Use Simple Collision as Complex, Use Complex Collision as Simple
  • Modifying the collision mesh (all settings result in the same “randomly described as a non-parallel collision” behaviour)
    • This includes going as simple as a Box Collision and as complex as a multi-Hull collision
  • Giving the Player Mesh a Physical Material
  • Going to Static Mesh Settings, with a complex collision box, and going “Use Simple Collision as Complex” seems to reduce the frequency of these erroneous Hit Normals, but they still happen

Changing which Normal I use:

  • Using Break Hit Result’s Impact Normal still occasionally results in these in-travel-direction Normal spikes
  • as does Break Hit Result’s Normal

Hey, thank you for the response!

The collision checks to see how much velocity the player had in the perpendicular component of the collision (u). If this exceeds Death Threshold, the player’s ship explodes. The speeds on all axes are (for testing purposes) in the ballpark of 150-500 and DeathThreshold is 200; because the plane can only strafe at 190 laterally, it cannot kill itself by colliding with a surface simply by strafing into it. Its forward speed is 300 by default, however, so an angled collision or a head-on collision will kill it. Of course, UE4 occasionally says these strafe-only collisions are 10-55% head-on…

  • BounceOrDie is as follows. (I made a mistake; meant V and then U, not U and then V.)
  • Hit Event is as follows.

Not sure what you mean by “in the same spot as one of the other two meshes”; I tried intersecting it with the default cube and then dragging the plane across the intersecting surfaces, but there was no special reaction; the plane was still recorded as hitting the BSP/imported surface at .428 on the X axis at some point (which killed it).

Just tried in a full tunnel again to make sure. Weirdly enough, with the BSP/imported mesh, it’s top-of-tunnel and bottom-of-tunnel motion that can potentially trigger this issue, but I can’t get it to trigger on purely left/right motion. Same case with both a complicated 4-hull collision mesh as with a Simplified 26DOP collision mesh.

EDIT: Put the plane on the outside of the tunnel and then strafed right into the outer side of the tunnel, and triggered a .4-X-direction collision. (This was after it had bounced far off of the tunnel wall, not just in a series of extremely quick grind-y collisions.) It’s so random…

When the normal on the X hits 0.5 or greater does it always result in player death as well? Can you take a screenshot of the Blueprint that handles the reaction to a collision? Does this happen if the imported/BSP created static mesh is in the same spot as one of the other two meshes?

Not sure I’ve ever witnessed this happening but we also don’t have a situation where a player may grind against a collider.

Noticed in the OP that you mentioned downward movement. Is this also the case with the BSP/imported mesh? Does it only report those values when moving downward or any direction?

Does it ever occur twice in a row?

I can get a lot of bumps with much less significant but still wrong values like 0.055X. Disabling the “die” code, I can get .1X-.3X several times in a row, yes. Generally it’s random enough that this doesn’t happen, though.

Still completely at a loss as to how to resolve this. I was considering going into UT4’s code and looking at the code for the Flak Cannon, since it has projectiles that ricochet and none of them ricochet backwards as if they’ve hit a wall head-on when they’re just scraping the side of one. Will maybe do so once I make more progress in other parts of the project.