I just wanted to touch on the description of Nvidia reflex (1:33:33). Reflex is made of two technologies. Reflex 1 is currently in use in games, but reflex 2 is unreleased. Gocnak describes the camera reprojection feature that is reflex 2. This feature, as described, checks the frame after rendering and sees mouse movement between the previous mouse movement read and the current time, applying a new projection using the depth map and then infilling gaps with ML. Gocnak also says that "Reflex [2] is because of DLSS's input latency". This isn't really the case. While it does certainly offset some of the additional latency of DLSS, the latency added by DLSS is in the range of just 0-2ms. Most of the latency it improves is from the game's processing between mouse input read and rendering. Reflex 1 is used to synchronise draw calls on the CPU with the processing of the GPU, preventing the need for a GPU render queue, meaning the latest frames are rendered at the same time as the drawing of the latest frame is called for by the CPU. This can reduce latency by a large margin depending on how the rendering works without it. I don't mean this comment as a "haha got you!" kind of thing, just wanted to explain that Nvidia reflex can be more useful in different ways! I hope this has been enlightening.
Hey, thanks for the clarification! I guess I am pretty ignorant when it comes to DLSS and other NVIDIA specific technology, especially as they ramp up towards focusing on AI features which should not be in rendering games but rather helping make games instead. I'm curious how well Reflex would do given our m_rawinput 2 setting, which interpolates mouse data to provide way more consistent mouse movements across framerates for users. So maybe we have more of a Reflex-lite mode with that? Also not sure why UA-cam was hiding this comment, this is super helpful information. - Gocnak
not sure if this already exists but maybe some kind of roadmap on the actual webpage for mm would be useful, that way any youtubers or people interested can just check in on it and then it would allow for hype to build up at a natural pace. Also i think the fact that cs2 has so many issues regarding it's movement scene with the whole hardcoded 64 tick + lack of kz menu + bad server browser is lowk a great opportunity for you guys. IMO a public prerelease would probably be popular just by virtue of that.
We will be updating our roadmap very soon after 0.10.0, which is when we will allow everyone into the Playtest as well. I agree a public resource for our progress is paramount to public reception, and while we have our GitHub roadmap here (github.com/orgs/momentum-mod/projects/28/views/1), we should have a clear and featured easy-to-follow one more prominently displayed. - Goc
@@MomentumMod 👍👍👍👍 btw i don't think it needs to be as detailed as the git just something broad like these systems are like 80% done blahblahblah would be great ❤
@@keg7991 Yeah good shout we'll try to get new roadmap on new website (which we've remade for 0.10.0 as well) (youtube please don't delete my comment this time)
@@fingerprince_ also I know that there's issues adding in a HNS mode due to how the networking works, imo it's a fair idea to allow people to setup private servers which do have a more traditional sync technology as seen in 1.6 or csgo. But only as very much an optional thing, additionally I'd say you probably don't even need to necessarily develop it just so long as it's allowed through open source devs It would probably totally fine. Sorry for the idea spam! xddd
@@keg7991 I'm afraid this is practically guaranteed to never be a thing. The Source Engine games make a very fundamental distinction between "singleplayer" and "multiplayer" games, where for singleplayer games, the player runs both the client and the server. Momentum is built this way from the ground up, and all over the codebase we make the assumption that this is the case. Producing two different builds of Momentum, one singleplayer and one multiplayer, would take an enormous amount of refactoring and introduce extra code complexity we have no interest in maintaining. Also, Momentum's game code (all the C++ stuff) unfortunately has to be closed source, since since 0.8.8 Momentum has been built directly of a custom build of the Source Engine (Strata Source) that requires an NDA with Valve to access. We *do* have plans for separate dedicated servers (or "dedicated lobbies") which are most likely still P2P though maaaaaybe we could do a central server that acts as a multicast relay between clients -- this could speed up networking a lot since it requires only one connection to a server, rather than P2P between in clients. But even if we did this, we still wouldn't be working on a tick-perfect sync model, it'd be the same pattern of updating other player entities as soon as we get the data. Ultimately the non-realtime approach to our networking has *so many* upsides: free, instant lobby hosting for anyone, can be on different maps in the same lobby, ability to do systems like roaming lobbies very easily. This model works excellently with the gamemodes in the current scope of the given, namely modes with a single player competing for a time on a leaderboard. The one case synced networking would be better is realtime racing, though we think we can manage that pretty well with desynced P2P anyway. Synced networking would be an *enormous* amount of work, for gameplay/gamemodes that don't fall in the current scope of Momentum anyway. Sorry!! (If UA-cam blocks THIS comment I swear to GOD)
I just wanted to touch on the description of Nvidia reflex (1:33:33). Reflex is made of two technologies. Reflex 1 is currently in use in games, but reflex 2 is unreleased.
Gocnak describes the camera reprojection feature that is reflex 2. This feature, as described, checks the frame after rendering and sees mouse movement between the previous mouse movement read and the current time, applying a new projection using the depth map and then infilling gaps with ML. Gocnak also says that "Reflex [2] is because of DLSS's input latency". This isn't really the case. While it does certainly offset some of the additional latency of DLSS, the latency added by DLSS is in the range of just 0-2ms. Most of the latency it improves is from the game's processing between mouse input read and rendering.
Reflex 1 is used to synchronise draw calls on the CPU with the processing of the GPU, preventing the need for a GPU render queue, meaning the latest frames are rendered at the same time as the drawing of the latest frame is called for by the CPU. This can reduce latency by a large margin depending on how the rendering works without it.
I don't mean this comment as a "haha got you!" kind of thing, just wanted to explain that Nvidia reflex can be more useful in different ways!
I hope this has been enlightening.
Hey, thanks for the clarification! I guess I am pretty ignorant when it comes to DLSS and other NVIDIA specific technology, especially as they ramp up towards focusing on AI features which should not be in rendering games but rather helping make games instead. I'm curious how well Reflex would do given our m_rawinput 2 setting, which interpolates mouse data to provide way more consistent mouse movements across framerates for users. So maybe we have more of a Reflex-lite mode with that?
Also not sure why UA-cam was hiding this comment, this is super helpful information.
- Gocnak
not sure if this already exists but maybe some kind of roadmap on the actual webpage for mm would be useful, that way any youtubers or people interested can just check in on it and then it would allow for hype to build up at a natural pace. Also i think the fact that cs2 has so many issues regarding it's movement scene with the whole hardcoded 64 tick + lack of kz menu + bad server browser is lowk a great opportunity for you guys. IMO a public prerelease would probably be popular just by virtue of that.
We will be updating our roadmap very soon after 0.10.0, which is when we will allow everyone into the Playtest as well. I agree a public resource for our progress is paramount to public reception, and while we have our GitHub roadmap here (github.com/orgs/momentum-mod/projects/28/views/1), we should have a clear and featured easy-to-follow one more prominently displayed.
- Goc
@@MomentumMod 👍👍👍👍 btw i don't think it needs to be as detailed as the git just something broad like these systems are like 80% done blahblahblah would be great ❤
@@keg7991 Yeah good shout we'll try to get new roadmap on new website (which we've remade for 0.10.0 as well) (youtube please don't delete my comment this time)
@@fingerprince_ also I know that there's issues adding in a HNS mode due to how the networking works, imo it's a fair idea to allow people to setup private servers which do have a more traditional sync technology as seen in 1.6 or csgo. But only as very much an optional thing, additionally I'd say you probably don't even need to necessarily develop it just so long as it's allowed through open source devs It would probably totally fine. Sorry for the idea spam! xddd
@@keg7991 I'm afraid this is practically guaranteed to never be a thing.
The Source Engine games make a very fundamental distinction between "singleplayer" and "multiplayer" games, where for singleplayer games, the player runs both the client and the server. Momentum is built this way from the ground up, and all over the codebase we make the assumption that this is the case. Producing two different builds of Momentum, one singleplayer and one multiplayer, would take an enormous amount of refactoring and introduce extra code complexity we have no interest in maintaining.
Also, Momentum's game code (all the C++ stuff) unfortunately has to be closed source, since since 0.8.8 Momentum has been built directly of a custom build of the Source Engine (Strata Source) that requires an NDA with Valve to access.
We *do* have plans for separate dedicated servers (or "dedicated lobbies") which are most likely still P2P though maaaaaybe we could do a central server that acts as a multicast relay between clients -- this could speed up networking a lot since it requires only one connection to a server, rather than P2P between in clients. But even if we did this, we still wouldn't be working on a tick-perfect sync model, it'd be the same pattern of updating other player entities as soon as we get the data.
Ultimately the non-realtime approach to our networking has *so many* upsides: free, instant lobby hosting for anyone, can be on different maps in the same lobby, ability to do systems like roaming lobbies very easily. This model works excellently with the gamemodes in the current scope of the given, namely modes with a single player competing for a time on a leaderboard. The one case synced networking would be better is realtime racing, though we think we can manage that pretty well with desynced P2P anyway. Synced networking would be an *enormous* amount of work, for gameplay/gamemodes that don't fall in the current scope of Momentum anyway. Sorry!! (If UA-cam blocks THIS comment I swear to GOD)
yeah, you should absolutely add scroll runs to the game, i agree
woot woot
at this point, game needs source 2 . cs2 surfing is dead
why would us being on source 2 change anything lol
@@fingerprince_ We should actually wait for Unreal Engine 6 and move to that when it comes out, when CS2 episode 1 surf dies.