VR Expansion Plugin

[michaelwbell]

Mordentral, do you think it would be worthwhile adding some more chaperone components?
To my understanding, at the moment blueprint exposes the 4x vectors of the Chaperone tracked area.

What if the VRexpansionPlugin had a few more components:

-Chaperone ground plane
-Chaperone Wall north
-Chaperone Wall east
-Chaperone wall south
-Chaperone wall west

By north, east, etc, i mean the wall that faces X in positive direction, wall that is along X in negative direction, etc.

The components could be added to the VR pawn and render a plane that is the correct size for that boundary.

I suppose this is a very easy task for a programmer to manually create these components based off the chaperone bounds and the height of the base stations, I thought it might be a good addition to the plugin to make user's lives easier. And is a feature many inexperienced VR developers might find useful in the plugin.
To my understanding, users of the VRExpansionPlugin's VR Pawns need to account for the way the HMD moves in order to continuously set the Chaperone boundaries in the right location
If users had these components, the users have an easy way to get, parent and place objects on those areas of the chaperone system.

[michaelwbell]

Hi again Mordentral,

I have one more request regarding the template project on Github.

Could you rearrange the template's content folder so that everything exists within one top-level folder?
That would match the way projects and assets are delivered on the marketplace and the "Allar ue4-style-guide specs.

That way it's very straightforward for anyone to migrate the template into a new project. Especially after pulling any updates from Github.
They can just sync with the latest template, and migrate the main top-level folder to their production project, overwriting any assets.

I have attached an example image to this post:

[mordentral]

Hi again Mordentral,

I have one more request regarding the template project on Github.

Could you rearrange the template's content folder so that everything exists within one top-level folder?
That would match the way projects and assets are delivered on the marketplace and the "Allar ue4-style-guide specs.

That way it's very straightforward for anyone to migrate the template into a new project. Especially after pulling any updates from Github.
They can just sync with the latest template, and migrate the main top-level folder to their production project, overwriting any assets.

I have attached an example image to this post:

Yeah I intend to get around to that, when starting the template I just imported some of my folders from my demo world and they were split up.

The idea of a manual 'tracked area' component as you describe sounds absolutely incredible!
How would this work? Does the user draw these manaul areas during runtime and the areas are seen?
Could the user draw these areas while in an editor preview of the game and receive the results in unreal editor after quiting the session?

I have made a 3d model of the entire studio space I work at and it is a pain having to re-adjust the virtual "tables", "filing cabinets", shelves etc after they have been moved.
It would be so cool if, in VR the user could plot that data and then see the results back in the editor to shift the virtual objects to line up.

If saving the tracked points / lines out to serialization its possible to keep them between sessions and in the editor yes. I am still mulling over how best to do it, a full procedural mesh or line batches to define areas.

Mordentral, do you think it would be worthwhile adding some more chaperone components?
To my understanding, at the moment blueprint exposes the 4x vectors of the Chaperone tracked area.

What if the VRexpansionPlugin had a few more components:

-Chaperone ground plane
-Chaperone Wall north
-Chaperone Wall east
-Chaperone wall south
-Chaperone wall west

By north, east, etc, i mean the wall that faces X in positive direction, wall that is along X in negative direction, etc.

The components could be added to the VR pawn and render a plane that is the correct size for that boundary.

I suppose this is a very easy task for a programmer to manually create these components based off the chaperone bounds and the height of the base stations, I thought it might be a good addition to the plugin to make user's lives easier. And is a feature many inexperienced VR developers might find useful in the plugin.
To my understanding, users of the VRExpansionPlugin's VR Pawns need to account for the way the HMD moves in order to continuously set the Chaperone boundaries in the right location
If users had these components, the users have an easy way to get, parent and place objects on those areas of the chaperone system.

I'll agree that this needs to exist, however I would prefere the full bounds of the tracked space drawn with the controller, not the "square" that is generated as a "safe terrain". I will have to look into if openVR still provides the HardBounds output or if they locked it to just the softbounds.

