VaM 1.x DLSS 5 in VAM2 + DLSS 5 Experiments in VAM1

Threads regarding the original VaM 1.x
Ideas that could improve this are:

  • Atom-specific rendering: A plugin that applies only to individual atoms, rendering the character model without processing the entire viewport or even the foveated viewport.
  • Multi-GPU support: A driver or architecture that makes SLI relevant again, allowing DLSS 5 to run on one NVIDIA GPU while the game world is rendered on a second GPU or even an APU.
 
Links to unauthorized "patches" to Paid plugins will be removed, and may result in restrictions to your account up to and including a ban.
 
Atom-specific rendering: A plugin that applies only to individual atoms, rendering the character model without processing the entire viewport or even the foveated viewport.

From what I saw and tested on the masks systems. Masking or not, this is an "image wide" treatment. Masks are just a way to adjust the final input but it won't cut your computation cost. For now at least.


Multi-GPU support: A driver or architecture that makes SLI relevant again, allowing DLSS 5 to run on one NVIDIA GPU while the game world is rendered on a second GPU or even an APU.

LOL. For fappin' 3mins and a half? Masturbation cost can't get higher than that haha :p
 
From what I saw and tested on the masks systems.
Were you testing this in VaM 2?
And if so are you planning to make any kind of announcement about whether this technology will actually be supported in VaM2? It would be really interesting to hear how you’re thinking about implementing it from the technical side, and what kind of problems or limitations it might introduce in game
 
Ideas that could improve this are:

  • Atom-specific rendering: A plugin that applies only to individual atoms, rendering the character model without processing the entire viewport or even the foveated viewport.
  • Multi-GPU support: A driver or architecture that makes SLI relevant again, allowing DLSS 5 to run on one NVIDIA GPU while the game world is rendered on a second GPU or even an APU.
Yeaaa to be able to choose would be very nice, especially with passthrough. I'm no techie, but that does sound difficult.

I loaded a scene on desktop that I had edited for passthrough use, NR took my chroma green and obviously altered it, as well as making my model looking sickly green lol.
 
Yeaaa to be able to choose would be very nice, especially with passthrough. I'm no techie, but that does sound difficult.

I loaded a scene on desktop that I had edited for passthrough use, NR took my chroma green and obviously altered it, as well as making my model looking sickly green lol.
Passthrough color manipulation is more art than science where you need to match colors using Sally's background plugin and all the lights in your scene need to have corresponding color that makes sense with the actual room you are in. If it looks sickly green it's the wrong color to use, i think the ALVR guide mentions "Blue (0, 71, 187) Similarity 20%, Smoothness 3% - Works on most, easy to use" . VAM 1 doesn't support invisible pixels because the engine is too old so other methods cannot work with VaM 1.0 . Everything is better from a developer standpoint with VaM 2.X because it's got more support for all the new technical features.
 
From what I saw and tested on the masks systems. Masking or not, this is an "image wide" treatment. Masks are just a way to adjust the final input but it won't cut your computation cost. For now at least.
Fingers crossed that Nvidia decides not to be evil and makes the tools available to indie developers.
 
Were you testing this in VaM 2?

Several games. Some implementation of the reshade versions allow to enable auto-masking which apparently targets mostly characters.
If you enable it, you can see that the options you change influence the render based on the masking (currently unavailable to preview), but the overall overhead of the NR is absolutely the same with or without masking.


Fingers crossed that Nvidia decides not to be evil and makes the tools available to indie developers.

When their features becomes available ( except during early phases where they give that stuff to big studios for a bit of fancy marketing )... anybody can drive them. It's just a matter of doing it.
So yeah you could mask... for now, unless something changes before release, masking will probably not help for perfs sadly.
 
Last edited:
With more plugins being written with AI help, a few misconceptions keep coming up. Quick corrections:

"I gave the AI the paid plugin as a reference, but I told it not to use it."
The AI doesn't have an "ignore this" switch. Everything you paste in becomes part of what it's reasoning over, and your instruction is just another line in that same pile. It might avoid pasting exact lines, but the original's layout, naming, and approach are still steering the result. You can't un-show it something.

"It rewrote everything in its own words, so it's original."
Rewording isn't originality. Copyright protects how a program is structured and organized, not just its literal text. A plugin that follows someone else's design with different variable names is a derivative of their work, the same way a retold novel is still that novel.

"That was a different chat. This one is fresh."
Not necessarily. The most recent AI keep memory across sessions and can search old conversations. You don't decide what they retain, and code structure and snippets are fair game. Starting a new chat doesn't reset what the system knows.

"I only looked at their code to compare."
Then you're the contaminated one. Once you've read it, your prompts, corrections, and design choices carry that knowledge into the AI even if the code itself never does.

The real clean-room rule, for people and machines alike:
The one doing the writing never sees the original. If that's not how your plugin was built, treat it as derivative — and don't share it on the Hub, on Patreon, or by DM. That's redistribution of someone else's paid work.
 
Back
Top Bottom