Disable portal related RTX options by default

[Kamilkampfwagen-II]

As stated in the description, this option uses additional memory yet doesn't have any effect on games with no portals, which is the majority of them.
It should be disabled by default. Note that users will have to enable it by config if they update the Portal & Prelude binaries with the latest oss release.

Enables using extra frustum-aligned volumes for lighting in portals.
Note that enabling this option will require 3x the memory of the typical froxel grid as well as degrade performance in some cases.
This option should be enabled always in games using ray portals for proper looking volumetrics through them, but should be disabled on any game not using ray portals.
Additionally, this setting must be set at startup and changing it will not take effect at runtime.|

[anon-apple]

This probably would be a good thing to change, though we'd need to make sure this option is enabled in Portal RTX's config and whatnot as currently it relies on this default I think (which would disable this if it received another runtime update). Mostly just adding this comment so that fact is not forgotten later.

[pkristof]

This setting can be made conditional on Portal textures being defined to auto disable it in games w/o portals, specifically rtx.rayPortalModelTextureHashes.

[pkristof]

This setting can be made conditional on Portal textures being defined to auto disable it in games w/o portals, specifically rtx.rayPortalModelTextureHashes.

There's two ways to go about it, the one mentioned above and/or changing the default for RTX option you are changing to the original value for hl2.exe in config.cpp.

[pkristof]

Once you address all the feedback add yourself as contributor to "Github Contributors" in ImGuiAbout::Credits::Credits(). The list is manually sorted by the last name.

[pkristof]

This setting can be made conditional on Portal textures being defined to auto disable it in games w/o portals, specifically rtx.rayPortalModelTextureHashes.

There's two ways to go about it, the one mentioned above and/or changing the default for RTX option you are changing to the original value for hl2.exe in config.cpp.

Scratch that suggestion. There are other hl2.exe games that don't use Portals so doing it in the config.cpp is not optimal either.

[Kamilkampfwagen-II]

This setting can be made conditional on Portal textures being defined to auto disable it in games w/o portals, specifically rtx.rayPortalModelTextureHashes.

RTX Option	Type	Default Value	Description
rtx.rayPortalEnabled	bool	False	Enables ray portal support. Note this requires portal texture hashes to be set for the ray portal geometries in rtx.rayPortalModelTextureHashes.

What about rtx.rayPortalEnabled
Actually I am not sure if the Default Value is actually false, I don't think Portal or Prelude had this explicitly enabled. Maybe it is conditional in either of those ways?
dxvk.conf

This setting can be made conditional on Portal textures being defined to auto disable it in games w/o portals, specifically rtx.rayPortalModelTextureHashes.

There's two ways to go about it, the one mentioned above and/or changing the default for RTX option you are changing to the original value for hl2.exe in config.cpp.

[Kamilkampfwagen-II]

I just checked Portal Prelude, the default rtx.conf doesn't have anything related to portals.
After saving rtx options in game with Save Changed Settings Only disabled, I can see that it is enabled.
rtx.rayPortalEnabled is either conditional, or enabled by default in shipped binaries.

Default: rtx.conf
Resaved: rtx.conf
Resaved all: rtx.conf

Edit: There's this line in dxvk.conf:
rtx.enablePortalFadeInEffect = True

[pkristof]

I just checked Portal Prelude, the default rtx.conf doesn't have anything related to portals. After saving rtx options in game with Save Changed Settings Only disabled, I can see that it is enabled. rtx.rayPortalEnabled is either conditional, or enabled by default in shipped binaries.

Default: rtx.conf Resaved: rtx.conf Resaved all: rtx.conf

Edit: There's this line in dxvk.conf: rtx.enablePortalFadeInEffect = True

rtx.rayPortalEnabled is enabled for hl2.exe matching games in config.cpp, but as I mentioned it encompasses more games than Portal so it's not the optimal solution. IIRC, a value for an RTX option is set in a following order, with latter overwriting the former: RTX Option default, value in config.cpp, dxvk.conf, rtx.conf.

Having said that, how much of perf/memory are you improving with your proposed change in a game you are optimizing for? Because this PR will require updating rtx.confs for Portal and there are more portal related RTX Option settings to account for if we are to apply your suggestion of disabling unused ray portal related effects.

[Kamilkampfwagen-II]

I just checked Portal Prelude, the default rtx.conf doesn't have anything related to portals. After saving rtx options in game with Save Changed Settings Only disabled, I can see that it is enabled. rtx.rayPortalEnabled is either conditional, or enabled by default in shipped binaries.
Default: rtx.conf Resaved: rtx.conf Resaved all: rtx.conf
Edit: There's this line in dxvk.conf: rtx.enablePortalFadeInEffect = True

rtx.rayPortalEnabled is enabled for hl2.exe matching games in config.cpp, but as I mentioned it encompasses more games than Portal so it's not the optimal solution. IIRC, a value for an RTX option is set in a following order, with latter overwriting the former: RTX Option default, value in config.cpp, dxvk.conf, rtx.conf.

Having said that, how much of perf/memory are you improving with your proposed change in a game you are optimizing for? Because this PR will require updating rtx.confs for Portal and there are more portal related RTX Option settings to account for if we are to apply your suggestion of disabling unused ray portal related effects.

I haven't done any tests. The description says 3x of a typical froxel grid, but I have no idea how significant it is.
I feel like it won't have any visible affect.

Ever since I read through the RtxOptions.md disabling it has become a practise for me. My whole motivation is simply disable anything that is costly yet unused.

Updating the configurations of Portal and Prelude is a one time operation. I think there's no need for adding an additional bit of complexity by making it conditional.

[nsubtil]

We discussed this and it does seem like a good idea. We want to make sure Portal RTX and Prelude stay compatible, so we'll need to update those config files first before we can take a PR that changes these defaults. We'd like to cover all of the ray/portal options in one go to minimize the number of times we need to push Steam updates.

