This is an interesting question but the simple answer is yes, the longer answer is kind of.
The philosophy of this project stems from the fact that a VR Template by its nature doesn’t make sense. As VR isn’t really a genre of games (say like a FPS or Racing Game) you can’t distil VR to a template-able set of functionality as it can exist in literally any genre you can think of. This means that any VR Template is bound to either be so restricted that it doesn’t provide too much use for the wide array of VR devs out there or become so bloated that it becomes too cumbersome for any VR dev to use.
This is why I went with the idea of a set of content examples which allows me to add any functionality I need later on without bloating any of the other examples. This means however, that when designing the examples I needed to make them extremely modular so that when you want to use any of the examples in your project you simply migrate the specific functionality you need out of the content examples and you won’t get any of the things you don’t need.
So this is kind of how I anticipated people would use the project if they wanted to use the examples in their own projects (migrating the things they needed and ignoring the rest), of course I also wanted it to be a learning resource as well
Hey if we had already started implementing your previous VR Content examples files into our own project a while back and now want to upgrade to your latest version what is the best way to do this?
Hmm it depends on which version you started with, in the later versions I pretty much redid from scratch the motion controller interaction I also renamed all the assets to be inline with Allars naming convention, so that kind of screwed any sort of backwards compatibility, sorry, I probably should have used some sort of semantic versioning to warn people but from now I think I’ve finally settled at a way of doing interaction that works for everything I can think of
I’m actively thinking about it, I’m currently making a MP game with a friend and there are a lot of optimisations that can be done in c++ so a blueprint only version like the content examples may not be optimal, I also don’t want to clutter the functions for those that only want a single player experience but I guess we’ll see how bad it gets when I implement it
I’ve been following along this thread for a while and really enjoy the progress you make. Really love that solution you made for object interaction. I was talking with some guys on Discord/Unreal Slackers yesterday about interaction methods and your example came up. I’ve noticed however that if i put an object on top of a held object, it will slide off (behave as if it has no friction). I was suggested to implement a custom friction model for the top object, but was wondering if you had a solution coming for this before i start trying to figure that stuff out?
Again, thanks for sharing your work. Very inspirrational and great work!
I hadn’t noticed this, it looks like that physically simulated objects that are attached to kinematic objects don’t apply friction for some reason (I looked into the code a little but the comments just seemed to say use constraints instead) so that’s what I did, .1
Constraints lose the ability for collision between two held objects but it keeps the collision with static meshes
Here’s an example with constraints and friction:
https://.com/watch?v=9vYdB6W6RGo
Hey , just a question about your book; are you going to be explaining the concepts and mathematics behind these blueprint examples in depth? Or will it be more targeted at C++ devs?
Getting back to you for a weird behaviour I get with the door BP…
So for the purpose of our projects, I modified your initial blueprint and added a few features to edit the door and handle visual parameters at will, aswell as having complex doors (ie double doors).
Problem is, the doors sometimes resets to the min/max yaw angles when fully opening/closing them and pressing the grip button. (ie link below)
Hmm I can’t replicate it on my end, but I remember running into a similar problem before, I think I fixed it by replacing my clamp floats in the physics sim with clamp angle. In your event graph does your physics sim look like this?
Sorry for the delay, caught up with work, I believe I’ve got a fix, in the door physics section where it decides when to call StopSimulateDoorPhysics you will just need to add a couple more conditions to the or condition.
It just checks to see if it’s over the max or below the min, this is just because if you grabbed the door with enough velocity it wouldn’t register that it had hit the end, I also increased the tolerance on the nearly equal conditions
i’ve been absolutely loving your book since it finally arrived on Tuesday. A mandatory purchase for any UE VR enthusiasts. It works through the many interactions seen in the content examples but has so much more. An analysis of the VR locomotion techniques, tutorials to create projects for the main VR devices (including GearVR), a discussion on how to optimize content for VR and more. you’re going down in history as one of the key figures in the VR Renaissance. Great book!
Totally agree, mine did not arrive yet, but I purchased the Amazon e-book too, i did not cancelled the physical book because I find it very valuable so having it in both format is very helpful.
I just miss one thing, you cove the GearVR setup, but you did not cover a Cardboard/Daydream setup, and this could be very welcome… maybe an update for the e-version?
I picked up the e-book version from Amazon. The book is quite comprehensive and is great for anyone starting out in VR, or anyone more experienced and just looking to fill in some knowledge gaps. Definitely worth a read.
