-
-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a ray_thickness
property to RayCast2D
#2577
Comments
I think that ray casting cannot have a notion of width, only length. It's like segment intersection on mathematical level. If this proposal is implemented as-is, then it would require rewriting the underlying physics backends on a deeper level. However, what you ask for can be achieved with shape casting, see #710. You'd need to assign a This feature is available in Goost, by the way: The same thing is possible to do in Godot via script, but requires working with low-level API. |
In addition to shapecasting, you can just adjust your rays. Instead of adding a single one at the center, add two at the edges. Add more rays in the middle to have wider coverage. Those are not that computationally hard to use them so sparsely. |
@pycbouh Thanks, but I'm well aware about this practice. I thought I was very clear about it when I wrote "Using multiple rays ..." right in the beginning. I submitted this proposal issue because I am really unsatisfied with using multiple rays (which I do often). Searching for Shape casting alternatives only led me to Godot's Raycast Shapes which has a bit unfortunate name as it sounds so much alike, but has nothing to do with this issue at all. I must have missed Xrayez proposal though. I thought I still put this up here to express my desire just in case someone does see an efficient way to implement it and feels inspired. If #710 gets included in the official binaries, and is userfirendly enough, maybe it turns out there is no need for this proposal any more. |
Sorry that I missed that, but that's still a valid practice. Gaps between the rays are fine, because there is really no perfect physics in games, it's all an illusion. You figure out a shape that works best for you and use that. And like Xrayez mentioned, there is really no concept of thickness in ray casting. I know that you know that, but that doesn't mean that this argument should be ignored. |
In my experience gaps are sometimes fine, often they are not. I don't write issues because I am board, I write them after being frustrated and annoyed with something I have used a lot, and tried what I can to find workarounds. Maybe for you in all your projects gaps are fine, and that is good. |
I'm not sure why you choose to use such an aggressive writing tone, but emitting a multitude of rays is a normal practice in gamedev. It's used everywhere by lots of developers. The only trick is to tinker the shape in which you cast your rays. That's all I'm saying here. |
ray_thickness
property to RayCast2D
@pycbouh There is no absolutely no aggressive mindset, intention and definitely no undertone whatsoever towards you, in my post or in my comments. Please try not to read into things. I assume you are having the best and only positive intentions, regardless what "tone" I might be inclined to read into your comments, please do the same for me. |
ray_thickness
property to RayCast2D
ray_thickness
property to RayCast2D
Is shape casting possible yet in node form? It’s so easy to add a raycast node and set it up visually with a node (something Unity never got) and it would be great to do the same with a shape. Also, multiple casts requires looping through each raycast node for collision checks which is surely not as performant as a shape. |
Currently doing raycasting in godot 4 with:
A very simple way of getting raycast results, but can shapecasts be used like this? It would still be nice to be able to define a thickness to an intersect_ray. |
This comment was marked as off-topic.
This comment was marked as off-topic.
@PerMalmberg Please don't bump without contributing significant new information. Use the 👍 reaction button on the first post instead. |
Or you could encouragingly let @PerMalmberg know it has been implemented and possibly close this proposal: |
Well I couldn't have known a random proposal that wasn't closed by someone else, no need for that attitude over a basic moderation message... This isn't necessarily the same thing as a shape cast, so I wouldn't close it, a shape cast covers some of this, but far from all If this had been considered just a case of shape casting it would either have been linked to that issue, or closed as a duplicate of the shape cast issue, but it wasn't as it's separate, shape casts were added over 3 years ago so it's clearly not the same thing (you could also have brought it up last year when you commented here, but I won't hold you to that as it isn't the same thing) |
I don't see how OP's proposal can be implemented without shapecasting, or throwing multiple rays that are close enough to each other. (How close they should be will depend on your needs, so this would mean adding another property to control ray separation.) |
A relevant difference is that |
Describe the project you are working on
Projects with projectiles, shooters, platformers ect
Describe the problem or limitation you are having in your project
Using multiple rays for when you really want a single thick ray is both a hassle and unreliable, because inaccurate. Whatever you do, there are always gaps between your rays.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
One ray with thickness instead of many rays with gaps would mean much easier, much more intuitive and way more reliable work with raycasts.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
If this enhancement will not be used often, can it be worked around with a few lines of script?
One raycast is rarely ever enough, so I would say this is used often and to my knowledge can't be worked around.
Is there a reason why this should be core and not an add-on in the asset library?
It would improve user friendlyness and reliability of an existing feature.
The text was updated successfully, but these errors were encountered: