this post was submitted on 04 Jul 2023
14 points (100.0% liked)

Godot

5839 readers
23 users here now

Welcome to the programming.dev Godot community!

This is a place where you can discuss about anything relating to the Godot game engine. Feel free to ask questions, post tutorials, show off your godot game, etc.

Make sure to follow the Godot CoC while chatting

We have a matrix room that can be used for chatting with other members of the community here

Links

Other Communities

Rules

We have a four strike system in this community where you get warned the first time you break a rule, then given a week ban, then given a year ban, then a permanent ban. Certain actions may bypass this and go straight to permanent ban if severe enough and done with malicious intent

Wormhole

[email protected]

Credits

founded 1 year ago
MODERATORS
Ategon
snowe
Feyter
14
Is there any way to get ray intersections with meshes that don't have collisions? (lemmy.blahaj.zone)
submitted 1 year ago* (last edited 1 year ago) by [email protected] to c/godot
17 comments fedilink hide all child comments
 

So far (outside of somehow adding it into Godot via C++ myself) this doesn't seem possible but wanted to ask to see if i maybe missed something.

The most i could find was this issue and a couple of related ones.

My specific use case would be for drawing bullet holes onto meshes (via decals). Ideally also being able to determine the texture used on the faces of the meshes that are intersected (to determine an appropriate decal to use).

Having everything that is possible to hit duplicated as a static body or area seems excessive to me. Since the only data required for ray intersection should be the transform of the meshes faces/edges/vertices etc which i would think are already contained in the mesh itself?

Failing being able to make intersecting a ray with meshes work i will probably try experimenting with using areas. They seem the lowest performance cost out of all the options the existing ray cast can detect. I would still end up with most of the games geometry being duplicated though, once as actual meshes and once as collisions for all the areas.

you are viewing a single comment's thread
view the rest of the comments
[–] nibblebit 1 points 1 year ago* (last edited 1 year ago) (1 children)

I'm having trouble picturing the problem. Are you trying to have a bullet leave multiple decals in it's path? Or decal non-colliders?

Maybe you can do something with collision layers and assigning the colliding objects to groups that determine the texture of the decal?

[–] [email protected] 1 points 1 year ago (1 children)

It seems op wants to have areas that can't be reached not have colliders for performance, but still wants his bullets to be able to register hitting them for placing a decal on the collision.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago) (1 children)

Yeah this, although i should maybe clarify that the "bullet" is not a object/scene that has a position, i just perform one raycast to determine where it lands.

Also its not just about areas that cant be reached but very small "detail" things as well. Eg.: i might want to have bullet holes appear on the leaves of a plant but other than placing the hole on them the leaves don't need to interact with the bullet or the physics system in any way. So creating an area or physics body just for this purpose seems like overkill.

[–] Feyter 1 points 1 year ago* (last edited 1 year ago) (1 children)

So for me what you want sounds either like magic or like nonsense.

Ray casting is part of physics processing and therefore need a physics body. Using physics body actually should reduce performance impact since you can reduce the geometry of those making calculation less extensive as when you use the full Mesh geometry with al the details.

So for me just creating an auto generated physics body for ray pickability or using the actual mesh geometry sounds like the same thing. But maybe I'm missing something here.

[–] [email protected] 2 points 1 year ago (1 children)

So for me what you want sounds either like magic or like nonsense.

maybe XD.

Ray casting is part of physics processing and therefore need a physics body. Using physics body actually should reduce performance impact since you can reduce the geometry of those making calculation less extensive as when you use the full Mesh geometry with al the details.

Yeah i know, but my problem (was) that almost all meshes visible to the player would need a collision to properly place decals on. And additionally, for the decals to look right, they need to be placed close to the mesh, so i need the collision shape to match the mesh very closely. Which doesn't allow me to simplify the collision a whole lot.

So effectively i have to duplicate most meshes in the scene as collision objects while barely or not being able to simplify the collision compared to the mesh. Also most of those collision objects would have no use besides being intersected by a handful of rays per second to place decals since. While most meshes that are visible to the player need bullet holes on them when hit. Most also don't need to interact with the bullet/shooting in any way besides that.

My fear was that Areas or StaticBodies cant be optimized well for something like this where i have large quantities of them with complex shapes that are rarely used. Ideally i would still have a way to directly intersect the visual meshes but i can see how that might be performance intensive to do even if built into the engine so it makes sense it doesn't exist.

So for me just creating an auto generated physics body for ray pickability or using the actual mesh geometry sounds like the same thing. But maybe I’m missing something here.

You aren't really missing anything. I'm attempting that solution now since it seems like the only feasible one and i'm just crossing my fingers and hoping that my fears about Godot not being able to handle that many areas without performance issues was unfounded. (Although in the current state of the scenes i have i suspect it is going to be fine either way. I'm just worried it might not scale well if i eventually use larger quantities of more complex meshes)

[–] Feyter 1 points 1 year ago

To much is always to much.

My advice would be to implement it first and try to optimize if you need to. I think disabling object outside of a range what the player can currently interact with would probably be a good start to save performance.