VR AttachToHead

[Amerio.Stephane]

Hello,

Still trying to simulate binoculars here in VR, so I gave a try to the VR sample and its AttachToHead component, but it looks like it's not working as intended (or I'm missing a lot of steps).

In AttachToHead.h/cpp, there is a pivot private member, but it's never initialized. So I can't attach something which would be really linked to the head (like a hat, or goggles), and not something that is simply at the same position.

Despaired, I try to directly attach my goggles to the head with goggles->setParent(vrplayer->getHead(), but when I rotate my head, the goggles rotation does not match (ie they don't stay at the same angle with the head) (it looks like two axis have been mixed up, like yaw and roll were swapped).

What is going on???

[bmyagkov]

Hello Stephane,

Would you mind giving this a try directly through the Editor first? On our end, it appears to work as expected when the objects intended to be attached to the head are set up using the "VR_Sample" demo, as shown in the image below:

There is a dedicated flag—"Can Attach to Head"—which needs to be enabled. Once enabled, two additional transform parameters become available to help define the initial position. Please note that the coordinate system is reversed: Y represents up and Z represents backward. If you're setting this up via code, you'll want to use the ObjMoveable component, which already contains everything necessary for the attachment logic.

Objects configured this way correctly follow head movement, as intended. Please refer to the attached image for reference.

Thanks!

[Amerio.Stephane]

I can't really use this component as-is, because it actually requires the 'hat' object to be near the head before calling 'grabIt' to be called (if I understood correctly); and we need to add the binoculars by code. Anyway, it looks like this component essentially just do a node->setParent(VRhead), which is what my code currently does.

(and what about AttachToHead component? is it a deprecated left-over?)

I fixed the incorrect rotation (another bug, independent). So now my binoculars node is correctly attached to the head, but it 'lags' behind the head movement (as if it was attached by some loose spring to the head). This will make the user sea-sick real quick... Any ideas?

 

[bmyagkov]

Hello, Stephane!

17 hours ago, Amerio.Stephane said:

I fixed the incorrect rotation (another bug, independent). So now my binoculars node is correctly attached to the head, but it 'lags' behind the head movement (as if it was attached by some loose spring to the head). This will make the user sea-sick real quick... Any ideas?

Could you please try editing the VRPlayerVR component as shown in the images below? The idea is to move the logic into the post_update() function. This change might help reduce or eliminate the issue you've been seeing with the attached object:

16  class VRPlayerVR : public VRPlayer
17  {
18  public:
19      COMPONENT(VRPlayerVR, VRPlayer);
20      COMPONENT_INIT(init);
21      COMPONENT_UPDATE(update);
22      COMPONENT_POST_UPDATE(post_update);
23      COMPONENT_SHUTDOWN(shutdown);
24  ...

72  protected:
73      void init();
74      void update();
75      void post_update();
76      void shutdown();

352 void VRPlayerVR::post_update()
353 {
354     head->setWorldTransform(head_device->getWorldTransform());
355 }
356 
357 void VRPlayerVR::shutdown()
358 {
359 }

Please let us know if this change improves the behavior on your end.

17 hours ago, Amerio.Stephane said:

(and what about AttachToHead component? is it a deprecated left-over?)

This is part of the internal implementation specifically designed for a head-attached menu GUI and is not intended for object grabbing, as it relies on a different object-handling logic that does not take head tilt into account.

Thanks!

[Amerio.Stephane]

Hello,

I did the move to post_update(), but the improvements is not visible. For completeness, here is the data we use (mesh+materials)binoculars.zip

and here is how it is added to the head:

binoculars = World::loadNode(path);			
binoculars->setParent(getPlayerVR()->getHead());

Here is a video capture too showing the behavior, when rotating the head to the left and to the right

 

 

[christian.wolf2]

Hi Stephane,

 

what VR headset are you using? We had those problems in one of our VR training applications too and modified the VRPlayerVive with the following code:

 

void VRPlayerVive::postUpdate()
{
	VRPlayerBase::postUpdate();

	if ((gasMask && gasMask->isEnabled()) || (selfRescuerGoogles && selfRescuerGoogles->isEnabled()))
	{
		Mat4 playerTransform = getPlayer()->getWorldTransform();
		Mat4 hmdPose = vive.getDevicePose(deviceHmd0);
		Mat4 hmdPoseWorld = playerTransform * hmdPose * rotateX(-90.f);
		
		if (gasMask && gasMask->isEnabled())
		{
			gasMask->setWorldTransform(hmdPoseWorld);
		}

		if (selfRescuerGoogles && selfRescuerGoogles->isEnabled())
		{
			Mat4 googleHmdPoseWorld = playerTransform * hmdPose * translate(0.0f, 0.0f, 0.0f) * rotateX(-90.f);		//gasmask_nohose
			//Mat4 googleHmdPoseWorld = playerTransform * hmdPose * translate(0.f, 0.00f, 0.0f) * rotateX(-90.f);		//googles_v2
			//Mat4 googleHmdPoseWorld = playerTransform * hmdPose * translate(0.f, 0.006f, 0.032f) * rotateX(-90.f);			//self_rescuer_googles

			selfRescuerGoogles->setWorldTransform(googleHmdPoseWorld);
		}
	}
}

Of course, the gasMask and the selfRescuerGoogles where part of the VRPlayerBase, which we attached beforhand to the VR Player rig as disabled objects in the editor.

Hope that helps,

Christian

[bmyagkov]

Hello Stéphane,

Thank you for sharing the video — it clearly illustrates the behavior you're observing. A slight lag is indeed expected when attaching objects to the head even when the logic is handled in the post_update stage.

The underlying reason is that the headset position is updated at the rendering stage in VR. As a result, even if an object is aligned with the head during post_update a small delay can still be noticeable during head movement at render time. In our Superposition VR demo this effect is minimal but in your case — as seen in the video — the object appears to lag behind the head by at least one frame, which makes the behavior more pronounced and somewhat unexpected.

This may be linked to scene performance. Could the render_supersampling parameter influence this behavior? For instance, would setting it to 0.5 have any impact?

It might also be useful to try running the scene with the default VR rendering preset and standard settings from the VR template to check whether this has any effect on the behavior.

In any case, if your goal is to simulate a disk aperture (e.g., to mimic binoculars) it might be sufficient to use the render_stereo_hidden_area command to enable custom culling using the meshes provided by OpenVR along with a circular or oval mesh defined by custom adjustable parameters via the render_stereo_hidden_area_transform parameter.

Please see the images attached demonstrating the method described above.

Could this approach potentially work for your use case?

Thanks!

[Amerio.Stephane]

Hi, thanks for pointing out the  render_stereo_hidden_area and render_stereo_hidden_area_transform parameters! I wish I had known about them sooner (well, now I have to re-read all the doc...). It would have been the perfect solution, BUT it doesn't work completely with the Varjo and it's foveated renderings.

Here is how it looks like on our Varjo XR3 with transform 0.3 0.3 0 0:

Now, this test shown us another issue: in 2.18 the foveated display tracks the eye position, but it does NOT in 2.19. Here is the 2.18 with transform 0.25 0.25 -0.4 0 when looking to the top left in the headset:

Also, in 2.19, vr_foveated_rendering_enabled seems to have no effect.

 Lastly, our FPS is low, CPU is high, but our own code does really nothing here. Attached microprofile in 2.19, in case you spot something.

Thanks!

microprofile_idle_vr.html

[bmyagkov]

Hello Stéphane,

Thank you very much for bringing this to our attention. The foveated rendering feature is still evolving and its current behavior may not yet fully represent the final intended implementation. Nevertheless, any unexpected results will be thoroughly reviewed and appropriately addressed.

To better understand the situation and align our investigation with your expectations, we would like to ask a few follow-up questions:

1) Enabling render_stereo_hidden_area on the Varjo XR-3 appears to produce a result that does not align with your expectations. Could you please confirm if the image below reflects what you would consider the correct output? Along with the context viewport, it should display only the foveated region bounded by the green area, while all content outside the hidden area is not rendered at all. Is that correct?

2) Regarding eye tracking: could you please clarify whether it is entirely non-functional in SDK 2.19 or only fails to work when the render_stereo_hidden_area feature is enabled? We’ve previously touched upon foveated rendering in one of your earlier messages, but it was never mentioned that eye tracking itself wasn’t working — which is why we’d like to confirm this point.

3) Does the vr_foveated_rendering_enabled command only stop working when render_stereo_hidden_area is active or is it entirely non-functional in the SDK 2.19 release? Please note that, according to our documentation this command is supported exclusively for Varjo devices.

