I think if some of those are “generic” object to pick up, maybe just setup a grab-able BP that are replicated and just replace the mesh(including collision)/material?
Usually, if you want client really smooth, say over 100ms(and I assume grabbed object “postion/orientation” is not gameplay critical) , you can always keep them update in a local thread with a fake object while the replicated one is not visible.
So once you throw away, you destroy/hide(so you can reuse later on) the “grabbed” object and let the replicated one do it’s thing with force/velocity update to server.
As far as the update side, as long as it’s not always lagging, it’s should be fine.(I might sound naive cause that was based on none VR experience.)
Shouldn’t need too, I have pre-built binaries included for 4.11.2 (thus why the folder size is so large…).
I am only concerned on the owners side, the whole reason for the plugin was to allow for collision and the late rendering positional updates to work together. Non owners and the server it doesn’t matter if it isn’t 1:1 because it’s not moving from their perspective anyway. Fake objects would work and you’d likely just notice a little weirdness about when pushing something with the held item. Would send an RPC to the server asking to grip an item, the server would grip and send back “grip fake copy of this” with the offset transform that it decided on, client would copy and hide the original on its end and then grip the fake one, I would think that would work without changes to the plugin really.
Would like to test with the original object and just keeping the late update client side and see how it looks at different latency’s though receiving base positional updates from the server. I’m not a fan of held objects lagging behind controller movement so I doubt it would be acceptable to me.
@ Magnvs Not sure I understand. 1) Do you put the Vive_pawn in the level at start or is it spawned through PlayerStart at start?I still have some test to do concerning the latter, especially while using 's plugin.
Also, if you physically walk within a mesh you can have some trouble teleporting outside because 1)Trace is blocked by blocking volumes if you mesh has one with right options enabled and 2)In teleport functions “Can teleport” boolean is checked only if the trace hit an object within 81-99 degrees (90% of normal angle). These two features are there to block teleportation in blocking volumes (including no teleport zones) and to teleport only on flat, horizontal surfaces. Off course this could be adjusted to teleport on uneven surfaces. I’ll put it as an option in next version.
Thanks Proteus & All. This is a pretty nice project.
Bounds on the controller skeletal mesh are messed up. This causes all sorts of occlusion/clipping problems. I think the correct way to solve this is to move the collision bodies in the physics asset under the ‘Main’ bone.
In my own project I just replaced all the convex bodies with 1 sphere and 1 sphyl. I find it gives pretty nice and predictable collisions and I can easily hold items in air with 2 hands etc.
I’m sorry I may not understand how it’s supposed to work entirely, I messed around with it this morning and realized that in 1.7 it spawns you at the same height regardless of where the pawn is? Earlier I placed the pawn on the veranda of a test building and was able to start from there, but now I start at the base (z0cm). I assumed it was collision detection earlier, but seems to be unrelated to whether anything is there or not.
@Magnvs. You’re right the Vive_pawn in the level always spawn at z=0 in the level. The problem is there whether you use Vive_Pawn in the level or via PlayerStart. Anyway I spent last friday trying to find the problem, couldn’t find it. I rebuilt 1.7 from 1.6, and now it’s working. If you can wait till tuesday everything will work. In next iteration I removed Vive_Pawn in the level and rather only use PlayerStart. Now you’ll spawn at PlayerStart location and rotation. @Guich Grabbing was removed in 1.7 cause it was far too ineficient. It will be back in 1.8 @Fnordcorps In the roadmap…
I welcome warmly suggestions to improve any aspects of the template as people far better than me frequent this forum. For the time being there is my roadmap for iterations of the template:
1.8
Grab function with interactive objects
Vive_Pawn and Vive_Character spawn at PlayerStart location and rotation
Fixed vehicle with animated handles
1.9
Face and hands meshes
Animated hands with 3-4 poses
1.10
Multiplayer
1.11
Interactive menus
1.12
Curved teleportation particles trace line
Tackle chaperone
1.13
Camera passthrough
1.14
…
Is someone want to solve one/many of these features, go crazy!
I’m getting the same problem AxelHunter, Dropped “SteamVR_1_7” into “C:\Program Files\Epic Games\4.11\Templates”, every time I open up a new project in 11.2, select SteamVR_1_7 as the template and load it up, i get the same message.
@Guy@AxelHunter Ok don’t know what can be causing the error but there is things that can be :
Be sure to open it properly through 4.11.2 launcher
Delete SteamVR_1_7/Config/TemplateDefs.ini, put the main folder into your regular projects folder and open it as a regular project through 4.11.2 launcher
It seems there’s a problem with the SteamVR_1_7_/Content/Vive/Controller folder. You can re-download this folder and its content on the onedrive under “Controller 1_7.zip”
Hey Proteus, first of all thanks for putting this together, it’s really nice to have something like this, makes everyone’s life easier…
I am testing the 1.7 version, and it works perfectly but when I try to build the project I just created based on the template I get an “unknown error” and the build fails. Anyone else getting this?
Has anyone been able to build a project from v1.7?
@PabloNajurieta I just built successfully the project from 1.7, both shipping & development, 32 & 64 bits. Could you post an image of the built errors in the output log (in red)?
Just updated the plugin with the ability to set a socket name as a snap target when gripping an actor. If it is a valid socket name for the actor’s root component it will use the relative transform of that socket instead of the WorldOffset for setting the actors position.
IE: If you make a socket named “Handle” on the root component and set it to 0,0,10 location relative to the root component it will keep the actor at 0,0,10 relative to the motion controller if you pass that sockets name into the grip function.
Just wanted to drop in and say thank you to @Proteus, @PenguinTD, @, and any other contributors. What an awesome project. I’m looking forward to 1.8!
I was seeing the same errors as Guy and AxelHunter. #3 below fixed it for me. (Two very large asset files seem to be missing from the Controller folder in 1.7.).
Btw, I’m currently working on a more flexible event system/flow that allow and simplify many things. Specifically the following.
one button can do multiple things depending on what you assign it to do in game.(basically call a assignAction event from whatever triggers it.)
be able to limit action to only one controller(say if you assign teleport to left hand, when you assign it to right, left hand will be set to do nothing)
the list of actions can be customized(Enum) and it can be separate into multiple groups, where actions within one group can not be on both hands.(ie. you can’t have teleport on one hand and ranged spell on another)
this will also let graph become more easily manageable cause every button action is now called by event dispatcher.(yes, you do need to bind/unbind events. But it’s a lot more simpler than branch/select.
I think this and possibly some future core function improvement would be my last major contribution. Cause this template project can go on forever and be a giant mixed pot of things and my project won’t ever start. LOL
So hopefully Epic did some update so we don’t need to expose those SteamVR functions from community plugins.(cause I really want those movement prediction functions.)
I will finish my setup in a different folder so it’s easier for Proteus to see which part is more useful to this template.
Thanks to all of your cool work Proteus and everyone else to that chips in! As an artist getting started with vr developement I would never be able to create my own play scenes to mess around with. I´m really excited about a grab function being added too as then it will start to feel more close to real life and get truly exciting. I made a beer pong scene in unity where I can throw balls across a table into cups and I was using these scripts as theyre all working and is super awesome. uTZ0xw4SPn0&feature=youtu.be however I must say I like unreal engine more in the sense that everything is smoother, runs better and looks better.
One thing that I really like about these scripts though is the fact you can individually import teleportation features via scripts. Drag and drop a grabbing function to the controllers. The thing I enjoy the most is putting the Grabable-object script on objects you want to be able to grab. It would be super cool to have something similiar in UE4. Im already loving your work here and Im forever grateful. Will this be possible in the future to have an easy way of making an object grabable you think?
Proteus brought up something about how I had object snapping set up so I’ve updated the plugin again with a new boolean in the grip function: bWorldOffsetIsRelative
If true the function will treat the WorldOffset as already in relative space, this way you can pass in a sockets relative transform (BP node GetSocketTransform with Component or Actor space selected) and it won’t convert from worldspace. Should have more flexibility for the end user as if you designate a snap socket the function only searches in the root component for it (I still kept the optional snap socket name for convenience sake as it is both faster and easier if the root component contains the socket).
You could also pass in an empty transform with 0,0,0 location and when WorldOffsetIsRelative is set to true it will lock the zero point of the actor to the grip which is more conceptually intuitive than setting it to the world transform of the controller itself.
At this point its pretty much for my original goal with the plugin, if anyone else has any suggestions I would consider them but I guess I need to make an actual project now.
