I’ve had trouble with implementing one thing in my game for about three weeks now.
The concept is that there is a first-person gameplay where the player only sees an arm with a tool attached to it. The arm itself is simply a child component (and a tool is a child to the arm) to the character. But the arm is not supposed to work based on created animations, but on physics, because the tool will interact with other objects in a scene with its momentum. The ‘F’ keyboard key would enable the “arm manipulation mode”, so that you could rotate the arm to make the tool collide with other objects.
There are two significant problems that appeared after trying to implement such behaviour:
Converting mouse location to world space does not work poperly as after some time of moving mouse without “arm manipulation mode” enabled, turning it on again changes the arm rotation according to the new mouse relative position (the mouse could for example be in the screen corner when the mode is enabled an consequently the arm rotates towards the screen corner).
Enabling any kind of physics options to the arm (I really tried all combinations in Physics and Collision tabs for the arm and the tool) makes it either fall on the ground or appear some distance from the character in a completely solid non-movable state or do any sort of another buggy thing.
I spend a really huge amount of time to find a solution to these problems and it apparently exceeds my knowledge.
I would strongly appreciate any help
About #1: what do you mean by converting the mouse location does not work properly? can you explain how are you using the world-converted mouse position? it is basically the position of the camera in the world + pixel offset depending on where the cursor is.
Perhaps you can show us your setup?
#2: I think we need more information about the arm… falling on the ground sounds exactly what a physics object would do?
For #1, he’s saying he wants the mouse to be relative rather than absolute. So for example, if he enables arm control and whips the mouse up to the corner of the screen, and then disables arm control, when he re-enables it, the mouse should be treated as being back in the center of the screen.
This can actually be done, it just requires some variable trickery (rather than using Get Cursor Position, when in Arm Mode you would use the output of the Mouse-driven Input events to additively set two float values which are capped based on screen resolution, and when you exit Arm Control, you would set them back to their default values and stop passing the Input Events to them until Arm Control was re-enabled.
As for #2, best explanation I can offer is “physics is wonky”. The best solution I can offer is to use a phantom root bone on the arm skeleton that is designed not to move. When you simulate physics on the arm, you’d have to do it for all bones BELOW that root. Otherwise, the entire arm simulates physics, meaning it ignores the movement of the root capsule component. By only simulating on bones below the static root, the root can remain “glued” to the capsule and the movement of the other bones will be constrained by that.
@RhythmScript
For 1. I will try what you say and post here any difficulties I come across.
For 2., the skeletal mesh of my character consists only of that arm. As I don’t have much experience with skeletal mesh functionality I am really not sure if I have set everything up correctly. This the setup of my character:
Potential children of ArmSkel are tools used by the arm.
I have also just realised that actually the arm does not need physics properties, because only the tools are interacting with other objects in the scene. The problem is that tools are not a part of the skeletal mesh and are not affected by the movement of the arm if Simulate Physics is checked.
Well, that’s actually sort of a problem. UE doesn’t like child components to affect the physics/collision of parent components. You’d have to simulate physics on the arm (BELOW the root bone, so the root bone remains stationary and thus attached to the capsule, and only the rest of the bones move), and then use a Physics Constraint to bind the tool in question to the arm, and simulate physics on THAT.
And it won’t be easy to get it working. You’re gonna have to do a LOT of trial and error. UE4’s physics/component implementation is simply not based around the movement of child rigidbodies driving the movement of skeletons like you want. I’m not saying it’s impossible, I’m saying it might be hacky to get it working.
I will work with physics constraints for a moment then.
Apart from that I can’t get the “arm manipulation mode” to work. This is how my blueprint looks:
Basically after pressing ‘F’ it finds central coordinates of the screen, stores them in variables and then uses the vars with Get Input Mouse Delta and sensitivity variable to calculate the new mouse position each tick. Next it simply updates the vars and uses them in Convert Screen Location to World Space. And here I think is the problem with this algorithm. I need to do something with the final Rotation output, because plugging it into Set Relative Rotation doesn’t work.
I would’t do that. I would use the InputAxis Input event system. That way you can completely skip calculating screen space and just use the raw Mouse delta every tick.
I got it working with Input axis and Add Relative Rotation nodes. Thanks a lot
I also need to create a constraint for the arm, but I can’t edit one in PhAT, because I have only one bone in my skeletal mesh, so there are simply no joints. Attaching physics constraint also doesn’t work, as I don’t simulate physics on the arm. I have implemented a constraint for the arm in BP:
What makes this BP poor is the rapid narrow wobbling of the arm that occurs when it reaches its constraint angles. It is of course only momentary, but still for some it might be nerve-racking.
Then why even use a skeletal mesh? I would just make the arm a rigidbody (static mesh) at that point, it will make the physics stuff much easier to do. A skeletal mesh is useful because it can be animated; if the arm can’t do more than rotate, it’d be easier to just skip the skeleton entirely I’d think.
I will confess that I hate setting up skeletal meshes (I always had someone do it for me ), so as I wanted to quickly realize my concept I have only created one bone and postponed the creation of a skelmesh.
Then again I managed to get rid of the necessity of implementing physics to both the arm and the tool with the help I got here. I also incorrectly thought that Get Physics Linear (or Angular) Velocity is only accessible when Simulate Physics option is checked. In general the arm would make virtually no difference when changed to a static mesh in this case, I think, and there is some room for developing the skeletal mesh eventually.
But still there is a problem with this constraint BP, which can actually be broken when the input axis is large enough.
Lastly, there also appeared supposedly the biggest issue which is probably buried inside the engine. Briefly saying, when an object that should generate a hit event is hit by a tool and it doesn’t have Simulate Physics property enabled, it neither generates a Hit Event nor initiates a Block Collision (Both the tool and the object have their Collision Preset set to BlockAll). It kind of makes sense, because after all it’s the motion of the mouse that provokes the collisions and if Simulate Physics isn’t enabled the motion of the arm cannot be stopped with a Block Collision and the engine refuses to detect it, which results in penetration of objects. With Simulate Physics enabled the object is moved by the hit of a tool, and consequently the movement of the arm doesn’t need to be blocked. And why is Simulate Physics option an obstacle? Basically, because objects must have Enable Gravity property disabled and I don’t want them to float around after being hit.
One workaround I thought of is based on the fact, that the engine still detects Overlap events under these conditions. I could then detect the overlaps between objects and tools, execute some BP and set a delay, so that it doesn’t execute the same script multiple times, when the tool is overlapping other object. However, here is one obvious flaw. The tool and the object would penetrate with each other, which could only be prevented by another script, which most likely is beyond my reasoning.
), so as I wanted to quickly realize my concept I have only created one bone and postponed the creation of a skelmesh.