• Hi Guest!

    We are extremely excited to announce the release of our first Beta1.1 and the first release of our Public AddonKit!
    To participate in the Beta, a subscription to the Entertainer or Creator Tier is required. For access to the Public AddonKit you must be a Creator tier member. Once subscribed, download instructions can be found here.

    Click here for information and guides regarding the VaM2 beta. Join our Discord server for more announcements and community discussion about VaM2.
  • Hi Guest!

    VaM2 Resource Categories have now been added to the Hub! For information on posting VaM2 resources and details about VaM2 related changes to our Community Forums, please see our official announcement here.

VaM 1.x Implementing VR-friendly interface and mechanics in scenes

Threads regarding the original VaM 1.x

Geraldo

Active member
Joined
May 12, 2024
Messages
48
Solutions
4
Reactions
203
Hey folks,

I don't have a VR headset and utilize VAM only in desktop mode, therefore my scenes are very desktop-focused. Since I know that a lot of the people play VAM using a VR headset, I feel like I'm missing out on a huge parcel of potential enjoyers 🗿🍷

Moving forward I'd like to introduce a more VR-friendly interface and mechanics so more people could also play them. But since I don't have one, I don't really know how that would play out. In my mind, the most stuff that I can facilitate for human interaction without needing to access a keyboard or the VAM UI would be a plus. I got a few things in my list to add and I wanted to know what else would be needed for people to just jump in and use my scenes in VR.

To-Do list
A more comprehensive UI: Lots of settings to configure the scene directly on the main UI, such that you don't need to open the VAM UI and set stuff manually (lights, speed of animations, sounds, etc).
Remove possibility to grab unwanted Atoms: The player should be able to interact and grab solely other Person Atoms (unless wanted otherwise, like pillows, boxes and other small objects). Therefore, the most Atoms in a scene that I can lock in place, hide or remove interaction while in Play Mode, the better.
Embody buttons in the UI instead of only hotkeys: This is already implemented in most of my scenes, but they only activate passenger. I'd need to add an extra button to activate possession instead.
UI facing the player: UI needs to be pointing the possessable Person Atom and not placed randomly around the scene environment.
Grab UI sphere: An object that allows the UI to be moved around as pleased.
Performance buttons: Since VR is very taxing on performance, I was thinking of introducing a set of buttons with predetermined performance settings to allow people to change stuff on the fly.

Please contribute by adding whatever functionalities you like to have down below. Also, a question: When implementing the possess Embody, do I need to configure anything specific? Any settings, preferences, triggers?

Thanks!
 
  1. Keep in mind to not overdo things. Too many things can be overwhelming for the user, difficult to show, or a pain to maintain.
  2. Hiding atoms is a common method to prevent people moving things by mistake and messing up the scene. Atoms have a "hidden" checkbox on their main tab.
  3. A few embody modes are triggerable, and as such you can have buttons for them
  4. Yes, if possessing it's good to have a way for the player to leave possession easily enough.
  5. Alternatively you place the UI in specific locations according to the scene.
  6. Performance depends on too many things and is user specific, however some options for the scene can help, like on lights for example
Embody question:
Don't mess around beyond default values. Those who use Embody already know how they want to use it.

As this is a complicated topic with no right or wrong answers, take a look at the variety of UIs in scenes and think about what strategies can work well for your scene needs.
Planning for a sane and flexible UI structure will save you a lot of time with experimentation. My advice is to separate as much as possible the visual aspect of a UI and the UI triggers, this gives you room to try out optons without constantly copying and edit triggers. I can explain in more detail what I mean with this if you want. You can also see my "NEXT" scene UI for ideas.

Some VR things to consider:
  • A pinned UI to the corner of a screen is used sometimes by some creators as it works well on desktop mode and is always in view, but it's terrible with VR because the image in the corners of the lens are blurry;
  • VR is a lot more demanding in hardware, and a common result is taking 50% of the FPS you have on desktop mode;
  • Possession is not restricted to VR, and a user in VR may not use it, but if possessing things get more difficult for UIs;
  • Animated head movements of a possessed person can be very annoying or even make the person sick;
  • It's ok to make a scene that is not super compatible with VR or for possession in some parts;
 
Hey atani, thanks for all the tips, I'll keep them in mind moving forward.

You briefly touched on something about Embody that I never thought about, which is exiting. This is nice to know because in my scenes they're currently UIButtons, so getting out of the possession is only possible via the hotkey or Esc. I'll change them for toggles. Thanks!

Regarding the separation between UI visuals and actual triggers, I believe what you meant is having the button for the UI to trigger another hidden button which is the trigger for all the actions, correct? That way the visual button itself only has one action trigger, to trigger the hidden button.
 
This is completely subjective: the moment I see more than an immersive setup of a handful of buttons, I'm litterally exiting the scene and deleting it.

But I think you're thinking the wrong way. It's not "what a scene should have" but "what a scene needs".

