XR: Allow locking the camera to the XROrigin3D for benchmarking or automated testing

[dsnopek]

I've been putting together a benchmarking project to help with optimizing the renderer for XR, and it would be nice to be able to lock the camera to a specific spot to get consistent measurements.

This PR allows doing this by setting XRServer.camera_locked_to_origin = true and then positioning the XROrigin3D to a particular location/orientation.

I don't think there's really a use-case for this in a normal application, given how uncomfortable it is to have the camera locked at single position, which is what I wrote in the docs.

[devloglogan]

Give this a quick test and seems to work as expected, LGTM!

[BastiaanOlij]

This feels very ugly to me and not something we'd want in the normal engine. I know people are going to abuse this and start giving us grief about it. There are plenty of people who don't understand the consequences of this and want this behaviour because they think that's how you do cut scenes or force a user to look in a given direction. Then start complaining about broken behaviour because it makes their users sick.

For a testing edge case, it feels wrong to add this in.

That said, I can't think of a good option to solve this nicely.

[dsnopek]

@BastiaanOlij Is there a way we could make the option sufficiently "hidden" that you'd be OK with it?

Because it is really useful! You can keep the headset on your desk, and run automated benchmarks or tests that report back via logs or a file, which can make for nice iteration. (Note: on the Quest, you need to use the Developer Hub app or some adb commands to prevent the headset from going to sleep)

Imagine trying different changes to a scene (messing with materials, or number of objects, or something) and being able to quickly check if it improved performance without having to put the headset on and off.

This feels very ugly to me and not something we'd want in the normal engine.

I think it needs to be in the normal engine (not just tools builds or something) so that folks can benchmark their game's scenes with a release build, which will naturally have different performance numbers.

There are plenty of people who don't understand the consequences of this and want this behaviour because they think that's how you do cut scenes or force a user to look in a given direction.

I could understand how someone could have this misguided idea at first, but I feel like they'll realize how uncomfortable this is as soon as they tried it.

[BastiaanOlij]

@dsnopek like I said in my last line, I can't right now think of a better way so possibly we'll just have to accept this for the use case. As we discussed on RocketChat, I've had ideas for a long time on how I want to improve the camera system to make things far more flexible but those changes are far more invasive and possibly Godot 5.x territory.

It still feels icky to me but I can't argue with the ease of benchmarking enabled by this.

I use developer hub alot, turning the proximity sensor off and using the casting feature is a perfect way to just have your headset sitting somewhere and running through iterations of testing.

[BastiaanOlij]

Discussed in XR meeting, while we see some potential mistakes made by users, we can explain this. Being able to do the benchmarking outweighs the potential for users to misinterpret this feature.
Just need to make sure we have clear documentation around this.

[akien-mga]

Thanks!

[DigitalN8m4r3]

This feels very ugly to me and not something we'd want in the normal engine. I know people are going to abuse this and start giving us grief about it. There are plenty of people who don't understand the consequences of this and want this behaviour because they think that's how you do cut scenes or force a user to look in a given direction. Then start complaining about broken behaviour because it makes their users sick.

For a testing edge case, it feels wrong to add this in.

That said, I can't think of a good option to solve this nicely.

xD i gotta say am probably the nr1 who is gonna abuse this without carrying for the user, thanks @dsnopek for adding this, even if it is ment for something else

[dsnopek]

@DigitalN8m4r3:

xD i gotta say am probably the nr1 who is gonna abuse this without carrying for the user

Have you actually tried this with the headset on? It is objectively uncomfortable, and I think could even make people who are sensitive to simulation sickness feel nauseous. Please actually test it yourself.

The use-case for this is running automated benchmarks of your game that produce reliable results while leaving the headset on your desk - it's not meant for a human being to be wearing the headset at the time.

[DigitalN8m4r3]

@DigitalN8m4r3:

xD i gotta say am probably the nr1 who is gonna abuse this without carrying for the user

Have you actually tried this with the headset on? It is objectively uncomfortable, and I think could even make people who are sensitive to simulation sickness feel nauseous. Please actually test it yourself.

The use-case for this is running automated benchmarks of your game that produce reliable results while leaving the headset on your desk - it's not meant for a human being to be wearing the headset at the time.

actualy i did and you are right, however my Intention Was to lock it Briefly while transitioning but the code i used before isnt working with the newest godot dev build, still on the matter of the above it is not to be used for cutscenes or whatever someone migjt have imagined, even i was wrong but i settled for enabling/disabling during a transition