Custom Character Collision - EXTREMELY IMPORTANT FEATURE

Dear Epic Staff,

I have discovered a need in the engine that, based on community interest over the past 3 years, should have a massive workflow improvement to many UE4 users.

PROBLEM: For any non-human playable character, such as quadrupeds, the current implementation of ONLY one non-rotatable capsule used for collision inside the Character Blueprint results in massive trouble. Scouring Google for hours only returned the two most common workarounds: 1. write or modify your own Character BP in C++ (with no explanations offered) or 2. use the Pawn or Default Pawn class instead, and try to recreate countless functionality already built-in to the character movement component (which is not a practical solution considering all you really need is additional collision volumes for your mesh).

This is clearly a super-needed feature that, if implemented, would simplify an enormous amount of difficulty for UE4 game developers.

I personally am working on a game that uses a quadruped character (in addition to bipeds). Collision is a nightmare due to the unique shape of the mesh, and there are no viable solutions existing online. To be able to add additional collision primitives (capsules) to your Character Class BP or to add a character movement component to a Pawn Class BP would be truly a dream come true, and would not only greatly assist this game developer, but also open up a plethora of quadruped games by talented developers that are currently impossible or virtually impossible due to sheer impracticality.

Thank you so much for your time and consideration in this.

Sincerely,
Adam Janz

As much as I can see the reason behind this request (I’ve written networked movement comps’ for two games now, which includes simple sphere collision to complex vehicle collision) - a lot of CMC’s functionality is based on the fact that a character can be represented by a Capsule.

If you think about it though, you’d still need to write your own movement component for quadruped movement. Quad’s can do a lot of things that bipeds can’t, so even if CMC supported multiple collision primitives - the movement would still feel like a biped.

A preferable option, would be to split CMC’s code off into segments so that it can be reused for other movement components. This is pretty hard to do though, and will most likely break backward compatibility. I’ve had a bit of luck with it.

Maybe I have misunderstood the problem but I actually work on several playable quadrupeds characters and I use the capsule for the ground collision only and make it very small.
For all other collisions, I use several trace line.
I don’t feel that the changes you propose will save my life :slight_smile:
Also, I have to confess that I’m working on a 2.5D game and that certainly make this much easier ^^

Thanks TheJamsh and JoGoiA for your input. I’m not sure if you would indeed have to use a new CMC for quadrupeds, just more animations or use this technique for quads that require it. However, at present, I’m using an extremely oversized capsule to encompass the quad’s large protruding appendages to avoid them intersecting with the world. It actually works better than I expected, but does introduce problems for correct collision above the character, as now there is quite a surplus of capsule in this area. Is there a way to stop a character from intersecting the static world just by using traces? “Stop Movement Immediately” just works like glue, slowing the character to a near crawl by the hit object but not actually stopping all movement.

You could eventually set the forward input to 0 when your quad touch something and then use the braking settings from the movement component of your character to make it stop with some “elasticity”…
But honestly, I don’t feel confident with discuss this thing because I’m much more an animator than a coder and in my case, I just prepare several hit and stop animation that I can play, according to the hit tests of my trace and the actual speed of the chara at the moment of the touch.
Maybe our two problematic are really different :slight_smile:

Thanks JoGoiA for your tips. I too am an animator not a coder, which is why it would be so nice to have more collision options rather than having to write/modify your own movement component. I can also see how having a character with wings would make it truly impossible to use only a single collision capsule to block environment movement or prevent intersection. Thankfully my character’s extra appendages don’t spread quite as far as wings, but it certainly poses a challenge. All the best with your game development.

You can simply duplicate the assets (ACharacter and the blueprint) and then switch out the capsule.

I understand very well the intention of Epic by giving us few very versatile tools and let us exploit them as we like.
If they had to build a special character class for quads, they will have to do it again with flying creatures, then for the fishes…
And someone will create a dragon some day !
etc.

We have to learn to make what we want with elements that are shared by any construction, like playing with lego :slight_smile:
In a way, that’s fun ^^.

You would lose a lot of optimization if Character supported multiple collision capsules, which just isn’t worth it 99% of the time.

The real solution is to allow CharacterMovementComponent to be usable on any actor, so you can create a pawn with a sideways capsule to fit a biped better. “Refractor the CMC to be usable with any actor” was on the old roadmap but it’s gone in this one.

Thanks rYuxq for your input. Eventually it may come to that… but for now I would prefer to not have to delve deep into C++ to achieve it. It would be nice if knowledgeable programmers who have done this in the past would post the required info to accomplish this, but I have not found any clear info yet.

I totally agree! But making a ball out of many square bricks will never be as functional as using curved bricks. Glad to see someone else whose creativity was likely kickstarted by LEGO, as was mine. :slight_smile:

