Well, I am not really using most of Plugin, so I may be of limited help. The only thing I am using really is the VRCharacter.
I have a totally different system for hand meshes and the 3rd person controller.
Well to be honest, I think that the crouching code is the only section of character movement code that I didn’t overhaul for the VR chracter, since it makes no sense to “toggle” crouching on a VR character. The Simple Character would probably handle it fine due to how it works. That is messing up because the actual capsule location is different from where the crouch expects it to be.
I was actually planning on disabling the crouching system entirely for the VRCharacter instead of overhauling it to try and prevent confusion, but I don’t think it would be that much effort to just clean it up instead.
I will alter the crouching functions today, but I will note to you that the best practice here would be two separate pawns, to avoid additional overhead and make control schemes easier. That being said I can’t think of a reason why I shouldn’t allow it for very special cases, so I will still change the crouching code.
The plugin has a License.txt file packaged with it, it is MIT, you pretty much are free to do whatever.
Pushed a new commit today to the plugin / template repositories
Added crouch capability to the VR characters, suggest not using for when possessed with a HMD, but allows for
when possessed by a different controller to work.
SimpleVRcharacter always had working crouch, fixes it for the VRCharacter.
Last possible interaction that needs testing is swimming.
Edit Also a reminder, I am still open to requests for additional features, I have been sitting on the core feature set for awhile now to check out stability.
I am not going to end up making the VR Boundries I was hoping to do as SteamVR removed their complex Room Scale Boundries functions :(.
Thank you for continuing to absolutely kill it with plugin, ! Also thank you very much for splitting the plugin into two modules.
Would it be possible to add the option to only use the wall push if your head is overlapping something? It gets weird pushing yourself away while leaning over waist high objects. I’ve managed a workaround on my project (by basically turning off collision on the vr root when you stop moving so you can clip into things, and added a head collision sphere to turn it back on if you push into something), but native support for that functionality would be great too.
Thanks again!
For the “std” VrCharacter there is actually already kind of a way.
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "VRExpansionLibrary")
bool bUseWalkingCollisionOverride;
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "VRExpansionLibrary")
TEnumAsByte<ECollisionChannel> WalkingCollisionOverride;
Setting bUseWalkingCollisionOveride on the root component and setting it to a channel that doesn’t collide with your waist high object channel would work like what you are currently doing.
(Not sure that I have documented currently).
An alternative is you can turn off player collision for those waist high objects / Have them be on a “table” collision channel that you turn on / off on the pawn if moving.
Its possible to run a separate check for the head but I have concerns about multiplayer, I would have to start sending the HMD position in the movement component replication as well.
I would like to get that better to be honest but feel like any “solution” is hacky without actual waist tracking. I had a solution 90% working with the VRCharacter with two separate collision components but that approach wouldn’t work with keeping the Simple character “simple”. It’s my intention to re-visit it eventually, but until I think of something that would be good enough to feel like a default implementation I don’t really want to commit to it (like climbing).
All of the distance based penetration and assuming lean systems that other devs have made don’t actually work if the player isn’t actually leaning, they just walk through the object then until they hit the limit, I don’t see that as being good enough over no collision in the first place.
Hi
currently in your plugin everything seems to be climb enabled, How can i dissable the climb option for a particular mesh,
Also when i import some walls into the scene it moves when the head is colliding.
Again the teleportation is not accurate for me and its without orientation. Please help
J
Create a filter for climbing in the “Getoverlappingactors” function.
I also don’t know what you mean walls move when the head is colliding, the walls themselves move?
What do you mean without orientation on the teleport? Its not supposed to re-orient you when teleporting currently, you can feel free to add that yourself but for roomscale it is pretty disorienting.
Hello ,
When I grab a destructible mesh and destroy it while it is grabbed, it causes the game (and the editor) to crash. Do you know how to fix it?
Thanks in advance
Hello ,
I hope you remember me from the PM’s!
I just had one question, how would i go on enabling the switch between VR, and None VR?
Thank you again for your work,
Cheers,
-b
Mmmm, I’ll have to look into the how it handles the base component when destruction happens, the broken meshes are handled in the async scene, so I assume that the actors physx scene reference is completely removed (normal objects aren’t on the async scene) when the destruction happens which might have issues with being currently constrained by a physx constraint. Regardless if you “drop” it right before “destroying” it will clean up any physics handles on the object and shouldn’t crash. You don’t have logs or error/callstack messages from when it happens do you? That could likely speed up seeing if it is fixable.
For plugin there are examples in the template, it freely switches between the two.
For something not using the plugin, its all about possession and unpossession of the proper pawns or if using a single pawn then turning off HMD lock on the camera and setting the controllers to either not be active or to be in a static location.
thank you ver ymuch for the reply
by orientation i mean the blue teleporting cursor which usually rotates with the trackpad. I am currrnetly using the stand only version not room scale. Please guide me how to add it.
also what can i do with teleporting accuracy, it seems slightly offset sometimes and sometimes it wont teleport.
appreciating a ton for plugin and speedy support
thank you
Ah, the HMD pawn uses a different teleport setup than the Motion Controller pawn for Epics setup, I kept their pawns alive in the template though so you can open up the HMDLocomotionPawn and add/remove (copy / paste over) as you wish. The offset is likely your position in the room offsetting you from center in my pawns, as they are roomscale it won’t show you centered in the teleport cursor (assuming standing position oculus, if you are on GearVR then I don’t know what you mean by offset).
The current default setup for the template example uses Epics MotionController Pawn teleport setup for roomscale.
I don’t have the log right now, but it fires an access violation exception in GripMotionControllerComponent.cpp at line 2316:
“if (GetWorld()->ComponentOverlapMultiByChannel(Hits, root, root->GetComponentLocation(), root->GetComponentQuat(), root->GetCollisionObjectType(), Params))”
. Could you tell me if the multiplayer voice-chat microphone stuff I see in the VR pawn is usable?
Thanks.
I have it disabled, but yes, it technically is usable. You likely would have to increase your client bandwidth settings to get SteamVoice to work correctly in engine as it saturates the network on default engine settings. The voice stuff uses my other plugin “Advanced Sessions” to toggle voice, so just a warning if you try and migrate it.
I was playing around with moving the motion controller near the mouth to activate push to talk, could be open voice or button toggled instead.
defaultengine.ini would need these changed to true:
[Voice]
bEnabled=False
[OnlineSubsystem]
bHasVoiceEnabled=False
Also Defaultgame.ini has setting:
[/Script/Engine.GameSession]
bRequiresPushToTalk=true
Excellent. Thanks for the important info, that’s probably saved me a headache. I’ll tinker with it. 
We’ve been playing with your plugin with a client over the net using quite a poor connection and it works great. Seems robust.
I tried to setup a racket game using the grip. After tinkering with all sorts of settings for the grip and the Physx properties it can be made to work quite well. However the penetration of the ball into the bat when hitting the ball spoils it.
What are your recommend settings for a bat/ball setup and is it possible the fix the interpenetration/lag issue?
Many thanks.
That is a result of the late update kicking in, visually the bat and its collider are slightly offset as it carries on a little past where it was when the physics were ran.
You can turn off late updates for it (bat will lag behind controller a bit)
Do some velocity checks and try and figure out the bats future position for impacts
Accept the interpenetration
I have the enum for “NotWhenCollidingOrDoubleGripping” that is defaulted to true for grips that when in collision the bat should stop late updates, however would cause a visual hitch in the bat itself and since the collision is likely across one frame it probably isn’t going to be noticable, so whether that is preferable or not I don’t know.
Also you might want to look into RoboRecalls bullet slaps as they use the new CCD setting for kinematic actors to keep hitting fast moving projectiles easy.
Bats also don’t really need to be physically constrained (could be a different grip type), but if you are getting acceptable results with a high strength constraint than thats fine.
I added a check to the motion controller where if the held object is a destructible component that is currently (just) fractured then it auto drops it and prints a warning to the log that such objects should be dropped before fracturing.
I was right, when fracturing it removes its scene reference and re-creates them in the async scene, normally wouldn’t be a big deal except the engines ComponentMultiOverlap function crashes on getting the objects physx scene shapes after fracturing (not exactly a plugin bug I guess). Also it leaves the object in hand which eats up resources so it shouldn’t be like that anyway.
If you want a cleaner way to handle held destructibles I would actually suggest having a grippable actor with a primitive root component and then a destructible mesh component attached to that root component. That way you are not directly constraining the object that will fracture and can work out some neat effects with it.
Regardless the check in in the plugin now, I am not entirely sure that I SHOULD be checking for , or whether I should be enforcing proper cleanup on the part of the user but until I make up my mind I added it in.
Pushed new commit to the template/ plugin
Fixed Vivecharacter not picking up base simulating actors anymore (when changing for the new IsHeld interface function I set a node wrong)
Added the plugins new check for destructible components being fractured, not entirely sure that I should even be doing .
In the future I may force the end user to properly clean up destructible meshes instead by dropping them or attaching them to
a root component that is gripped instead.
Currently auto drops the held component when it detects fracturing
I think the info about handling the late update setting could be what I’m looking for. I’ll add setting to the pot when exploring the grip parameter space.
Thanks once more.
A tip for other folks playing with spherical Physx bodies. Make sure you turn on Enable PCM in Project Settings - Engine - Physics - Simulation - Advanced. Your balls will be badly behaved otherwise (!)
I added a check to the motion controller where if the held object is a destructible component that is currently (just) fractured then it auto drops it and prints a warning to the log that such objects should be dropped before fracturing.
I was right, when fracturing it removes its scene reference and re-creates them in the async scene, normally wouldn’t be a big deal except the engines ComponentMultiOverlap function crashes on getting the objects physx scene shapes after fracturing (not exactly a plugin bug I guess). Also it leaves the object in hand which eats up resources so it shouldn’t be like that anyway.
If you want a cleaner way to handle held destructibles I would actually suggest having a grippable actor with a primitive root component and then a destructible mesh component attached to that root component. That way you are not directly constraining the object that will fracture and can work out some neat effects with it.
Regardless the check in in the plugin now, I am not entirely sure that I SHOULD be checking for , or whether I should be enforcing proper cleanup on the part of the user but until I make up my mind I added it in.
Pushed new commit to the template/ plugin
Fixed Vivecharacter not picking up base simulating actors anymore (when changing for the new IsHeld interface function I set a node wrong)
Added the plugins new check for destructible components being fractured, not entirely sure that I should even be doing .
In the future I may force the end user to properly clean up destructible meshes instead by dropping them or attaching them to
a root component that is gripped instead.
Currently auto drops the held component when it detects fracturing
[/QUOTE]
First of all thank you very much for yourf work!
I tried to attach the destructible mesh to a static one that dissappears when the destructible fractures, but it causes instant fracture, which is undesirable. I don’t know if you mean another thing by primitive root component.
Again thanks in advance