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 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.
