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.
I might be wrong but decals dont really care about collisions so you can just spawn a single decal regardless what it hits. If you really want to use different decals for different materials you can put them on different layers and spawn multiple decals on those layers. This works for static things. If you want decals on dynamic things you need to keep track of those objects Im afraid.
If you really want to use different decals for different materials you can put them on different layers and spawn multiple decals on those layers.
Ooh, yeah that might be an option, ill keep it in mind when i get there, thanks :D.
I might be wrong but decals dont really care about collisions so you can just spawn a single decal regardless what it hits
Ive already been using a single decal to begin with and i’m having problems that being able to get ray intersections with meshes could solve. The decals need to be close to the mesh they are supposed to be projected on to look right. Otherwise they seem to fade with distance.
For example here:
The bullet is colliding with a triangle shaped collider that goes over these small stairs since that is more convenient and simpler for collisions with the player. But because the collision is simplified compared to the stairs actual mesh the decal can get placed far away from the mesh and not show up or only show up in some places.
If i can only get ray intersections with colliders i’d have to create a much more complex collider that matches the stair mesh much closer to be able to place the decals closer to the mesh. But creating that many colliders that have no other uses besides this one seems like a waste. If i could get ray intersections with meshes directly i could just use that to determine where the decal should be located.
You can adjust the size of the decal and the vertical fade to avoid these issues. You can use the mesh’s AABB to approximate the size so that it always hits the mesh. I dont know of a way to intersect per primitive, I think that is a fairly expensive operation. That is essentially the same as GPU raytracing except not on the GPU. Another idea would be to use a simplified collision mesh that is on a completely different layer to everything else. Hopefully the engine optimizes that in a way that it is not checked against other colliders during the phyiscs step. But I think the better approach is to fiddle with the decals in a way that the end result is satisfying.
You can use the mesh’s AABB to approximate the size so that it always hits the mesh […] But I think the better approach is to fiddle with the decals in a way that the end result is satisfying.
I’ve been trying this approach now for a while (at least if i understood you correctly). Though im approximating the size of the decal by finding the location where the raycast for the bullet exits the collider instead of using a bounding box. Currently struggling a bit with sizing and positioning the decal correctly for it to show up properly😅. But im also starting to think this approach isn’t going to be satisfying when i do get it to work.
The problem is that i am not sure along which direction to project the decal. If the decal projects along the path of the bullet (which would make the most physical sense i think) it can end up incredibly stretched when it encounters the mesh at a very shallow angle. Eg:
So i’m back to the original problem of not being able to determine where/which face of the “visual” mesh the bullet would hit and what its normal is, at least not without making a lot of unnecessary colliders that match it more closely. And if i use the one normal i do have access to (the one from the collider) i cannot guarantee that it is similar enough to the normal of the mesh face the decal will be projected onto to not be stretched anyways.
I dont think there is anything wrong with that picture. That makes perfect physical sense to me.
Well yeah physically its sort of right, but for one (though im not sure if this is just a difference of opinion or if its not clear from the picture) imo the streched hole does seem abnormally large. But also if i use any decal more complicated than just this black circle it would seem off. Since the bullet hole texture would be modeled off a “clean” 90 degree impact bullet hole it would look off if streched like that.
Here a simple example that makes it a bit more clear where i put a white x inside the bullet hole.
Decals that make sense for (near) 90 degree impacts would look bad (or at least very different) when stretched like this.
Oh yeah, that makes sense. You can try capping the angle between the collision normal and the incoming ray. But it will always be an approximation. I dont think you should get too hung up on it. People always see malformed decals in games. Or footprints on hard surfaces etc. Its not a big deal.
Alternatively if you get the mesh by using the collision shapes you can iterate on the mesh’s surfaces and use godot’s geometry class to check for intersection. If you get a reference to the mesh you can use get_faces method and Geometry class’s ray_intersects_triangle method. This is a very manual method and not very flexible regarding node setups. It is also not very performant.
Oh i guess this is exactly what i was asking for XD. Although im probably not going to try it since always needing to place the relevant meshes in the same places relative to the collider does seem like a pretty strict requirement like you said.
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?
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.
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.
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.
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)
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.