What is the best way to achieve capsule collider collision without body movers or humanoids?

I’ve been thinking about this for the past few weeks and I just can’t seem to come to the right conclusion.

I don’t want to use humanoids, as I can’t find a way to make movement instant. The way humanoids currently work, they apply a force (you can’t control) which means that the character slowly increases to the desired speed, rather than immediately reaching it. I can’t find a way to enable rigidity which would mean players would immediately be travelling at a certain speed either. It also means less control over other potential movement types (like sliding, crawling, custom flying, or other small things I like to tinker with).

I don’t want to use body movers (such as LinearVelocity, etc…) as they do not immediately move an object within the same frame it’s set to, and can have side effects such as friction. While they allow more control, they feel less reactive, and aren’t instant or rigid. However, they do allow collisions, which can be good.

I am considering CFrame because this is: instant, rigid, and allows me to move the character within the same frame that input occurs, making movement feel snappy. I can also have further control, in the future if I wanted, over the rate at which a character should reach a target speed and also de-accelerate. They also mean I can implement any number of other mechanics, without interference.

Implementation

Part 1. The capsule Itself

I wasn’t imagining a full length capsule collider, something like this instead:

I.e. the torso, arms, and head would be inside where the capsule collider would be, however the “leg space” would be occupied by where the legs are. This would allow me smoothly move up stairs, ledges, and the sort without encountering bumpy behaviour. I believe this is the optimal way to do part 1 of the problem.
Essentially, collisions would focus on just the upper part of the body (because if your hips can’t make it, then the whole body shouldn’t either).

Part 2. Movement, and potential collisions

This sort of has me stumped. I’m not sure what the best approach to take here is.
My first thought is to do some kind of raycasting, however determining the number of rays to do per second is problematic, as too many rays may cause performance issues on older machines at the cost of higher accuracy, however fewer rays can increase performance at the cost of accuracy.

One problem in particular I can think of is the following.

Imagine this as a picture from behind the capsule collider, moving forward.
The red is the outline of the capsule collider, with the crosses being where raycasts are being shot out, to detect collisions.
The brown grid is some geometry within the game, imagine a garden square fence thing.

With the raycasts, its entirely possible that the character would not detect the geometry and could clip through it as if it was never there.
Now, while this is a low possibility, its still a possibility, and not something I’m really happy about.
There are also other possibilities such as a thin horizontal part, or wedge, not being detected and the character walking through the part, despite the fact that shouldn’t be possible.

One way I could potentially get around this, is by using a boxcast, or partcast, of some kind, in the direction of the movement vector to attempt to detect any parts that may be in the way, and determine the closest point in the opposite direction of the movement vector, to the surface of the capsule. This would then be the maximum magnitude of the movement vector and would be how far the character would move.
This may be possible with standard parts where the shape and orientation can be known, however it’s not with unions or mesh parts as geometry data is not revealed to be able to do collisions on them.

I’m not sure if some kind of method exists that would allow you to sort of partcast, with a direction and magnitude and then return the longest magnitude you could move when that cast is complete without colliding into anything, if it does, please let me know.

Thanks for reading, I know there’s probably not going to be many people out there who are able to answer this, let alone read this, so if you do know, please share your knowledge :slight_smile:

2 Likes

important question. why are you trying to make a capsule collider in the first place, why not just use Roblox default physics engine instead?

like you could just model a capsule in blender. Then from there create your own controller script

if your truly wish to create your own 3D collision detection this website could help its written in c++ code though: Capsule Collision Detection – Wicked Engine Net

As I’ve stated in my post, neither humanoids or movers provide instantaneous, rigid, controllable movement.
If input is true during the start of the frame, the movement (and camera) should occur within the same frame, and end if it ends.
There are also problems with movers not moving at the specified speed when framerates are low, when compared to using cframes.
Also I read that website, and while it would work for standard parts it would not work for parts that are unions or meshes.

i don’t think you understand my question. why create an entirely different 3D collision system when you could just use the built-in one. like Roblox has collision detection soooo…

How do you propose I use the built in collision system, while maintaining instantaneous, rigid, and perfectly controllable movement?

I would love to use the built in collision and save myself the energy and headache of not having to calculate my own collisions, but that doesn’t seem to be an option.

If you know something that I don’t, please tell me.

Wait are you making a Rigidbody-based character controller?

Yes, I’d like to be able to have the character be able to instantly move from being at 0 velocity one frame, and say, 16 the next, however, other solutions don’t seem to be able to offer that.
Even bodymovers seem limited in this scenario.

This video could help: Making A Physics Based Character Controller In Unity (for Very Very Valet) - YouTube although again it’s written in c# but the code seems simple enough to translate

you could also look at this project on github: https://github.com/LPGhatguy/luanoid

1 Like