Thanks Ohriginal for that great suggestion! I hope Epic reads this and brings that back into the roadmap!

:cool:

LOL, nice. Someone’s gonna have sore fingernails if they ever have to pull that thing apart piece by piece. :slight_smile:

I am “glad” I am not the only one annoyed with capsule issues for non-bipeds, I just posted a thread about it. I thought the issue was only about the shape of the capsule, but now I realize the whole ACharacter class is made to work with such a shape profile (but why exactl?).
This is a major issue, I am surprised UE4 has such a basic issue with no official workaround after so much time in existence. Guys at Epic should really be looking into this. I guess in the meantime we have to base quadrupeds on APawn?

Update: I have been looking at the engine code, the capsule shape concept in not only used in ACharacter, but also in UNavMovementComponent (see UNavMovementComponent::UpdateNavAgent, FNavAgentProperties) which is quite bad… So indeed changing this would involve much code refactoring, but it is needed I think. Or maybe a less radical change would be to enable rotation of the capsule.

Been saying this for years folks :wink:

You can’t though, as I said CMC relies on the primitive being a capsule. So does Navigation etc.

Have any of you looked at how the Kite demo Deer were put together? Might be suitable for a Quadruped - though it won’t be perfect.

In the Kite demo they are using a vertical capsule for the deer… There is little code associated to it as they mainly handle it part of a crowed management system.

I really think that you should look at the capsule as the main coordinate system for a character, the “center” of things for the MCM and all that stuff…
But not as the only collision object. Maybe is it also some sort of relic from the time when UDK was a FPS oriented engine but still…

If you rotate the capsule, you rotate the forward vector of the character.
Do you want your chara to crawl up and down when you push the stick to the right or left ?
No. Then you will have to code something to tell the MCM that the capsule has rotated for it to compensate the rotation…
I don’t want that.
It’s a mess !

Just stop using the capsule as the collision system for your character if it doesn’t fit your needs and prefer some other collision model ( a volume of your choice, Physic asset or per poly…) but keep the capsule for what it is : a dummy object for the character code (and components) to work with.
Eventually, it can be an average approximation of the chara but it will never fits every purpose in collision matters and I don’t think that Epic think of it as the ultimate collision system when they coded that.

If you can / want use it for collision, do it.
But if you want another collision model, something you can work with easily, just add it in your BP and let the capsule lives the way it wants :slight_smile:

Capsule pride !

Edit :
I really think that Epic knows what they are doing.
They certainly had a lot of reunions where they discuss with senior users on how to deal with all that stuff.
They are making (very good) games since before you were born (I’m old…) !
We have a lot to learn from them.
We have to think about the way they want us to do stuff in their engine before asking them to change it.

JoGoiA: if adding another collision volume to the character BP would work that would be great, but this is not the case as far as I know. See this thread and others about the topic.

“We have to think about the way they want us to do stuff in their engine before asking them to change it.” : I am asking for a workaround for non vertical characters and others have done too, but I have seen no valid answer besides rewriting a good part of the character movement feature. When we are using a game engine this is not to rewrite it!

I don’t see why providing the ability to rotate the capsule would be a mess. Actually this might be a simple workaround Epic could implement into the engine as an intermediary step before thinking of a new architecture if this ever happens. If it doesn’t happen, at least we’ll have capsule rotation which will make things much more managable than they are today.

Thanks eyoli for your support. I am currently just using a hugely over-sized capsule for the character’s collision. Unfortunately, this means the character can’t fit through openings that are only as tall as the character, unless you modify the capsule size in realtime. You can use a smaller capsule to permit fitting through small openings, but then large appendages on the character will have no collision with static objects, even if you add additional collision capsules to these areas set to block all. However, this technique seems to work fine for blocking dynamic objects, but most of the environment must be made up of static objects. Not even blocking volumes can stop character penetration with the static world… only the single default capsule will do this!

I think Epic need not be afraid of implementing this change due to backwards compatibility. Simply make a separate, NEW character class that implements the adjustable collision or make a NEW character movement component that works with any class and keep the old versions in place for backwards compatibility. :cool:

Doubling up on this request.
Bringing this back into the light.

Would it be possible to have a root capsule that is the basis for the vector math needed, and then a number of capsules that keep legacy reference due to being lower in the hierarchy of capsules (inheriting their vector alignment, if that makes sense, from the root which is always the default original capsule). I imagine this would look similar to physics assets, but allow much greater flexability while maintining compatability.

I’m no coder. So I hope my rambling made sense.

Cheers!

As people have already explained, allowing you to flip the capsule or any of those tricks won’t really help you since the entirety of the movement code would still be biped-like. Quadrupeds needs a lot of special handling for stuff that bipeds can’t do so doing such extensive changes to the CMC would be like putting a bandaid on a broken leg. Except the leg isn’t really broken and there is no leg in the first place.