x

Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

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: http://stackoverflow.com/questions/573084/how-to-calculate-bounce-angle/573206#573206 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

Product Version: UE 4.7
Tags:
more ▼

asked Jun 08 '15 at 01:06 PM in Using UE4

avatar image

TodSusser
1 1 3 3

avatar image HailstoneRyan Jun 13 '15 at 10:41 PM

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.

avatar image TodSusser Jun 13 '15 at 11:44 PM

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).

avatar image HailstoneRyan Jun 13 '15 at 11:55 PM

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?

avatar image TodSusser Jun 14 '15 at 12:07 AM

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...

avatar image HailstoneRyan Jun 14 '15 at 03:04 PM

Does it ever occur twice in a row?

avatar image TodSusser Jun 14 '15 at 05:53 PM

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.

avatar image TodSusser Jun 27 '15 at 09:21 PM

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.

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

0 answers: sort voted first
Be the first one to answer this question
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question