@Kamilkampfwagen-II, can you modify your PR to set all relevant ray/portal options to false by default? Would be extremely helpful if you could also provide updated config files for Portal RTX and Prelude that enable all the options you disable in your PR.

If you happen to get numbers on the perf delta, that may also help speed (ha!) things along on our end, but not required.

[Kamilkampfwagen-II]

@Kamilkampfwagen-II, can you modify your PR to set all relevant ray/portal options to false by default? Would be extremely helpful if you could also provide updated config files for Portal RTX and Prelude that enable all the options you disable in your PR.

Most other portal related options are set to false by default, though I believe Source games have rayPortalenabled by config.cpp?
I am not sure if these have any affect if rtx.rayPortalEnabled is set to false or have a cost to begin with.
The description of the rtx.enableVolumetricsInPortals explicitly states that it should be disabled if no use.

RTX Option	Type	Default Value	Description
rtx.di.enableCrossPortalLight	bool	True
rtx.enablePortalFadeInEffect	bool	False
rtx.rayPortalCameraHistoryCorrection	bool	False	A flag to control if history correction on ray portal camera teleportation events is enabled or disabled. This allows for the previous camera matrix to be set to a virtual matrix to correct the large discontunity in position and view direction which happens when a camera teleports from moving through a ray portal (in games like Portal). As such this option should always be enabled in games utilizing ray portals the camera can pass through as it should fix artifacts from incorrectly calculated motion vectors or other deltas that rely on the current and previous camera matrix.
rtx.rayPortalCameraInBetweenPortalsCorrection	bool	False	A flag to contol correction when the camera is "in-between" a pair of ray portals. This is mostly relevant in applications which allow the camera to move through a ray portal (games like Portal) as often the ray portals are placed slightly off of a surface, allowing the camera to sometimes end up in this tiny gap for a frame. To correct this artifact (as it can mess up denoising and other temporal surface consistency checks due to the sudden frame of geometry in front of the camera) this option pushes the camera slightly backwards if this occurs when entering a ray portal. Similar to ray portal camera history correction this option should always be enabled in games utilizing ray portals the camera can pass through.
rtx.rayPortalEnabled	bool	False	Enables ray portal support. Note this requires portal texture hashes to be set for the ray portal geometries in rtx.rayPortalModelTextureHashes.
rtx.useRayPortalVirtualInstanceMatching	bool	True
rtx.viewModel.enableVirtualInstances	bool	True	If true, virtual instances are created to render the view models behind a portal.

[Kamilkampfwagen-II]

So do I need to turn off any other option from the list before composing the new config for Portal and Prelude?

[nsubtil]

Yes, I believe that's all of them. Please post the resulting config files when you have them.

That's also a lot of options, so I'm leaning towards having a master enable in the PR that flips them all to the current defaults. That way, any games that need to enable portals wouldn't need to figure out the magic set of options to do so. But let's get the config files updated first since we need to do that anyway.

[Kamilkampfwagen-II]

Yes, I believe that's all of them. Please post the resulting config files when you have them.

That's also a lot of options, so I'm leaning towards having a master enable in the PR that flips them all to the current defaults. That way, any games that need to enable portals wouldn't need to figure out the magic set of options to do so. But let's get the config files updated first since we need to do that anyway.

My point is that rtx.enableVolumetricsInPortals is costly, even with no portals present (according to the desc). Others might be dependant on rtx.rayPortalEnabled = true or presence of valid portal instances. We could use some help from rendering devs, for clarification.

[nsubtil]

The only option that we expect will have a measurable effect today is enableVolumetricsInPortals.

The reason we want to cover all of these options in one go is that there is likely some perf left on the table behind these enables. Biggest savings might be getting ray/portal logic out of the resolver entirely via shader specialization. We also found that some of the CPU ray/portal logic within the scene manager could early-out based on these enables, but we don't always do that today.

Making these improvements happen starts with getting these options switched off by default, which requires updating Portal RTX + Prelude. Updating shipped games requires some work, since we need to QA anything that goes live on Steam. We'd like to do this once and include all options that may result in perf benefits down the line in the update.

[Kamilkampfwagen-II]

I did amend the commit, here are the updated configs both in ZIP and as a gist
Updated config files.zip
Portal RTX
Portal Prelude RTX

[nsubtil]

Thanks! We'll give the conf files a go in QA.

For the PR itself, I think it looks good. One suggestion would be to create a "master" enable option that toggles all of these together. This would probably work as a macro of sorts that runs immediately during config file parsing. Is this something you'd like to take on? I'd say it's optional for this PR, since it's something we can get done on our end later, but would be nice to land it at the same time as the new defaults if possible.

You should also add yourself to the list of contributors in dxvk_imgui_about.cpp.

[Kamilkampfwagen-II]

Thanks! We'll give the conf files a go in QA.

For the PR itself, I think it looks good. One suggestion would be to create a "master" enable option that toggles all of these together. This would probably work as a macro of sorts that runs immediately during config file parsing. Is this something you'd like to take on? I'd say it's optional for this PR, since it's something we can get done on our end later, but would be nice to land it at the same time as the new defaults if possible.

You should also add yourself to the list of contributors in dxvk_imgui_about.cpp.

I don't quite get it sorry, other options are inactive if rtx.rayPortalEnabled is false, why not prevent rtx.enableVolumetricsInPortals from allocating more memory if ray portals are disabled anyway.

[nsubtil]

As an update, we're trying to get the config file changes through QA now (we didn't have enough cycles to verify this leading up to the 0.4.0 release). Once that's done we should be able to post them to Steam, then merge this PR.

[NV-LL]

REMIX-3066 for tracking