would it be possible to have a "point collider" or "vector collider"

hy guys,
i was just thinking it would be handy in editor /physics collection to have another collider type like "point collider" or "vector collider"

this type just would handle one single collision point and one normal. why ? simplicity...and maybe faster ?

what for ? for use for example in a character controller to check distance between an obstacle, or the height of an obstacle, the depth of a pit etc etc
actually it can be done handling sphères or boxes but it would be simpler to handle only one point..

does it make sense ?

thanks

 

I dont really understand what you mean. Is it something raycasting, spherecasting, etc... cant do?

 

sure raycasting can do that... but you must define it by script.
a point collider just would act exactly as a sphere or a box except that it would provide only one point instead of a collection.

typical use would be to attach it to a character controller and define distance to an obstacle when running for example, test the height of the obstacle and thus, triggering a jump or a stop (if obstacle it too high), it could also be used to define if the character is approaching a cliff or a pit, triggering a stop.

if you say it's useless then fine, i'll take your advise.

 

The short answer is no, it's physically impossible. The long answer is that a collider works this way:
1.it moves
2.it checks for intersection
3.it moves so the intersection goes away
You could cheat a little, and set a sphere collider to a very low radius, but a true poibtcollider wont be possible.

 

I forgot to explain why it wont work, sorry. So the game corrigates the overlap so:
1.After checking, if there's an oveerap, it checks, which side intersects with the other object the most
2.After that it applies forces to the object, so they doesnt intersect anymore.
A point has no sides so it wont work in the normal way. You could make one, but it would need to check, where it came from, then applying forces to it, until it gets out of the object. It would be complicated.

 

thanks,
i understant that the word "collider" implies physical data as well as mesh data.

but call it "impact" or "rayHit" for example, and it would just basically indicate the point of collision, eventually the normal and that would be enough for bullets or projectile impacts ie, or to check if a player reaches an obstacle.
the difference is that you could attach it editor side instead of having to code a raycast.

but nvm that was just a suggestion, i'll stick with std colliders and rays

thanks

 

I wrote something like a point collider into Virtual RC Racing (2004 version) for its collision detection/response system. It was a pretty common approach at one time back in the days of much more scarce CPU resources (I had a 333Mhz laptop at the time), and because it was simple to do. I believe Microsoft Flight Simulator used something like it too, and I had several friends writing their own race car simulators that were doing it as well. While I don't remember all the details about how mine worked (probably wrote it in 2001), the basic idea was this:

The mesh had a handful of "collision points" assigned to it that were strategically placed around the car meshes in places that usually worked reasonably well. The track and track object triangles were sitting in a quadtree. Each collision point would check which quadtree node it was in, then do a quick dot product with the normal of each triangle in the quadtree node to see which side of each triangle the point was on. If it was on the backside of a triangle, the point was projected to each triangle plane. That point was then checked to see if it was inside the triangle.

If it was inside a triangle, you'd generate a collision impulse somehow. I used the depth of penetration of the point like a spring which produced a force along the triangle normal direction. That's enough to keep a car that's flipped over from falling through the track (most of the time, anyway). There was also a velocity based force in there too. You compute the velocity of the point, dot that with the triangle normal and out pops the velocity in the triangle normal direction which is used to compute an impulse for higher speed collisions.

The "spring depth" approach is called a "penalty method" while the velocity approach is called an "impulse method." Contrary to being impossible, this was very common years ago due to its simplicity and speed.

It comes with its own problems and isn't the best (which is why years later I spent over a year rewriting the collision detection/response system to a much more robust box system that used the edges and so on too), but it was very fast.

Just last week I wrote something that was inspired by it for my boat game (Design it, Drive it: Speedboats). I use it to place objects like the seats and driver's feet firmly on the floor of a procedurally generated mesh created by the user inside the game. It's all just points. Here's one of the stages of its operation rendered:



The green lines are just visual markers that extend from the center of some of the possible hit triangles to a vector where the seat is going to be pushed along (up in this case) to get the seat to pop up out of the floor. It's not exactly the same thing, but pretty similar. I'm doing the raycasts myself on the mesh triangles directly. There are no Unity colliders or Unity RayCast() calls here.

Anyway, for all practical purposes that really is just a simple raycasting system which would be easy to add into Unity oneself. One of many downsides is that you can only collide with things from one direction. You could also do a raycast from the last point's position to the current point's position or something similar I suppose (that doesn't work anymore once the object has pretty much stopped though), but yes, point colliders are possible and is what just about everybody used to do back in the day. They are quite limited compared to geometrical colliders like Unity and most other systems probably use now, but they do have their uses. The main benefit is that they're very fast and much easier to write. The downside is they don't always work very well. The 2004 version of VRC was notorious for cars that bounced around or occasionally were shot into outer space.

 

I can't speak for Unity, but vertex checks on box and other colliders often work very much like this, where you just do a point comparison against a mesh to see if it's inside something or not. But you can't check point colliders against other point colliders of course, only points versus triangles.

 

Thanks a lot Todd Wasson, for that really interesting answer, really.
it makes it cleat that it is fast.
and yes, i do'nt plan to use it for collisions and physics but just to indicate whether ot not the player is in front of an obstacle, a cave, a cliff, a hole , water, etc
almost like a sonar system.

maybe i'll have to build a prefab, with a script and a dummy.

thanks for helping

 

That would probably be pretty easy. I'd just make it a script or two that you can drop on to whatever objects you want. Probably most of that type of stuff wouldn't even need a ray cast. Maybe just a distance check along a forward vector here and there.

You can do a lot with points. I say go for it.

 

thanks Todd