Thanks guys, this looks incredibly useful. Very glad I found this thread.
I’m an experienced C++ developer, but new to Unreal, and very keen to start messing around with VR stuff.
This looks like exactly the head-start I need.
(Haven’t been able to try it for real yet - although Vive arrived yesterday (Yay), I didn’t realise I was going to need a Display Port cable. (Boo)).
Ok finally got a chance to test the coding I did today, I am successfully getting OnHit events while holding items now. It needs some clean up still but the results are promising. I made a subclass of the motion controller that hijacks the oncomponenttick where it gets the new controller position and performs sweep tests on the root components of all actors that are attached to the controller or a child component to the controller when the motion controller moves.
Now for the issue, what to do when it does collide? Currently it will be generating a hit event for every frame it is contacting the object. How it works normally is that it will back the object out of intersecting and leave it there as its new position, I would have to decouple from the motion controller at that point to do that.
I would like some input before I choose something, I could even leave it as is and you could have it spawn a physics handle when colliding with an object so it offsets correctly and then re-attach itself when the collision ends.
Overlapping works as you would expect without any modifications, in fact if you use begin overlap and end overlap as your collision indicators then you don’t need the OnHit at all.
A test having them simulate / un simulate with every hit event. Obviously it is buggy since it is firing them every frame at the moment and it will do both multiple times for each swing.
https://.com/watch?v=YjjxU7XWCYA
Nice test ! Looks great. @Proteus, I wouldn’t worry about iterating too rapidly. I’m finding this super easy to swap out, and once we’ve got basic teleport and grab we’re in business. Any chance of getting a hold of a 1.7 with grab functionality? My virtual floor is littered with cool stuff that I’m currently only able to prod at…
I realized after I made that video that it looks bad because of setting the simulating state for every hit event, it will continue flipping the boolean over and over until contact is lost so it looks like it is unreliable as the end result of simulating or not is random…oops. Just setting them once to simulate and then interacting with them has no actual issues currently, I just need to think if anything else should be or if it is good as is.
If it leave it as is it would be up to the user to determine what happens when contact happens, I guess I could set some sort of “OnHitStart” and “OnHitEnd” Events that detect when it is no longer colliding for a frame and fire the end event? I would assume that would be more useful than a frame by frame hit notice.
Also with physics substepping and a custom physics handle where I removed interpolation for the movement I might be able to get the physics handle to perform as required as well, I’ll check tonight, the downside is that substepping has a performance impact.
Question, is it too resource intensive to use Set location in a tick event to keep the object “held”? That way you wouldn’t actually be attaching?
Collision issues in Unreal are the biggest problem for UE4 VR developers I think right now. Like, I am not even sure how you would make a baseball bat hit a baseball with current implementation.
@ thank you very much on the input about the picking up function. I think you’re very close to have solve it. @bitcloud1 I’m eager as everybody to have a minimal working template. Right now I stopped working on grabing function and try to solve the frame skip on the moving platform. I tried binding event, playing with framerate and delta time, the problem still there. It’s pretty important since it would enable being transported on vehicles and platforms. I’ve depleted pretty much my bag of ideas for this one… @weibo.xie Your problem is that you treated the template as a standard project and opened it directly or through the launcher. These are not project files, they are a template. Just follow the procedure in my first post, everything will then be allright.
Confident to implement at least a reliable grabbing function and fade out camera when entering no teleport zone in 1.7 next week.
So, how I am attempting the hover junkers method was to actually make the platform an Actor that can accept control from the player character. Basically when on the platform the player wasd controls get interrupted and sent to the platform which has the floating platform controller component thing. I am currently developing for VR blind right now (Vive is not here yet) so maybe this is only an issue while “In VR”.
Now, platforms external from the character (like an elevator) I am not really sure what the problem would be. Doesn’t the character movement component already do moving platforms? Can you not use it with VR? I assumed you could since there is a Vive video floating around that shows WASD directional movement and roomscale at the same time.
Edit: Here is the video I spoke of…
DI60cz-30yc
I have also developed a directional teleportation system that merges WASD movement and Teleportion by using raycasting.
While that works, you can still get motion disassociation when doing it during a tick (wobbling), should probably derive off of the motion controllers component tick instead to keep them sync’d.
IE: Every time the motion controller ticks and updates its location you update all attached actors as well to match the new location / orientation. You would have to set a tick prerequisite like in AttachTo though.
I have that as a 4th grip attempt somewhere, I may go back to it. I will have a lot more time this weekend to sort through things.
Yup, I forgot about that, it does a late positional update on the render thread. Would be really painful to get that working with non attached components.
@OneShotGG That’s an interesting I didn’t think of that. So I’m pretty confident that this method would work for vehicles like Hover Junkers and in the video. In fact I had the idea of implementing as optional/additional means of transportation the same thing as in the video this week in 1.7. However this would imply adding movementscomponents to the pawn. Of course, this kind of moving platform could also be possessed and controlled by AI. Well, our little toybox could become a joyful playground with the addition of a mock HJ vehicle!
However, the doesn’t resolve the problem for external actors such as these 2 moving platforms. It seems that Unreal has a hard time syncing the pawn’s sceneroot and platform mesh worldlocations. Not sure if the solution is in the BP.
Maybe 1 thing I could try is move both the platform and the pawn together in matinee. 'll try that morrow.
Well, if I count all public and private attempts communicated to me it seems the grabing thing, which I thought resolving in 2 days, will have taken much man-hour-brain than estimated. thanks all
H there, i have a question, i’m not into programming, 3d modeller here so i had no luck to compile myself the VR edition of Unreal (still trying)
With your template can i use the standard Unreal Editor with my HTC Vive?
Thank you
Hi Devs, I tried to swap the Vive-Pawn-Controllers to the integrated Leap-Motion Plugin. Changed the Pawn-Class to Leap (under Game-Mode) but I cant get the Leap to work? What do I have to do to disable the Vive-Controller?
@Nedo the template is compatible with version 4.11.2. Everything related to SteamVR is in the folder Vive, some options in the Project Settings and some functions in the level blueprint. The rest is the blank BP template @AlexKlwn The leap character is vastly different from the simple Vive_pawn. From what I know it’s still customized for the DK2. I can find my DK2 somewhere in a box and try it tonight it should be plug and play. Quoting @acolgan " There are two important differences between the Rift and Vive to keep in mind. The first is the offset. On the Oculus Rift, the distance between the controller and your eyes is about 8 cm. The virtual controller within the game engine needs to have the same offset from the VR cameras. Since the Vive is slightly bulkier, this offset should be increased to 9.5 cm. The second difference is a little trickier – image passthrough. The plugin currently delivers infrared images with a field-of-view (FOV) crop fixed to Rift DK2. Because the Vive FOV is different, augmented reality projects will not work correctly on the Vive. This will be resolved in a future release so that passthrough will be HMD-agnostic." I’ve messed around a bit with the leap, but so much things to do I think that unless someone gracefully develop it, I’m confident that @getnamo will provide us with a leap-vive pawn once he received his.
@Proteus Okay thank you I have managed to get it to work now but the HMD view is way to high, when I put on the Vive I feel like im 3m tall, how can I change the HMD View height?
@AlexKlwn It depends on how you setup your pawn, e.g. if you added vive functionalities to leap_character or you added leap to the vive pawn. Does camera follos hmd checked? did you use a character or a pawn? All these will inflluence the view height. It’s difficult to guess without more infos.