Not sure if this is a repost in this thread but Epic has recognized the HTC Vive HMD and Controller tracking issues as indicated in this thread:
Not sure that is fixable (the controller trace), the low latency update is taken right before rendering in the rendering thread to re-orientate the controller visually. Traces by design need to be in the game thread and long before that so that game logic can be ran.
They could probably get a “better” result by creating a way of re-sampling the controller position just prior to a trace but it would never be perfect as it could re-position slightly before the render. I don’t think that is is a “bug”, when the trace happens that is where the controller is at that time (+/- a little) and it is in a different location by the time it is rendered.
The real fix for it would be a much higher update (tick / FPS) rate but that brings out a whole bunch of other issues like performance degradation.
The reason it is located “correctly” when turning off the late update is because the engine then no longer late samples the position so it is using the same value to render as to trace.
Think of it this way, if you are moving the controller at 10 feet per second and are running at 90 fps, then you are sampling roughly every 1.3" of movement on the game thread. That is a lot of movement missed for a relatively slow movement speed.
Excited to see the grabbing explanation or I´ll wait for 1.9 and I hope to play around with grabbing in that!
Version 1.9 – UE4.11.2: May 12, 2016
- [FIXED] Controllers size and location
- [FIXED] Grab function
- [FIXED] Ghost Mode
- [FIXED] Performance issue with Chaperone enabled
- [FIXED] Vehicle location while turned on
- [FIXED] Platform exit
- [FIXED] Destroy particles issues following teleportation
- [FIXED] Reduction of trackpad sphere size and opacity
New features
- Vive Pawn Head
- Controllers skins
- Controllers opacity selection
- New lightsaber
- Mirror
- Select alternate meshes for controllers
- New documentation
Now the instructions are in a pdf file, it’s easier to maintain everything in one place and easier for users to follow/print instructions. Guide in the onedrive, or direct link at Microsoft OneDrive - Access files anywhere. Create docs with free Office Online.
Thank you very much @PenguinTD I didn’t have the time to integrate your features in 1.9 but I’m working on it as soon as tomorrow for the next iteration.
will follow tomorrow. Have fun!
Wow! Thank you so much! I will test it as soon as I can!
This is looking awesome and working pretty smoothly! Thanks for the lovely work, I really want to not have that capsule collision invisible upon trigger being pressed though! Is there any fast way to have it be invisible?
Edit: Found the node in the grabbing section of the VivePawn and changed the debug drawing option to none! Awesome.
Wow. I get busy for a few days and you guys like double the features. It’s amazing. Thank you for all of your hard work!
Has anyone tried tackling the possibility of using math to figure out a rough “chest direction”?
Right now i am using Vectors from both controllers and averaging them before comparing with the last “forward vector”. If the abs angle is above a certain amount I rotate the “body” of the character.
Curious if someone has a better or more accurate solution. HTC and Valve really need to have at least a third tracker for chest/back in CV2.
Fantastic update. I migrated over to my game project and everything works great!
What was the issue and the fix? Always interested in things to watch out for for performance.
@muchcharles Spawning particles at chaperones was put on a loop and hitted the performance. Now it’s doing it only on one tick. However if you change place the chaperones won’t follow. If you want to spawn chaperones elsewhere just map it to a button.
Should probably do chaperon differently than corner particles. Like attaching components to the actor to represent it or something.
Hey guys, I just updated to this new version 1.9 and now my pawn and controllers start about a foot off the floor. All other games are fine.
Also I’m not a fan of the new red ‘teleport beam’ how can I get rid of this?
Thanks
@ExtinctGames go to Vive_Pawn Event Graph, in Teleport Method 1 nodes, and set “None” to Draw Debug Type into LineTraceByChannel for each hands. As chille9 discovered it, I unintentionally also left a debug sphere on the right grabbing hand. You can disable it the same way in “Determine if can pick up” nodes. I also forgot to set a power on/off button on the lightsaber if picked up with the left hand.
Thank you so much for the effort and for sharing in the community! Is there anyway can I use the grab function on a destructible mesh (pick up glass, throw it then have it shatter)
Thanks!
I’m not seeing that anywhere in the Teleport(method #1) nodes?
Also any idea as to why my pawn and controllers start off the floor after this update?
and one other question… for some reason I can’t teleport onto the stairs that I have in my game. My regular controlled actor can walk up them just fine, but when I try to teleport up them using the Vive Pawn I’m unable to move there.
@ ExtinctGames
- There are the nodes in question. They are at the bottom of the Vive_Pawn Event graph, red circles.
2)As for the pawn does it start at floor level even if playerstart is upstairs or your camera is at floor level? If you always spawn at floor level, be sure that Planar Movement/Snap to Plane at Start is unchecked (in FloatingPawnMovement in Vive_Pawn). But if you just fired the template without alteration everything should be fine?
3)I already answered the same question 2 weeks ago, so I’ll put it as an option and explain it in the guide:
1)Essentially, the pawn will teleport on mesh following their collision capsule. Look at the stairs:
The collision boxes are purple.
-
When tracing the possible teleport point (the red dot), the Break hit result/normal will compute the normal of the point on which we want to teleport. The normal will be between 0 (90 degrees to the floor) and 1 (0 degrees, perfecly aligned with the floor). You can test it by doing a print string with a one frame line trace. It will tell you a z value betwen 0 and 1. Test it on the sphere will you see all values (tangents) go from 0 to 1.
-
Anyway, I put a safeguard (green circle in 1st picture) in the fonction of .90. What does it mean? It means that you can only teleport on surfaces with a normal of at least 9%*1 normal, so surfaces who are aligned within 0 to 9 degrees of your floor angle. Without this, you would teleport on blocking volumes and on walls. However, you just have to relax this value, let’s say 0.5 rather than 0.9, and you should be fine teleporting on uneven surfaces. However before this check you stairs collision boxes to be sure theyr are ok
Thanks everybody to bring attention to any bugs. There is my roadmap for next iteration for now:
Know bugs (will be fixed in 1.10)
- Lightsaber: on/off left hand; glowing light same color as blade
- Grab function: drop problem when both hands are grabbing objects at the same time
Next new features of 1.10:
- Teleport/Exit matinee platform
- Teleport: Adjustable “safe” value to teleport on uneven surfaces
- Penguin’s TD menus
- Rotate playground in teleportation
- Vehicle: Vehicle will rotate with controller input
- Chaperone bounds will spawn meshes instead of particles, retriggerable
As of options in the settings, they will eventually be transfered in an in-game 3D menu so everything will be simpler.
Loving this tool, cant believe how far it has come but I am having a problem with 1.9.
Installed 1.9 in the Templates directory however when I go to start a new project it tells me “This project requires the GameAnalytics plugin. Would you like to download it from the Marketplace?” When I say yes it takes me to a missing page?
Any help would be appreciated. (Just said no and it looks like the project is launching. Any issues I should be aware of?)