Announcement

Collapse
No announcement yet.

Inverse hit detection?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    Inverse hit detection?

    I don't think it is available, but if it is that is certainly the solution I'd prefer. I have something bouncing around inside a sphere, and I can make it work with complex line traces using the sphere's mesh. I'd prefer to simplify things by using a collision component which provides a sort of inverse hit event (ie. hit events for when the ray trace stops overlapping the collision component). Unfortunately I am tight on time for this project so I can't thoroughly research how ray traces and collision components interact. I've got about 8 hours in my current milestone sprint to allocate towards this problem.

    My questions are three.
    1) Is there a built in solution I've overlooked which would work with ray tracing? Or a marketplace solution? [I'm not entirely sure what the least ambiguous way to describe this in a search query even is]
    2) Is this sort of reverse collision component possible?
    3) How do ray traces and collision components interact, if this is relevant to solving the problem?

    I'll take whatever experience/help you can give.


    edit:
    I think my post may have been a tad ambiguous and difficult to follow. I'm looking for a way to use simple collision detection on both the inside and outside of a sphere.
    Last edited by JoshC; 12-10-2018, 05:40 PM.

    #2
    If i understand your problem correctly, to get traces and components to generate hit events you do the following:
    Go in your project settings>collision, create a new object channel called "bouncecollider" with default "ignore".
    Then create a new trace channel called "tracebouncer" with default "ignore".

    Then in your presets further down, double click yoour "bouncecollider" object channel and make sure everything is set to ignore, except Trace Type "tracebouncer", which should be set to "block".

    Then set your collision component collision channel to "bouncecollider".

    Now you can do line traces on the "tracebouncer"-channel, which will only generate a hit event if it hits your collision components mesh, but ignores everything else.

    As far as i know there is no trace to generate hit results when leaving a collision zone, only when entering/hitting it.
    The easiest way for an inverse trace would be to make a mesh that completely and perfectly encapsulates the area/object you want to get a hit result when "leaving" that object, just like a gift wrap paper encapsulates a box. You'd then give the wrap paper that "bouncecollider" object channel and do line traces for it from inside the box. As soon as the trace hits the gift wrap paper, you'll know you are outside your box and can get that as a hit result from the line trace.
    Last edited by StefanHohnwald; 08-13-2018, 06:58 AM.

    Comment


      #3
      I'm a bit confused. I've got the feature working right now without any bounce collider channel, is this to help create the effect of trace exit events?
      Would a regular sphere collision component work for this? as they don't seem to work at all when doing traces from inside them, though I haven't tested with creating a new custom channel. It's just my gut is telling me it shouldn't behave any different in that scenario.

      Comment


        #4
        1. The words you likely are looking for is concave and convex collision shapes.

        2. Or surface or line intersection collision. You only want collision detection during a surface intersection. (Assume everything is hollow)

        3. Depending when you want the event to trigger. Can you not just use "EndOverlap" instead of "BeginOverlap" event?

        https://i.imgur.com/b8a8B7h.png

        Most collision systems are completely built around a convex shape (fully solid with no overhangs). To have a hole in something and detect the 'interiors' of an overhang would fall into the concave shape category. Most systems typically encouraging breaking concave shape into multiple smaller convex shapes.

        However, there are work arounds as you mentioned with tracing and other things but are typically considerably slower than a traditional convex collisions.

        In 2d space its typically easier to do a 'every line collision', or "hollow shapes", where you could just hit detect on a line intersection. But in 3d space it becomes far more complex because most things are technically hollow but collision systems assume they aren't. It gets tricky.
        Last edited by namrog84; 08-21-2018, 05:34 PM.

        Comment


          #5
          Originally posted by namrog84 View Post
          3. Depending when you want the event to trigger. Can you not just use "EndOverlap" instead of "BeginOverlap" event?
          Unfortunately that is far from ideal. I need to use a line trace for a number of reasons, not least of which is because I'm using third party code - of which I have little understanding - and it needs to line trace for the hit-data line traces provide.

          Comment


            #6
            Okay so I finally got a working solution, better late than never. I have not been working on it all this time. I found a way to accomplish my goals using purely built-in functionality, which is nice.

            I've got a laser attached to a projectile, and on the projectile's sphere component I've set the collision as seen below.




            This isn't the ideal solution I was looking for, but I am not sure that the solution I want is even possible. Since ideally the "simple" collision component would be a concave primitive shape. If it is possible, perhaps it could be done with some calculus describing a hollow sphere or something as seen below.



            If somebody now or in the future has such a solution, please share.
            Last edited by JoshC; 12-17-2018, 11:22 PM.

            Comment


              #7
              If you know the surface you're hitting is hollow and the surface "thickness" is 0, just flip the impact normal and bam - there's your inverse hit. If the surface you're hitting has a defined / known thickness, you can also offset the impact point along the trace normal too.
              Last edited by TheJamsh; 12-11-2018, 05:42 PM.

              Comment


                #8
                Originally posted by TheJamsh View Post
                If you know the surface you're hitting is hollow and the surface "thickness" is 1 unit, just flip the impact normal and bam - there's your inverse hit. If the surface you're hitting has a defined / known thickness, you can also offset the impact point along the trace normal too.
                That is a nice trick for getting the normal for a hit, but on the other side of the sphere. I think that should work for any surface.

                If only the shape could be made as a collision component. I want simple collisions =(

                Comment


                  #9
                  Simple method I've used this MouseOff() events on Actors and Components in several projects:

                  - save pointer to actor and/or component your ray trace hit this frame and last frame
                  - if they aren't equal then MouseOff() event on the object hit last frame
                  Last edited by Jocko Jonson; 12-11-2018, 10:14 AM.

                  Comment


                    #10
                    Backface line tracing isn't really possible, it's not supported by PhysX. You just have to use a crafty method to get around it.

                    If you just want the normal of the backface, you can flip the impact normal of the hit result.

                    Comment


                      #11
                      Originally posted by TheJamsh View Post
                      Backface line tracing isn't really possible, it's not supported by PhysX. You just have to use a crafty method to get around it.

                      If you just want the normal of the backface, you can flip the impact normal of the hit result.
                      Thanks now I at least know what to refer to it by.

                      Comment

                      Working...
                      X