Toybox: 4 objects with skeletal sockets: the sword, the gun, the baton, the lightsaber; 1 object with mesh socket: the book
Freak’n lightsaber cause May 4th (latency test)
Improved quit platform
Removed matinee / sequencer platform because there are quite the same, and only way to avoid glitches/drop in FPS is to move the pawn together with other objects in matinee itself
Lot of small fixes
More infos (found in the docs):
The vehicle
In settings, select Menu buttons=1 (Start Machine). You have to put your right hand on the black handles and start it with the right menu button. Joyride with the left trackpad. Off with the left menu button. Yes, the vehicle is always at the origin (center) of your playground. It’ll fix that soon with some transforms wizardry.
The freak’n lightsaber
Hey, it’s May 4th. Push right menu button for blade on/off. Yes, the line trace (blade) is lagging behind the saber and shows which kind of lag could be observed without the plugin. ’s plugin is that good refers to his docs for more infos. You can make a nicer lightsaber by turning off the trace and replace it with mesh/particles within the lightsaber’s blueprints. And glows. And wooosh. And **.
**
Grab function (right hand only for now)
You will find one the one drive both file with/without plugin. If you download without the plugin, be sure to put ’s plugin in the plugin folder before start.
Based on ’s plugin found at https://bitbucket.org//ue4-vr-grippable-motion-controller-plugin/overview . Please go there for in deep informations. For now, you can grab/drop with the trigger whether with posed skeletal sockets, with simple mesh sockets. By default it will grab at object pivot origin. You can also apply transforms to put the object at the right place. @PenguinTD is right it will become soon like a meatball spaghetti. We should maybe coordinate soon to clean/optimize/streamline everything.
As per roadmap, I’ll add soon more hand poses + left hand + grabbing functions for both hands. There is also some validity check to add here and there, notably in the destroy particles following teleport method 1. Next iteration.
Its looking great, though Im a bit confused regarding the making objects grab-able part! Do you mind going into a bit more detail on that? A big thanks, this is gonna be awesome!
I dont understand this part “All actors to be gripped currently MUST have a UPrimitiveComponent derived component as the ROOT component (otherwise it will return false as it doesn’t know what to grip or simulate).”
Honestly im not really sure what a UPrimitiveComponent derived component is or how you´d make it/aquire it so the explanation is not quite noob-proof yet! I tried to make a blueprint using the hat in the scene and giving the root hat mesh one of those socket things as the book and other things have with no success. Im sure youre turning your heads back and forth slowly reading this!
I wish I could buy drinks for @Proteus@PenguinTD @ and everyone else that has so far contributed. This is phenomenal stuff and exactly what I have been looking for. This will be huge help to anyone who is trying to get up and running quickly with VR development on the VIVE/room scale. I tried it out and it is a fantastic baseline.
@chille9 There’s no shame at being confused with Unreal. Everyone is here to learn, and UE4 is not the simplest thing on earth. The goal of such project is for one part having a Vive-compatible pawn to drop in our games/exp, and also to learn by taking apart the blueprints and understanding each function.
The project has 2 different kind of grabbed objects. The first 3 ones are grabbed via skeletal socket to have a more elegant grip into the (arthritic?) hand. The book illustrates socket mesh. If you enables nothing, it will be pivot against pivot.
I think the difficulty of this one is that you have to identify at start (look at the construction script in Vive_pawn) which objects are “grabbable” by putting/extracting them in a matrix (array).
My first attempts were via the level blueprints (still found on the bottom). There, you don’t need this step as you can only drag and drop the object to grab. However, it’s not the way to go so I’ve abandoned these nodes but they are still usable if you connect them.
Finally, the grabbing nodes found in the Vive_pawn are far from elegant and I’ll rework them, remove these nasty bools and increasing the recourse to arrays.
Anyway, I’ll do a very simple / ELI5 tutorial tomorrow for the grab function you’ll have everything you need to grab objects you want in 30 secs.
“UPrimitiveComponent” : Also @chille9 just take any mesh, right click “Make a bluprint with this”, enable BlockAllDynamic in the mesh and that’s it. Add sockets if you need it. The rest is in the Vive_pawn BP.
Good new, I think I finished some pretty basic and easy to follow menu->assign action to button(track pad or other). It worked like this.
1.press a button(could be anything really) to enable menu, which brings the trigger volume to your current controller location and enable floating menu text to choose which action you want to assign to track pad
2. rotate your wrist to switch to different action
3. pull your controller off the trigger volume, menu text and volume would disappear, and action is assigned track pad button now for this controller.
Bonus, you can switch on both trigger menu at the same time. You can maybe modify the trigger volume so it always exist or using some other action(eg. reach back of your head) to show it.
This also offer some simple mechanism to mutually exclusive actions(designer choices), so you can never assign teleport to both hand.
ToDo? Need to test it further and see if this system are safe in multiple situation. (ie. no glitch when you enable both controller menu and assign actual different actions to it. )
I think if you assign teleport, hold the trackpad button, and then use menu to assign teleport to a different controller, and release at the same time, it might cause glitch.
I don’t know, pretty tough to pull it off “at the same time”, so kinda have to test different situations.
And the floating text menu(a TextRenderComponent) could get blocked by controller mesh, maybe there is a way to always render it in front of mesh??
I’ll see if I can record a video tomorrow as it’s quite late here.
You really don’t need to keep an array of “Grabbable” objects, why don’t you just implement an interface like you had before and check if the object inherits it when attempting to grab? If it does then you grab, if it doesn’t then you don’t grab, this would also let you call an interface function such as “PickedUp”/“Dropped” on the actor to notify it of what is happening. Then you could just create a child BP of both skeletal mesh actor and static mesh actor (PickableSkeletalMesh / PickableStaticMesh actors) and give them that interface.
With an interface you can even have events like “HasGrips” and “GetGripClosestTo” and things like that instead of trying to manually store and set socket names. Also StaticMeshes can also have sockets assigned to them.
For my test bed I had all of my grip sockets start with VRGrip, the grip function calls “GetClosestGripSocket” on the interface, the actor goes through them all that start with VRGrip and grabs the one closest to the given point and returns it. If the socket is within a snap distance then the grab function will use the socket as a snap point, if it isn’t or there wasn’t a socket then it just grabs off of the location it is touching the actor at.
A UPrimitiveComponent is an actor component that has geometry of some sort, a Mesh, a shape ect ect, just don’t have a scene node be the root currently. I could iterate over child components to the root and work off of them but then I run into cases where it might have multiple primitive components attached to the root and it wouldn’t know what to do.
I have a pretty good list that I already created of features and suggestions for SteamVR/Roomscale based on other VR experiences, games and discussions. Shall I just list it out so that we can pick and choose? Don’t want to slow down your momentum.
You guys already have a lot of the needed baseline features that people will be able to utilize right away in this template. We have benefited greatly so far from what you created in such a short amount of time. Coming from a popular game mod from many moons ago it is great to see other devs jumping in to help out.
The following list leans more towards a SteamVR playroom feature set with various options rather than a baseline template. So some of it of course is out of scope for now but if a lot of what is here was implemented then it would be a significant additional toolset for people to work from. It is an edited down list based on other VR experiences, games and discussions and something that I have been putting together over time. If you all think it is a useful list I could apply it to a Trello board it voted on for prioritization.
Interactions
Lever/switch mechanic
Door (for cabinet or room) user can open and close by handle
Drawer user can slide open and close by handle
Turntable or conveyer belt with interactive forward and reverse buttons/lever
Enhancement - Quick fade out hand on object pickup interaction. Quick fade back when letting go
Function to freeze objects in place - very useful and immersive for inspecting objects that are closer than your hand. More for a seated experience but could still be useful in room scale.
Enhancement - Index finger for activating or touching. Middle finger for gripping.
Traverse
Blink locomotion
Parabolic curve locomotion (I believe this is r1.12 Curved teleportation trace line?)
Portaling locomotion
Weapons
Bow & arrow
Sling Shot
Cannon
Grenade pull pin weapon with time based report
C4 or Dynamite with plunger
Reload ammo system
Targets
Simple static targets that show decal hits or sparks
@ Yes I find it strange myself that I debuted with interfaces than switched to arrays. I wanted to define a list of grabbable items at level start but in afterthought implementing interfaces is more flexible, specially when considering closest hand and sockets. I’m already 50% on the way of implementing an interface-based grab system. @JHalper thanks for the list. I see there different kind of features tackling problems of varying difficulty. What I like the most is the features directly related to the headset and the controllers, such as Toys and Weapons. Once we have established a reliable way of capturing controller world space data and attached objects (i.e. 's plugin) then lot of things are simple BP (i.e. doors, switches and drawers), or have features already found in the marketplace. Other would require sit and think (i.e. bow). I also thought porting games such as Couch Knights wouldn’t be much difficult. Globally, I think the most important thing right now is to have a reliable and easy-to-setup template with all the basic features, which should be within 4-6 weeks. After that, that would be a very interesting idea to setup a Trello I think!
Totally agreed on the focus of a reliable and easy-to-setup template and you guys are doing great. If it can be in 4 to 6 weeks that would be phenomenal. That timeframe will go by real quick and based on how much progress made so far I believe you guys can do it.
This starter list could be broken down into BP, port or “start from scratch” groups along with the prioritization. If people are really interested in some items more than others then devs who want to participate could start on simple visual or code/bp assets. That way they are ready to go when the time comes to implement on the baseline template. I could personally handle some of the possible low hanging fruit items since it will benefit titles I am working on in the short term and long run.
Hey guys, everything seems to be working well for me, in my game. The only issue I have is that my chaperon seems to display the boundaries quite far away from the actual limits. So I can barely move around without the grid and blue camera coming up. It’s not like this any of the VR games I’m playing.
Any ideas? Is there a setting somewhere to adjust the distance from the actual limit, that it displays?
Hi, thank you so much for this. It’s been very helpful.
One thing though.
The controllers are by default too big. I set the scale to 0.9 and they match with the scale when I bring up the steam menu.
They are not aligned correctly either, so I move them -2 on the X axis, and -1.5 on the Z axis. This makes them line up much better compared to the steam menu controllers.
I tried to make a blueprint using the hat in the scene and giving the root hat mesh one of those socket things as the book and other things have with no success. Im sure youre turning your heads back and forth slowly reading this!