If you're aiming to users wanting a "ready made sandbox with a lot of controls", then yeah, you could consider the sort of UI you're talking about in the first post.
If you're aiming to do an immersive scene and storytelling for instance, controls should be diegetic and the least immersion breaking possible.

On top of that, unless you're using exactly the same workflow/setup in every scene, trying to summarize a single UI/UX setup is a bit useless as, as I was saying above, you'd scale and do the UI depending on your scene.

All and all, I think your initial post would be more useful if it was like "Best practices for X or Y case" than simply talking about UI and user interaction.
 
My only comment on this so far is about hotkeys. Please don't ever use standard alphanumeric keys as hotkeys. F2, F3, F11, F12 are the safest ones. Nothing irritates me more than trying to type something while modding a scene, and BAM, all of a sudden I'm in Embody mode. Spacebar as a hotkey is not user friendly...
 
Hey atani, thanks for all the tips, I'll keep them in mind moving forward.

You briefly touched on something about Embody that I never thought about, which is exiting. This is nice to know because in my scenes they're currently UIButtons, so getting out of the possession is only possible via the hotkey or Esc. I'll change them for toggles. Thanks!

Regarding the separation between UI visuals and actual triggers, I believe what you meant is having the button for the UI to trigger another hidden button which is the trigger for all the actions, correct? That way the visual button itself only has one action trigger, to trigger the hidden button.

For the Embody plugin wheither you use Tracker or Passenger option, they work well in VR. If the person head in which we will be in POV, look straight to the girl, it would be perfect in VR.
IIRC Embody with Tracker, the player will have free look so if the guy is moving his head a lot, you won't be sick. As opposed to Passenger, you could be sick but it depends of the user.

For switching between POV or nor, ispinox / C&G STUDIO use button, when we open the VaM menu with our VR controller, it automatically exit POV. We can go back, by either click on the POV button of the scene, or to go inside the Embody plugin with our VR controller.

AWAKENING has made an awesome UI that work both on desktop and VR. The Menu won't show up until you look at it.
 
Hey atani, thanks for all the tips, I'll keep them in mind moving forward.

You briefly touched on something about Embody that I never thought about, which is exiting. This is nice to know because in my scenes they're currently UIButtons, so getting out of the possession is only possible via the hotkey or Esc. I'll change them for toggles. Thanks!

Regarding the separation between UI visuals and actual triggers, I believe what you meant is having the button for the UI to trigger another hidden button which is the trigger for all the actions, correct? That way the visual button itself only has one action trigger, to trigger the hidden button.
Whether UIbuttons or toggles, doesn't matter what it is, just to note that someone on VR is very likely not near or able to use a keyboard for hotkeys. It's not essential, as any player with even a little experience can get in or out of embody via the VAM UI or using UIAssist (such an essential plugin imo), depends on what you want in the scene.

Backing up what hazmhox says, a UI should be modelled on the scene's intended usage. I'm not saying you shouldn't have more than the essentials, which by the "essentials" I mean the minimum amount of things for the scene to work, you can extend them of course but without compromising the scene or the immersion potential too much. This balance is easier said than done, and given that a desktop user and a VR user using possession have different needs and limitations, experimentation is crucial, leading me to the topic of separated triggers for UI.

Separated triggers from UI

I like to use the plugins VAMStory Actions for UI and VAMS Director for triggers that the UI will use. By separating, I can change the UI as much as I want and not be concerned about copying triggers around, the UI only triggers the intended Director triggers. Changes to UI triggered triggers is in a single place or multiple by themes of actions, making it all much more flexible and tidy. This gives a lot of flexibiltiy on scenes that you are still developing or plan to explore over time. Naturally, if you have a scene that is very linear, not for repurposing or you know already how you want to have it finished, then this separation doesn't offer benefits.
 
then this separation doesn't offer benefits.

It does! And I can tell you that because I'm on a daily basis with a couple of creators who have the "creator ADHD" and change their mind 5 times mid way through scene creation :p
On my end I do it all the time to ensure I don't have to duplicate or fix 3, 5 or 10 buttons that have the same role. The magic of Director is that, as you say, you can "centralize" triggers and call them as much as you want. This is very handy to improve iteration and update speed.

All and all Geraldo, I won't tell you that because I did VAMS and I want to "sell it" above all else, but I did that tool to ease my flow initially for Djinn (which someday, maybe, eventually I'll find the time to finish) and fit my needs. But if I can give you several objective points for it instead of going "vanilla UI":
  • As above, really fast iteration time if your organize your scripting properly
  • UI overhead is way lower than vanilla VAM. I was working with several creators who had perfs issues and several dozens of buttons who weren't using VAMS, I motivated them enough to migrate it : for just 20+ buttons/UI elements, the scene got almost 20 to 30 fps back. VAMStory, properly used is almost zero impact on your framerate.
  • You can go nuts and even custom since the last update, which allows you to make beautiful UIs tied to your scene style.
 
Thanks everyone who contributed by giving some nice tips 🗿 they're greatly appreaciated. I'm already applying some of them on my scenes 🙌
 
Back
Top Bottom