For a raycast, I know you can approximate a point of impact by getting the closest point between the ray and a simplex. For example, you could get the closest point between a ray and line segment, and if the distance is less than the thickness of the ray + the thickness of the line segment, it is a hit, and the closest point on the ray is the hit point. But this isn't accurate; it shouldn't be the point of deepest penetration, but of first penetration, which requires a bit more weird math to compute. Are you using the approximate or exact method (or some other method) to calculate the hit point?
Also, I'm guessing the Bresenham algorithm is a way to enumerate through cells that intersect with a line. I'm guessing it intuitively just checks what face of a cell intersects with a line, and then navigates to the neighbor on the other side of that face, repeating until the end of the line or grid is reached. I think Wolfenstein did something similar to this to render their grid-based 2.5d worlds.
I can see this being slower than just enumerating through a small list of occupied cells, though it might be faster when there are a lot of them... which shouldn't happen too often (maybe it'd be more a problem with fluid?). (I can see this approach being especially costly when you have to also search neighbors when using a thick ray.)
I wonder what % of occupied cells would be required for the more complex enumeration to be worthwhile. ::thinkingface::
In any case, this is just food for thought. I'm sure this is plenty!
Regarding the collision-detection stuff needing to be enabled for raycasts to work (as otherwise the simplex grid isn't built), it might be a good idea to make note of that on the solver in the inspector, just for the sake of making it easier for future users. Perhaps name the collision module "Collision/Queries" and when unfolded, it shows a HelpBox() in there. *shrug*
Oh, and on a side note, I'm imagining how cool it'd be to have a level in a game where some of the walkable surfaces are cloth.
Like, a room with a tarp draped over a gigantic pit.(Though, I can see tunneling being an issue unless the cloth is especially thick.)
Also, I'm guessing the Bresenham algorithm is a way to enumerate through cells that intersect with a line. I'm guessing it intuitively just checks what face of a cell intersects with a line, and then navigates to the neighbor on the other side of that face, repeating until the end of the line or grid is reached. I think Wolfenstein did something similar to this to render their grid-based 2.5d worlds.
I can see this being slower than just enumerating through a small list of occupied cells, though it might be faster when there are a lot of them... which shouldn't happen too often (maybe it'd be more a problem with fluid?). (I can see this approach being especially costly when you have to also search neighbors when using a thick ray.)
I wonder what % of occupied cells would be required for the more complex enumeration to be worthwhile. ::thinkingface::
In any case, this is just food for thought. I'm sure this is plenty!
Regarding the collision-detection stuff needing to be enabled for raycasts to work (as otherwise the simplex grid isn't built), it might be a good idea to make note of that on the solver in the inspector, just for the sake of making it easier for future users. Perhaps name the collision module "Collision/Queries" and when unfolded, it shows a HelpBox() in there. *shrug*
Oh, and on a side note, I'm imagining how cool it'd be to have a level in a game where some of the walkable surfaces are cloth.
Like, a room with a tarp draped over a gigantic pit.(Though, I can see tunneling being an issue unless the cloth is especially thick.)