Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Raycast vs Instantiate

Discussion in 'Game Design' started by Flynn_Prime, May 9, 2017.

  1. Flynn_Prime

    Flynn_Prime

    Joined:
    Apr 26, 2017
    Posts:
    387
    I am making an Android shooting game. I have done some research as to the pros and cons of using raycast and instantiate and I would just like more information on themy really.

    I understand that using projectiles can be more expensive, but I don't think this will be too much of an issue (hopefully) as I can use object pooling. Other than that the only thing I notice is that the projectile seems to pass though objects no matter what colliders I have on them.

    Is there any real need for me to use raycasts, and if so why? They seem much less customizable (not that I am very clued up on them) and as they are instant hit I can't see them being very good for various types of weapons with diffevent trajectories, and projectile speeds etc.

    Thanks in advance for any input!
     
  2. neoshaman

    neoshaman

    Joined:
    Feb 11, 2011
    Posts:
    6,492
    Look for hitscan vs projectile weapon in fps, there is design issues and it's not a either, as the best game use both (destiny, doom, etc ...)
     
  3. Flynn_Prime

    Flynn_Prime

    Joined:
    Apr 26, 2017
    Posts:
    387
    Thank you for the reply. Use both in what way? Simultaneously or either depending on weapon type?
     
  4. neoshaman

    neoshaman

    Joined:
    Feb 11, 2011
    Posts:
    6,492
    Well look at this:


     
    Kona likes this.
  5. Flynn_Prime

    Flynn_Prime

    Joined:
    Apr 26, 2017
    Posts:
    387
    Thanks for those, I found them very helpful. Although my game is going to be top down (with similar mechanics to unity's survival shooter) I will try to make use of both projectiles and raycasting.

    However, is there a way to add things like bullet trails to hitcast?
     
  6. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    Yes just set up a Trail render at one location in the current frame and move it to the hit location in the next. Not sure if it would work from the instantiated position (weapon launch point) then moved to the hit location, in the same frame, so give that a test and let us know.

    Or you could just use a beam object setup it's pivot point at one end and scale it to the desired length. Should be lower draw calls than a trail. Two double sided planes or 8 tris vs a trail renderers need to work out the camera facing angle and draw a triangle strip.
     
    cstooch and Flynn_Prime like this.
  7. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,008
    The problem with colliders is that if they move very fast (e.g. several hundred meters/second) then you may end up with a situation where they are behind an obstacle in one frame, and in front of it the next frame - so there is no frame in which the colliders actually intersect, and no collision is detected.

    The best way to deal with this afaik is to store the bullet's position at the end of each frame, and raycast from the previous position to the current position each new frame to determine if there was an obstacle there.

    This is also great for instantiating hit effects in the correct position, because when only using a collider, even if a collision is detected, it is not detected at the collision entry point but rather wherever the bullet ends up at the end of the frame, usually somewhere inside the object that has been hit.

    In terms of trails, I think it is best to use a rigidbody on the projectile and move it using physics, but leave out the collider and use the raycast method I described. That way you can have a physically accurate bullet (non-instantaneous hits, and you can even add bullet drop and other nifty things) and then just add a trail renderer to it as well.

    PS this is not a game design question btw, should have been posted elsewhere.
     
  8. Flynn_Prime

    Flynn_Prime

    Joined:
    Apr 26, 2017
    Posts:
    387
    Thank you for the input! Sounds like a good idea. Would using a trigger instead of a collider face the same issues? Also, if there is no collider on the object how will the script no when the projectile hits an object?

    Apologies, I didn't know where else to post a query like this. It's not really a scripting problem
     
    Last edited: May 10, 2017
  9. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,008
    A trigger collider is simply a collider which does not physically react to hitting an object, like a 'ghost' collider. It still registers the collision by detecting intersection with another object, but it will not bounce off or anything like that, but will pass right through. So the problem still applies because it is due to the collider being on different sides of the obstacle from one frame to the next, and never registering an intersection.

    The way you detect the collision without a collider is as I described, using a raycast from the previous position. You simply:
    • Store the position of the bullet at the end of each frame;
    • In the next frame (the bullet will have moved from the previous position) you raycast from the stored previous position, to the current position. If your raycast detects a hit, then your bullet has hit something between the frames, and you can create hit effects etc at the hit position (see the manual).
    FYI the game design section is for overall design strategies such as how to prevent players getting bored in an openworld game, or something like that. This is an implementation question and belongs in the Physics or the Scripting section.
     
    Carmelblob likes this.
  10. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    A trigger and collider are the same apart from a trigger allowing things to pass through it without any physics collision happening. So same issues in speed.

    A collision can be detected by either object having a script with OnCollision/Trigger methods.
     
  11. ZakCollins

    ZakCollins

    Joined:
    Jun 11, 2014
    Posts:
    52
    Do you know a good way to make the physics collision still happen as normal in that situation? I'd like my projectile to bounce off and also knock back the thing it hit just like it does in a normal collision.
     
  12. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,008
    As far as I know, the best way would be to script the collision - there's really no way to make physics work great at very high speeds. So when you detect a collision with the raycast, place the bullet at the impact point, clear its velocity, and add an impulse force to throw it backward - and another opposite force on the object you're colliding with.
     
    Carmelblob and ZakCollins like this.
  13. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    You can normally make physics work at high speeds by altering the rigidbody collision settings to dynamic or continuous and also increasing the physics solver iterations.
     
  14. neoshaman

    neoshaman

    Joined:
    Feb 11, 2011
    Posts:
    6,492
    Re reading OP I realize it was a technical question lol, I totally read that first as a game design question, glad my answer did help though lol
     
  15. cstooch

    cstooch

    Joined:
    Apr 16, 2014
    Posts:
    354
    Just thought I'd throw my own personal experience on this (or lack of!). This topic interested me as I was running into the challenge that Billy4184 mentioned (collision detection for fast moving objects can be tricky).

    To start, I used a bullet object with a sphere collider on it to detect a collision with a target. That bullet was moving so fast though that collisions frequently were not picked up because the bullet would basically warp past an enemy between subsequent frames. So I then decided to ditch the projectile collider idea and go with a Raycast from my gun-tip to a set distance away in the direction it was aiming. That ended up working, but I lost the nice visualization of a bullet sailing off.

    Tip of the cap to both Billy and Arowx for coming up with good solutions to that problem... Raycasting from the bullet's last known position to the new position (not sure why I didn't think of this simple idea) in Billy's suggestion, or doing a trail of some sort in Arowx's suggestion and just Raycasting.. no bullet required. I think I like the trail idea best, so I'm going to give that a whirl tonight.

    I haven't tried using continuous detection yet just because I'd heard others still had the problem even with that set on.. but I may give that a go first, as I like the simplicity of just having a projectile fly out and do the collision detection.

    Anyways, my post isn't meant to offer advice.. just saying thanks for the good suggestions by Billy + Arowx
     
    Carmelblob likes this.