Hubris on Pimax

[SmallBaguette]

Seeing a dev hop onto the forum here to engage with users like this is fantastic, very very commendable.

[Heliosurge]

Welcome to the OpenMR!

I have bumped your user level by one and added a DeV title. Thanks for joining our community!

[Sargon]

@Wouter_Cyborn

Hubris engineer here.

Thanks for getting onto the forum to support Hubris running on Pimax VR headsets!

@SmallBaguette

Seeing a dev hop onto the forum here to engage with users like this is fantastic, very very commendable.

I poked them on their pinned thread about compatibility issues with other VR headsets on the Steam forums and gave them a link to this thread, and they came!

Very nice to see a game dev respond to its community like that. I’m very encouraged and looking forward to getting to play this game once it’s working properly on Pimax.

[mr_spongeworthy]

Great to hear from a Dev already. I know a lot of us are really looking forward to this title, so it would be great if you managed to get it fixed. Until then; many (nearly all) games have a standard txt config file somewhere. If I can find that file and disable AO completely, maybe things will be playable.
EDIT: ini files are in one of the usual locations: AppData > Local > HubrisVR > Saved > Config > WindowsNoEditor. Nothing in there at first glance would completely disable AO. How about a steam Launch Option string?

[Wouter_Cyborn]

Exposing the config files is a good suggestion! Right now they’re packed along with the other assets. We’ll check if we can change that without messing things up for current players.
That said, we have tracked down the issue and we’ll be patching it soon.

[jojon]

@Wouter_Cyborn

That said, we have tracked down the issue and we’ll be patching it soon.

Nice! Perhaps it could be worth whipping up a short article on the issue in some trade publication, which other developers could benefit from, since stereo-mismatching AO is quite common in VR games? :7 (I have been assuming there are assumptions made by some shaders (not just AO), that do not go well with the asymmetric camera frustums that are usually used with VR headsets… (EDIT: …already before giving canted screens an initial thought…))

[mr_spongeworthy]

Since you are digging into it, if there is a way to get it to work without PP needing to be enabled, that will make life 100% better for all of us here. Really. We hate PP. Hate it. It is the bane of all existence.

[Sargon]

@mr_spongeworthy

Since you are digging into it, if there is a way to get it to work without PP needing to be enabled

Since @Wouter_Cyborn is likely not familiar with Pimax lingo, what is meant here is “Parallel Projection” mode. Pimax VR headsets have canted displays due to their wide FOV. Not all games support this properly and assume that the displays are parallel on the same plane. In order to work around this, it’s possible to select parallel projection mode in Pimax’s configuration. This causes it to emulate parallel displays in software, but it comes at a heavy frame rate performance penalty which worsens with the wider FOV you select. In general, using the full FOV of the 8KX is not practical in this mode.

Hubris seems to be one of the games that assumes that the VR headset has parallel displays. Which actually no game should assume that. This issue only affects a few high end headsets now, but presumably wide FOV will eventually become commonplace in future VR headsets from all manufacturers.

[Heliosurge]

A simple solution is to maybe look at the Unity fix that @NextGenVR had made? It needs I believe modifying the in game camera(s).

[Update] Universal Unity Culling Fix Mod V2.0.1 now released - Much simpler and more universal!

Update: Changelog for v2.0.1 I’ve fixed a bug where some games after loading a scene, would unset the Camera causing the mod not to work. Download Version 2.0.1 here: https://github.com/dmel642/UnityCullingFix/tree/master/Version2 This is Version 2.0.1 of the MelonLoader Unity Universal Culling Fix Mod. I would like to thank @koochy_rat for programming this version of the script which directly references openvr_api.dll, eliminating the need for referencing Valve.VR. This makes the mod much simpler and more universal. I implemented it into a mod and did lots of testing. Instructions: Go…

[Sargon]

@Heliosurge

A simple solution is to maybe look at the Unity fix that @NextGenVR had made?

Note that Hubris uses Unreal 4, not Unity. Though the same concepts may apply for how to fix the issue. I don’t know.

[Heliosurge]

yeah am aware. But it is related to the in game cameras.

[Wouter_Cyborn]

Hi all

So the patch was rolled back temporarily because of another unrelated issue but it should be back up later today.
The issue here is not necessarily one of PP (which apparently isn’t post-processing here). It is however due to the fact that we apply our AO in screenspace and due to the bigger differences in reprojection between the eyes on Pimax & Index, there is a parallax issue. There is nothing that can be done to ‘fix’ this as a screenspace effect will always create these issues on such HMDs. This was simply an oversight from our side.

Theoretically, by rendering some kind of UV buffer accros the visible tris in the scene, AO could be done screenspace and could be correctly remapped but solving that is just too much for our small team right now. Hopefully we’ll get to this in the future if it would still be relevant to do screenspace AO.

What we’ve done now as a workaround is increasing our AO blend radius to a point where most people wouldn’t notice it and visual fidelity doesn’t suffer too much. We’ve added an option in the graphics settings to increase the radius even further if you would find it necessary.

Finally, on Pimax:

• We fail consistently in getting it work with SteamVR. Either Pitool crashes, or SteamVR or they’re not linked. So we haven’t been able to run Hubris on Pimax yet.
• PimaxXR seems promising. It’s detected, succeeds in initialisation but seems to crash when adding a xrCompositionLayer. We’re still tracking this inbetween the other todos

[acegamer]

thanks for the update

[Wouter_Cyborn]

It’s live again! Let us know if there are any other issues due to PP etc! (except the vignetting which will be horrible )

[mr_spongeworthy]