4) Concerning the high CPU load — the behavior seems unusual. From the attached image it appears that something external to the application is interrupting our rendering pipeline holding VR:Render for nearly 20ms (highlighted in red) whereas the actual task takes less than 3ms (highlighted in green). Do you have any insights into what might be causing this delay?

If possible, could you try reproducing the issue using an empty VR or IG + VR template project? Or are there additional steps required to observe the same behavior? It would also be helpful to see how setting render_supersampling to 0.1 might impact this.

We’ll continue our efforts to reproduce the issue on our side but any further details or hints you can provide would be greatly appreciated.

Looking forward to your response.

Thanks!

[Amerio.Stephane]

1) Yes you understood correctly the expectation. When using a 'scoped' vision, all views shall be limited to this. So the foveated renderings shall too be only visible in the yellow region. This is the main gripe to be fixed.

2&3) I tested again after a reboot, and it worked correctly this time. Let's consider it was some one-time bad luck. So to sum up, in 2.19, eye tracking for foveated rendering works correctly, and vr_foveated_rendering_enabled works also as expected, when using a Varjo XR3. 

4) I still have this strange CPU load, with no extra application running in the background (that I know about). I'll dig deeper and test on other PC too. I forgot to test supersampling, I'll post it here later.

[bmyagkov]