Specialized functions like that by the way are likely to only be fleshed in for OpenVR, I do not have the ability to test on the OculusSDK.

[Shanowzer]

I'm going through things I might want to implement on my upcoming two weeks off for the holidays, I think primarily I would get a server browser / basic multiplayer up and running, also have a note for a component to handle drawing / defining manually areas within the tracked space to set as visual boundaries in game (draw around a chair for example and have it shown in the relative roomspace in game).

I might tackle climbing but the mechanics of that are so unique from implementation to implementation that I have been avoiding doing so.

Any other ideas?

I think I have a basic setup for LAN multiplayer done? My team is going to demo our build at SXSW so it wouldn't need a server browser.
Would you mind if I posted some screenshots of what we did on networking and see if it makes sense/would work?

[mordentral]

I think I have a basic setup for LAN multiplayer done? My team is going to demo our build at SXSW so it wouldn't need a server browser.
Would you mind if I posted some screenshots of what we did on networking and see if it makes sense/would work?

Yeah sure.

[Shanowzer]

This is handled inside our VRCharacter blueprint


While this is handled in the VRGameInstance


My partner (the only other one with a Vive right now) went on Holiday break to visit family, so I won't be able to test it until he gets back.

[mordentral]

This is handled inside our VRCharacter blueprint

My partner (the only other one with a Vive right now) went on Holiday break to visit family, so I won't be able to test it until he gets back.

Use the template blueprint code for switching between fps and VR pawns. It lets you test at least one side of it with a single HMD as long as you have two computers or filter it by server/client as to who uses the HMD. I checked a lot of my multiplayer tests using my wife computer before I packaged it out to friends with vives.

[Shanowzer]

So I could just plug my ethernet cable between the two computers and the one without the HMD would load in as the FPS Pawn?

[mordentral]

So I could just plug my ethernet cable between the two computers and the one without the HMD would load in as the FPS Pawn?

On the same network yes

[Shanowzer]

On the same network yes

This is now getting out of the area of your plugin. Thanks for the help and looking at what I had set up.

[Shanowzer]

Is there a way to have an actor get the actor/character that is gripping it?

[mordentral]

Is there a way to have an actor get the actor/character that is gripping it?

If it has the interface there is an "OnGrip" event that is triggered that passes in the controller gripping it that could be checked for owning actor and/or stored. Otherwise no you'd have to manually check.

Its supposed to be fairly abstract as that is something that I assume the user to know how to handle best for their case and I didn't want to force base actors.

[michaelwbell]

Merry Christmas Mordentral! Just wanted to share a quick video using your plugin. Extremely basic stuff so far but the plugin has made interactions so intuitive. Have learnt heaps so far and hoping to make a lot of progress during this holiday break. Thanks again for the fantastic plugin!

https://youtu.be/oqR2vuOTdEA

[UE4Hobbyist]

Hi Mordentral, I am spawning an actor on server and on the same frame I grab it with the grip motion controller. This works fine on server but on client the attachment never takes place. If I add a a delay after the spawning of the actor the attachment works on clients as well. Am I doing something wrong?

[mordentral]

Hi Mordentral, I am spawning an actor on server and on the same frame I grab it with the grip motion controller. This works fine on server but on client the attachment never takes place. If I add a a delay after the spawning of the actor the attachment works on clients as well. Am I doing something wrong?

The client may not have the replicated object yet when you are saying that it has been gripped. Replication isn't guaranteed to be in the order you send them in and the object has to be initialized first. This is expected behavior with non attachment "grips". The client side "GripNotify" function is probably failing due to the object not existing on the client yet.

Merry Christmas Mordentral! Just wanted to share a quick video using your plugin. Extremely basic stuff so far but the plugin has made interactions so intuitive. Have learnt heaps so far and hoping to make a lot of progress during this holiday break. Thanks again for the fantastic plugin!

https://youtu.be/oqR2vuOTdEA

Thats really cool, looks like you have the grip detection pretty smooth since you were cycling pretty fast there without issues.