koobas.hobune.stream
RayCast or LineCast?
Hi,
First let me say I've chosen LineCast because I'd read that Linecast will detect intersection even if both StartPos and EndPos are within the collider in a old post in this forum.
I'm generating a flight path and every 0.2 seconds I call a routine that sends out line casts in a 180 degree arc looking for colliders, all works fine until one of the line cast arcs spawns say inside a block, like a tower block, even with the ends of the line cast showing through the block they do not show a detection, has line cast been changed, now on Unity 5.5
Cheers.
just tested this, and linecast behaves like raycast, ie. the direction matters so it won't register a collider hit if the start position is inside of the collider. If both start and end positions are inside it also doesn't register a hit. I don't know if this was recently changed, but it's way it is now!
I'm working on a project that needs to do a similar thing to yours with ray/linecasts and what I'm doing is using two RaycastAll in BOTH directions to get an array of colliders no matter where the cast starts/ends.
Hi, thanks for the input, when you say you are going to use two RaycastAll in BOTH directions to get an array of colliders no matter where the cast starts/ends.
How exactly will that work? I'm doing a bezier curve and checking every 0.2 seconds along the direction of the curve, so you say as it exits the collider doing the raycast at the same position but reversed? That would work just more expense, mobile.
Ah sorry, I didn't make that clear. I'm not casting from the same position for both rays. The "reverse" ray starts at the end position of the forward ray. So I'm casting from start to end forwards, then end to start (of the forwards ray) backwards. Hope this helps!
Linecast and Raycast always worked the same way. It's just a different way of specifying the ray. So neither Raycast nor Linecast has ever detected a collider if the ray starts inside the collider. Any collision surface is a directed surface, It simply doesn't exist when "seen" from the backside. Any collider (with the only exception: the non-convex $$anonymous$$eshCollider ) represent a convex, closed volume. So any ray starting anywhere inside the volume can never hit the outside of the collider.
@Griffo: I'm a bit confused. By "180 degree arc" do you mean you cast something like 180 raycasts, one every degree? While this is possible it's in most cases a waste of processing power. Why don't you simply use OverlapSphere? It will return any collider which bounds intersect with the sphere you specified. If you want to restrict the objects returned you can filter them either based on their relative position or do an additional raycast to the objects center if you need an actual impact point.
You didn't really say for what exact purpose you do those raycast and how you use the results.
@conman79 thanks for clearing that up for me, appreciate it.
@Bunny83 sorry I didn't make it more clear, 180 degree sound to complicated but I only send out a LineCast 7 times starting at -Vector3.right and adding 30 degrees each time, I've attached a picture so you can see what I'm doing.
I generate a bezier curve a random amount of times, each new start position becomes the last bezier curves end position and I divide each bezier curve into 100 points, then I keep adding the points to a list, when the whole flightpath is generated it tells the iRobot its finished so he can go flying.
I also send a LineCast down from the flight point 2mt to check the flight path is not to close to the floor, in the picture that have a small yellow sphere at the ends, just for my visual debugging.
All this is called from a routine every 0.2 seconds.
If any of the LineCasts detect a collider I then delete that bezier curve and a new one is generated, and so on until no collisions are detected.
@Bunny83 you may be able to help me with another problem I posted on this forum HERE I appreciate your help and I'd appreciate anymore you can give, thanks.
PS .. The white Vector3.up's every flight point you can see are again for my visual debugging when trying to get the rotation (roll) of each fight point, in my other problem.
![alt text][2]
