hey ****,
let me again offer my kudos on the plugin. Navigating around in it last night was so awesome. I can’t wait to learn it more fully.
I’m happy to help with documentation if I can, for people less technically inclined like myself. If there’s any interest in that kind of thing, let me know. I’m happy to try and work with you for a ‘dummy accessible’ version of documentation or whatever you’d like. I’m able to do video captures pretty easy on my end.
Anyway, quick question: In the attached video clip, I’m navigating via the DPadHover-ControllerOrient… is actually the reason I initially was looking for your plugin (to get away from the transporting default) in UE. At the beginning of the clip though (around 2-3 seconds in), I’m unable to re-orient the camera without physically turning around. is a bit tricky for me as I’m on Oculus, and the sensors don’t really allow 360 room scale full turning. Is there a way to have the right thumb stick orients the camera (either in smoothly or in steps) while the left moves it it?
Am I missing something obvious here?
I’m just looking to be able to switch the relative rotation of camera (kind of like in Echo Area if you’ve tried that).
p.s. the automatic action on the space rifle is amazing!
For snap turning hook node up to a button or however you want to trigger it: MovementActionSnapTurn
If you are doing single player only then you don’t even need to worry about that as it is for multiplayer syncing and can just use: AddActorWorldRotationVR
Both methods account for the HMD location and pivot the rotation around it.
Edit also doesn’t look like you realized it yet, but you can grip the front of the gun with your second hand as well.
Also snap turning isn’t in the template because I am showing off so much that I am out of buttons and haven’t put in a menu or radial menu yet.
Man, : you are on some serious dev. work here.
I realize I have a lot to learn before asking too many more questions haha.
Thanks again for the quick and helpful response.
I’m going to go over the wiki in full, brush up on my blueprint skills (I know very little), and come back to the thread in a few weeks.
Hello. I have a question / problem I’m working on.
I’ve implemented some basic functionality using the VRSimpleCharacter actor. I notice that the actor stays in sync with the location of the HMD, but not the rotation; ie, the actor is always facing world-space “forward”, unless I call AddActorWorldRotationVR. I planned on updating the actor’s rotation every tick, using GetOrientationAndPosition, and plugging the rotation into SetActorRotationVR(self), but the actor’s rotation doesn’t change.
Been slow on plugin updates last few days, been trying to track down some engine bugs in 4.19 so they can get fixed before release and re-factoring the OpenVR libraries.
Since vive pro will eventually bring the 2.0 lighthouses trackers with it and since WMR doesn’t use outside tracking objects at all the static list of objects to retrieve no longer makes any sense (already didn’t really).
I am moving all of the OpenVR functions to be purely index based with retrieving functions as well, that will also sync them to the UE4 implementation and mean that device index’s will be in parity back and forth.
Eventually the model loading function I have will go away since it is being built into the engine itself but I will wait until the official one is working correctly first (currently is has incorrect color channels for the texture).
Its given me some time to go through and fix some minor bugs and optimize a bit, there have been some minor additions to the repository but nothing comprehensive enough to collate and list yet.
Just a slow period, once 4.19 is stable and dev worthy I’ll choose the next major feature to start in on.
I’ll ask about that destructible mesh thing again. Maybe it’s a stupid question but I read every previous post about destructible meshes several times and in incredible plugin it’s the only thing that’s causing me troubles.
Through several approaches I’ve managed to make a grabbable DM a few times that works fine for some second and then freezes in the air, slightly vibrating with the rotation of the controller, and then drops and violently hurls towards the controller at the constraint break distance. Not grabbable with the other controller until dropped.
Tried many actors consisting of a destructible mesh and a grippable mesh or a grippable capsule but destructible meshes were unresponsive to so many blueprint calls that I have no idea what exact approach needs to be used.
I took out direct support for DM in 4.18 due to it now being a separate plugin and off by default, I didn’t want to tie the plugin into something that isn’t on normally.
You should still be able to grab them just fine as they have a physics body and the physics scene is auto selected with physical grips, the issue comes in if you let them shatter while holding them, then the body instance is removed and breaks the grip. It needs to be dropped prior to that. (I had a manual check specifically for DM’s in older builds that I had to remove due to its new plugin status).
AFAIK there were no issues with them prior to removing the manual check, except that you will have to manually grip them if you are using the template since I don’t check for them.
Note that destructibles are by default in the async scene, which doesn’t actually interact with anything but static meshes or other async scene objects normally during simulation.
You may want to try passing in the hit bone of the destructible to the grip function (newly supports ).
short question, it seems my hands miss the grabbing animation. Is that something wrong in my template, or didnt you provide one? I can grab things, but the animation misses. But its possible i deleted something or did something weird when i tried to get other hands in the template (VRhands instead of the robot hands).
Also the controller triggerbutton doesnt move when used, is also in your original template? If yes, then that probably the reason i didnt get the vr hands animation inside your template!
Controller’s aren’t seperated no, I only provide the full model loading from the steamVR API, since Epic is directly supporting it in 4.19 (have seen it worked on for awhile now) I decided not to finish that part and load the parts separately. Regardless even after their system is complete the driving of the buttons rotations would still have to manually be done off of axis values, they aren’t skeletal meshes.
As for the hands, I left epics overlap animations in, but I didn’t extend or modify it any. To be honest it doesn’t interest me much and is more an artists area.
Thanks. Where is the manual check for breaking located? I think on the build I’m on it’s working in some weird fashion: when a DM breaks it doesn’t drop cleanly but does the same thing where it freezes (just the root, the fragments still simulate fine) and vibrates slightly along the acceleration of the controller, until fully dropped, or until denied gripping. So maybe it’s that what’s triggering it prematurely for me. When it happens prematurely I can force the DM to set its world transform and that works for me, even if a bit jittery, but I’m wondering if there’s a better way to force it to start updating again.
I recently implemented snap turning using MovementActionSnapTurn and while I was in there I added a smooth turning option using the same function. sort of works but it’s extremely choppy. I see above that you recommended AddActorWorldRotationVR for non-networked scenarios, but what should be done in networked scenarios? I apologize if is a nooby question. I’d imagine it’s more or less the same as mouse control… but don’t know enough about either system to make an informed decision here.
Love the plugin by the way. I’m using it in my game Hailstorm VR, mainly for character movement and replication stuff. And for everything else, the code is a wonderful reference for my own.
Choppy how? MoveAction snap turn only sends the location offset and leaves the rotation up to the control yaw being sent in. I could see you having issues if the control yaw is turned off for the character, but at that point you will need to be sending the rotation manually anyway.
Edit Yeah I tested it on network, wasn’t choppy for me?
Edit2 Actually there is choppiness on the clients looking at the server itself, which doesn’t make much sense to be honest. I’ll look into that.
Its in the main grip loop, casts and checks if the first destructible body exists or not.
It may be broken in some instances, I never tested it beyond what one user needed, however it worked for all of my tests. You would likely be better off re-gripping on fracture, the issue is that the physics body gets destroyed out from under the grip constraint.
Byte values don’t have the granularity for smooth turning like that. And it is made worse with the root offset that VR has.
Regardless you can also set it in blueprints in the character BP here:
https://i.imgur.com/j759nMt.png
I am hesistant to set it to the default setting for characters due to the fact that unless you are specifically doing smooth turning it shouldn’t be an issue.
Edit actually pitch and roll should almost always be zero anyway, so they won’t rep besides the bitflag. I’ll probably default it since its a one byte cost then.
Also i’ll add your game to the using list if you don’t mind
I actually already had rotation quantization set to short. It’s possible is just a frame rate issue, but it does seem a bit choppier than the standard mouse movement. That being said, mouse movement is also pretty choppy.
Here is a video of me comparing the smooth turn to the mouse input (which is simply setting world rot on the camera): https://youtu.be/nnYizTsCfls
The “choppiness” I’m referring to is the apparent duplication of objects during turning. It is very noticeable in VR. I don’t notice nearly as much during lateral movement, though it is still present.
It’s very possible that is outside of the scope of the plugin, but I do not recall observing while driving the car in the template project. leads me to suspect it has something to do with the VR Camera or something… but I really have no idea.
EDIT: just tried Epic’s FPS template, it gets more or less the same effect when motion blur is disabled. Unfortunate
Oh, that is an entirely different thing, and no it isn’t caused by the plugin. It should be more apparent with fast jerky side to side movements when using TAA (actual ghosting) or at low framerates (jerky).
Lateral movements don’t actually adjust the apparent scene as much as rotational ones do, and mouse / direct rotation can be significantly faster than manually turning in VR. I assume you are driving the rotation by DeltaTime too, as you would need to do that.
The car doesn’t turn straight on axis, it turns over time smoothly, also while in the car you are still using the same camera…
If it was VR specifically related you wouldn’t see it in 2D, the late update pathway isn’t used without an HMD being used and tracking.
You asked originally about networked turning, which doesn’t have anything to do with actually.
You’ll notice the same thing in the FPS template as well, although I haven’t seen it as bad as you are showing, you have either really bad framerate there or are not driving it correctly.
Hi,
I’ve tested the PluginExample scene in order to see how the plugin is used and how to setup actors for what I need.
Unfortunately I notice that I can’t modify the components inside the Characters BP ( Vive Pawn in my case ), since everything is inherited, but I can only add stuff ( which is how the inherited pawn works ).
I order to integrate the plugin/BPs with my project I need to be able to access the inherited data…which I guess is pure C++ code you developed, correct?
Since I need to integrate some stuff ( VR gloves, mocap suit with IK given by the controllers ) and modify some stuff ( controller position in Z and other things ), the best solution would be to do all of that at Event Begin Play, by setting transforms and attach to actor?
Or it is possible to modify the inherited VR Character class with BPs?
Sadly aside from onconstruction and begin play BPs are rather limited in that area (in c++ you can directly override objects classes or remove them from base classes). Controller position in Z shouldn’t ever be required though assuming actual tracking is being used?
Regardless, yes, you can re-attach components however you like in BP or remove them entirely. Its just a little more manual effort.
I had considered removing the motion controllers from being default to the base VRCharacter but I do have some special setup for them (tick ordering and an RPC function pointer) that is more convenient to setup on init in the character than on attachment/controller init. I may do it yet in the future, it will break projects as the component will not be the same is the issue.