VR Expansion Plugin

[Emidee_FC]

Hello mordentral,

we started to use your plugin to develop a multiplayer VR game and even if we are still early in the development, I would like to thank you for the amazing work you put in the plugin.

I have one question though:

I created a character class which inherits from AVRCharacter and I updated your code to allow me to create a skeletal mesh, because we'd like to have a 3d rendering of the other players.
I attached that skeletal mesh to the VRRootReference component, and added a negative vertical offset to it so that the feet are at the bottom of the capsule.

The issue I face right now (using an oculus touch) is when I see in game another character, the capsule is correctly grounded, but the skeletal mesh is floating in the air.

Would you have any idea of what could be going on there?

Thanks in advance

[thelazylion]

Its a side effect of how BP handles overriding default base classes, its why I made a seperate VRRootReference variable when I overrode the capsule component to use as a direct reference. Casting to a grippable mesh and storing the pointer will work just fine, its just the BP graph not understanding class substitution fully.

Thanks for confirming that..

Also not sure if this is a bug on my end or in the plugin, but on the new 4.25, for some reason connecting clients cannot use any form of mouse input.
This only happens after "on possess" is called .. If the client joins as their own pawn it works fine..

But if they spawn clean, as just a controller, and spawn an actor to posses, then mouse input is permanently broken. At some point with enough fiddling, I managed to get a crash that pointed to this line, which seems relevant (120) VRBaseCharacter.cpp

I'm gonna keep tinkering for now..
Thanks again, and anything that comes to mind is appreciated.

[Fele]

I am using the set tracking origin -> Stage (Centered Around Play Area)" which works perfectly to align a my ground plane to a real world play area with the exact dimensions - with oculus quest.

This function gets called when entering the game and the players VR position matches the exact location in real world.

However, with the VR expansion character I noticed an offset after stepping out of the play area and re-entering it an so far the only way is to restart the game. (The boundary itself still matches perfectly but the level kind of drifted...)

This did not happen with the UE standard pawn and I was wondering if this might be related to the way of how the VR pawn actually moves while the standard pawn only moves it's components?

Is there a way to prevent this offset from happening?
Looks like the VR pawn keeps moving for a short distance before stopping / "leaving the game" and on re-entering the position kind of continues but with an offset...

[CokeKuma]

In tests those guys were hiding invisible colliding bodies that are constrained to the controllers, then offsetting the pawn based on how far away the body is from its target location on collision, that is probably the easiest method to conceptualize how to go about doing it, then you can move to more stable iterations.

Its not a difficult concept to achieve if you think about it. Can do it with locking on to surfaces and reading positional differences as well (their hands lock on to the top of the surface when starting to climb, then they read the positional difference in that video and offset the player, the arms are not physics driven), or running fully simulated arms and reading wrist to controller differences, or for that matter, from held objects being stuck on things and reading where the hand is and where it should be.

If you really wanted to get involved you could also make the player based on an actually simulating body that is forced upright and use constraints from the hands to move it around directly when against objects, somewhat like lone echo.

Also the plugin doesn't support "physics body / gravity", its a character controller, all interactions are faked. Its not actually simulating on the physics scene, just being moved around in it as a kinematic actor.

The answer was very helpful. Some of the features shown in the video were reproduced.
But one more feature seems to be needed. Can gravity simply be added to the climbing mode provided by the plugin?

hi. mordentral.

Climbing function through hand succeeded in producing results above the intended level. But the problem is that the object, not the hand, is physics handling. The hand and object have different criteria to trigger on, and in the case of an object, the direction in which climbings should be allowed varies depending on the shape it occurs. Therefore, a very diverse number of cases must be considered. So I try to find a simpler solution other than this one, but I don't have a good idea. What do you think?

And how do I apply gravity in climbing mode? I tried to modify the code, but only the result of zero gravity came out.

[Antonyvw]

