The interaction properties set that.
I created a test project based on your example template, packaged it and tried to upload it to the Oculus store to see if it would work. Oculus rejected it with the error:
The package contains DLL libraries that are known to cause issues when running on the Oculus platform. These files must be removed prior to uploading: Engine/Binaries/ThirdParty/OpenVR/OpenVRv1_0_2/Win64/openvr_api.dll, Engine/Binaries/ThirdParty/Steamworks/Steamv132/Win64/steam_api64.dll
Do you know if is just an issue with the version of the api.dlls or does Oculus just reject anything built with the steam APIs?
Steam api doesn’t cause issues with their platform, they just reject anything built with it…likely because it lets the program communicate with a competitors service and they want their games launched on their front end. That being said you can untick the Steam/OpenVR plugin in the engine and it won’t compile it out anymore. You would have to be sure to not use any of the steamVR specific code however as the plugin assumes that steamvr is available if compiled on a windows computer (controller skinning, tracked device properties). The controller skinning wouldn’t work on oculus plugin anyway so it shouldn’t really be a problem.
The motion controller backend and HMD backend are platform agnostic and should work with the oculus plugin, I can’t test however as DK2 was my last oculus hardware.
We’re trying to have a two bone IK to link our shoulder piece to our controllers.
Whenever we select the bone on the Two Bone IK it crashes UE4.
Using the two bone IK is how you got your arms to work correct?
Nah, it likely would be the correct way to do it though. I used the FABRIK node to link the bone chains from the shoulder to the wrist and set the wrist target to the controller + a positional offset.
In your preview your secondary hand attaches to the “VRGripS1” socket on the gun. Where is code?
Edit: Also, I migrated the important stuff from your sampleProject, but for some reason moving the top cube on the gun does not work.
Thanks!
In the grip function it checks for “Primary Grip socket in range”, if it finds one then it grips it there by passing in that socket transform.
Suggestion: Add a third person camera, one that outputs to the monitor.
That way you can see around your VRCharacter and his surroundings.
Thats not something the plugin needs to handle as without re-writing part of the hmd code and making a new class for it I would have to render to texture and display the texture to the screen witch could be done just in blueprints instead.
Also seperate views to the window is something currently slated to be done by epic themselves probably in 4.15 and integrated by default.
I’ve been able to use IK (in my case on the hands but using a full body model) working without a hitch using BIK but I have not tried it using Two Bone IK. In my case (using BIK) I placed Effectors on the controllers themselves. There are some feet grounding issues which I haven’t fully worked out yet but had time to dig through on focus on fixing. That may or may not be helpful but figured I’d mention it.
Yeah like I said, FABRIK was quick and dirty to get the default arms working, but with a rig built for IK it shouldn’t be required.
I`d like to limit the maximum distance the controllers can get away from the camera to prevent cheating in multiplayer. What is the best way to tackle ? Should I be adding an offset to the controllers if they exceed some distance?
I wouldn’t bother, I would just turn them semi transparent for visual feedback and deny using anything and drop anything held. You would have to account for a large persons wingspan though and would probably want to limit it only on the distance of the x/y axis.
For roomscale bounds I have a Trello note to limit the HMD and motion controllers to the drawn limits to prevent tracking loss sometimes throwing them out of it…however I realized that the actual tracked space is significantly larger than the drawn limits so that would be a bad idea.
I’m going through things I might want to implement on my upcoming two weeks off for the holidays, I think primarily I would get a server browser / basic multiplayer up and running, also have a note for a component to handle drawing / defining manually areas within the tracked space to set as visual boundaries in game (draw around a chair for example and have it shown in the relative roomspace in game).
I might tackle climbing but the mechanics of that are so unique from implementation to implementation that I have been avoiding doing so.
Any other ideas?
The idea of a manual ‘tracked area’ component as you describe sounds absolutely incredible!
How would work? Does the user draw these manaul areas during runtime and the areas are seen?
Could the user draw these areas while in an editor preview of the game and receive the results in unreal editor after quiting the session?
I have made a 3d model of the entire studio space I work at and it is a pain having to re-adjust the virtual “tables”, “filing cabinets”, shelves etc after they have been moved.
It would be so cool if, in VR the user could plot that data and then see the results back in the editor to shift the virtual objects to line up.
, do you think it would be worthwhile adding some more chaperone components?
To my understanding, at the moment blueprint exposes the 4x vectors of the Chaperone tracked area.
What if the VRexpansionPlugin had a few more components:
-Chaperone ground plane
-Chaperone Wall north
-Chaperone Wall east
-Chaperone wall south
-Chaperone wall west
By north, east, etc, i mean the wall that faces X in positive direction, wall that is along X in negative direction, etc.
The components could be added to the VR pawn and render a plane that is the correct size for that boundary.
I suppose is a very easy task for a programmer to manually create these components based off the chaperone bounds and the height of the base stations, I thought it might be a good addition to the plugin to make user’s lives easier. And is a feature many inexperienced VR developers might find useful in the plugin.
To my understanding, users of the VRExpansionPlugin’s VR Pawns need to account for the way the HMD moves in order to continuously set the Chaperone boundaries in the right location
If users had these components, the users have an easy way to get, parent and place objects on those areas of the chaperone system.
Hi again ,
I have one more request regarding the template project on Github.
Could you rearrange the template’s content folder so that everything exists within one top-level folder?
That would match the way projects and assets are delivered on the marketplace and the "Allar ue4-style-guide specs.
That way it’s very straightforward for anyone to migrate the template into a new project. Especially after pulling any updates from Github.
They can just sync with the latest template, and migrate the main top-level folder to their production project, overwriting any assets.
I have attached an example image to post:
Yeah I intend to get around to that, when starting the template I just imported some of my folders from my demo world and they were split up.
If saving the tracked points / lines out to serialization its possible to keep them between sessions and in the editor yes. I am still mulling over how best to do it, a full procedural mesh or line batches to define areas.
I’ll agree that needs to exist, however I would prefere the full bounds of the tracked space drawn with the controller, not the “square” that is generated as a “safe terrain”. I will have to look into if openVR still provides the HardBounds output or if they locked it to just the softbounds.
Specialized functions like that by the way are likely to only be fleshed in for OpenVR, I do not have the ability to test on the OculusSDK.
I think I have a basic setup for LAN multiplayer done? My team is going to demo our build at SXSW so it wouldn’t need a server browser.
Would you mind if I posted some screenshots of what we did on networking and see if it makes sense/would work?