If I could contribute on a use case for batched shapecasting: we have some pretty complex hitboxes and multiple at that. Our current implementation relies on casting from hundreds to thousands of points every frame and sometimes we need to have a little extra to make sure hits register.
I’m not sure how useful batched casting would be for us, but if it allowed us to grab a result over multiple casts, that would be pretty neat and abstract a lot of the handiwork we do with our current implementation.
Below is an example of an older model we use. All the green points represent points which we cast from. For accuracy’s sake, we don’t amalgamate this into a single hitbox since accurate hits are a huge part of what make the gameplay feel satisfying, responsive and flexible on design.
This is a feature I was looking forward to, anyway I think this could be much better if there was a way to create your own convex support function for shape casting, I am also a bit disappointed with the limitations. I wonder if those limitations are due to the way this casting shape algorithm is made.
If I’m not mistaken, this uses GJK + Conservative Advancement to achieve a shape cast, right?
For example, we could have a method like this:
Also Physics Engine like Bullet Engine uses a radius that covers the shape, this guarantees a faster result since GJK computes the distance between two non-quadric shapes way easier. Also, to my knowledge Bullet Engine uses Conservative Advancement, I wonder if Roblox uses Bullet Engine too.
How comparable is it, performance wise, to fire one shapecast downwards to determine if a player is in the air compared to using FloorMaterial of the Humanoid (casts up to 9 rays)?
When I heard the name Shapecast, I thought it would create a shape around an origin point once and detect the first collision with that shape, In other words, If I want to detect collisions for a moving projectile, I would create a Shapecast at the origin of that projectile per frame as the projectile is moving,
But casting a shape in a direction? yeah, never thought of that, Not even sure which one is better but I think the latter makes it easier for devs, I think the first approach would leave areas without detection (gaps) as the projectile is moving with high velocity, I guess I can understand why they did it that way.
I’m still not sure how this would be used for slow moving projectiles though, perhaps the same approach used in Fastcast can be used with this, might not provide the best performance though.
Also, what about AOE attacks, it only returns one collision per cast, so perhaps it’s not suitable for that either.
When creating an explosion at the target point, you’re still using an infinitely tiny line to detect the object in question, meaning the explosion will miss the target if the raycast doesnt collide with the object or with anything else close enough for the explosion to hit the object. With the shapecasts, the ray has volume, so the object doesnt need to be directly touching the center of the ray to function.
Also, making an explosion and connection for each ray doesnt sound well on performance.
Yes! This would be perfect for “detection radius” AI - something like a monster searching for players, you could Conecast from it’s face to detect players in it’s frontal cone.
Would be great if we could customize the radius of the cone, perhaps even the distance in studs that it’s projected outwards to - I’m definitely excited for this!
Great update! I don’t really know if their will be a scenario where I would need to do this but if that comes up then I’ll be glad to use it!
Couldn’t you just get all players within the max distance using a query then raycast to each of them to see if there is line of sight instead of raycasting hundreds of rays?
Just an idea, not too sure about the in-game applications for it, but what about a surface-only property? Take the sphere cast, then hollow it out, and only return parts intersecting the surface, allowing us to do a high-density spherical cast everywhere within x distance.
Myself and many others would appreciate this + an implementation of a bulk raycast API. In general, too much frame time is spent on performing multiple raycasts.