Forum Discussion
mattnewport
10 years agoProtege
HSW rendering issues after 0.6.0 SDK update
I've finally got things rendering again after updating my code for 0.6.0 (which was a bit of a painful process from 0.4.4...) and things look more or less correct now except the HSW is rendering with some kind of weird double image effect that makes it painful to look at. I can't quite figure out what's going on with it but it makes my eyes hurt!
The same effect seems to be present in the OculusRoomTiny sample and to a much lesser extent in the test scene from the configuration utility. I wonder if this is something to do with the new QuadHeadLocked layer type? The docs say about QuadHeadLocked: "However, it can be uncomfortable if used for text information and it is usually preferable to use a QuadInWorld layer type for this purpose.". It's so deeply unpleasant that I really don't want that to be the first experience that greets anyone trying out my app.
Does anyone know what's going on here exactly? How can I fix it?
The same effect seems to be present in the OculusRoomTiny sample and to a much lesser extent in the test scene from the configuration utility. I wonder if this is something to do with the new QuadHeadLocked layer type? The docs say about QuadHeadLocked: "However, it can be uncomfortable if used for text information and it is usually preferable to use a QuadInWorld layer type for this purpose.". It's so deeply unpleasant that I really don't want that to be the first experience that greets anyone trying out my app.
Does anyone know what's going on here exactly? How can I fix it?
7 Replies
- jhericoAdventurerMy hypothesis is that the HSW is being presented at an infinite distance, meaning that it's in the same relative position for each eye. If you relax your eyes and look as if you were starting at the sky it seems to resolve OK. However, if it's being composited over a scene with any depth information then you get an uncomfortable mismatch between the overlay and what's behind it (but has depth cues indicating it should be in front).
The solution would be to wait to render anything until the HSW is gone, but since Oculus doesn't allow us to query for that, we're kind of screwed. - mattnewportProtegeYeah, I think the problem is essentially what you describe. It seems like in the Oculus Room Tiny sample and in my app your eyes immediately try and settle on a prominent foreground object (the table in Oculus Room Tiny) and the fact that the HSW message renders over the top of it but has stereo disparity for infinite distance causes the unpleasant/uncomfortable sensation. With effort I can focus attention on the HSW message and my eyes eventually adjust to it if I try and ignore the rest of the scene. The first few seconds are always unpleasant though.
I'm surprised Oculus shipped this given their messaging about the importance of viewer comfort. The HSW message is the one thing that every app will share as the first few moments of the VR experience and as of right now it's probably the most uncomfortable VR experience I've yet suffered. I haven't seen many other people complaining about this yet so maybe it's something I'm particularly sensitive too (I seem to be particularly insensitive to motion sickness fortunately) but I can't imagine it not being noticeable for anyone else which makes me wonder how this shipped? - drashHeroic Explorer
"jherico" wrote:
The solution would be to wait to render anything until the HSW is gone, but since Oculus doesn't allow us to query for that, we're kind of screwed.
Wait a second... are you saying that in 0.6.0, we no longer have a way to determine how long it will be displayed and whether it's been dismissed? If so then yes, that's a problem because that's how we make sure we don't start showing content until the HSW is gone. - mattnewportProtegeYeah, there don't appear to be any API calls to query or control HSW display status any more in 0.6.0. It's all handled invisibly by the layer manager process it seems.
- jhericoAdventurer
"drash" wrote:
Wait a second... are you saying that in 0.6.0, we no longer have a way to determine how long it will be displayed and whether it's been dismissed?
Yes. You hadn't noticed?
My two main issues with 0.6.x are the lack of ability to determine when the HSW is no longer present, and the inability to determine where the Rift is if it's in extended mode.
Granted, while it's easier to not have to write separate code paths for direct / extended anymore when creating VR output, there's no way to ensure that a non-VR window you create and place explicitly isn't ending up on a Rift display, where it's totally unusable.
And granted, while it's nice to not have to think about the HSW anymore, not having any information about whether or not it's being displayed means you can't avoid presenting content before it appears, which can result in a sub-optimal user experience.
I pointed out both of these things during the 0.6 Alpha and was pretty much ignored on both points. But whatever. I guess developing something other than a VR-only application on Win32/Direct3D/Unity is something only nerds and weirdos do.
EDIT: If I'm a little more venomous than usual, please note I've had a bit more to drink this evening than usual as well. - volgaksoyExpert ProtegeThere was a bug in the SDK that caused zero-eye-offset rendering in the HSW when the user passes null into the SubmitFrame call for the ViewScaleDesc struct. The fix is in, and should be in the next release. Also, it shouldn't be surprising that the HSW is going through a major overhaul in every aspect.
- drashHeroic ExplorerThanks for the update Volga. Do you happen to know if there's a plan for the SDK to provide a way for developers to avoid presenting anything until after the HSW is fully dismissed?
Quick Links
- Horizon Developer Support
- Quest User Forums
- Troubleshooting Forum for problems with a game or app
- Quest Support for problems with your device
Other Meta Support
Related Content
- 1 year ago
- 11 months ago
- 2 years ago
- 7 months ago