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.
Bastiaan Olij
Creator of
Recent community posts
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.
Sadly yes, that is a hard limitation on most XR platforms. There is a lot of division on whether this is a good thing or not within the industry. Meta kinda started the trend and there is merit to the argument, everyone else followed suit We'll see if things change under market pressure. Apple has already swayed a little allowing access for business XR applications but not consumer applications (e.g. not for apps on the AppStore).
Index controllers should just work through SteamVR without requiring any layers. Possibly requires a restart.
I have noticed that SteamVR gets confused sometimes depending on how the action map is submitted but again a restart usually helps. Someone also mentioned that his project name got in the way (we sent the project name along with the action map so Steam VR can display it in the bindings editor, but I guess it doesn't like all characters)
Indeed for simple elements Label3D and such childed to the XRCamera3D work well as a HUD.
The other option is to use the new composition layer objects in Godot 4.3 to present a 2D UI. They need to be children of the XROrigin3D node so you need to make them follow the players head by updating their position but when natively supported by the XR runtime, there is a noticeable quality improvement.
It's a grey area, it depends a bit on what you did in that week, if its just general framework/setupwork I see little difference between that and using say the Godot XR Template. I think many jammers will take something they have already build as a base or copy stuff from existing projects to save time.
If you had been working on something for months and decided to reskin it to the theme, that would be a clear violation.
But after only a week, even if it is "half finished", unless you had prior knowledge of what the theme would be I don't really have a problem with it. Especially seeing that right now our jam is just for fun. If we had prices up for grab I might be taking a closer look at what "half finished" meant :)
Thanks everyone for joining in on this first Godot XR game jam. I hope everyone had a lot of fun, I sure enjoyed trying out all your creations.
So I'm not entirely sure if itch has an overall winning category, I think we just marked the first as primary... My take on it is that we have a tie between Super Steam Hands and Cloud Shepherd, both taking 2 out of 5 categories.
That said, I was super impressed by the quality of the entries, amazing how much people put together in 3 days especially was I noticed we have a few new people amongst us that were still learning the ins and outs of Godots XR implementation.
HEY! Judges don't get to compete :P :P
Seriously though, this is a really fun little project that shows Godots Tiltfive capabilities off nicely. A few teething problems on the TiltFive drivers we still need to work out. Shame not many people will be able to try the entry just yet.
Note that there is a video of the gameplay on the games page.
Very cool entry, can definitely see this has a lot of potential. It looks amazing too! I was surprised I did not get any motion sickness even though you're flying around like crazy, a bit more control would be nice but I probably just need more practice.
I do suspect people who are much more susceptible to motion sickness than I have might like a warning :)