Hi . I’ve got a StaticMeshGrippable actor with a Child Actor Component. I’ve noticed a subtle problem in that the mass of the child actor seems to affect the gripped object (seems to make it heavier/grip softer) even with the child actor not set to simulate.
Is it possible there is a bug or info that I need to know about on how your plugin handles child actors of the gripped actor? It’s likely not a bug just my poor understanding on what is actually going on but I’ve eliminated some obvious things I thought it could be with no effect and thought I’d ask.
I’m not welding physics bodies unless I misunderstand. I have a GrippableStaticMesh actor which has greyed-out SimulatePhysics and MassInKg boxes. I can grip just fine with Interactive Collision with Physics & Late updates always off.
If I add BP_Box as a child actor that weighs 100Kg to the grippable actor but with Simulate false on the child actor I am expecting the 100Kg not to contribute to the mass of the gripped object. I.e. just act as another collision primitive. Is there any way I can setup behaviour?
Child components auto weld to their parents, you need to turn that off in the settings if you don’t want it to effect weight (uncheck auto weld in the component/actor).
Thanks! That is almost certainly the source of my problem and I was unaware of the option before. However the auto weld option is not available for the Child Actor components. Can you suggest a workaround? Child Actor components are so powerful it would be terrible if I can’t get them to behave as wanted for gripped actors.
You don’t set it on the child actor component, you set it on the root of the actor that it spawns / unweld and re-attach.
Child actors are newer to the engine and don’t fit the architecture as well as just components themselves, you will find times you need to make up workarounds for them.
Also in many cases scripting behavior into a component itself provides all of the logic you need, you very rarely need a full additional actor.
Yes, I understand better now. I have turned off auto weld in the roots of my attached child actors and it seemingly makes no difference. I need to do more tests but you are correct that the plugin is not involved here and what I am seeing is a peculiarity with child actor components and physics objects. I know there have been problems with child actors and realise that workarounds are needed for some things. Another one may be needed for or it may be a genuine bug.
Of course having written I will immediately find it’s all my fault… I appreciate your expert help, I’m pretty certain the auto-weld behaviour is at fault here once you brought it up.
I appreciate that adding child actors as components can be a sledgehammer to crack a nut but we have a great feature that means I must get them working in case.
EDIT: Attached Child Actors set to simulate work perfectly with the gripped object but are free to move independently of it. Auto weld setting has no effect. I may experiment with setting simulate and/or force welding the child actors on Construction or On Play as attempted workarounds.
how can I make an object change hand without dropping it first?
I have an object in my left hand and I want instead take it in my right hand. If I try to grab it with my right hand it doesn’t work. I have first to drop it from my left hand and than grab it with my right hand.
Where does the second grip gets implemented in the project template ? I know there’s a bool set for bCanHaveDoubleGrip, however I’m wondering where I’d need to check to make controller/hand invisible on second (double) grip, especially that I’ve been trying to find any kind of reference to second socket (VRGripS1), no luck though.
Thanks so much for plugin, it helps so much, and your example project is great to learn from.
I’m having an issue with the gripping in my project though, and wondering if it’s just something simple. When holding an object in one hand and trying to grab it with another, only the sphere trace works… getOverlappingComponents returns nothing. Overlaps happen normally on objects not being held.
In the grip check code it first checks if the other hand is holding it, if so and it allows for a secondary grip then it activates the secondary grip. The grippable components return the grip points, not the player, its implemented in the default for grippables to check for the closest VRGrip prefixed socket.
Pushed a new commit to the plugin and template today
Template
Added new rolling average and exponential low pass filter nodes to template
Converted smoothing step for RIP and armswing to use the new nodes.
Also included an implementation of a rolling average low pass filter in blueprint for reference.
Added new test actor "VRStereoWidgetActor" which uses the new VRStereoWidgetComponent.
Plugin
Added rolling average and exponential low pass filter nodes to the plugin for quick use when wanting to smooth values from
things like HMD and controller movements.
Added new component to the template "VRStereoWidgetComponent", acts like a standard widget component except when in VR will render the widget to a stereo layer instead of the world.
Probably needs a lot of testing (mostly since I don't have oculus hardware anymore) and will need some cleanup, however the basic world space version of it works.
Sadly OpenVR stereo layers don't support world depth and occlusion, Oculus ones may work correctly with setting but I am unable to test.
I updated the plugins without any real problems. I had to update my base PawnCharacter to use the new filter nodes based on your template manually and remove now unused vars.
Is there an example use of VRStereoWidgetComponent in the template level? If so I must have overlooked it…
No, its fairly alpha currently, I need to fix it in headspace. But for world space, just attach it to an actor, and set its widget to any random menu that you have (tested using the server browser). Unless the override is on it will render only in stereo layer while the HMD is active, it is best used for temporary menu’s in openVR though as there is no world depth for stereo layers in openVR. Oculus has a world depth and may perform with occlusion correctly, I can’t test.
The original idea is from Mitch, its just a lot cleaner and more compact to implement in C++ instead of blueprint.
Just an update, working on implementing the IVRCamera interface for “portals” to the real world possibilities, also have a tracking puck on the way that I intend to play around with after Wed.
Is it possible to change the grip collision type while you have an object already gripped? I would like to switch from “Interactive collision with physics” to “Physics only” while I have the object in my hand. I set up a small test case but SetGripCollisionType always returns On Failed. I am doing something wrong?
You can’t “Make” a Grip struct in blueprint, I have most of the variables BlueprintReadOnly in order to prevent people from misusing them. What you should be doing instead is finding the grip for the held object and then passing that grip struct in to SetGripCollisionType (GetGripByComponent / GetGripByActor). That screen shot is failing because the “gripped object” is invalid.
For the server it immediately recreates the grip when the SetGripCollisionType function is called, when the array replicates over to the clients if they detect that the collision type has changed it will “Recreate” the grip then for them.
There is of course a minor performance cost in recreating a grip, over not doing it, when recreating it iterates over all of the values again and sets relevant component settings, but its nothing more than gripping an object in the first place does.
Actually I should probably add GetGripByObject too…