Hello Stéphane,

It seems we've identified the source of the extra 22ms delay.

We compared the behavior across all three available VR runtimes using the VR sample demo and it turns out the delay you're seeing is related to a specific Varjo Base setting.

After further review, we found that setting the Vertical synchronization parameter to either "Automatic" or "Enabled - Fixed 45 fps" introduces this 22ms overhead.

Disabling the Vertical synchronization parameter in Varjo Base, as shown in the screenshot below, should help reduce the VR::Render time by approximately half.

Could you please give this a try and let us know if it improves performance on your side?

Thanks!

[Amerio.Stephane]

Hi, it looks like indeed this is the 'culprit' for the extra wait time. Thanks!

[bmyagkov]

Hello Stéphane,

On 7/8/2025 at 9:59 PM, Amerio.Stephane said:

Hi, thanks for pointing out the  render_stereo_hidden_area and render_stereo_hidden_area_transform parameters! I wish I had known about them sooner (well, now I have to re-read all the doc...). It would have been the perfect solution, BUT it doesn't work completely with the Varjo and it's foveated renderings.

It seems that you might be able to get this to work though with some limitations. Enabling Simple Rendering mode disables the focus display and for some reason, also turns off the eye tracking feature. It's unclear whether this behavior is expected as the Varjo documentation doesn’t provide specific information regarding eye tracking when Simple Rendering is enabled.

That said, if you'd like to try this approach, you'll need to enable Simple Rendering and execute the following console command:

vr_peripheral_rendering_mode_enabled 0

This should produce a result similar to what’s shown in the screenshot below.

Could this be a viable solution for your case?

Thanks!

[Amerio.Stephane]

Thanks for the suggestion, but the Varjo was selected specifically for the high quality of his foveal rendering, and it's a highly sough after feature by our pilots. They specifically request to be able to read text and digits on the dashboard control panels, even in VR with NVG active.