And that’s what I was worried about your statement was meant to say. The jest makes it extremely hard to discern information from just a scribble in jest.
@dstar even took it up for a good ole jostle at the pedantic bureaucrats who are disappointed by 103<120.
I also believe that information was shared by the Chinese COO (not @PimaxUSA) [EDIT: Co-CEO] that lens type inserted would either be a tab in PiTools or that some type of RFID solution was being researched on.
If your referring to Nordic he is from my understanding Co-CEO not a COO
If one imagine that’s an NFC tag he speaks of, on each lens… I wonder what is on it, then: Just an ID, with the driver, or its config-file(s) holding the data set which it selects; Or maybe the whole distortion profile, view matrix, hidden area mask, and all, which would let a third party make lenses which could work right away, without requiring any handling of config files elsewhere, but would require a reflash to get updated profiles into them… The latter might require one of the larger capacity ones… :7
Technically, this is exactly how it should work and is a valid question. The target of any headset designer is to match the lens FOV with the display size. In general there are some leeways along the way (moving display further/closer to the lens) but not much.
The lens FOV is defined by two aspects: The area it can cover in human eye FOV (this you can tweak to some extent by moving the eye closer to the lens), let’s call it outer FOV and how much this area can be covered by the display behind (let’s call it the inner FOV). The idea is balance those two.
This was a pure geometrical talk so far, without taking into account the limitations coming from the other optical properties of the lens, in particular its focusing plane and distortions, but it gives a good notion of how the lens work for the rendering purpose.
If some headset asks an app to render the FOV it cannot display, or the user cannot see (for whatever reason), it just wastes the precious resources. The idea of hmdq tool and the whole HMDGDB is based on an assumption that no one would want to do that.
Right.
As noted above in reply to @SmallBaguette the rendered (requested) FOV has to correspond to the lens FOV. So the distortion profiles for each lens will be different (since you need to “squeeze” an information of different angular size to the same size display) and so will be the requested FOV for rendering, reported by hmdq.
While feasible the NFC transfer rate is not very ambitious (IIRC it is 848 kbps), plus you would get to micromanage the potential profile updates in the lens. Having just a unique ID on each lens should be perfectly fine. The drawback of the whole NFC idea is that you need a NFC reader. I do not know if it is supposed to be in the headset (or they plan to use some phone app), but if in the headset this will add some considerable design challenges (operating radio in already cramped space).
Correct - they seem to like duo’s at the exec positions. Robin & Batman Nordic as CEO’s, Ying Zheng and Kevin as COO’s.
Thanks for that! Really appreciate it.
As for the lens thing, there appears to be some form of contacts on the lenses so no need for wireless transmission. I would imagine it would be a very simple ID and nothing more, the less the better with things like this.
Nor do I… I might have imagined simply identification in the form of just one or a few passive pins, or holes, or printed dots, or something, read e.g. mechanically, or by a small photo transistor array, or maybe something similar with a magnet array, or pogo pins coupling with a shorting PCB pattern on the lens flange; But the guy did say: “chip”, which all of a sudden sounds a lot more ambitious. Would require a pair of pogo pins, or RF, I imagine, unless reliable enough contact is made through the screw points, even when screws are not used, after one have sweated in the HMD for a few months, that they can be used for the purpose… :7
It doesn’t even need NFC, pin holes, QR codes…etc. We just assume that people will be able to set the correct software settings according to the lenses they install. No one will bother to set it to “42ppd” after installing wide-pov lenses, right? Even if they do so, they will just see a very distorted 3D space, which serves no real purpose.
Nope indeed, but the word “chip” came out of the horse’s mouth, in the context. :7
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.