Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

No, you are right. The XRCamera3D is tracked in relation to the XROrigin3D node (which is on the floor) and gives you the height of the player. Obviously if a player is sitting down on a chair, that height will be fairly low, while if they are standing it will give a real indication of the height of the player (or atleast the eye height), and you can detect if a player is crouching.

However, in many games you can have a good reason for "fixing" the player height. For instance if in game your player character is standing and walking around, while you allow the player in real life to be seated. Or if you want your game to not care whether its played by a short or tall person, but fix the height to the actual character you are playing.

XRTools implements this by allowing you to specify the desired height of the character. It will then compare the height of the player to the desired height when the player body is added to the scene tree, and adjust the height according to the difference. You can turn this behaviour off (property is called `auto adjust height` from memory. 

Thanks, found it—player_calibrate_height on PlayerBody. Now that I'm no longer hovering above the floor, I see that my table was way too high. I think the player height thing was somehow related to my early failure at scaling the player down to dollhouse scale via world_scale. I don't want to change it back, though; I like that the entire game takes place in a single space.

I think my general problem is that I don't really understand VR in Godot all that deeply. The XR Tools gives some neat shortcuts to most of what I need to do in an VR space, and this works for 99% of the game, but every now and then there's those weird little thing which isn't pre-coded for me—registering a button press, turning the player towards 90.0, rendering to specific left or right eye, triggering a double jump (kinda fixed that), extending XRToolsPickable (screws with XRToolsGrabPointHand) ... probably more. Still, this jam has pushed me to actually look at what goes on inside the XR tools, which I sorta considered to be some kind of overworldly stuff not meant for lesser beings. So things a starting to make a little more sense.

(+1)

This is definitely an issue for many VR developers, and I think is an issue with game engines in general.

XR tools and similar toolkits offer you a shortcut by providing loads of functionality out of the box so you can hit the ground running, but it also means that you're skipping over the fundamentals. Especially if you're new to Godot you're not only skipping over the fundamentals of XR development, you are also skipping over the fundamentals of building games in Godot.

As more and more developers choose Godot and get experience with this, and as a result more and more information is made available through blogs, devlogs and tutorial videos, this becomes less and less of an issue, but right now it is easy to get on the wrong foot with things.

Godot itself has a few quirks that don't help either, for instance Godot 4.0 introduced the ability for you to add nodes with a script attached automatically through the `add node` button, but most of XR Tools scripts are design to work in conjunction with a scene and you need to use the `add child scene` button or things won't work properly.