[Runtime Feature]: Additional Remix Api Methods (Updated 2026)

What is the context of the feature/improvement?

Extending the feature set of the remix api.

While the current api already allows for a lot more freedom and interaction with the runtime, it's fundamental scope is to directly interact with the remix renderer without relying on the d3d pipeline and thus, it's lacking a few features for projects that are either not open source or just need simpler methods (game script methods in a way).

Please describe the feature/improvement?

• Remix Config Variables:

  It's already possible to animate remix variables to create event triggered effects or transitions (eg. tonemap color tint) or settings that are applied per map but resetting or transitioning back to the original-saved value is not as straight forward as it's currently not possible to retrieve the value/s of a remix variable so:

  • a method to retrieve the current value of a remix variable, eg: GetConfigVariable would be a nice addition.
  • a method to reset a remix variable back to it's saved state, eg: ResetConfigVariable would be a nice addition.

[!NOTE]
15th March 2026:

• a method for getting a complete list of variables, with types and current values

As a workaround (and for context):

I'm currently using logic that parses the `rtx.conf` on game startup and places the remix variables into an __unordered_map__ 
that holds information about the `reset value` (the initial conf value), the `current` value and the variable `type` .
If I now want to change a remix variable via the api, I'm updating the `current` value in the __unordered_map__ and then send 
it to the runtime via `SetConfigVariable` after crafting the value string. This then allows me to transition back to the original 
value as long as I properly keep track of the variable.

It's up for debate if something like this could be included in the api header (maybe a second header specifically for helper
functions) or if that is a community task via "extensions".

🟠 As a side note: It would be really nice if remix variables of type `float` could be displayed as such in the `rtx.conf`. 
Meaning adding `.f` to the value even if it's saved state does not contain any decimals. I'm currently having to interpret
everything as `float` as there is no way to differentiate between integers and floats.

• Mesh / Material Properties

  Tweaking mesh / material properties of objects that are not created via the api, meaning objects that the runtime intercepts via the D3D api (if fundamentally possible) would be a nice addition. It would be great if that would also work for objects that already have replacements (via an usd mod layer). Some ideas in that regard:

  1. Tweaking specific properties:

     User specifies the object hash and the property to change.
     Function returns the previous value of the property so that the user can restore the property when needed.

  2. If the above is possible:

     A method to restore all changed object properties back to their default values at once

  Conceptually, properties changed in this way would act like the a virtual usd layer with the highest priority?
  Restoring the original properties would remove all overrides for the given hash in this case.

  While all of this is already possible when the object is created and managed via the api, this also requires the user to specifically disable drawing of this object in the game's code (which might require logic similar to the hashing logic the runtime uses to uniquely identify the mesh) and with that, also looses the ability to edit it via the traditional capture -> toolkit -> mod layer way. It's currently this or that. A mix of both worlds would be great is what I'm trying to say.

• Hide / Show USD Layers

  I think it would be a really great addition if there was an api method to hide or show usd layers given that they are already part of the mod.usda in either a visible or hidden state. This would come in handy in multiple ways. A user could make specific overrides to certain meshes or materials that can be toggled eg. when a specific event is triggered or when the map changes.

  Usage examples:

  • enabling a layer containing lights when a map switches to night time
  • if a model is used on multiple levels, one could switch that to a different model that is specifically made for that level

  It's more or less the same as tweaking individual mesh / material properties but in a more general way and involves toolkit usage which would make it a "best of both worlds" feature 🙂

[!NOTE]
15th March 2026:

• the above would also be useful for remix logic

[!NOTE]
15th March 2026:

• A way to force a hash for the mesh / instance (per legacy d3d9 drawcall)
• Setting a custom hash for the legacy texture (per d3d9 drawcall) - useful for dynamically changing textures where one might not want to change the colormap (because its animated) but want to make other replacements like adding a normal -> used that for the portal gel in portal 2 which is using a dynamically updating texture similar to a lightmap - also used in various other comp mods of mine
• Setting a texture category for a d3d9 drawcall
• Ability to prioritize lights (RTXDI) created via the api - eg. a scene with 200+ lights, prioritizing lets say the headlights would help a ton with fizzle issues around light edges of the headlight (while moving fast)
• Proper enums for these would be nice so that we do not have to wiggle with numbers: https://github.com/NVIDIAGameWorks/dxvk-remix/blob/8eb4f537b5b78093ec4e346b800cde422a6ae60b/public/include/remix/remix.h#L717
• Waaay beyond the scope, something in the way of AutoPBR -> a way to tell remix about texture texture-types (what type is in what texture stage) and a string argument for "hints" / material name / shader name used-> runtime would associate that data with the colormap of the drawcall which could then be used to dump all of that to disk later (+ association info with hint text to see if something went wrong, for manual fixing) / (automatically create roughness and octa-normals while dumping 😛 )

Media

I've posted a video in the showcase channel on the remix showcase discord with remix variable transitions:
https://discord.com/channels/1028444667789967381/1028600697463263314/1269343492199420009

Start with public/include/remix/remix.h and the existing SetConfigVariable API, then review rtx.conf and mod.usda to understand the current variable and layer representations. The request spans several unrelated runtime and D3D features, so it needs to be narrowed to one specified API behavior with an explicit completion criterion before implementation can begin.