GrabbableObject Editor Flexibility

Excluding programming, most of the time spent while authoring interactions is on creating grab poses and editing grabbable objects. Grabbable objects are configured using a GrabbableObject component, telling how the object behaves and one or more points that the object can be grabbed from.

Complex interactions in a cockpit

Having a good GrabbableObject editor is very helpful to minimize the time it takes to make an object grabbable. But after developing many different VR applications, it has been the most challenging to get right. We often got to this point:

  • An application requires a new manipulation parameter for an object because the current parameter list doesn’t support this behavior.
  • The component is now more flexible, a new parameter has been exposed for editing.
  • The more parameters that are exposed, the more cluttered the UI becomes and the more difficult it becomes to use.
  • At some point, it becomes too difficult, unintuitive and the initial goal of lowering turnaround times is not met.

This is expected. After all manipulation is an extremely complex process and there are hundreds of things that you can do with an object. It’s not pressing X on a control pad to ‘use’ an object anymore, now it’s all about being inside the world and using your own hands to manipulate objects. The possibilities are endless.

I have found that in these cases, most of the new functionality can be grouped into two main categories:

  1. How an object is grabbed. For example, being able to grab a stick using every position and angle possible, in both directions.
  2. How an object behaves. For example, a knob in a control panel that can be turned to four different positions.

My solution to this problem has been creating a solid GrabbableObject base and the architecture to expand functionality using two types of specialization components.

  • GrabPointShape: Expands single grab points on an object to well-known shapes that make grabbing more flexible. For example, a cylinder shape can be added to a crowbar so that the single, default grab point can now be used along the whole length and with any angle. Another example can be a box shape so that a book can be grabbed by an arbitrary point in any of the 4 sides instead of a single spot.
  • SpatialControl: Adds specialization functionality by taking over control of some of the parameters in the GrabbableObject and add new behavior. For example, a Knob component will hide all GrabbableObject parameters that allow editing rotational constraints, take control over them, and add behavior to snap to the different positions in the knob rotation.

This new architecture has proven to be very valuable because functionality is now well compartmentalized. It has the additional benefit of simplifying user interfaces because these specialization components will hide a lot more parameters from the GrabbableObject than they expose on their own component. And these are way easier to understand because they relate directly to the specialized functionality instead of being generic.

– – — – –

These have been some important experiences that helped us shorten development times and establish a solid foundation that can be expanded in the future. Thank you for sticking with me. I hope these thoughts can help make clear some of the inner workings of VR applications. Maybe they can also inspire other VR developers working on similar tech or even make them consider using UltimateXR in their projects.


This article may contain affiliate links. If you click an affiliate link and buy a product we may receive a small commission which helps support the publication. See here for more information.

  • Ad

    Making hand poses from hand tracking data seems like an essential feature.

    Also, is this sponsored content, or did RtoVR have some role in developing this?

    • Sean Bannister

      I totally agree, the Oculus Interaction SDK has a hand pose recorder.

      • Why is that a “shame” …? lol
        You want it also work on some cheap Chinese AIO piece of junk?
        Who else besides Meta is doing ANYTHING in accessible VR …?
        Oh yeah that’s right: NOBODY.
        Get with the program, bud: “anti-Facebook” is so 2019 ….

        • Sean Bannister

          I think you misunderstood my sentiment. This isn’t an anti Facebook comment it’s an anti “vendor lock-in” comment coming from a software engineer who’s worried about the long term implications of adopting a framework. If I adopt vendor specific frameworks I have to adopt a seperate vendor specific framework for every VR platform in the future and maintain multiple implementations of my VR interactions. However adopting a framework like the one mentioned in this blog potentially allows me to abstract away these seperate implementations as the developer will maintain them. This is why it’s a “shame”

    • Ben Lang

      We don’t do sponsored content. This is an invited Guest Article:

  • Sean Bannister

    Open source is a big plus. As a developer my biggest concern when choosing any framework is long term development and support. However the competing open source framework VRTK is stagnant and I’m glad I didn’t choose it a few years ago as I don’t have the resources to maintain it for my project. I wish one of these frameworks would build components on top of Unity’s XR Interaction Toolkit so I felt like I had a safe place to fallback to if the project stops being maintained.

  • They are doing a great job. I evaluated their SDK for the project I’m doing, and I discarded it because of reasons related to the specific project, but I anyway found it quite cool