godot-xr-tools VS godot-proposals

It’s a dream compared to UE. I tried on and off over a couple years to power through building some toy VR apps in UE and was never really able to make much progress past their prefab maps. It’s just so freaking complex that, IME, the fun of the process gets crushed under the weight of making zero forward progress.

As I started a NixOS immersion program a few months back I was looking for a new platform that I col could do 100% of my dev on Lunux. Ran into godot searching vids on YouTube and was really impressed with the workflows so I installed godot and steam (home.packages = [ pkgs.unstable.godot_4 pkgs.steam ]). With openXR support built into godot 4, it automatically picked up the shared lib that stream dropped and in under an hour was walking around using my index and Vive in a VR env and could also build a package for my son’s quest.

Within a month on-the-side I had built a tabletopesque tank battle game with a custom ray-based suspension over high poly terrain, particle effects, ballistic artillery, and a unique controller input scheme based on the tilt of the controllers (left for body rotation, right for turret). The physics engine is great, rocking the body on fire was simple as an inverse off the shell spawn vector, and the body properly rolls under both lateral and longitudinal axis by virtue of the damper shocks.

All that to say, I think the biggest difference is that with godot 90% of my effort, code, and time was spent writing implementation code for my game while on UE it was spent writing integration code.

You obviously miss out on hot topic things like nanite et al, but I learned a long time ago that fidelity has no correlation with an engaging game. The other con will likely be around performance, it’s passable at 90hz, but if you want to start hitting framerates like 144hz, the critical code will probably need to drop to C++ using GDExtention.

I’ve also noticed that, with the popularity gaining in gltf, that it was rather trivial to find little assets with native support.

I’d recommend watching some vids on creating VR apps, and another great resource, if you want to grok the interface code is godot’s open-xr-toolkit project: https://github.com/GodotVR/godot-xr-tools/tree/master/addons...

It probably depends on what you want to do and if you want this to be a career. If you want to do this as a hobby and the functions you need are described in this toolkit, then I would give Godot a try as the fastest way to try your idea and get up and running and have fun: https://github.com/GodotVR/godot-xr-tools/tree/master/addons/godot-xr-tools/functions. If you want heavy physics based actions like boneworks with a full body avatar, then yeah go unreal or Unity. If you want to try to get hired by a VR studio, then unreal or Unity.

Using Godot (actually the engine is 3.3 in game, but I used 3.5 in the editor), and using basically every one of the XR tools: https://github.com/GodotVR/godot-xr-tools

Hi although developed for VR I wonder if this might give you some ideas: https://github.com/GodotVR/godot-xr-tools/blob/master/scenes/sphere_world_demo/sphere_world_demo.tscn

There is also a 2din3d object in the xrtools I think that allows you to assign a scene via code if you wanted to make a mame machine. https://github.com/GodotVR/godot-xr-tools/wiki/PointerAndUI

Godot XR Asset and XR Tools asset, making it 100x easier to make these VR conversions, and especially MalcolmNixon who jumped in and literally created an extension of XRTools for the purpose of walking on planets for this project that now everyone can use: https://github.com/GodotVR/godot-xr-tools.

XR Tools asset: https://github.com/GodotVR/godot-xr-tools

Godot was fine, for the most part, it's a good engine for small games. The main issue was around working together and resolving conflicts with git (Godot isn't really working and constantly kept changing IDs in resource files), and it kept losing data in scenes when the code changed so we had to rebuild things several times. On previous test games we also ran into huge performance issues in the editor when we wanted to do too much work in scenes, so we had to switch to doing most of the work in code.

The worst part was when I had to rip out a bunch of testing code that used @tool for release as it seemed to cause issues when doing a release build. The engine is generally not great when you want to follow clean software engineering (e.g. dependency injection is not possible, I opened a proposal to that end here[1]).

[1]: https://github.com/godotengine/godot-proposals/issues/8850

If we had a Mask2D, this would be super easy and straight forward.

So if that's what OP meant, clip_children property won't work. Instead OP needs to use a CanvasGroup parent and the Line2D (with CanvasItem Material in Subtract mode) and TextureRect as siblings, or any of the other methods explained here until we have a Mask2D node.

There is an open proposal to have a compile option for a LibGodot, as a Library https://github.com/godotengine/godot-proposals/issues/6267

Yes, there could be the option to open at least 2 tabs at the same time, when working with scripts. This has probably already been suggested in: https://github.com/godotengine/godot-proposals

I cannot tell exactly where the jitter is from the video, but if it is what I'm thinking of, it is a known issue, see here. There is a proposal to fix this, with tons of discussion here. Try some of the workarounds mentioned in these two links. Game looks great by the way!

It's in the release notes. Here is a link to the pull request, based on this proposal.

Currently not possible: https://github.com/godotengine/godot-proposals/issues/7213