I'm guessing that using the VR Expansion plugin is not really for beginners. I have looked at some of the videos, and quite frankly I'm confused. I managed to follow the first one, (after a lot of head scratching with why my copy of Visual Studio wouldn't work), but then video 2 onwards were clearly meant for someone with a working knowledge of the system. For example in video 2. "4.24 Input changes", I was lost as soon as he said he migrated things from his original project to the demo. I tried to copy that, it copied the folders over but not the contents, even if I selected the contents separately. (I have migrated things before but this foxed me). For me, as a beginner, I would have put locomotion before gripping, simply so I could walk up to the objects first. I haven't watched all the videos yet but I have seen nothing that explains to me how to prevent my character walking through walls, collision. A lot of info needed for a beginner was skipped over, this I presume is because, as I said its not really for a beginner.
Don't get me wrong, I'm not knocking what the plugin can do. I can see from the demo what it can achieve but trying to understand how to add those functions to my own scene/character is another matter. All I would like to achieve at the present time is to enable my character to move around, interact with things (like pick up a lamp), and NOT walk through walls. I had the plugin recommended to me because it could achieve those things, but as I said, I'm a beginner, and this really is way over my head.
Lol. I guess I still need my hand holding while I learn. Eventually this will all make sense to me and I will look back and say, "why was this a problem?", but until then, I guess Im not going to to solve how to not walk through walls or climb stairs. Sorry for my ramblings. I'm just frustrated I cant achieve what I thought should be an easy task

[Fele]

I am using the set tracking origin -> Stage (Centered Around Play Area)" which works perfectly to align a my ground plane to a real world play area with the exact dimensions - with oculus quest.

This function gets called when entering the game and the players VR position matches the exact location in real world.

However, with the VR expansion character I noticed an offset after stepping out of the play area and re-entering it an so far the only way is to restart the game. (The boundary itself still matches perfectly but the level kind of drifted...)

This did not happen with the UE standard pawn and I was wondering if this might be related to the way of how the VR pawn actually moves while the standard pawn only moves it's components?

Is there a way to prevent this offset from happening?
Looks like the VR pawn keeps moving for a short distance before stopping / "leaving the game" and on re-entering the position kind of continues but with an offset...

ok I think I found the issue but I am not sure why this happens.

In 3d, my play area is about 20cm elevated and I set up a plane to prevent the player actor from falling down. I am not 100% sure but it looks like the VR expansion character gets stuck for a moment while returning to the play area and this small "hang" generates the offset to previously matched play area. I removed the elevation and after the problem disappeared...

[Magneto]

I'm guessing that using the VR Expansion plugin is not really for beginners. I have looked at some of the videos, and quite frankly I'm confused. I managed to follow the first one, (after a lot of head scratching with why my copy of Visual Studio wouldn't work), but then video 2 onwards were clearly meant for someone with a working knowledge of the system. For example in video 2. "4.24 Input changes", I was lost as soon as he said he migrated things from his original project to the demo. I tried to copy that, it copied the folders over but not the contents, even if I selected the contents separately. (I have migrated things before but this foxed me). For me, as a beginner, I would have put locomotion before gripping, simply so I could walk up to the objects first. I haven't watched all the videos yet but I have seen nothing that explains to me how to prevent my character walking through walls, collision. A lot of info needed for a beginner was skipped over, this I presume is because, as I said its not really for a beginner.
Don't get me wrong, I'm not knocking what the plugin can do. I can see from the demo what it can achieve but trying to understand how to add those functions to my own scene/character is another matter. All I would like to achieve at the present time is to enable my character to move around, interact with things (like pick up a lamp), and NOT walk through walls. I had the plugin recommended to me because it could achieve those things, but as I said, I'm a beginner, and this really is way over my head.
Lol. I guess I still need my hand holding while I learn. Eventually this will all make sense to me and I will look back and say, "why was this a problem?", but until then, I guess Im not going to to solve how to not walk through walls or climb stairs. Sorry for my ramblings. I'm just frustrated I cant achieve what I thought should be an easy task

Yeah this is the thing thats a little bit of a let down with this great vr expansion it doesn't have a plug and play mode or simple switching on and off features. Id really like to now see a half life alyx fps ready type template we can all easily use to get going without the complexity or needing to go though many guides which there are few of with this one anyway.

[mordentral]

Hello mordentral,

we started to use your plugin to develop a multiplayer VR game and even if we are still early in the development, I would like to thank you for the amazing work you put in the plugin.

I have one question though:

I created a character class which inherits from AVRCharacter and I updated your code to allow me to create a skeletal mesh, because we'd like to have a 3d rendering of the other players.
I attached that skeletal mesh to the VRRootReference component, and added a negative vertical offset to it so that the feet are at the bottom of the capsule.

The issue I face right now (using an oculus touch) is when I see in game another character, the capsule is correctly grounded, but the skeletal mesh is floating in the air.

Would you have any idea of what could be going on there?

Thanks in advance

The VRCharacter has its zero point at the floor, unlike normal characters which have their feet at waist height. This is done because it makes more sense to handle roomscale that way, and because it makes more sense in general with VR. Just offset your mesh, also typically your mesh should be attached to the ParentRelativeComponent with it set to floor mode instead of the root capsule directly.

[mordentral]

Thanks for confirming that..

Also not sure if this is a bug on my end or in the plugin, but on the new 4.25, for some reason connecting clients cannot use any form of mouse input.
This only happens after "on possess" is called .. If the client joins as their own pawn it works fine..

But if they spawn clean, as just a controller, and spawn an actor to posses, then mouse input is permanently broken. At some point with enough fiddling, I managed to get a crash that pointed to this line, which seems relevant (120) VRBaseCharacter.cpp

I'm gonna keep tinkering for now..
Thanks again, and anything that comes to mind is appreciated.

Shouldn't have anything to do with the plugin unless I missed a super call somewhere, and then you would never have mouse input at all.

That line in VRBaseCharacter is unrelated as it is just casting the character type for future reference, though I would like a copy of that crash report if you get it again, cast shouldn't crash there.

[mordentral]

I am using the set tracking origin -> Stage (Centered Around Play Area)" which works perfectly to align a my ground plane to a real world play area with the exact dimensions - with oculus quest.

This function gets called when entering the game and the players VR position matches the exact location in real world.

However, with the VR expansion character I noticed an offset after stepping out of the play area and re-entering it an so far the only way is to restart the game. (The boundary itself still matches perfectly but the level kind of drifted...)

This did not happen with the UE standard pawn and I was wondering if this might be related to the way of how the VR pawn actually moves while the standard pawn only moves it's components?

Is there a way to prevent this offset from happening?
Looks like the VR pawn keeps moving for a short distance before stopping / "leaving the game" and on re-entering the position kind of continues but with an offset...

Don't have the character movement component in "physwalking" or any mode that allows push back. The way it handles movement with CMC is it rewinds the HMD movements and plays them back during the actual walking cycle, leaving tracking entirely can offset the character since it will register the loss of tracking as invalid movement inputs and freeze the pawn for that duration.

Having the character in movement mode "none" will keep it locked 1:1 with the real world. Though at that point there isn't much point to using the VRCharacter itself and a basic pawn with the grip controllers would do just as well.

[mordentral]

hi. mordentral.

Climbing function through hand succeeded in producing results above the intended level. But the problem is that the object, not the hand, is physics handling. The hand and object have different criteria to trigger on, and in the case of an object, the direction in which climbings should be allowed varies depending on the shape it occurs. Therefore, a very diverse number of cases must be considered. So I try to find a simpler solution other than this one, but I don't have a good idea. What do you think?

And how do I apply gravity in climbing mode? I tried to modify the code, but only the result of zero gravity came out.

You can manually lock the hand to the surface if you want and track the controller vs it, or use physical arms, or any other methods that you like.

As for gravity during climbing, just apply a offset with the custom movement addition as well to equal gravity. Though you have to be careful with that as it will offset your hand more and cause more of a correction the next tick, depending on how you handle the compensation logic.

[mordentral]

Yeah this is the thing thats a little bit of a let down with this great vr expansion it doesn't have a plug and play mode or simple switching on and off features. Id really like to now see a half life alyx fps ready type template we can all easily use to get going without the complexity or needing to go though many guides which there are few of with this one anyway.

You have been complaining about the same things with every single template in this engine for YEARS now. Maybe its time for you to buckle down and either really learn the engine, or start modding Alyx with their mod tools. Expecting everything to be plug and play fully complete, with brand new game features matching AAA and without any learning curve is moderately ridiculous, and rather entirely against the entire point of why I (and others with their tools) choose to make flexible systems where a lot of interactions are possible, instead of focusing on blindly recreating the FOTM game.

My goal isn't to make your games for you, it is to provide you with as many tools as I can so that making them is easier. I stay away from specific game play systems as much as possible as its limiting my work to the specific few that need them, and locking down innovation. Plug and play game systems are generally terrible, either too feature rich to handle any case (slow) or handling only one or two specific cases that the creator felt was needed (inflexible and limited).

I'm guessing that using the VR Expansion plugin is not really for beginners. I have looked at some of the videos, and quite frankly I'm confused. I managed to follow the first one, (after a lot of head scratching with why my copy of Visual Studio wouldn't work), but then video 2 onwards were clearly meant for someone with a working knowledge of the system. For example in video 2. "4.24 Input changes", I was lost as soon as he said he migrated things from his original project to the demo. I tried to copy that, it copied the folders over but not the contents, even if I selected the contents separately. (I have migrated things before but this foxed me). For me, as a beginner, I would have put locomotion before gripping, simply so I could walk up to the objects first. I haven't watched all the videos yet but I have seen nothing that explains to me how to prevent my character walking through walls, collision. A lot of info needed for a beginner was skipped over, this I presume is because, as I said its not really for a beginner.
Don't get me wrong, I'm not knocking what the plugin can do. I can see from the demo what it can achieve but trying to understand how to add those functions to my own scene/character is another matter. All I would like to achieve at the present time is to enable my character to move around, interact with things (like pick up a lamp), and NOT walk through walls. I had the plugin recommended to me because it could achieve those things, but as I said, I'm a beginner, and this really is way over my head.
Lol. I guess I still need my hand holding while I learn. Eventually this will all make sense to me and I will look back and say, "why was this a problem?", but until then, I guess Im not going to to solve how to not walk through walls or climb stairs. Sorry for my ramblings. I'm just frustrated I cant achieve what I thought should be an easy task

I take care to mention this decently often, no its not a beginners plugin, it taps into a hundred base engine classes and most parts of the engine at this point. Its to help people with advanced interactions, either as an implementation example, or as a set of tools to use. That being said, its not beginner hostile, just has a bit of a curb to step up to.

The tutorial videos were made by a community member as he himself was learning the plugin, he documented his learning process by example. The text tutorial for basic gripping on the website, using the VRCharacter as your base pawn, and adding movement input like a normal character, would be enough to get off the ground with what features you described above.

[HienNguyen27]

Yeah this is the thing thats a little bit of a let down with this great vr expansion it doesn't have a plug and play mode or simple switching on and off features. Id really like to now see a half life alyx fps ready type template we can all easily use to get going without the complexity or needing to go though many guides which there are few of with this one anyway.

I think you should hire a programer if you find it too difficult to code. The plugin itself is very good, it offers a lot of tools to help developers. You should stop complaining and focus on learning, because game development is really hard work. What's more amazing when you have a free plugin, the plugin creator is always ready to answer questions and support, and you can go to the source code to read, to learn whenever you want.

[Magneto]

You have been complaining about the same things with every single template in this engine for YEARS now. Maybe its time for you to buckle down and either really learn the engine, or start modding Alyx with their mod tools. Expecting everything to be plug and play fully complete, with brand new game features matching AAA and without any learning curve is moderately ridiculous, and rather entirely against the entire point of why I (and others with their tools) choose to make flexible systems where a lot of interactions are possible, instead of focusing on blindly recreating the FOTM game.

My goal isn't to make your games for you, it is to provide you with as many tools as I can so that making them is easier. I stay away from specific game play systems as much as possible as its limiting my work to the specific few that need them, and locking down innovation. Plug and play game systems are generally terrible, either too feature rich to handle any case (slow) or handling only one or two specific cases that the creator felt was needed (inflexible and limited).

It's because the whole point of these is to make basic game play easy and mostly ready to use otherwise it kind of defeats the point surely?

It's been done successfully before like UVRF handpresence for example so why can't you here? Sadly many templates are now unsupported with bugs and are showing their age. If instead of replying to a hundreds of questions you instead created some proper guides you might not have to waste time as you seem to with comments like these. Other contributors on the forum manage to just fine and you've had years.

I think I've been reasonable in both praising and criticizing this particular plugin and am just giving some fair feedback. Really if at the end of the day if you're so great at coding such complex features then it can't be hard to make some easy ready made modes and switches for what we're asking?

If getting an epic grant and supporting the vr community was your goal then that should include non programmers and artists as well to be fair.

I think you should hire a programer if you find it too difficult to code. The plugin itself is very good, it offers a lot of tools to help developers. You should stop complaining and focus on learning, because game development is really hard work. What's more amazing when you have a free plugin, the plugin creator is always ready to answer questions and support, and you can go to the source code to read, to learn whenever you want.

Like others I've been giving some reasonable feedback and im not a programmer nor would i hire one for little projects. If you think that's the answer then it's more a criticism on the creator not the users.

[mordentral]

It's because the whole point of these is to make basic game play easy and mostly ready to use otherwise it kind of defeats the point surely?

It's been done successfully before like UVRF handpresence for example so why can't you here? Sadly many templates are now unsupported with bugs and are showing their age. If instead of replying to a hundreds of questions you instead created some proper guides you might not have to waste time as you seem to with comments like these. Other contributors on the forum manage to just fine and you've had years.

I think I've been reasonable in both praising and criticizing this particular plugin and am just giving some fair feedback. Really if at the end of the day if you're so great at coding such complex features then it can't be hard to make some easy ready made modes and switches for what we're asking?

If getting an epic grant and supporting the vr community was your goal then that should include non programmers and artists as well to be fair.

The Epic Grant, while appreciated, was not my goal, my goal was a robust back end for people to build on top of or reference for advanced VR projects. There is room for people to bake in easier front ends on top of that, but I don't feel like that is my job or a requirement of me. I understand your frustration, I've had artists want to use it before that were confused, but I have limited free time (I have a full time job and family, this is my hobby), and extending the core plugin and helping the majority of my users comes first, I also do not want to create game templates for people, and basic gameplay "ready and easy to use" is also not my goal.

Who defines "basic gameplay"? Is it the musical experience developer? The VR RTS developer? The FPS creator? What is your definition of "Basic gameplay"? Alyx? It would be arguable that there is a lot that is wrong with Alyx's gameplay, story aside, and i'd rather that developers make up their own gameplay, tight and clean and only with what they need.

UVRF did bake a lot of prefab stuff into it, and thats cool and it helped a lot of developers out, but at the same time now a lot of them are stuck asking for additional features that the developer doesn't have the time to add in himself, UVRF's template IS UVRF, there is no backend and anything beyond what is exampled still needs to be implemented by the end user.

I'm still confused about exactly what you even want "done for you" here, the character is setup to perform much like a normal engine character in as many ways as I could do it.
Documentation is definitely somewhat lacking in areas, but you aren't really asking for documentation of the plugin here, you are asking for tutorials for game mechanics and full prefab gameplay systems.

I could see the case for a "simple template" that is just basics implemented without multiplayer and without any extra mechanics. But then it also has to be maintained alongside the main one, and again where do you cutoff the feature list for that?

In the end I think your confusion comes from thinking of the "plugin" as a "template", while I think of the plugin as an "SDK", with the example template as examples of how to use the SDK.