So I’ve searched the forum and I can’t come up with any worthwhile answers.
Why isn’t there a cone trace component in blueprint? I mean it would seem obvious to do something like this. For now the best thing available is to attempt to fake it through multiple single rotating box traces in order to get things working. Definitely not cheap performance wise, takes a lot of time to set up properly and creates a lot of visual clutter.
Why not try a box or sphere trace that contains the desired cone, and then determine the angle from the center of the cone to the object to determine if the object is within the cone or not?
Or even a cone-shaped mesh that you use purely for collision and disable when not in use?
Why would it not be a good thing to have a cone shaped trace? It doesn’t make sense not to have one, as the performance hit would arguably be minimal. It would also add to the readability of blueprints as you’d need less nodes to just mimic similar behavior. Even a trapezoid shape would suffice, and that’s just a cube with its points adjusted accordingly.
I also just found out that there is the additional challenge of binding the rotation of the trace to the forward axis of the object projecting it. Is there any way of doing this?
I think a cone-shaped trace would be great, there are lots of games that would benefit from using conic shapes. But there isn’t one right now, so you’ll have to make something yourself:
Difficulty to implement/Accuracy/Estimated runtime cost
Hard/High/Cheap - Write the collision math from scratch or find an existing implementation that’s easy to port.
Medium/Medium to Low/Cheap to Medium - Use an existing trace, and then determine the angle between the object and the center of the cone.
Low/Low to Medium/Cheap to Medium - Use several line traces, more needed the wider the end of the trace is and the smaller the object you’re looking for is.
Easy/High/Expensive - Activate a conic mesh as needed.
I’m sure there are some more solutions but those are all I can think of.
The problem with the traces is the problem I hinted at in my previous post: Trace shapes (or lines) won’t rotate with the object, meaning they will always face the direction they were put in. I have yet to remedy this problem, but it essentially nullifies all solutions containing trace nodes. What’s left is to hardcode it myself, a task I’m not going to attempt.
Alternative, if there would be some way of using the cone check option from the behavior tree (as my setup currently is using BTs), that would be great. There is however very little information about this, and no way to debug it. My attempts with it have been futile due to insufficient documentation.
Traces can easily be set up to rotate with the object, by using the forward vector, multiplied by a constant, and added to the position vector, to determjne the end point of the trace.
So my findings in this: I got the cone check working in a static location, however I’m facing the same problem as before: The cone will not rotate with the object. I would very much like to know what I need to do to make it rotate, save for messing with the mesh and adding a socket just so it will work.
It would be useful, especially to implement realistic visibility calculations. My guess (I’m not physics engine expert, so definitely just a guess) is that it wouldn’t be a minimal performance hit.
UE4 calls both of these Traces, but one is tracing a ray and the other is sweeping a volume through space.
To try to implement a cone trace with one of these methods, you’d either have to a) shoot a N rays in a cone pattern to approximate it or b) sweep a bunch of objects (spheres or boxes probably).
Both methods suffer from the following problems:
They have variable resolution along the sweeps. At the beginning of the trace/sweep when the rays/objects are near each other, they are good at detecting hits, but as they move along the cone height, they get spread out and may miss hits that fall in the cone. The worst resolution is at the end of the cone, which is a function of the cone’s radius.
They require N traces/sweeps, depending on how much resolution you want. Since you lose resolution as the cone radius increases, you may also want to do more sweeps to compensate, which means users of this function would have to make a choice between performance and resolution.
I don’t know enough about the math behind traces and sweep hit detection to comment intelligently, but I think a cone trace, if possible at all, would require something completely different than they are doing now. For example, to implement a cone trace for visibility calculations like I want with a sweep, the physics engine would have to sweep something like a disc, increasing the size as it moves along.