There's a horrible problem right now with for example flatgrass. The problem is that everyone receives updates of every single entity and therefore causing super lag.
(Let's face it. Not everyone wants to see your 100 props monster truck ramming on the other end of the map and lagging you)
I've been thinking of one solution but failed to implement it, hence this thread.
If we divided the "flatgrass" area to let's say 2 separate areas. (with a solid wall which is big enough to be higher than most of the constructions people make)
Example:
[IMG]http://img695.imageshack.us/img695/6293/img1v.png[/IMG]
Now since we have something to block the visibility couldn't we somehow block also the drawing of the other side?
So basically what I want to do:
[IMG]http://img141.imageshack.us/img141/6765/img2jb.png[/IMG]
If a player stands on red area he can't see(Doesn't draw | Won't show with mat_wireframe 1 | doesn't receive updates for props on that area from server) the green area but can still see blue area.
If player is on blue he can see both green and red.
Without optimization he can see everything which is very bad if we want to minimize lag and useless network traffic.
This would all be fixed if we could just isolate the areas but since people also like to fly in Garry's Mod this can't be done.
So basically how could I optimize this situation so that the server stops sending sh*t about props for player who can't even see the props on the other side of the wall.
Another problem is that since the area is so huge we need to use stuff like func_viscluster which seems to break func_areaportal at least the way I use it. <- This is how it has been tried by me and how I failed at it.
Now it's your turn, any ideas, solutions, etc?
ps: If I can't find a solution I will use a closed areaportal and let people cry that they can't see the other side.
Why not use fog? It will look weird but it should work if you have the far Z clip plane low. You could also go to map>map properties and try changing the start and end fade pixels.
Because like you said, it will look weird. I rather try this first. Or might use closed areportal(window)s after all since they cause the least hassle and work really well (hopefully even the server understands them).
Someone said and I agree that fog is just to hide one's poor optimization. And would you like to see "fog" on a map that has nothing to do with weather and which would just cause annoyage.
[QUOTE=Python1320;19351424]Because like you said, it will look weird. I rather try this first. Or might use closed areportal(window)s after all since they cause the least hassle and work really well (hopefully even the server understands them).
Someone said and I agree that fog is just to hide one's poor optimization. And would you like to see "fog" on a map that has nothing to do with weather and which would just cause annoyage.[/QUOTE]
Read the rest of my suggestion.
[QUOTE=Firegod522;19350890]Why not use fog? It will look weird but it should work if you have the far Z clip plane low. [B]You could also go to map>map properties and try changing the start and end fade pixels.[/B][/QUOTE]
You could also make the huge wall brush a func_occluder which stops [i][b]props[/b][/i] on the other side of it from being rendered/seen.
[editline]05:36PM[/editline]
And then just get people who want to go through to noclip
[QUOTE=CoolCorky;19352011]You could also make the huge wall brush a func_occluder which stops anything on the other side of it from being rendered/seen.
[editline]05:36PM[/editline]
And then just get people who want to go through to noclip[/QUOTE]
occluders only prevent props behind them rendering.
There's one big problem with this analogy. You see, Gmod has physics. That's the reason it's so fun. Physics are continuously updated no matter where the prop is. This happens because a physical action must still be performed even though the player is not in the PVS where said event happens.
A good example is in HL2, where you have to shoot a few barrels to release a ram that rams open a gate, and allows you to sail right through. This event happens, the barrels explore, ram releases, hits the gate, gate swings open and everything. All these calculations put strain on your CPU. Watching these events happen puts strain on your GPU.
Lag mostly comes from a heavy strain on CPU. The Source engine isn't a GPU heavy engine, like the CryEngine.
[quote]Let's face it. Not everyone wants to see your 100 props monster truck ramming on the other end of the map and lagging you[/quote]
This is not something you can overcome whatsoever. All you can do is use prop fading to take strain off of the GPU.
This would suck it would ruin wars
Using fog and and a far Z clip plane is harsh, but with an edited skybox texture that has your fog color on a large part of the horizon, it can look professionally done.
[QUOTE=metallics;19352535]occluders only prevent props behind them rendering.[/QUOTE]
I thought that was his problem? Too many unnecessary props being rendered?
The use of "anything" in your post is misleading, merely correcting it for reference in case anyone else is reading this thread.
Not much you can do really, placing a wall means it's not flat grass, just....grass with a wall. your best bet is to roomize each area.
[QUOTE=Firegod522;19351516]Read the rest of my suggestion.[/QUOTE]
That will still only fade props and I don't know whether it works for servers or not.
[QUOTE=CoolCorky;19352011]You could also make the huge wall brush a func_occluder which stops anything on the other side of it from being rendered/seen.
[editline]05:36PM[/editline]
And then just get people who want to go through to noclip[/QUOTE]
My goal is to stop the physics updates from server. Occluder won't stop these.
[QUOTE=SweetSwifter;19352689]There's one big problem with this analogy. You see, Gmod has physics. That's the reason it's so fun. Physics are continuously updated no matter where the prop is. This happens because a physical action must still be performed even though the player is not in the PVS where said event happens.
A good example is in HL2, where you have to shoot a few barrels to release a ram that rams open a gate, and allows you to sail right through. This event happens, the barrels explore, ram releases, hits the gate, gate swings open and everything. All these calculations put strain on your CPU. Watching these events happen puts strain on your GPU.
Lag mostly comes from a heavy strain on CPU. The Source engine isn't a GPU heavy engine, like the CryEngine.
This is not something you can overcome whatsoever. All you can do is use prop fading to take strain off of the GPU.[/QUOTE]
This is not my biggest concern. The (still very) limited bandwidth of a server is the bottleneck right now.
I should have said that I am trying to make a map for multiplayer servers with optimization concentrating on bandwidth usage minimization.
[QUOTE=FLIPPY;19352709]This would suck it would ruin wars[/QUOTE]
No, you would still see everything if done correctly (the way I am trying to do it). The server wouldn't just send the updates of the entities from the other side of the wall. And I am planning to add tunnels to let vehicles, players and such pass through.
The tunnel will be made with areaportal window.
[QUOTE=Hostel;19352798]Using fog and and a far Z clip plane is harsh, but with an edited skybox texture that has your fog color on a large part of the horizon, it can look professionally done.[/QUOTE]
Maybe, yet to see one map which would look professional ;)
And I am not only doing heavy optimization with the map's structure but I also try to minimize the size since no one is going to wait your 50MB oh-so-awesome map.
[QUOTE=omega322;19355063]Not much you can do really, placing a wall means it's not flat grass, just....grass with a wall. your best bet is to roomize each area.[/QUOTE]
Hence why the "flatgrass" I still want to let people fly ontop of everyone if they want so.
[QUOTE=CoolCorky;19353209]I thought that was his problem? Too many unnecessary props being rendered?[/QUOTE]
Too many props being sent over network but that too: I run sort of statistics system on my server too and only around 1/3 pass 25 fps on gm_flatgrass/gm_construct during even slightly busy times...
[QUOTE=FLIPPY;19352709]This would suck it would ruin wars[/QUOTE]
Thanks for your input, really.
Would it have to be a flat open plane? (plain?)
[QUOTE=Python1320;19356137]That will still only fade props and I don't know whether it works for servers or not.
My goal is to stop the physics updates from server. Occluder won't stop these.
This is not my biggest concern. The (still very) limited bandwidth of a server is the bottleneck right now.
I should have said that I am trying to make a map for multiplayer servers with optimization concentrating on bandwidth usage minimization.
No, you would still see everything if done correctly (the way I am trying to do it). The server wouldn't just send the updates of the entities from the other side of the wall. And I am planning to add tunnels to let vehicles, players and such pass through.
The tunnel will be made with areaportal window.
Maybe, yet to see one map which would look professional ;)
And I am not only doing heavy optimization with the map's structure but I also try to minimize the size since no one is going to wait your 50MB oh-so-awesome map.
Hence why the "flatgrass" I still want to let people fly ontop of everyone if they want so.
Too many props being sent over network but that too: I run sort of statistics system on my server too and only around 1/3 pass 25 fps on gm_flatgrass/gm_construct during even slightly busy times...[/QUOTE]
I don't think your aims are realistic. The server working out what the player could and couldn't see would require more network traffic and some coding I should imagine, as visibility, area portals, occluders and such are all clientside, whereas what you are thinking of is both client and server side.
[QUOTE=~ZOMG;19356974]Thanks for your input, really.
Would it have to be a flat open plane? (plain?)[/QUOTE]
make a house around spawn and put the func_areaportals(or what ever) in the windows and the doorways
[QUOTE=FLIPPY;19361660]make a house around spawn and put the func_areaportals(or what ever) in the windows and the doorways[/QUOTE]
Then it wouldn't be flatgrass.
This is kinda pointless, You want it to be flatgrass but like it's not flatgrass.
Multiple levels is the only choice.
[QUOTE=metallics;19357076]I don't think your aims are realistic. The server working out what the player could and couldn't see would require more network traffic and some coding I should imagine, as visibility, area portals, occluders and such are all clientside, whereas what you are thinking of is both client and server side.[/QUOTE]
Oh you are wrong. Area portals (even windows) shield the level even on server side. (try make one and spawn thruster on the other side and put them on, watch how net_graph 3 inceases entity updates, then go to the other side of the areaportal(which is closed) and see entity updates drop)
And server does calculate this already. I just wanted to know if someone knew how to fix it for large open space levels as the portals are totally wrong when I try to make them (will draw even the other side behind the wall hence not working at all)
This problem essentially requires "only" thinking with (area)(window)portal(visleafs)s.
[QUOTE=omega322;19364822]This is kinda pointless, You want it to be flatgrass but like it's not flatgrass.
Multiple levels is the only choice.[/QUOTE]
I do not want it flatgrass. I just wanted to use flatgrass as your base image of how the level would look like.
If it's too hard for you to imagine with my flatgrass example replace all the "flatgrass" words with a word "cube" or something :s
[QUOTE=Python1320;19372654]Oh you are wrong. Area portals (even windows) shield the level even on server side. (try make one and spawn thruster on the other side and put them on, watch how net_graph 3 inceases entity updates, then go to the other side of the areaportal(which is closed) and see entity updates drop)
And server does calculate this already. I just wanted to know if someone knew how to fix it for large open space levels as the portals are totally wrong when I try to make them (will draw even the other side behind the wall hence not working at all)[/QUOTE]
You have no idea what you're talking about. All areaportals are purely clientside. The server doesn't tell the client what the client can see, the client determines the visibility problem on their own.
Moving large portions of the map into other leaves / areaportals where spawning players can't see isn't going to help the "Reliable snapshot overflow" or other entdata problems, because the server sends all entdata in the map to the client when they connect, regardless of where they spawn in the level. In the Ep1 engine and prior, it worked this way, but in OB it doesn't.
[QUOTE=GiGaBiTe;19376631]You have no idea what you're talking about. All areaportals are purely clientside. The server doesn't tell the client what the client can see, the client determines the visibility problem on their own.
Moving large portions of the map into other leaves / areaportals where spawning players can't see isn't going to help the "Reliable snapshot overflow" or other entdata problems, because the server sends all entdata in the map to the client when they connect, regardless of where they spawn in the level. In the Ep1 engine and prior, it worked this way, but in OB it doesn't.[/QUOTE]
Updates, frequent entity updates are killing players. When Reliable snapshot overflow happens, it happens. Nothing I can do about that.
But I am trying to replicate for example the effect of two not connected rooms: While you are on the other room you won't be receiving frequent updates from the opposite room hence greatly reducing lag.
Only if we could have something to where if you aren't looking at it, the player won't draw it.
[QUOTE=Firegod522;19377402]Only if we could have something to where if you aren't looking at it, the player won't draw it.[/QUOTE]
That is done by source engine already. You just can't see it :V
But the updates are still sent even if you aren't looking at it. It's enough that the entity is on the same visleaf than you or the visleaf you're on can "see" the entity's visleaf.
Now back "ontopic":
Let's take a real example of the current problem I have:
[media]http://img706.imageshack.us/img706/4941/mewans.jpg[/media]
red lines basically tell how I would like it to do things. (it would calculate the correct visibility for that specific area instead of the whole area going all the way up the skybox (which CAN see over the wall).
If it did it like I want it to do, it SHOULD stop drawing stuff on the other side.
Hint planes.
[QUOTE=metallics;19381329]Hint planes.[/QUOTE]
I never got them to work in this case. Feel free to show.
Sorry, you need to Log In to post a reply to this thread.
