HMD Geometry Database - call for help

vr-academy

#1

I have finally managed to publish all the geometry data I collected from some VR headsets on the web site here:

I invite anyone interested in solid numbers to look there - and there are some pictures too! :wink:

At the moment I have the data from Pimax5k+, Pimax8k, Oculus Rift CV1, HP Reverb, HTC Vive and Valve Index (thanks to the support from @Heliosurge, @jojon, @nukular and @DrWilken).

I would definitely like to add more headsets, so if anyone would be willing to participate and share his/her headset data, I will appreciate it (read https://risa2000.github.io/hmdgdb/contributing.html about how to do it).

Note to HP Reverb owners: I have already one dataset from @nukular, but his data are really pretty confusing, so I am desperately looking for another data to confirm the strange values.

I am also keen on answering any questions and resolve any problems related to the site and/or data contained.


Table of Contents (Wiki)
HMD Geometry Database
#2

Hi, thank you for posting this info, it’s very interesting,

There are some strange numbers for 8K as reported by HMDQ and HMDV in the table

Pimax 8K [Large+Native] - Recommended render target size: [3024, 1920] - total 5 806 080 pixels
Pimax 8K [Normal+Native] - Recommended render target size: [2656, 2244] - total 5 960 064 pixels
Pimax 8K [Small+Native] - Recommended render target size: [2428, 2492] - total 6 050 576 pixels

while for Pimax 5K+ RRTS is much larger:

Pimax5K+ [Large+Native] - Recommended render target size: [4268, 2632]
Pimax 5K+ [Normal+Native] - Recommended render target size: [3200, 2632]
Pimax 5K+ [Small+Native] - Recommended render target size: [2636, 2632]

Are you sure these are correct numbers?

EDIT: I remember your post about RRTS in March, do you think it’s because of how Steam is interpolating the PC rendering speed? But it seems 8K data is way off the normal settings anyway…what I mean shouldn’t 8K and 5K+ RRTS be roughly the same?


#3

These reported sizes are what OpenVR “recommends” to the application (which in this particular case is hmdq tool running to gather the data). Unfortunately this recommendation depends on several factors, some of which are user configurable.

For example, user can change Render Quality in PiTool, or change the supersampling factor in SteamVR, or leave the SS factor in SteamVR at auto and get an arbitrary value depending on the current CPU and GPU performance.

Since the P5k+ was recorded by me with PiTool RQ=1 and SteamVR set at 100%, the numbers shown in P5k+ stats basically correspond to the “baseline” (i.e. everything at the default).

P8k stats were recorded by @Heliosurge, and I would guess he had some different settings for the PiTool RQ and the SteamVR supersampling, so the recommended render target size in his case is smaller.

Anyway, this particular number really does not say much when it is recorded with user’s arbitrary settings and I now realize could be thus confusing to interpret correctly. I should probably either ask everyone to record the data at one particular RQ and SteamVR SS settings (possibly 1.0 and 100%), or remove it from the displayed info.

This is however really just a suggested resolution for the rendered image and has no impact on the other information which is presented in the database.


#4

@risa2000 Why Pimax 5/8k diagonal FOV in your table is less than horizontal ?

Edit. Ok I see, it might be reduced by HAM (mask)


#5

Just to note that if you click on the diagonal FOV value in the main table, it will display the visualization of all different FOVs, and the HAM and there it should be visible, how exactly is the HAM limiting the FOV.

In particular, the diagonal FOV is rendered by cyan triangle and the Pimax has the HAM in the outer corners quite big, so the consequence is that the diagonal is trimmed down. The only exception is Pimax with Large FOV and parallel projection ON, which does not have any HAM in the outer corners and there the diagonal FOV is bigger than the horizontal FOV, but only a bit :slight_smile:.


#6

Really neat and tidy, and to-the-point presentation. :slight_smile:


#7

Thanks man. Though I did not realize first what it would take to complete :smile:.


#8

Maybe it’s for the best that you didn’t, or you might have had second thoughts. :wink:

All data collation, diagram generation, and markup generated in a single pass by one script, or? :7


#9

Three scripts actually (and more than 20 additional Python files) :wink:. One to process all the collected data files, sort out what is what, fix some minor details, rewrite the files into a normalized directory structure, generate the corresponding web pages and the scripts for the renderer. (BTW the web pages are generated in markdown, the “publishing” to html is done by Jekyll which is run by GitHub pages automatically.)

Second script to run all the rendering scripts through Blender to render the corresponding images, and the third script to do the image postprocessing (basically put those fancy texts on the images, while using the original data and some metadata generated in the previous step).

What I found interesting was that rendering on the GPU is really productive, even for my “puny” GTX 1080 Ti (I thought I would have to have Quadro or Tesla or something to see some advantage), but even on the normal consumer card the render time on my GPU is half of the time on the CPU (Ryzen 2600X), plus the PC is silent, even when GPU runs at 100%.


#10

Aha - there is something to be said for not plonking every related and non.related task down together into one big tasty Spaghetti Bolognese of code, I have heard. :7

Can’t quite get over how well that stylishly clear, strict, and balanced theme you chose, works really well with the right sort of laconic no-nonsense presentation.

Never actually did any rendering with Blender, save some baking of various cube-, -light- and shadow- maps. Rendering with Cycles, then, rather than settling for Eevee (even though it’s “just” diagrams)? :7

Here’s hoping you’ll get data from more headsets, now that you’ve got everything ready. :slight_smile:


#11

I spent maybe one day going through different themes. The GitHub pages have even several themes “built-in” (you can pull in any theme found in GitHub though) and you might expect that since it is for web pages from GitHub i.e. probably technical projects, these themes will be more tuned for technical presentations and clean to the point style, but no - I went through all of them without finding anything suitable. Most of them had unpleasant tables.

Then, widening my search I spotted this theme and it immediately stood out. I just had to tweak the navigation in the header, the side bar menu, remove some wasted space, change the fonts and the colors and “reshape” the margins. I admit, at the end, I was surprised how well it turned out. So I am really happy, someone else can also appreciate it :).

For the Eevee vs Cycles, I tried both (and posted some images from Eevee here). Eevee has a big advantage that it blends the colors literally, so if you blend red and green you got pure yellow (which is used in images with PP on), while with Cycles, you got something “not exactly yellow” and you have to tweak it much more as well. But in the end, I think raytraced images look much better (even though for the side and top views, they are probably overkill).