Ah its because I uploaded to the private demo, my bad, forgot the website linked to a different one.
I re-uploaded the same file to the public one now.
If you are on 4.26, are you on the precompiled binary or the repository version, the hand socket came out at the start of 4.27 so the precompiled binary is likely too old to have the last fix.
If you ARE using the precompiled binaries let me know, you can download the latest from the repo but I need to install 4.26 again at some point then and re-make those binaries.
I’m on a really old precompiled i’m sure, I’ll likely upgrade to 4.27 right away here I mostly just wanted to verify it was working first before I did. I got a chance to try that newer demo as well, and it worked awesomely so thanks for your time.
When a version is “locked” away because a newer one comes out I generally build the precompiled one last time and then sit it there. The repo branch for that engine version continues to receive improvements and bug fixes for as long as they cleanly merge in.
In case its likely worth re-compiling 4.26 one last time since that bug was fixed very shortly after the final binary and invalidates a component.
If you had the repo version of 4.26 it should function without issue.
i downloaded the locked 4.26, then rebuilt and the problem still persists for me. I’m in the process of moving over to 4.27, but even if I build a clean project with the 4.27 plugin it fails to build. both in launcher and manually. I also doubled checked, and deleted the intermediate to force it on the rebuild again but it comes up with the same errors on a fresh project.
Severity
Code
Description
Project
File
Line
Suppression State
Warning
Warning: Plugin ‘VRExpansionPlugin’ does not list plugin ‘PhysXVehicles’ as a dependency, but module ‘VRExpansionPlugin’ depends on ‘PhysXVehicles’.
Did you download the 4.27-Chaos branch? You should have downloaded the master branch, the chaos branch is only for chaos.
As for 4.26 i’ll install 4.26 again tomorrow and see if that is a problem in the core, I haven’t had anyone else on 4.26 have issues with the packaged hands but i’ll double check.
edit I did double check on 4.26 and its also working correctly with latest 4.26-locked branch?
Is there an easy way to make a rotation based lever (custom grip) that allows multiple grips?
I’ve tried creating a blueprint with Grippable Static Mesh Component as the parent class and setting the relative rotation manually, but Event Tick Grip only has one output for the gripping controller, so while the other hand still visibly grips the mesh, I can only get controller movement from one hand.
You would want to sample it in a timer or the objects tick instead in that case, grip tick is called from the handling controllers tick so that it is always post its movement.
You can also call IsHeld to get the list of holding controller and work off of that list. If is a stationary object though you would likely get better behavior using a physics constraint and just letting two physical grips apply their forces onto it.
In short though yes, its easily doable, the hard part is deciding HOW you want two hands influences to effect the rotation so that it feels decent.
Great advice, using a physics constraint works perfectly when setting the constraint damping to 0 to remove the jitter. Thanks for the quick response, the plugin is amazing!
You can have a damping > 0 if you set the projection limits to very low values and have the grip settings have a ForceCoefficient of 1.0f. That will prevent the grip constraints from getting stronger the farther away from where they want to be that they are (default constraint behavior in engine).
Good news, after finally getting around to updating to 4.27 it SOLVED my hands issues.
So quick recap for anyone searching in the future.
My issue was custom deltas on GUNBASE not conforming to the mesh in Unreal Engine 4.26, and the hand would stick wide open when running a standalone build of my game.
You can try updating to the LOCKED version of the PLUGIN of the version you’re currently using to see if that’ll fix it for you.
If doesn’t work for you, update to 4.27 and be sure to download the right branch for the Unreal engine you are using as the CHAOS and regular MASTER are different.
If when compiling, you’re getting errors requesting for CHAOS elements you have the wrong version for what you’re doing.
Thanks again, feels really awesome now.
Working on PS4 optimization, we noticed some weird behavior about grip scripts.
We massively use “gun tools” and “lerp to hand” grip scripts for almost all in-game objects.
Those scripts seem to trigger compare and dynamic rep routines every tick even if those objects are not gripped causing a huge waste of resources. Is replication even needed for GripLogicScripts property?
Hmm, in general no they don’t need to, however there are exceptions and they are meant to fully support replication. I cannot have an array that mixed replicated and unreplicated UObjects in engine so its either all or nothing.
That being said I don’t see why I couldn’t add a bool to universally not replicate scripts on a per grippable basis. That would allow people to turn it on when required and off when not. In your case you could likely leave it off for most (or all) of your objects. I have people making modular level editing tools that require the replication and some advanced logic scripts that require it as well.
What engine version are you working with? I would need to know how far back to port it to accommodate you, also if you have upgraded to a more recent engine version the global lerp to hand setup may be good for your uses.
thanks for your reply, we’re on 4.27, but no hurry: for now, I got rid of them overriding your ReplicateSubobjects with a Super::Super::ReplicateSubobject() call
Dear , all,
Since the 4.27.2 and OpenXR support, I’ve had issues with my grasping hands curls, but so far I did not bother, I had many more project-levels bugs. Now I would like to investigate the issue, I suspect that it has to do with my former OpenVR configuration from UE 4.26 and below, but to be sure, I would like to describe my problem here.
Here are two snapshots from the VRE Master example (current master branch, retrieved today) with my UE 4.27.2 binary.
The first one shows how a regular hand is displayed.
The second one (same view angle) how a grasping hand with finger curls on is displayed.
The regular hand fingers are parallel to the interaction laser beam, as should be.
However, the grasping hand fingers (or physics hand, won’t change the result) with finger curls checked exhibit a larger angle with respect to the interaction laser beam. The open hand is visibly “too opened” and the visual result is even more visible with custom hands and gloves.
So my question is: should I still expect in VRE for 4.27.2 with OpenXR a hand with finger curls which still correctly opens at the right angle, or is the ‘crooked’ visual aspect of the open hand when finger curls are checked a known issue with the current OpenXR support?
My setup :
UE4.27.2 binary (no chaos, no source-based)
Steam VR beta 1.21.8 (but had the same issue with the main branch)
Valve Index controllers which work correctly (my current VRE-based 4.25/4.26 projects without OpenXR still show correct open grasping hand aspect when curls are on)
I’ve checked my configuration, but I cannot find an obvious place where my previous non-OpenXR configuration would interfere with the current OpenXR-based implementation.
Any thoughts or recommendations as where to investigate? Thanks
Its because openXR doesn’t have the concept of “curls”, instead of blending between a relaxed and closed pose its directly driving the transforms. I would like to estimate some curls eventually but don’t want to commit to iteration time on that until the oculus hand tracking is also functional so it can be universal.
The hand opens more than normal because the mesh for the manniquin hands are not bound exactly the same as the steamvr hands relative to each other, joint lengths, angle to the mesh, ect.
There is another avenue of using the relaxed pose as a base for additive, however then the end fully gripped pose is likely to have some clipping.
When you think about what they are estimating with the controllers, your hand fully off of the controller “should” be considered fully open like that, they have no other data to go off of, relaxed pose would normally be the hand slightly closed around the controller. The old curl method actually never fully allowed you to open your hand even.
The even more annoying part is that the oculus hand tracking is going to behave differently than the steamvr back end as well in openXR. So you can’t exactly just run the steamvr hands alone and expect that to function as expected.
Thanks for the explanation, at least I won’t look further for any local configuration mismatch.
There is another avenue of using the relaxed pose as a base for additive, however then the end fully gripped pose is likely to have some clipping.
That’s what I tried when noticing the issue, but as you say, the gripped pose then presented issues so I did not pursue the investigation.
I am not in a hurry, so I’ll wait for possible enhancement (in terms of fine-tuning the curls in a somewhat decently easy way) in that regard in the future.
Steam seemed to be of the opinion that engines were going to implement their own curls off of the openXR data, yet to see anything on that front from any major openXR implementation so far however.
Perhaps for the same reason I have been holding off, not every API being fully functional yet for that and needing a universal solution now.
