This is a very simple library I am working on that will lower the barrier of entry for making VR games.
Here is an example script showing the simplicity of the library. (not production level code, just debug / testing level)
local Lib = game:GetService("ReplicatedStorage"):WaitForChild("VRLib")
local VR = require(Lib)
local Devices
local getOn = function(button)
local input, gpe = VR:GetInput(button)
return input and not gpe and input.Position.Z > 0
end
local char = script.Parent
local RightBrick = char:WaitForChild("RightBrickTest")
local RightBrick = char:WaitForChild("LeftBrickTest")
local Body = char:WaitForChild("VRBody")
local wasOn = false
VR.OnUpdate:Connect(function(step)
if getOn(Enum.KeyCode.ButtonL3) and getOn(Enum.KeyCode.ButtonR3) then
if not wasOn then
VR:Recenter()
end
wasOn = true
else
wasOn = false
end
-- used to "glue" the player to the seat or character
VR.CFrame = Body.CFrame
--these can be assigned to outside of the function too
VR.Height = 4
VR.Scale = 1
Devices = VR.Devices
RightBrick.CFrame = Devices.RightHand.CFrame
LeftBrick.CFrame = Devices.LeftHand.CFrame
VR:ApplyCamera() --call this to update the cameras location
end)
There is a lot more to be added in the coming future, but in the meantime, it has adjustable height and scale settings, automatically moves the camera and provides hand and input access without having to do it separately, making it very easy to make a simple VR game.
Eventually I will try to support a simple VR character controller with hand tracking for arms and add different movement modes like teleport or snap turning in a easily usable way
Try being more specific next time, rather than just insulting his work as being “gorboge.” Maybe then you’ll get what you want. Or, maybe make it yourself.
Other than that OP, this looks like a great start. Might give it a try sometime.
Adding on, I accept criticism and suggestions. This module is in somewhat of a work in progress state and while it is still available for use to the public because it does appear to work (at least on the devices I have tested), but I will make sure to update it to accomodate for other devices, input settings, and features without having too much of an impact on existing code. Even if changes are made, you can use older versions or just update based on changes I make.
I’m not talking about the module. I’m talking about the literal support roblox has given it. I think this module is awesome for people getting into roblox VR for the first time.
Do you know what the cause might be? Could just be Roblox’s lack of support for Vive. I can’t modify how Roblox handles VR so if even the controllers don’t move then that is not my fault unfortunately. I think my system binds all inputs for controller so it should be able to pick up any inputs.
If it is a binding issue, most likely. My module should show the inputs being triggered so you could try checking those too. Also, I just updated the documentation
I myself have tried roblox on both Oculus and Vive, and I’d say that Oculus performs much better on roblox, I experience a lot more weird graphical bugs on the Vive.
It is a module so it should work right off the bat whenever it is required lcoally. I am working on a server sided version that will include another module to make it easier to communicate between the client and server
One question, it looks like you expose VR CFrames through a part. If that’s the case, do you update this on Heartbeat? Assuming you do in fact update CFrames on Heartbeat, you should actually be able to create server sided parts and give the player NetworkOwnership of them. On the server, you can have another update function on Heartbeat, and due to how replication works, you should get exactly the same behaviour/appearance on the client and server.
These parts can be invisible on the server by default and the client can override the transparency itself if necessary. This would eliminate the need for remotes, which are notoriously bad for physics, at least in my opinion.
Also, I have no idea if you have anything related to this already, but it’d be really useful to have an “object in hand” utility function. You could accept similar arguments that a raycast would, and then you can perform one or two raycasts using those arguments in front of each hand when called. This would allow for creating interactable objects, for example, being able to detect when the player is attempting to pick up a sword, or grip onto a door handle, and developers can implement their own grip code.
I didn’t really think of adding any functions for grip detection because a lot of people can do it in different ways and some might want features such as long distance gripping like in VRChat or fling gripping like in Half Life: Alyx, but I might add something similar in the future as non-obtrusive default options (that can be disabled entirely or manipulated at run-time). Also, I don’t use a Part, I use some tables that get updated each frame. You can make parts if you want to but I needed to store other kinds of information with the hand and some people don’t need a part.
As far as replication goes, I am working on integrating my Ping Module into the VR Module and making it easy to set up. This will not be automatic, however, because I want to make sure that
They can use the Ping Module to transfer other kinds of data as well, for thing such as the mouse location on desktop, reducing complications due to already wanting to transfer data over
The module doesn’t run in the background 24/7 when there is no manual replication being done.
I am also trying to work on lag compensation features that would require the ping module (to extrapolate / attempt to sync position data between clients and the server based on ping / latency derived from the module)
My main focus, however, is making sure that even if I do make changes, that the module stays the roughly same and will not be changed so far that it affects backwards compatibility and forces users to change their source code in order to accommodate for newer features. Likely, even if Roblox adds support for full body tracking and I add support for a bunch of tools and kits for VR use, scripts from the very first generation of the module should still work (provided they use the API properly, and none of its backend properties)
I’d like to have a go at creating a fully physics-based character controller. However, I’m not sure the physics engine is stable enough to accomplish that. Have you tried by any chance?
Well, if you mean using constraints for the arms, I really really advise against that. Constraints aren’t usually the best solution. I would recommend, instead, to use Inverse Kinematics to move the body to match the arms, and then just make that body collide. That is what games like Boneworks usually do. As far as collisions and physics simulation goes, sure, have at it! You can even make things like in Boneworks where you grab an axe in different places and swing it! You just have to make sure you adjust the hand positions so that they don’t break the constraints.
Also, again, because of replication, you might have a few issues related to something like throwing a knife at someone for example.
