Create the base functions of the fancy UI parts

RobotZap10000 commented

2024-09-22 11:58:35 +02:00

(Migrated from codeberg.org)

This project began in the summer of 2024. The entire point of it is to see if our idea of a fancier UI would be a better experience than the plain old one. As of writing, we have 14 days to deliver an entire study about it and we still don't have our UI that works. That is not a good look for our research supervisor. I was unable to do this earlier, because this feature is a lot more challenging than I had expected it to be and because my current workflow of VR development is very frustrating and demotivating.

The whole idea was to replace the touchscreen-laserpointer-tablet UI that is currently the staple for VR UI with one that is comprised out of mechanical controls, such as levers, switches, dials and more. The idea was to simulate physical restraints for these objects, so that the levers couldn't be ripped out of their sockets or break it other ways.

The problem we had was with implementing these physical constraints, unlike the Godot Game Engine itself, the OpenXRTools plugin that we used to heavily simplify development did not have the most comprehensive documentation. That made finding the code that actually moved the grabbed objects around nigh impossible. I dug through the original code for hours, but to no avail. This motivated our decision in #4 to pivot to still have the mechanical controls, but only be able to manipulate them by pinching them in a certain spot.

The other problem was with the VR workflow. We both have wireless headsets. They don't need a whole cable rig to use comfortably, but the downside is that your experience will be heavily influenced by your wireless connection. Wifi is rather notorious for being spotty and somewhat unreliable. This usually isn't a problem if you're downloading webpages or video streams, because they usually have buffers to keep it moving. However, in VR, you can't simply wait 5 seconds for your display stream to reconnect. You'll most likely feel like vomiting rainbows due to the disorientation if it doesn't boot you out of your stream.

The connectivity problems are already bad enough, but they're not omnipresent. We both use standalone Meta Quests, which have their own battery and processor. It makes them heavier than a wired headset, which requires tighter head straps to hold it against your face properly. While developing, I quickly need to switch between VR and the real world to make quick changes. Both of the Quests have passthrough cameras to see the real world without taking them off, but the image is not detailed enough for me to read my own code easily enough. The act of unscrewing the strap, removing the headset, making my changes, putting the headset back on, screwing in the strap and still seeing my problems unsolved becomes very tiring very quickly. This made us both somewhat averse to developing the VR components of the game, and put this issue off until much later. But it still must be done, and we will do it now.

This project began in the summer of 2024. The entire point of it is to see if our idea of a fancier UI would be a better experience than the plain old one. As of writing, we have 14 days to deliver an entire study about it and we still don't have our UI that works. That is not a good look for our research supervisor. I was unable to do this earlier, because this feature is a lot more challenging than I had expected it to be and because my current workflow of VR development is very frustrating and demotivating. The whole idea was to replace the touchscreen-laserpointer-tablet UI that is currently the staple for VR UI with one that is comprised out of mechanical controls, such as levers, switches, dials and more. The idea was to simulate physical restraints for these objects, so that the levers couldn't be ripped out of their sockets or break it other ways. The problem we had was with implementing these physical constraints, unlike the Godot Game Engine itself, the OpenXRTools plugin that we used to heavily simplify development did not have the most comprehensive documentation. That made finding the code that actually moved the grabbed objects around nigh impossible. I dug through the original code for hours, but to no avail. This motivated our decision in #4 to pivot to still have the mechanical controls, but only be able to manipulate them by pinching them in a certain spot. The other problem was with the VR workflow. We both have wireless headsets. They don't need a whole cable rig to use comfortably, but the downside is that your experience will be heavily influenced by your wireless connection. Wifi is rather notorious for being spotty and somewhat unreliable. This usually isn't a problem if you're downloading webpages or video streams, because they usually have buffers to keep it moving. However, in VR, you can't simply wait 5 seconds for your display stream to reconnect. You'll most likely feel like vomiting rainbows due to the disorientation if it doesn't boot you out of your stream. The connectivity problems are already bad enough, but they're not omnipresent. We both use standalone Meta Quests, which have their own battery and processor. It makes them heavier than a wired headset, which requires tighter head straps to hold it against your face properly. While developing, I quickly need to switch between VR and the real world to make quick changes. Both of the Quests have passthrough cameras to see the real world without taking them off, but the image is not detailed enough for me to read my own code easily enough. The act of unscrewing the strap, removing the headset, making my changes, putting the headset back on, screwing in the strap and still seeing my problems unsolved becomes very tiring very quickly. This made us both somewhat averse to developing the VR components of the game, and put this issue off until much later. But it still must be done, and we will do it now.

RobotZap10000 commented

2025-01-25 17:51:53 +01:00

(Migrated from codeberg.org)

Since our skill level is not high enough to implement physical levers, we'll have to animate them. To control them, transparent red arrows will appear next to the elements when the player's hand approaches. The red arrows are placed and shaped in a way that communicates the possible actions that the player can take. Once a player's hand gets close enough to a single arrow, it becomes fully opaque, highlighting the fact that it is being selected. When the player presses down on the grip control, the arrow turns golden, to signify it being used. When the player releases, all arrows of the element disappear and its state change animation plays. This should be very akin to a button from the GUI of a PC.

RobotZap10000 commented

2025-01-25 18:59:05 +01:00

(Migrated from codeberg.org)

Here's a diagram of the elements we wish to implement. Most of the elements are covered gray, with the aforementioned arrows floating alongside them. The big red button and small switch don't need arrows and instead will be colored themselves. On the right are the previously spoken states of the arrows.

RobotZap10000 commented

2025-02-01 22:42:21 +01:00

(Migrated from codeberg.org)

We may have decided to cut a lot of our project to meet our deadlines, but this is quintessential to the project's existence. I have already implemented the ghost and hover arrows, but the select arrows and the movement of the elements cannot be done with what little time we have left.

Rows
Columns

Create the base functions of the fancy UI parts #6