I mentioned some versions before that rotation of Physics Handles is broken and now it is even more broken.
Set Target Rotation of a physics handle does now nothing. With constrain rotation off It just freely rotates around. I do Set Target Rotation every tick to rotation 0.0.0. When I have constrain rotation on, it stays in zero rotation only when I do Set Rotation on the actor that is currently grabbed every tick as well. But after it collided with something it get stuck in a rotation that is slightly off from zero. I assume that it gets more extreme off the more stress it had in the colliding before. Also any collision becomes very jittery with constrain rotation set on.
Using physics constraints instead is not a good alternative since objects can just get pushed inside other collisions pretty easily and things can get very jittery.
Considering that physics interaction is really important for VR it would be great if fixing this could be made a priority. If there are any other working solutions currently for grabbing physics objects please let me know.
Everytime I grab a object again it first goes slowly a bit down. While it does that it also moves through other collisions.
Once I had like 10 simple box collisions welded to a parent box and then grabbed that parent box. The performance became horrible, to ca 14 fps from 90 fps.
As for the last issue (performance going from 90 FPS to 14 FPS), were you by chance toggling Simulate Physics on those collisions? We just recently fixed a bug that would leak PxShapes when toggling SimulatePhysics on a parent component with children welded to it. The number of shapes leaked per toggle was equal to the number of children, so in your case grabbing the box 10 times would leak about 90 shapes (100 - 10 that are actually valid).
As for the other issues, I’ll start taking a look and see what I can find.
The first in question actually won’t be available until 4.13 I believe. If you’re building from source though, I listed it in the other question (it’s a very trivial fix).
I don’t actually think what your describing is a bug, as much as a misunderstanding.
All of this code uses PhysX to perform the movements. When you set “TargetRotation” to 0,0,0 what it’s doing behind the scenes is telling PhysX “hey, I’d like this component to move to this rotation”. That’s where the “Constrain Rotation” option becomes important.
We only enable angular drive when “Constrain Angle” is true. This means that PhysX can only enforce a target angular position (i.e. rotation) when it’s enabled. It’d sort of be like sitting in a car and pushing the acceleration pedal. It’s only going to work when the engine is on (and it’s in gear of course). As far as the object hitting something and getting stuck slightly off, unfortunately this appears to just be a limitation of PhysX, where it’s trying to resolve as close as possible.
However, I did notice the other issue you mentioned, where the object seems to “lag” behind. To me what looks like is happening is that the object is not creating the joint correctly for whatever reason (it’s not properly rotation around the current actor). This does appear to be already fixed in 4.13, but I haven’t quite figured out where / what is causing this issue yet.
On a side note, if you want the object to appear rigid and stay in an orientation similar to when it was grabbed, you have 2 options. First, turn up the Interpolation Speed; Linear and Angular Damping; and Linear and Angular Stiffness. This will still cause your object to have some dynamic motion if it’s completely block, but for the most part it should feel tight.
The second way is to actually disable Simulate Physics on the object and Weld it to the parent. The nice thing about this approach is that it will give the object a completely “locked in” feel.
Yea, well that is a bit misleading then with constrain rotation but even with constrain rotation enabled it does not constraint it as much as I need it that is why I also use set rotation on top. The problem with set rotation on a physics objects is that collisions can become really jittery.
The problem with the lagging is also that is heavily related to performance, with great performance it is lagging behind only slightly while with bad performance it lags behind a lot. Either delta time has not been taken in account somewhere in the source of the Physics handle or the “set target location” system is just problematic in any case.
I already tried turn up all the settings to get the rotation rigid, I would need those values to get up much higher I guess. Interpolation Speed is already clamped at 100. My game is basically made around boxes in a grid, similiar to minecraft, you can grab cluster of boxes, move them around and when let go they go to back in the grid. Any rotation feels awkward. Even with “set rotation” every tick it can still rotate a little off and there is the jittery collision problem which gets worse the further the target location is from the actual grabbed box location because it tries to force it more and more through any collision.
Disabling physics simulation and attaching it is beside the point. Attached objects just move through any collision. You also have to take in account that this is VR. There is no way to force the players hands in a location when they are blocked in game. I think something specifically made for VR motion controller physics interaction (grabbing and pushing) would be great. Something that feels tight, that can handle physics collision well, with it being not a problem when player hands go through stuff and some good rumble feedback and of course performance is a concern in VR. Well, I can say so much that it is very tricky would be cool if you the experts at Epic could cook something up specially for that.
Like I mentioned, the code for physics handles are all just wrappers and pass-throughs to PhsyX. From what I’ve seen 4.13 (which hasn’t been released yet, unfortunately) does seem to have better behavior in general. Additionally, we should be integrating a new PhysX version soon, which may also address more of these issues.
Looks like I found another way to crush the performance, it behaves very similar but is not using any physics so I guess it is not related to this performance bug?
I recently added static mesh components to my boxes which make up basically the walls of the box with different meshes. Before It was just the box static mesh as the root. That are 12 components that get added in the construction script with different rotations and meshes, they have no collision. I change the meshes and visibility also at runtime (not while moving). Again each of the box is a actor and there are max 20 boxes being attached to a root box which I use to move the whole cluster of boxes. Moving is Set Actor Relative Location (No Teleport, No Sweep) every tick over the time of ca 0.5 seconds moving 10 units. Now every time I start a move the performance gets lower just like that bug with the performance, and just like that bug the performance only crushes while the movement is happening. But the performance is then crushed for all clusters no matter If I didn’t move that cluster before.
This bug does not occur when I don’t use any extra static mesh components in the box actors. Maybe there is a overarching problem here with actors being attached to actors while components attached create more problems. Well, hard for me to make any guesses.