Found it, Delete the following blueprint (I deleted it going forward in the template): Content/VRExpansion/Vive/Testing/PlanerLock
Its a corrupt blueprint, its not a very useful tutorial item so just deleting it is fine.
Edit Also had to make a small edit to the non networked character just refreshing a node.
im completely confused on the process of bringing a gun into the game and dont understand the process. I cant follow any tutorials because your plugin is different.
is there anyway to just use to gun base you made and just change the mesh picture? im trying to have less problems, and I thought I could but no matter what I do the gun loses all its features once the mesh is changed which I think its strange because its not changing the code. for example with your gun base, if I click and pick up the weapon with left mouse and let go of left mouse, your gun stays, with my simple mesh change the gunbase you made loses all its features.
I spawned a GrippableSkeletalMeshActor and it to loses all its features, I can grip it but then when I let go of left mouse it doesnt stay in my hand like your base gun. it just drops to the floor and keeps on rolling and rolling and rolling. yet when I hit play it floats until I pick it up, and if dropped keeps rolling.
do you have any videos on how to properly bring in a gun into the VR world and keep its settings?
Thank you very much for your quick response!
It breaks was perhaps the wrong way to put it. When I added a gamemode and had the player spawn off of a VRPlayer Start, the mesh became offset, the camera was looking out of approximately the center of the mesh, and the arms were no longer moving around with the motion controller properly. I believe it has something to do with where my mesh is placed relative to the HMD’s position. Is there a specific way I should be attaching it to the ParentRelativeComponent? Or will I need to find the offset myself when adding the mesh to the character?
The strange thing is that when there is no gamemode, the HMD and motion controllers move the character properly and the hands move to the proper side of the character. When the gamemode is added, even a BaseGamemode that’s been extended and uses the right pawn (I think), the arms no longer translate properly with movement. The head still follows the proper rotation. I think means that the HMD is in a different position relative to where it originally was?
Is there an example character in the template that uses a single skeletal mesh with a VRCharacter I could take a look at? Apologies for the rambling question.
Sounds more like you have bad collision on it, just switching the static mesh on the weapon shouldn’t have any different effects. Literally clicking on the static mesh in the actor and changing the mesh it references should work fine. When you convert from skeletal to static it likely doesn’t have any collision then, you need to generate some for your model.
As for a standard GrippableSkeletal, no it wouldn’t behave like that, the gun is customized with the settings it uses to behave how it does, you would have to copy the gameplay tags and setup it uses into any new grippable you want to copy it. The GameplayTags in the template for grippables define what buttons grip and release it and how, in a normal game these wouldn’t exist but they are there in the template for maximum flexibility and to allow me to demo all of the different features.
Edit Oh, you will also need some Sockets on the new mesh if you intend to use the exact same gripping logic (snap to handle, ect), look in the mesh for the template gun and copy over the named sockets in there to where you would like them on the new gun. For advanced users you can switch to components and the like as well but generally the socket method is the most flexible.
You aren’t using the correct pawn if the camera is waist height to begin with / you haven’t started up VR mode correctly. If you want head locked VR you need to change the cameras position (change NetSmoother height), if you want roomscale you need to set the VR mode to roomscale and then that simple character should just work.
Sounds like you have the VR mode set to Eye Level to be honest which none of my default setup is made for, its easily possible to use that mode, but there is less reason to since the main point of the characters are the room scale movement being tied into their actions.
Edit I guess you could argue that the networked snap turning and climbing are reason enough to use a non standard character for head locked VR.
Regardless, when you changed game mode you were no longer initializing VR correctly.
As for the Parent Relative Attachment, it is by default locked to the head position for chests and inventories and waists and the like, you can set a bool on it to lock to the foot position instead which is generally better for being the parent of a SkeletalMesh body.
Also no, I don’t have a full IK example in the template, to do it “correctly” would involve forcing a third party plugin or coding custom IK, neither of which I am willing to do for it. The default in engine IK setup is not good enough for a decent full body rig in VR, there are many third party solutions now that perform well so I point people to them when asked instead (leave that up to the specialists).
Thanks again. I think that’s the issue, I didn’t set VR mode properly. I’ll fix that and get everything working. I think the eye level setup was a remnant of some previous work we did in the same project with Vive specific setups.
I’ll also take a look at the full body VR rig solutions. Sorry for so many dumb questions, thank you so much!
Sorry for the double post, but wanted to follow up:
Setting the VR Mode and changing around the values you suggested worked perfectly! The character is now running around and has its arms moving no problem. We also found that part of the problem was that there were two pawns being spawned, one ending up below the world for some strange reason. After deleting that, it solved the IK problem immediately.
We actually found that the problem was that we never set the VR Tracking Origin and it was set to floor level by default- we’re using a Vive, so we needed it to be Eye Level. By combining all these fixes, we have a working character with arm IK. Thank you so much for all your help, I really appreciate it!
Eye level is the incorrect one actually if you want to retain room 1:1 and camera height, floor level is what you would normally want with a Vive unless you are sitting down.
It will work if you offset the camera of course, but you sacrifice 1:1 height with the tracked space.
Pushed a new commit to both repositories (for 4.20), pre-compiled binaries will be generated tonight since 4.20.2 just came out.
Plugin
Added GripScripts fully into the master branch with four reference c++ implementations
GS_Default (default gripping logic)
GS_LerpToHand (lerp initial grips to the hand)
GS_InteractibleSettings (Functions like the removed InteractibleSettings options)
GS_GunTools ( Currently unfinished set of tools for advanced gun interactions)
Removed rollback on custom movement modes
is to remove "climbing mode" hanging in place and seated mode issues.
Really only an issue in really high packet loss situations, but wanted to cover it.
Also added a GetReplicatedMovementMode function that returns the current Conjoined movement
mode.
Set OnClimbingSteppedUp to a BlueprintNativeEvent so that c++ users could use it.
Set GetOpenVRModelAndTexture node to not fail out if a texture is missing and to just pass out a nullptr now.
It was failing on Knuckles Left controllers as they are missing a texure in full model mode from the OpenVR
RenderModels api.
Corrected an oversight with the new OnDropped event on the motion controllers having a possibly stale variable (thanks SlimeQ)
Template
Re-wrote how the character / player controller is initialized to be far cleaner.
Added Knuckles EV2 default controller profile and changed some of the character logic to check for it in OpenVR.
Changed the FPS test pawn to load its profile in a different area
Removed a corrupt BP and prepped everything so that packaging with PackageAllDirectorys works without issues on the template.
Removed unused content that was just bloating the repository (left over EpicVR template content)
Reference BP Grip script will be coming later.
Changed Sedan actor to use a Boxmesh around it for the navigation modifier.
Thanks for that. I see the event on the sedanBP but shall I start it from the levelBP referencing both the car and my character so I can pass the info the function needs?
Also, not sure if there is an example video of how to setup a socket grippable like for example, a bow (So the controller automatically sets the location on the center of the bow with the apropiate rotation. Like the gun for example.
If you leave default logic in place and do not override anything, just add a socket name VRGripP to the bow and set the rotation on it to whatever feels right. If you only want snap grips possible (no free gripping elsewhere on the bow) then you’ll either want to change the PrimarySlotRange on the object to be higher, or override the GetClosestSocketInRange function and just always return your grip point.
As for setting seated mode, whatever makes the most sense to you and your game.
?
Hey there, love the plugin. Trying to squeeze that 90 fps is a real pain tho. all the ticks used in the current setup make it extremely heavy. I tried to nativize the vr character blueprint but got error. any ideas?
Thanks again
UATHeler: Packaging (Windows (64-bit)): -\Unreal-\Plugins\VRExpansionPlugin\VRExpansionPlugin\Intermediate\Build\Win64\UE4\Inc\VRExpansionPlugin\VRBPDatatypes.generated.h(12): fatal error C1189: #error: “VRBPDatatypes.generated.h already included, missing ‘#pragma once’ in VRBPDatatypes.h”
UATHelper: Packaging (Windows (64-bit)): [6/19] Module.VRExpansionPlugin.gen.6_of_9.cpp
UATHelper: Packaging (Windows (64-bit)): [7/19] Module.VRExpansionPlugin.gen.4_of_9.cpp
UATHelper: Packaging (Windows (64-bit)): [8/19] Module.NativizedAssets.2_of_3.cpp
UATHelper: Packaging (Windows (64-bit)): -\Unreal\PILLAR-\VRExpansionPlugin\VRExpansionPlugin\Intermediate\Build\Win64\UE4\Inc\VRExpansionPlugin\VRBPDatatypes.generated.h(12): fatal error C1189: #error: “VRBPDatatypes.generated.h already included, missing ‘#pragma once’ in VRBPDatatypes.h”
UATHelper: Packaging (Windows (64-bit)): [9/19] Module.VRExpansionPlugin.gen.8_of_9.cpp
UATHelper: Packaging (Windows (64-bit)): [10/19] Module.VRExpansionPlugin.gen.9_of_9.cpp
UATHelper: Packaging (Windows (64-bit)): [11/19] Module.VRExpansionPlugin.gen.7_of_9.cpp
UATHelper: Packaging (Windows (64-bit)): [12/19] Module.VRExpansionPlugin.gen.2_of_9.cpp
UATHelper: Packaging (Windows (64-bit)): [13/19] Module.NativizedAssets.gen.1_of_2.cpp
UATHelper: Packaging (Windows (64-bit)): -\Unreal-\Plugins\VRExpansionPlugin\VRExpansionPlugin\Intermediate\Build\Win64\UE4\Inc\VRExpansionPlugin\VRBPDatatypes.generated.h(12): fatal error C1189: #error: “VRBPDatatypes.generated.h already included, missing ‘#pragma once’ in VRBPDatatypes.h”
UATHelper: Packaging (Windows (64-bit)): [14/19] Module.VRExpansionPlugin.gen.3_of_9.cpp
UATHelper: Packaging (Windows (64-bit)): [15/19] Module.VRExpansionPlugin.gen.1_of_9.cpp
UATHelper: Packaging (Windows (64-bit)): [16/19] Module.VRExpansionPlugin.cpp
UATHelper: Packaging (Windows (64-bit)): [17/19] Module.NativizedAssets.3_of_3.cpp
UATHelper: Packaging (Windows (64-bit)): [18/19] Module.NativizedAssets.1_of_3.cpp
UATHelper: Packaging (Windows (64-bit)): -\Unreal-\Plugins\VRExpansionPlugin\VRExpansionPlugin\Intermediate\Build\Win64\UE4\Inc\VRExpansionPlugin\VRBPDatatypes.generated.h(12): fatal error C1189: #error: “VRBPDatatypes.generated.h already included, missing ‘#pragma once’ in VRBPDatatypes.h”
UATHelper: Packaging (Windows (64-bit)): ERROR: UBT ERROR: Failed to produce item: –\Unreal-\Binaries\Win64*.pdb
UATHelper: Packaging (Windows (64-bit)): (see C:-–\AppData\Roaming\Unreal Engine\AutomationTool\Logs\C+Program+Files+Epic+Games+UE_4.20\UBT-*-Win64-Development_2.txt for full exception trace)
UATHelper: Packaging (Windows (64-bit)): Total build time: 232.79 seconds (Parallel executor: 0.00 seconds)
UATHelper: Packaging (Windows (64-bit)): Took 233.0981982s to run UnrealBuildTool.exe, ExitCode=5
UATHelper: Packaging (Windows (64-bit)): ERROR: UnrealBuildTool failed. See log for more details. (C:\Users-–\AppData\Roaming\Unreal Engine\AutomationTool\Logs\C+Program+Files+Epic+Games+UE_4.20\UBT-PILLAR-Win64-Development_2.txt)
UATHelper: Packaging (Windows (64-bit)): (see C:\Users--\AppData\Roaming\Unreal Engine\AutomationTool\Logs\C+Program+Files+Epic+Games+UE_4.20\Log.txt for full exception trace)
UATHelper: Packaging (Windows (64-bit)): AutomationTool exiting with ExitCode=5 (5)
UATHelper: Packaging (Windows (64-bit)): BUILD FAILED
PackagingResults: Error: Unknown Error
I will note that full nativization didn’t work until 4.20 because the engine had several bugs blocking it with the interface when manually implemented on an object (partial nativization worked but that is a pain). I got a bunch of them reported in early previews and it nativizes fine in 4.20 now (for me, you seem to be on 4.20). That error is about auto generated code headers not having PragmaOnce which is kind of out of my control and I don’t get it when I nativize, you might want to try clearing your intermediate folders and regenerating the project before trying again.
As for “hard to hit 90fps due to ticks”, are you on mobile? I can’t imagine that being the case on any other platform, the template is not CPU limited and most things don’t tick unless interacted with (hands, camera, pawn aside). Did you actually profile that CPU was the issue for you?
thank you for plugin, its helped us greatly, we have gotten alot done using the FPS guy. My son and I have both been doing project together, just a father and son thing.
we have some questions, As we move forward, and put code on the like health and armor and other code that will be needed for the game, just which blueprint are we suppose to edit? As of now we have both been using the FPS_VivePawnCharacter. While it works when on our laptops the road with our laptops,we have found certain things like the radar not working correctly on our actual real VR vive headset like it does on my FPS_VivePawnCharacter.
which blueprint will be the one for the vive? we dont want to get to so much done in FPS edit mode, only to have none of the features pass over . I only get to see my son every other weekend so it would be nice to enter the virutal world together.
and also
because my son keeps asking me if his cousin in California will be able to play game with us, even though he has a rift and we have vive. Is there a blueprint or something for the rift here ? It would make sense to copy and paste the code to the rift blueprint now to avoid problems later
awhile back i think you said something about controller profiles and grip offsets by socket, and i want to ask a question about that. im having to rotate the grip socket 90 degrees for the grip sockets in every gun i create. and im about to to start making a ■■■■ load of them.
i also dont want to screw my self in the future if i need to adjust them for vibe when i start trying to support it. is there a system for that or do i need to make one.
There is no different blueprint for a rift, it translates the controllers differently and adjusts for them.
Also you have been editing the TEST pawn, it is a child of the Vive_PawnCharacter, you should be making a new child of the Vive_PawnCharacter and editing that, or editing it directly.
Can you works in VR with Forward Rendering without problems?
I can’t run any project with Forward Rendering enabled except VRExpansionPluginTemplate. In 4.19 run smooth. If i create a Blank project, enable Forward Rendering, save, close and reopen, when it open again, go to Project Settings and UE4 Crash… With Template all runs well.
Anyone can test ?
The error is:
Fatal error: [File:D:\Build++UE4\Sync\Engine\Source\Runtime\Engine\Private\Materials\MaterialShared.cpp] [Line: 1803] Couldn’t find Shader TBasePassPSFCachedPointIndirectLightingPolicySkylight for Material Resource FloorPlaneMaterial
UE4 4.20.2
You are using the VR Expansion Plugin Template or in your game?
I recommend do a multiple things on VR. The DynamicShadows is a huge pain to VR. Set all illumination to Static, don’t use many Movable lights with shadows enabled, Merge Actors as you can, Proxy Meshes, HLOD and instance as you can, set Oclussion Culling and Precomputed Visibility. Raise up MemoryPool, by default is too low. Be careful with DrawCalls, not raise it above of 1000 or 1500 draw calls. Care with Postprocesing and Traslucent materials.
Create in the Config folder a DefaultScalability.ini with settings, raise up if you need it:
[TextureQuality@0]
r.Streaming.PoolSize=800
r.Streaming.MaxEffectiveScreenSize=1080
[TextureQuality@1]
r.MaxAnisotropy=4
r.Streaming.PoolSize=1200
r.Streaming.MaxEffectiveScreenSize=1080
[TextureQuality@2]
r.MaxAnisotropy=8
r.Streaming.PoolSize=2300
r.Streaming.MaxEffectiveScreenSize=1080
[TextureQuality@3]
r.Streaming.PoolSize=2800
r.Streaming.MaxEffectiveScreenSize=0
Look to get the best result in VR. https://forums.unrealengine.com/development-discussion/content-creation/112248-deconstructing-robo-recall
Thanks for the tips! Ive definately been getting better results in my own test optomizing, i will also apply your tips to get more fps out of it.
my original question however pertained to nativizing the blueprints - as they seem to be quite resource heavy. eg, when i take the standard vr character and take away the tick functions (i just unhook them for testing purposes) - my 45fps jumps to 90. The problem now is that I can package a game no problem, that works. its that it only fails when I try to nativize the blueprints.
Is there some special things i have to do to get nativiztion of bluejprints that use the plugin working
Run a profile on your template, I have never seen the combined tick events take over 2.5ms (that is for ALL objects, not just the character) and that was in debug mode on a weaker computer, the tick events for the vr character are just some motion tracking and state handling, nothing that should cause a ton of work. Also it would be worth noting that due to reprojection being on, FPS is always either 45 or 90, event if it a stable 88 it will half frames to 45.
As for nativization, it works for me in 4.20, I don’t know what else to tell you, if you are running inclusive with no changes it should function. If you are running exclusive you need to make sure that you also nativize BPs that it depends on.
■■■■■■ Unreal, i can debug why the editor crash in forward shading. Is a problem in Forward Rendering with the StarterContent. With the VR Expansion Template won’t crash because project doesn’t have the StarterContent. My project has the StarterContent (i don’t use it, but when i created my project don’t uncheck ) and now i cannot open my project in 4.20, ■■■■!
Can anyone test in his computer, please?
Create a blank project with the starter content, go to Project Settings, check Forward Shading, close the project and reopens it, when the project compiling all the shaders, go to Project Settings, and the Editor should will crash.