Thanks a lot for you replay!
I still experience the same problem, basically now that I climb I can “push” myself up I go up infinity unless I grab the box.
In my test I grab the top box on the right and tried to “push” myself to the left to be “floating” to the left side until I grab a different box or reach a wall.
But when I try to push myself to the sides (working good with up and down) it seems like there is no force.
I tried to check what cause force to be applied when going up and down but I got a bit lost in the blueprints :
Hope if you can help or point me in the right direction.
I hope its clear enough…
Hmmm, i’m not getting that behavior with the brief test I ran to get you the best settings, on release for me its retaining velocity in all directions like it does anyway for falling. Did you change something about the blueprints from the default template setup? By default it goes into falling after releasing from climbing which retains the velocity you had going.
I’ll note that low grav is interesting enough that I started working on something for directly handling today.
Pushed a new commit to the Plugin repository today, have not pushed it to the template yet as I am going to do some more testing, only moved it to the plugin due to a packaging bug that needed fixed.
Added pipeline for replicated movement mode changes that tie in with fSavedMovements
Does not currently support Custom MovementModes outside of the ones I define.
SetReplicatedMovementMode()
To get it working correctly with up to 16 total values the Flag_Custom_0 and Flag_Custom_1
and Flag_Reserved_1 and Flag_Reserved_2 of the saved movement have been taken up. There is room
for 6 more custom modes to be added to the plugin at a later date.
Added Alpha LowGravMovementMode
Set StepUp to be overriden now that it is supported.
Added EVRConjoinedMovementModes enum that combines the default modes with my custom ones.
Added PostClimbingMovementMode property to climbing settings to set the auto step up
movement mode switch.
Added boolean SetDefaultPostClimbMovementOnStepUp defaulted to true, if true then
will auto switch movement mode to the PostClimbingMovementMode value on the auto step up.
If false the movement mode will need to be manually set instead when OnClimbingStepUp event is called.
Added VRLowGravWallFrictionScale that modifies the speed that you retain when hitting a wall
in low grav mode, defaulted to 1.0f.
Added VRLowGravIngoresDefaultFluidFriction boolean defaulted to true, when true the low grav
movement mode will ignore the default Air Fluid Friction that the engine uses. allows
low grav to work correctly without changing the default fluid friction, it will still use
custom fluid frictions otherwise.
Moved inline functions into header for root component to prevent a packaging error
without removing inlining on them.
Set step up capsule directional influence to only be used with walking movement
in step up as it does not function with LowGrav / Flying correctly.
Added capsule directional movement influence to VRClimbingStepup for VRCharacter
Set VRClimbingStepUpMultiplier to default of 1.0 now
Fixed step up height issue from today.
Edit Video going over some of the things to better explain them
Fantastic work by the way but i’m having an issue(?) with teleporting vs what teleporting is like just with the plain UE4 VR template project. In the plain UE4 project you can teleport anywhere you want, not limited by the size of the room scale area. But using it seems to restrict me to choosing places that would “fit” into the room scale space, is there any way to disable so i can teleport to intentionally thin locations?
It shouldn’t be prevented from anything with the roomscale size, what prevents teleporting is the navigation mesh since the epic teleportation is setup based on navigation.
You can press P in the editor to view the navigation mesh in your level and either fix it where its not teleporting by regenerating of altering navigation settings, or throwing out the navigation check all together and teleporting anywhere the end touches.
I honestly only have it using epics navigation check because their template had it and I wanted the teleport to be recognizable.
Thanks a lot again!!
I took the latest project template and there everything is working now.
So its probably related to a change I made, Ill investigate it later. Ill continue exterminate but those at the moment gives me a very nice results, so again thank you!
I got a suggestion/Feature request that could be helpful to the users of template
Basically its UI Touch interaction like you could see in Star Track VR game
What do you think?
Again million thanks for you help and support on amazing plugin and template!
I was considering it after first playing that game, the main problem is of course that it works best WITH IK like they are using as you can pass your hands through the surface and slightly above it and still retain contact with the controls (the IK is “sticky to the surface”. Their IK system, while not perfect, is well tuned for the actual interaction part and plays a large role in why it works so well for them.
The actual “touch” with widgets capability would be easy to do with either baseline widget interaction components with a very short trace, or extended widget interaction components that implements a touch on hover. 90% of the functionality is already covered in engine by the widget interaction components honestly, with maybe some slight quality of life tweaks.
Thanks, you were correct, I was missing a Super:: call in PhysCustom. Its fixed (will upload later today), although you’ll still have to declare a custom mode past 1 which is the plugins last one currently as I don’t call it for index’s that the plugin uses already.
There is a enum EVRConjoinedMovementModes, that you can use to easily know the correct first index for custom movement modes. I take up the first two slots with Climbing and LowGrav but I filled that structure with additional values of Custom1 - Custom6 for 6 total custom movement modes.
Its also the structure used when calling SetReplicatedMovementMode which is a method of setting the movement mode in a way that ties in with the SavedMovement system so the server does it at the same point in the character movement as the client did and supports rollbacks from the server.
These changes will be in the commit later today.
Edit Pushed a commit to the plugin as well as made the testing branch of the template with these changes live
Fixed a missing Super:: call in PhysCustom so that the HandleCustomMovement event would
fire for blueprint users on custom movements that are not already handled by the plugin.
Expanded EVRConjoinedMovementModes enum to include 6 custom movement mode definitions
will make it easier to select a custom movement mode that doesn't overlap with already used
values. also allows SetReplicatedMovementMode to work with those 6 custom movement mode
index's for true during movement mode switching without explicit RPCs.
Changed the auto step up for climbing to call SetReplicatedMovementMode now instead of
directly changing movement mode, allows it to still function if the server rolls
back a move and replays (previously in rare cases it was hanging on climbing as the rollback replay
wasn't re-setting the out of climbing mode).
Hi there. First of all thank you very much for that nice plugin and contribution.
Now to my question (maybe I’m just to stupid to find that right know): Do you have a project available with the plugin and all of its features implemented? Like shown in the videos?
I would like to give our students the opportunity to work with it, but they would be overstrained with the implementation, besides the fact that your documentation is awesome. They are art students and not many of them have a programming background. If that’s not available I would build it myself.
Is there any way, to download the template and load into the unreal 4 engine editor without compiling anything? Doesn’t matter if 4.16.1 or4.15.2. It doesn’t matter which commit I try it just says missing plugins VR_Exampledll] . When I start my own project it works. Or is there a way to download the blueprint code for climbing / teleporting objects / picking up / showing hands (or controllers) seperately?
The pre-packaged binaries as long as the date on them isn’t too far from the templates last update should also work, the downside being that the template also uses the sessions plugin which has its own pre-packaged binaries…
You can actually directly transfer the uassets over, but it would be a little difficult to know the exact ones you want.
BTW for everyone else, the reason that climbing and movement “logic” are not built into the code and are handled in blueprints is two-fold
#1: I wanted anyone to be able to play with and modify how they work easily so they can get it working how THEY want.
#2: For blueprint users it gives them examples of how to achieve different things, for c++ users, they can convert blueprints to c++ at will anyway.
I have been considering building some common objects into a c++ “pack” in the plugin, like levers and buttons and dials and the like, haven’t made up my mind yet.
Sheit, sorry to make it seem the way I mentioned was the only way.
@rohezal
If you just want to see the plugin with minimal effort, dgaf about anything else, and just want to move around like a VR madman climbing on stuff and scaling/gripping/flinging isht (none of which you made) to kingdom come, here’s a link to a prebuilt template for UE4 version 4.16.1.
tl;dr
Custom Static/Skeletal Grippable Mesh actors aren’t oriented/positioned exactly mirrored in each hand, but the Template Gun_Base is.
What things might I need to make sure are good?
I have custom-made hands, and equippable items (all made in Blender). When I use them hands to pick up the grippable static mesh gun_base in the template, the gun orients perfectly! To be more specific, the position is just a little bit off, but it’s off identically so for each hand, which I assume means it’s because the pivot point on my hand is not the same as that on the mannequin hands in the template. That’s totally cool. The important thing here is that they are angled/oriented perfectly regardless of the hand I grab it with; the gun always faces forward exactly at the same angle.
I’m not getting same, exactly mirrored orientation on my own grippable static mesh and 2 grippable skeletal meshes though. The static mesh’s orientation is perfectly mirrored along UE4’s Y, but its location isn’t if I move the socket’s Y position (it’ll be distanced good from one hand but not the other).
The skeletal meshes are more effed. I spent about 6 hours today mucking with the root’s roll of the 2 skeletal items, tried orienting the entire armature in the exact same direction as that of the GunBase mesh (facing down -Y in Blender, +X in UE4) but still no luck.
Anyone familiar with Blender/UE4 reimporting know how to fix ? I think it’s likely a roll or root/armature rotation problem, but I’m not sure. I do know for a fact though, that reimporting fbx in some cases doesn’t implement all changes between the fbxs (specifically in regards to Anims, possibly armatures too I’d suspect).
The Static Grippable Mesh position prob is maybe because the origin/pivot is off from. I’m away from the work computer for the weekend (Japan time). I’ll be able to try any other solutions 2.5 days from now.
The hand meshes don’t have anything to do with the objects location, the object is mapped on to the controllers zero point itself, where your representation of the hand is from that is entirely up to you, you can move your hand position relative to the motion controller at any point.
As for skeletal meshes and root bones, due to a bug with physically simulating objects and root bones I have to add the root bones extra rotation into physics grips to support objects with a rotated root (the engine does not account for and the object will be orientated incorrectly otherwise). It may be that Epic finally fixed and I was unaware of it but you seem to be saying that the preview of the mesh is incorrect not the gripping of it for .
If you get a chance and want to pass me a PM with one of the problem Static and problem Skeletal meshes I could look at them.
The whole point of how I handle it currently is to avoid requiring people to orient meshes a specific way in order to work with the plugin.
I just dislike the concept of closing off gameplay element modifications from strictly blueprint users, the main goal of the plugin is to be a flexible back end, not a rigid front end as well.
Edit I guess they could still implement them in blueprint as well if they wanted custom ones, and I could leave the current blueprint versions intact.
I ported some of the AIControllers navigation functions to the VRCharacter and setup client side navigation for VR (engine by default is server sided navigation only). If the movement mode is set to navigation when it ends the teleport arc it calls ExtendedSimpleMoveToLocation instead of teleport, its the SimpleMoveToLocation node with a few more features/options.
The out of body movement does the same thing except it also switches the camera during the movement part, I added a “NavigationEnded” event that fires when navigation ends (end of path, error, ect).
