#Server-Side Occlusion Culling (Anti-Visual Exploit)

11 messages · Page 1 of 1 (latest)

valid coyote
#

As a community server owner in DayZ, I can honestly say it’s pretty bad due the DayZ player base using NVIDIA Filters, and stretch resolution. We PC-check players regularly when they agree to it, and around 80% of the time it’s people using filters, no-tree settings through NVIDIA Inspector, or stretched resolution (1280x1080).

The problem is that those same PvP focused players are going to move over to Ardem and use the exact same tools they currently rely on, because many of them don’t view it as an unfair advantage... even though it absolutely is.

#

.
Along with this, there also needs to be a system that prevents trees, bushes, and other objects from disappearing at certain distances when looking through a scope, especially due to players lowering their graphics settings from extreme to poor.

It becomes a major issue during long-range fights because you may think you’re concealed behind cover, while to someone using lower settings, you’re basically lying out in the open with little to no vegetation rendering around you.

lapis prawn
#

I'd agree with you if I didn't personally understand the constraints that multiplayer open-world survival games have in terms of networking to begin with. Conceptually it's cool idea but I don't think it's fair to use Valorant as an example for applicability when it's a game of a significantly lower draw on networking.

#

It's not, not worth testing out. But I wouldn't be surprised if they rely on 3rd party anti-cheat for the most part.

tame pumice
# lapis prawn I'd agree with you if I didn't personally understand the constraints that multip...

Fair point on the Valorant it's not a 1:1 comparison, the networking load isn't the same. But that's exactly why you wouldn't do it the way Valorant does it. The concept scales if you change the approach. You wouldn't do real time line of sight checks on every player pair every tick, that would destroy performance on any open world server. Real time per player ray tracing on a 64 player open world would be brutal. You divide the map into sectors ahead of time and bake a lookup table of which zones can see which zones based on terrain and large structures. At runtime the server isn't calculating anything, it's just checking a table. Zone 14 to zone 37, yes or no. The expensive part is players near zone boundaries, but even that is just blending overlap between adjacent zones. Unreal already has Precomputed Visibility Volumes built into the engine for exactly this kind of thing. It's not a custom solution from scratch, it's extending what's already there. You're right that 3rd party anti cheat is the more likely route though. I just don't think it solves the visual exploit problem since the issue isn't software cheats, it's monitor settings and hardware level adjustments that no anti cheat can detect.

rich quiver
#

Couldn't you use a decimate mesh algorithm(lots of them are very good, work both with vertices/triangles/UV's AND preserves bone structure which allows to keep animations etc.) on all the meshes to create proper VERY VERY low poly meshes(like from 60k => 500-2k) of everything but still keep their bone structure and therefore animations as well.

Then, use this algo for all the meshes that should be 'non-transparent/things through which players should not see through/in.

And then use those meshes in a 'virtual' memory map purely on the server side(exact real-time positions of in-game server objects) and then use them as mesh colliders with the current physics system and either:

a) Do a ray cast on every vertex (Faster to do)
b)** Do a ray cast on only the outer edge vertex's** (Faster processing but needs a custom algo to obtain said vertices based on players server pos/camera angle)
of those low poly meshes AFTER basic occlusion culling, use that to determine if a player is behind an object or not. If player is fully behind an object, do not send that players info to any other client that can't see it.
You could even get the raw object vertices and write an algo to do the 'raycasting' part yourself to make it run like the wind if you don't trust the physics system.

This is a way more precise and proper working solution than unreal's PVS btw, because if you want proper precision you'd have to raise PVS's settings, but that will cause a lot of lag compared to this solution. And you'd want that precision if you plan on having sniper rifles and such tactics in the game.

I've worked with several things doing exactly that and honestly it's quite a great solution.
We even ported this small algo on the GPU and used a cheap GPU on the server to quickly do this for every player online.

P.S: SCUM already implements part of this solution, Garry(Rust) is also working on the same solution(you can scroll through rusts dev log and find their posts on it)

tame pumice
# rich quiver Couldn't you use a decimate mesh algorithm(lots of them are very good, work both...

That's a much cleaner solution than static zones. I went with precomputed PVS as the simple pitch because it's already in the engine and easy to explain, but you're right that precision falls off fast especially at range with say a sniper.

Decimated mesh raycasting gives you object level accuracy without the full geometry cost, and offloading it to a cheap server GPU is a smart move.

I didn't know SCUM was already doing this or that Garry was working on it for Rust. That's exactly the kind of precedent that makes this viable.

Appreciate the breakdown, this is the kind of implementation detail that turns a concept into something a dev can actually scope and build. If the devs don't go with this natively and the modding tools give us enough access to hook into the network layer, this is something I'd look into building server side for my own server. Just depends on what they expose.

rich quiver
#

@tame pumice
Ty for the response.
I've been doing complicated things like this for nearly two decades now, ranging from building physics engines from scratch to running scientific computations for aerospace companies.

I have a special need when it comes to performance :p

But yeah, this solution is the logical and practical way this should be solved. There are a few optimizations that I could've added in my initial message but discord's message limit hit me.

I personally run a self modded SCUM server where I modded the crap out of the server, I reverse engineered their C++ assembly code with the help of IDA and other tools, now I do the frick I want with it. :p

I even asked them if it was fine and they were pretty chill about it as well since they said they're about to roll mod support of their own sooner or later.

SCUM has a partial solution to what I said, its not perfect since they didn't want to follow all the instructions, but it works for their purposes I guess. (They cheated by just increasing the network sync distance to a larger one and turned off occ. culling(this check) after a few hundred meters :p

Garry on the other hand went full ham with rust, they almost had it, but their programmers are having issues so this progress is kind of stale right now, but you can still scroll the rust dev log and find the entries. It works exactly like I mentioned, but without server GPU support since they want it to be portable.

tame pumice
# rich quiver <@1187466621153968214> Ty for the response. I've been doing complicated things ...

That's a hell of a resume. Reverse engineering SCUM's assembly to mod your own server is exactly the kind of thing I respect. The fact that they were cool with it is a good sign for the modding culture in this genre.

Interesting that SCUM basically took the shortcut, just extending sync distance and killing the check past a few hundred meters. Gets the job done but it's not the real solution. And Rust's team hitting a wall on it without GPU offloading makes sense, that's a lot of per-tick computation to keep on the CPU for a game that size.

If Techtive opens up modding with enough low level access, I'd genuinely want to pick your brain on implementation.

rich quiver
# tame pumice That's a hell of a resume. Reverse engineering SCUM's assembly to mod your own s...

When Techtive releases the game, that is already enough for me :p
Tho I will wait for a while maybe they'll release mod support in the same year hopefully, that will help me avoid a few sleepless weeks.

About Rust, yeah they have huge procedural map sizes and a lot of dynamic objects in the game, not to mention the player counts per servers (1000s per server).
Its quite hard to get everything performant on generic hardware, much less cheap server hardware that most of the userbase is running it on.

Essentially they'll have to resort in porting the algo to use either AVX2 or AVX512 to get the performance benefit, tho realistically they'll probably stick with AVX2 since most machines have that, then again, most semi-modern server do actually support AVX512 so who knows.

Anyway, great talk with you man, and also nice to meet you as well :)
Right now I am getting my ass fisted by a horde of undead in a game, so I have to deal with issues there atm. If you wanna chat about something just @ me in the appropriate channel, I'll read it when I have the time. ^^

tame pumice