Thank you. I’ll give it a try ASAP.

[mr_spongeworthy]

Thank you for this update. I’m sure everyone here really appreciates it! As far as I can tell you guys have pretty much nailed it. There are still occasional minor shadow issues, but they seem to rectify themselves in just a second or two. It looks and runs fantastic now! Also, I’m playing it with PP off, and so far no problems.That means a lot, as PP has a massive performance overhead. You could, possibly, just consider adding the option to disable AO completely. IMHO it’s always better to let the end-user choose what they prefer; whether that’s AA amount/method, bloom, lens flare, you name it. The ability to turn AO off could resolve the few remaining issues with very little loss of quality. I’m having no problems launching through SteamVR BTW, but the entire Pimax ecosystem is ‘fragile’ - you guys may find you want to make a clean rig for Pimax testing.
EDIT: OK, here is where we are at in my testing today after having played a couple of hours: 1) Your fix for the shadows is pretty good. Not 100%, but good. With PP off. Unfortunately with PP on the shadows actually get somewhat worse again. Not a problem if we don’t need PP. 2) However, the game does need PP for underwater scenes as there are a lot of issues there with PP off. That won’t be a big issue if there are not a lot more underwater scenes. Performance absolutely tanks and I’m just maintaining 60fps at Normal FOV with PP on (100% game resolution, 100% Steam SS.) That’s on a 4090. So for now we are kind of left quitting and changing PP settings based on whether or not we are playing a level with a lot of underwater activity.
Still a LOT better response from you guys than we typically get, so thanks a ton. Hubris is playable now, looks great, and is plenty of fun.
Question; I would like to be able to turn AA off or reduce it. Mid-range and distant objects get quite soft - a problem with many VR titles that use TAA(?). In this set of prefs I see some possibilities:
[ScalabilityGroups]
sg.ResolutionQuality=100.000000
sg.ViewDistanceQuality=3
sg.AntiAliasingQuality=3
sg.ShadowQuality=3
sg.PostProcessQuality=3
sg.TextureQuality=3
sg.EffectsQuality=3
sg.FoliageQuality=3
sg.ShadingQuality=3
But I would rather not spend a hour or two testing all of those settings if you happen to know their valid values and what those values do. For example, does =0 turn an effect off?
EDIT2: Tested the AA setting. =0 does indeed turn it off. The title looks vastly better with AA off and also performs much better.
EDIT3: Further observations. Underwater issues appear to be mostly related to plants (shadows again), the squids, and squid gibs. All of those are to some level borked without PP. Other underwater scenes so far have been fine. Also, the AA in this title absolutely KILLS performance, and the games looks vastly better without AA on. Currently I’m testing 75hz and 140% SteamSS at Normal FOV with PP off and it looks amazing and runs well (if you do get a stuttery scene you can manually turn the in game resolution down a little.)
Also, going to Wide FOV is certainly possible at 75hz at 100% steam SS, maybe even 90hz, but Wide FOV introduces shadow and light source issues again. So it looks, for now, as if Normal FOV is the best we can get.

[jojon]

Before people started implementing TAA, the AA in most Unreal Engine 4 based titles was three levels of this terrible static blur, which was utterly unacceptable IMHO, so right to sg.AntiAliasingQuality=0 it was for me, whenever a game “obeyed” users’ meddling with .ini files; Much as I dislike aliasing, I’ll suffer it any day, if blur is the only alternative.

Upping sg.ResolutionQuality instead, to deal with the aliasing, was desireable to me anyway (too bad about the inherent performance hit, though), because of the resulting much better image quality – 100% was really on the low end, producing this fuzzy, pixellated and undetailed view; And supersampling using that parameter was necessary, because almost all UE4 titles at the time (don’t know about today, nor about other VR runtimes) totally ignored what ever render resolution settings one had in SteamVR, and substituted some resolution which I have no idea where the engine sourced if from - I thought GetRecommendedRenderTargetSize() was the standard method of acquiring it, but…

Anyway, it’s good to see the “velvety” effect of mismatching AO being addressed to some degree; Hopefully in time it will become standard practice for screenspace shaders, and cascaded shadow maps, and other things, to account for only partly overlapping stereo views, and for non-parallel stereo cameras.

(…or even better: Give me fully pathtraced games at 2 times full resolution 120fps, already tomorrow! )

[Djspyker]

I have actually no problems playing this game I just start it through pitool and everything works fine on large Fov but looked very bad but now I play on normal Fov on 1.5 no pp and contrast +1 and brightness -1
And in Hubris I changed everything to the highest settings and everything looks really great and works fine and if there are many problems with shadows and stuff well then I haven’t noticed because I was just having such a good time playing it
really nice to see there are still great games being made for VR

[mr_spongeworthy]

Overall this title looks really decent now. I certainly HOPE that they manage to fix the remaining issues, but it’s about 95% playable at this point without PP, so that’s great news. I played it for hours yesterday, and there are some scenes; just a handful of place so far, where the performance really tanks. It’s repeatable, so it’s something in these rendering in those specific areas (sometimes it makes sense, sometime you’ll get this when look at something that should be really simple to render, so probably it’s just a few areas that still need optimized better.) If the shadows and lighting worked at wide FOV (they do not), then this would be a Wide FOV title for sure.
That issue brought me right back to the entire idiotic PiTool 1/3 rate fiasco though, as I could easily run this title at 90hz and let those few places drop to 45, but instead they drop to 30. Pimax: Your software is now so bad that it has broken your hardware!

[dstar]

Just turn it off and it just drops to 70.