I've spent the majority of today looking into methods of getting the UI's fundamentals down in Unity and have had quite the rollercoaster of an experience. Quite simply, it's amazing how difficult something so simple can be. I've gotten myself lost in the jumble so I'm going to use this post both to recap the situation and realign my thoughts to the goal.
So far, I've got the Unity GUI's format very down pact and can manipulate it rather comforatably, though that's nothing to write home about. The real kicker though comes in when I try to interact with this menu. My intended goal is to make the menu a 3D interactable item that can be interacted with by the player's 3D avatar. I thought this would be simple, however, I've found that the GUI is rather stubborn with what it actually allows to make contact.
At first, I attached box colliders to the GUI elements and set a debug.log line into the update void in monodevelop to make sure the interactions were happening. They weren't. I tried to see if there was a problem with the code and found that I'd forgotten to set up either of the objects as a rigid body. I do this, and again, receive no data. I perhaps though that the items that were children of a canvas weren't interactable so I tried creating a basic cube and attaching a collider and the debug set up to that. It worked. Now rather ticked off, I went on to try and investigate what was going on. During that time, a twitter follower "JohnNowIn3D" sent me a link to an amazing video that shows a UI interface that does basically what I'm hoping for, but skinned to be like the Sword Art Online interface. They used a Leap Motion controller to interact with this menu in 3D space and I must say it really does evoke the SAO feel rather well. Another video made earlier by one of the developers behind Siteline: The Chair (EXCELLENT VR Demo) that shows off the same functionality using the LeapMotion 3D as well. I though the Leap wouldn't play too much into things, but I fear it may have been the crux of the matter.
Perhaps I missed it, but I couldn't observe an instance where the menu was interacted with while the graphics were off screen. After investigating things further, I've started to think that we may not be able to interact with the GUI without either using a custom cursor system, something I think the Leap Motion may be using or using direct prompts. This is problematic since it means that items may have to be onscreen to properly interact with GUI elements, a philosophy that while somewhat reasonable, may be problematic for the versatility of VR going forward since immersion of kinesthesia should allow people the ability to manipulate multiple parts of their body in rapid succession without having to look at them to know their location. This means there would effectively be no viewport or screen data for them to interact with 3D UI elements with.
At this point, I'll be trying to figure out if there's anyway to properly collide with the UI, but I can't say I'm particularly enthused. I can foresee two solutions to the item at hand, neither of which I'm particularly enthusiastic about.
The first would be to simply make the GUI out of world elements and ignore Unity's in built GUI system. However, I really like a lot of the features it provides and think it'd be a shame to waste the benefits they offer so quickly. Philosophically though, it makes sense since the goal is to make the GUI an item in the "same plane" the user will be in, but I'm saving this as a last resort.
The second method would be to make GUI interactive in the 3D space somehow. I'm reading into the matter via post on this blog, though it's a bit advanced for me, so I'll be doing some homework to really get my mind around it, but I think it's the most reasonable and the blog even touches upon Unity's lack of documentation for the functionality. I suppose it'd require me to create a script to make 3D objects into software cursors or something of that like, perhaps I could transfer the actual contact relevance via scripts of some kind, but I think simply being able to do at all would be a start.
Well, that just about sums up my thoughts on the matter of doing things in terms of the mechanics of this stuff. Aside from that, I'm still wondering about how I'm going to implement things. I want to make Project Navalusu's "Inner Sanctum" item if I'm to progress with the rest of development so perhaps I'll be moving forward with that. It shouldn't be too complicated considering it only really requires 2 main items: the player and the menu, but the item I have in mind may give the menu a degree of complexity comparable to Android's current appearance so it may be tricky to really get to run constantly in the background of all the software I develop. Really, this has gotten trickier than I'd originally intended, hopefully I'll get things done soon.
Depending on how much work I end up having to put into this, I may not be able to keep my word on making this free. Not entirely anyway. I wouldn't mind doing a tutorial on how to do this if it's short enough, but depending on how complex things get, I may not be able to justify things without getting compensation here. Everyone's got to eat and I can't freeload forever.
No comments:
Post a Comment