aframe-gui
aframe-gui copied to clipboard
rdub80
How to align to specific places of the screen?
Using Babylon GUI I can align any UI element to the left, right, top or bottom of the screen. Can this component do the same?
I am not aware of any system to do that with this interface. I once wrote a little code to align something else to somewhere on the screen by hand for another project a few months back, though. it's not that hard. You need to get the viewport width/height, and get the FOV in degrees, pick a depth for your gui, and then use cosine to calculate placement--picture your view camera as being the top of a pyramid, distance from that camera as the height of a pyramid, and then basically select placement on the floor of the pyramid.
Might be a nice feature to build-in, not a terrible idea, since this has use in non-vr situations as well. That said, in VR, that's generally a bad idea. In my usage, I never pin menus to the screen, always in the world. I just make sure that it initially shows up in front of the user.
@rdub80
Might be a nice feature to build-in, not a terrible idea, since this has use in non-vr situations as well. That said, in VR, that's generally a bad idea. In my usage, I never pin menus to the screen, always in the world. I just make sure that it initially shows up in front of the user.
Also when you rotate the phone, it should be responsive, ideally. See this example on your phone, then rotate from landscape to portrait and vice versa.
Well, I hope you do decide to implement it. I think it makes sense since this is a GUI plugin.
A-Frame is a VR library. This is meant to be a gui for A-Frame, and therefore its primary use case if a gui for VR. But if Roland wants to go that way, I could see the argument for it.
A-Frame is also used for AR. On AR you often need screen GUI. Just would be nice to use A-Frame all the way. I hope you guys decide it's worth it. If not, oh well. Thank you for your time.
In general, the approach most people take to that is overlaying DOM elements above the A-Frame canvas. I think that's usually a superior approach when an overlay gui is needed, especially in mobile AR, as it's going to be way less resource intensive. The only argument I see for using this library in that case would be visual consistency if you're mixing both styles of interfaces (in-world + overlay), though I think that is valid.
@kylebakerio
The only argument I see for using this library in that case would be visual consistency if you're mixing both styles of interfaces (in-world + overlay), though I think that is valid.
A case I just ran into for an AR experience. I have an in-world UI that I need to move to the screen. Typical scenario where the client wants this is if you are making an image tracked experience, but the user is not pointing the phone at the image, so it's not being tracked. Under this circumstance, the client may want the UI(or the whole scene) to go to the screen.
But I guess this plugin is dead. No replies, last commit 5 months ago ;_;.
This component is far from dead... It's very common for A-Frame components to not get frequent updates. It just had an overhaul 5 months ago.
Again, as I said, the math for positioning relative to the user's camera is pretty straightforward. It is in no way a necessity for this library to implement the logic to place this on the screen for your case--nothing in this library is inhibiting it, it's just no one has done the work for you.
You're free to make a pull request.