Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
The culling bugs are worse than you think--and unlikely to ever receive anything more than a half-ba
Quizzical
Member LegendaryPosts: 25,348
When people first talked about "the culling bug", there were a bunch of different things that I thought could plausibly cause it. Having played the game for a while, the source is nearly "all of the above". It's not a single bug. It's a bunch of different bugs that all lead to the same intuitive final effect: something that should be visible on the screen isn't. Let's break it down, starting with the best news and moving to the worst.
The one cause that I thought was possible that doesn't seem to be a problem is delays in loading data. I have an SSD (OCZ Agility), so I can't tell if the code to load new textures or vertex data is efficient or not; a good SSD can make even rather bad code look good. But all of the instances of improper culling that I've found either corrected themselves very quickly or could be conclusively shown that "waiting to load data client-side" was not the problem. So let's call loading stuff from the hard drive "not a bug".
Next we have bad network code. Some things in the game world change, so the client doesn't know when and where to draw players, NPCs, and mobs, among other things, until the server tells it where. For bandwidth reasons, the server can't tell a given client more than a tiny fraction of what is going on in the game world. But that's fine, as you don't need to know what is happening on the other side of the map.
The problem comes if the server mistakenly neglects to tell the player about something that is near enough that it should be drawn. If the server mistakenly neglects to tell the client that there is a mob in the area, then the client doesn't draw it. If the mob is attacking the player, however, the damage will still register. That's a nasty problem.
The good news is that bad network code is fixable. The bad news is that, just from playing the game, I'm not 100% convinced that bad network code is a problem. I've seen situations where I was fighting a mob that suddenly vanished, while other players continued to attack it. The server no longer telling my computer to draw that mob is one possible culprit, but not the only one. Regardless, ArenaNet has said that network code is a problem that leads to at least one culling bug, and they're working on fundamentally redoing the network code. I'll take their word for it.
Now, a fundamentally wrong algorithm is a nasty problem to discover this far after launch. Typos are easy to fix, but trying to redo an algorithm entirely will probably introduce new bugs, and possibly very nasty ones. That's fine if alpha testing is a year away; you can fix the bugs as you find them. It's not fine if the game launched months ago. That this is the least bad of the culling bugs should indicate that there are some serious problems here.
The problem is that not all of the situations where you might blame network code are actually the fault of network code. I've seen the game cull my own character in exactly the manner that it culled players or mobs that could plausibly be bad network code. The client doesn't need the server to tell it where on the screen the player's character is: it's always in the same place, up to camera zoom perhaps. The server telling the client that where the player is can affect where the camera is, but not where the player is relative to the camera, apart from how far the player is zoomed out. If a player's own character is culled, then bad network code is categorically not the problem. This means that even if ArenaNet fixes the network code perfectly, at least some (and possibly all!) of the culling bugs that one might intuitively think are due to bad network code will still remain.
And yes, it still gets worse. Next is attempts at declining to draw objects that the client thinks will not appear on the screen. This might actually account for that last culling bug.
Declining to draw objects that won't appear on the screen is a very important performance optimization that 3D games basically have to do in order to be efficient. If you can tell that an object definitely won't appear on the screen, then you skip drawing it that frame. The alternative is to compute the uniforms for the object, pass them to the rendering thread, upload them to the GPU, switch to the appropriate texture and vertex data, send the appropriate drawing command, process the data in the first few stages of the rendering pipeline (incidentally, as a DirectX 9.0c game, Guild Wars 2 necessarily skips 4 of the first 5 stages), destroy every single primitive in either back face culling, clipping, or fragment tests, and then not make any changes whatsoever to the framebuffer. If you can tell that in the end, it's not going to change the framebuffer or depth buffer, then a few quick CPU-side instructions to verify that and skip the rest of those steps is far more efficient. Since most of the objects near enough to you to be buffered won't be on the screen at any given time, this can have a big impact on your frame rates.
The problem is if you decline to draw objects that would have appeared. This happens in a number of places in the game, where you can be facing an object, rotate the camera, and the object suddenly disappears, even though it's far from the edge of the screen. Rotate the camera back and the object reappears. It disappears and reappears as you rotate past a certain spot that is well within the screen. The ideal behavior is that the object would be culled slightly after it goes off of the screen.
Determining absolutely for certain whether an object would appear on the screen is impractically slow to do on the CPU. But there are some easy tests that you can make. If you know that all vertices in a model are within a distance d of some particular point, and that particular point is at a distance greater than d from a clipping plane and on the side that will be clipped, then the entire object won't appear. If the "center" point is a little bit nearer than d to the clipping plane, then the object might appear or it might not, so you have to go ahead and send the rendering commands and let the video card sort it out.
If you're only slightly wrong, this can lead to objects being mostly off of the screen, then suddenly having the last bit vanish abruptly rather than continuing to scroll off. The third palace boss in Zelda 2 did this, for example. But Guild Wars 2 commonly culls objects this way that aren't anywhere near the edge of the screen. Probably the clearest example of this that I've found is the rocks on the ground at the entrance to the cave between Doldenvan Passage and Darkriven Bluffs in Wayfarer Foothills.
This could easily be caused by either a bad function that isn't properly computing whether things are off the screen, or bad model data that claims vertices are close to some particular point even though they aren't. The good news is that the former would likely be easy to fix. The bad news is that if it were the former, it's extremely probable that the game would have culling issues at least an order of magnitude worse than they are today. That means it's not likely to be the former, and rather, there's a lot of bad models in the game.
Why is that bad news, if it's only particular models that are bad? It's bad because fixing it means you have to go through and check every single model in the entire game to see if it's culled properly for being off of the screen. That's a massive undertaking. If ArenaNet didn't do that as they made the models (which is when you should do it), then it's pretty unlikely that they're going to do it now.
And finally, we have the worst news of the bunch, and the one that is extremely unlikely to ever be fixed: near plane clipping. The way that 3D graphics is done is that you compute the position of all of the vertices relative to the camera over the course of the first several stages of the rendering pipeline, and then you clip away anything that isn't in a particular frustum, which is basically a pyramid with the top cut off. Well, technically you convert everything to homogeneous coordinates in real projective space RP^3 and take a box from that and clip everything outside of that box. But the way that 3D perspective graphics (as opposed to other projections, most notably isometric) is almost invariably done is to compute the coordinates of every vertex, and then multiply by a matrix that converts the frustum you want to the box that the video card will clip. It's probably more helpful to think of it in terms of a frustum because most computer programmers don't know anything about projective spaces.
Four of the clipping planes correspond to the edges of a rectangular window. For example, one of the clipping planes tests whether a vertex would be off of the left edge of the game window, so as not to proceed with further computations of data that won't appear on the screen. These are pretty easy to handle.
The other two clipping planes are the "top" and "bottom" of the frustum, and correspond to the near and far clipping planes. Anything beyond a particular distance from the camera will be clipped and not drawn. Anything too near to the camera will also be clipped and not drawn by the near clipping plane. This is most emphatically not just a case of not drawing things behind the camera. Up to some minimum positive distance in front of the camera, things that are right in front of the camera won't be drawn.
Whoever makes a game engine can set the near plane clipping distance to whatever he wants. In order to avoid near plane clipping problems, you'd like to make it as small as possible. The problem is the way the depth buffer works. If the near clipping plane is at a distance d from the camera, you use up over 90% of the depth buffer precision for objects less than 10d from the camera. You use up over 99% of it for objects less than 100d from the camera.
If your far clipping plane is at a distance of 1 km (technically the clipping plane coordinates are unitless, but you probably have some distance scale in mind while writing the program, so let's use units) and the near clipping plane is at a distance of 1 m, you chop off anything within 1 m of the camera. If you set the near clipping plane distance to 1 mm, then you don't chop much off for being too close, but you do use up over 99.9% of the depth buffer for objects within 1 m of the camera. For objects far off in the distance, one object could be a full 10 cm in front of another, but they round to the same depth buffer value, so the video card can't tell which is in front. That will cause graphical artifacting, most likely of the flickering sort, as which object appears in "front" in a given frame depends on which happens to be rendered first that frame.
There are three ways to fix this. One is to set the depth buffer manually in pixel/fragment shaders to something other than the fixed function depth buffer value. The problem with this is that it means that you can't use early fragment tests and skip running the pixel shader when you know that an object is behind another object that has already been drawn. This brings a large performance hit.
The second fix is to not use 3D perspective. If you use an isometric projection instead, the problem is basically solved. Of course, many players want a 3D perspective rather than isometric, so for many games, this is a non-starter.
The other approach is to pick an arbitrary distance for the near clipping plane and then set your camera position such that it never, ever gets too close to anything that would be problematic if it gets chopped up by the near clipping plane. This can be a bit of a pain, but it's doable. The real problem with it is that you have to have this in mind as you determine where to place the camera for objects that block it as you create every single model in the game that can block the camera.
One might ask, why is the depth buffer done that way if it's such a pain? The answer is that the formula for the depth buffer was chosen to be something that is fast to compute. In the early days of 3D graphics, this was a big deal. A bit of a pain to handle the near clipping plane in exchange for 10% faster frame rates across the board would be well worth it. (The 10% is a made-up number that would vary by game, but it was substantial as compared to some other possible formulas.)
The problem with the near clipping plane clipping things that you would prefer to draw isn't merely that you lose track of a few things right up against the camera. It's that, when combined with back face culling, very large objects can disappear.
Many objects are closed surfaces, that is, they don't have a boundary. For these, some faces will inevitably appear in front of others. Think of a cube, for example, where it's impossible to see more than three facets at a time from a single viewpoint. For closed surfaces, you can check to see which faces are in front and which are in back, and not draw the faces in back. You do this because it's faster to not draw something than it is to do all of the work to draw it, only to have it covered up by something else. Only having to draw half of the faces is a huge performance optimization.
The problem comes when the front faces that would have appeared on the screen are destroyed by near plane clipping while the back faces are eliminated by back face culling. In that case, the entire object is invisible. Guild Wars 2 has a pretty bad case of this. You can make some entire mountains in Guild Wars 2 completely vanish, thereby allowing you to see what is behind the mountain, even while you're staring right at the mountain.
The fix, as I said above, is to make sure that the appropriate objects block the camera far enough away that they aren't culled by near plane clipping. For example, if you set a near clipping plane distance of 10 cm, then anything that needs to be drawn must block the camera such that the camera position can never be within 10 cm of the object.
This is a form of collision detection. You check how far along a particular line from the player the camera can go up to the desired zoom distance before it runs into anything. You stop when it runs into anything, and that's where the camera will be placed for that frame.
The problem is that collision detection is hard. Collision detection done properly in 3D is especially hard. Collision detection done properly in 3D and implemented in a way that it will run fast is harder yet. And running fast matters, because you can't start computing where everything is relative to the camera in a given frame until you know where the camera is.
Alas, ArenaNet's solution to 3D collision detection being hard was to not implement it at all. Collision detection in Guild Wars 2 is fundamentally 2D. It's a height map, where any given point on the ground is assigned a height. If the slope where you're standing is too steep, you lose your footing and slide down. The proof of this is that there are many places in the game where there are two discrete objects with one substantially above the other. If you stand halfway between them, you stand on air at a height between the heights of the surfaces of the two boxes or poles or whatever. Height maps tend to do that by their very nature, but it takes a severely botched approach to fundamentally 3D collision detection for that to happen more than once in a great while. (If you want to know how it's possible to have one player standing above another, there are multiple height maps, and the game checks the one that your own height is nearest to.)
The advantage to this is that it's a lot easier to implement than fundamentally 3D collision detection. The disadvantage is that if your game is fundamentally 3D, it simply doesn't work right. This is one of the reasons why jumping puzzles are so awkward, for example: you can't really tell where you can stand and where you can't except by standing there and seeing if you fall.
Height maps are fine for games that are fundamentally 2D. For example, Guild Wars 1 did the same thing, and it worked fine. But you can't jump in Guild Wars 1 or fall off of a cliff or whatever, let alone fail a jumping puzzle because you rolled at an inopportune time. (Yes, I know how to turn off the double-tap to roll option, but enabling it by default was a terrible decision.) To tell whether two objects collide, it only needed to check their x and y coordinates, and not their height. Many games that we think of as 3D are fundamentally 2D for collision detection purposes, and it works fine if it's never possible for one object to be above another.
The reason this is so bad is that it means that the near clipping plane glitches are basically unfixable. Fixing them properly would mean redoing collision detection for the entire game. That's not just implementing a new algorithm for it. You'd have to go through every single model that has any sort of collision detection involved--whether players, NPCs, mobs, or terrain--and redo a good chunk of the model. That's tremendously expensive, and really a non-starter. But anything short of that will mean that Guild Wars 2 has culling bugs forever.
Comments
Nicely written explanation and introspection; too bad many may suffer from ADD and thus can only suffer through reading one to two paragraphs on most forums.
Guild Wars' 2 culling issue has nearly driven me away from playing the game, since all my avatars are level 80 and I spend most of my gaming time in WvWvW. Presently, in Tier 3, the huge zergs know they can take advantage of the culling issue(s) and the constant appearance of 30+ atop one is more than a tad annoying. Also helps thieves and dd elementalist who use ride the lightning; the latter to escape more than they should.
If my computer were mere pittance of an electronical toy, I could at least blame it.; alas neither it nor my internet speed is an issue, so i await AN's "fix(es}" and only time will tell if they will deliver before my patience finally ends.
Btw, just my opinion, but I would have preferred a fixed over the shoulder camera view with a manual zoom function as well as a better field of vision to what AN implemented; the constant zooming inout especially when one gets tossed into a hill, fence, bridge or other object is downright poor and gives me eye strain and the narrow FOV is just mysteriious to me.
Maybe you can send this to them lol. Honestly, I'd still be playing the game if they fixed culling. I'm not even sure how people still put up with it, but it's their choice I guess.
Enter a whole new realm of challenge and adventure.
This is something that isn't all that surprising.
The 'culling' has been really badly handled by ANet in terms of communication and this technical reason is why.
ANet really can't admit 'hey we can't fundamentally fix culling'.
But this is just bizzare, ANet committed to the WvWvW / DE with massive amount of players from the very start.
Either there was massive miscalculations at the start or something fell off during development.
Gdemami -
Informing people about your thoughts and impressions is not a review, it's a blog.
I wouldn't really call an intended performance optimization a bug.
https://forum-en.guildwars2.com/forum/pvp/wuvwuv/Update-on-Culling
As you know we’ve been working on this problem for a while but what I think we haven’t ever said before is that our goal is to remove culling completely from WvW. In order to remove culling completely we have to address three issues:
1) Bandwidth out of our servers/datacenter (traffic would increase without culling)
2) Bandwidth in to each client (traffic to each client would also increase without culling)
3) Client performance issues related to rendering (potentially) all the players on a map at once. (Note that we base our performance requirements in this case on min-spec clients. We don’t want to stop anybody being able to play the game after all.)
Until all three of those issues have been dealt with we can’t turn culling off because doing so would cause something to break or perform poorly.
Ok, now let’s talk about what progress we’ve made!
Issue #1 was the easiest to deal with because we can basically just throw money at the problem. When we first started down the road toward removing culling from WvW I took a bunch of bandwidth measurements and then went to the executives and said, essentially, “Hey, if we disable culling our network traffic will increase by X%. Are we ok with that?”. The answer I got was a clear and unambiguous “yes!” So issue #1 isn’t a problem after all.
Issue #2 is a little harder. We need to ensure that folks with a min-spec network connection won’t be overwhelmed by the data we send them and we obviously can’t just buy a better connection for all of our players. So we put our heads together and came up with a plan to reduce the bandwidth required for WvW (and Gw2 in general) as much as possible. Those changes are in testing now and will be rolled out as soon as we’re convinced that they’re solid. Assuming we’re able to get everything working the way we’d like (and I’m fairly confident that we will) then this will address issue #2.
So that leaves us with issue #3: client performance. Some time ago the WvW team acquired an engine programmer who is focused 100% on this issue (and he is being assisted by another engine programmer who isn’t officially on the WvW team). They’re working on some really fantastic optimizations and engine modifications which we hope will allow even min-spec clients to render all the players on a WvW map. We’ll be talking in more detail about the specific changes they’re making when things get just a little more nailed down, but I can say right now that I’m very impressed with the work they’ve done already.
https://forum-en.guildwars2.com/forum/pvp/wuvwuv/The-real-problem-here-is-invisible-enemies-Give-their-algorithms-time-to-match-servers-properly/page/4#post356817
This is a multi-faceted issue that involves both reporting from the server to the client and client asset loading. Much like a super villain team-up these two parts of the issue are combining to make an unpleasant situation worse. We’re pursuing both parts of the issue and hope to see incremental improvements as we get fixes in and tested.
The reporting issue is really all about performance tradeoffs. Every decision that the server makes about what to report to which client consumes resources, as does the act of reporting itself. These resources (server CPU, network bandwidth, etc.) are finite and are the same ones that are used by every other aspect of WvW as well. How we make use of those resources determines the number of players we can support in a given map and how smooth the simulation feels. The system that we have in place now constitutes an attempt to strike a balance between a perfect simulation that handles all the details and makes them available to every client immediately and a simulation that supports a reasonably large number of players while maintaining smooth performance under most gameplay situations. This is a true dilemma because we really want to achieve both of those goals completely and simultaneously but that just isn’t possible at the moment.
Could we throw more hardware at the problem? Maybe, but the servers that we’re running on now are Serious Business™ and simply buying faster CPUs likely wouldn’t gain us even a linear increase in performance. With today’s hardware I believe that we’re likely to gain far more improvement from code changes than we would from slightly faster CPUs. As you might imagine the way that we manage client/server communication is pretty well core to the way our game works so making changes to that system is a tricky affair that must be undertaken with great care and much testing. Further, since we can’t really create any more resources (CPU, network) every substantial change involves making a hard decision about performance, scale, and completeness of the various aspects of Gw2. Some of the most robust, correct, and appealing solutions to this issue are also the ones that will take the longest to implement correctly, thus adding response time into the mix of factors we need to consider. In a situation like this, sadly, there are no easy answers. That said, we’re evaluating possible changes to reporting even now and are committed to making WvW into the best experience we can.
The client issue relates to the way that we load assets when preparing to display characters. WvW hits this more than most other parts of the game because players are pretty much the most complicated characters that we have and, especially at higher levels, they tend to be quite varied (so things like texture caching don’t help us as much as they might elsewhere in the game). WvW tends to have much higher player densities than the rest of the game so that’s why we see these issues coming up in WvW more than elsewhere. This asset loading issue will be influenced by client hardware (kind of like saying water is wet, I know) but we see this issue crop up on even high end systems so it’s clear that hardware is not the major determining factor. So, while better hardware may improve the situation a bit it won’t make the client issue go away completely. At this point we have a solid repro of the client issue and we’re aggressively pursuing fixes.
Currently playing: GW2
Going cardboard starter kit: Ticket to ride, Pandemic, Carcassonne, Dominion, 7 Wonders
I am no where near as technically proficient as Quizzical but even I can see that the ANet's post about culling doesn't address OP's concern.
Course we can say 'its not a bug, it is a feature!' but I tend to deal with facts and bugs are bugs. Bad game design is sometimes just that, bad game design.
Gdemami -
Informing people about your thoughts and impressions is not a review, it's a blog.
I wont pretend to be techy and understand your long post quiz, but i wanted to throw something in there you might have missed, possibly. You could very well have said it in your post somewhere. It's hard to explain, but i'll give it a shot.
The data on movement of other players seems to be calculated client side. If another player on your screen moves left, the server seems to register that, but lets your client do the 'how much and how far', which, when tinkering with client side data of your OWN character, will apply to theirs. For instance, when using a hack program to make yourself move at 50% increased speed permanently, it will also make OTHER characters on your screen move at that speed as well, causing desyncronization.
What ends up happening, is youll see players falling off cliffs, or running against walls, or jumping when their is no need to. On THEIR screen, they are hopping from rock to rock, whereas on MY screen, they are jumping around in the middle of a field of grass.
So instead of 'X player is at position 123, -123, 321, then 124,-124, 320, then 125, -125. 319' being sent to your client to render, it simply says 'X player is moving left....left...left....up...up....left...jumping...jumping' and it lets your client decide how much and how far that movement is going.
It DOES, however, seem to check both your current position, and the other characters current position( from each their own client) when attacking. So, i could be standing in front of an enemy player, hitting the button to attack, yet it will still register as Miss or Obstructed, as on the other players screen, they are far away or behind a wall.
I think GW2 is a beautiful game, and have found said program to let me reach places i shouldnt to take great screenshots.( For instance, using a Climb hack, i have pictures of my asura sleeping in the Statue of Dwayna's arms, as you cannot normally climb up to get in said arms.) It is not strange to be flying above rata sum, snapping pictures, and see every player on the map zipping around in the sky with me as well.
So, in short, i think it's an error in the way they use clients, instead of sending coordinates to you to render directly, it is sending general movements for your client to decide on its own. I believe this is a BIG source of culling, as you must wait for YOUR computer to 'think' about where players are. As we know, players have vastly different computers and they each have their own limit to what they can 'think' about at once.
Again, i'm not techy, so this might not make a lick of sense. apologies. Hope i added something to your conclusions.
The Deep Web is sca-ry.
Nothing I do affects other players, nor can be used to gain me a higher advantage over them. As i said, i's quite hard, if not impossible, to use the program to 'cheat'(as in, fly over WvW and hit people from the sky) since anything i set to my client applies to any characters on my screen as well. So sure, i could run up the side of a cliff and try and hit players, but it simply wont work, as my client will think they are somewhere they never are. I have 436 screenshots of gw2, currently being photoshopped to perfection, simply for my own collection. That is the limit to what anyone can do with it. So if karma's gunna come get me for wanting pretty pictures, god help my soul.
My point, outside of that, was to show that when an enemy zerg is coming for you, your computer is thinking about where they are, how fast they are coming, etc, instead of simply being transferred hard coordinates to.
The Deep Web is sca-ry.
Cullinng is best known as hidden surface determination, hidden surface removal, occlusion culling or visible surface determination.
Guild Wars 2 uses the Umbrs Occlusion engine.
No, culling isn't a bug.
And of course there is tons of information directly from Anet for those actually interested in the problem and not on bashing Anet.
https://forum-en.guildwars2.com/forum/pvp/wuvwuv/January-WvW-culling-loading-changes/first#post1272774
In the January update we’ll be making a couple of preliminary changes to WvW.
1. The first of our engine changes will be coming on line to help improve character load times by using fallback models.
2. We’ll be switching over to the culling methodology that we trialed in December.
The engine change we’re making uses fallback models to represent characters until their detailed models are fully loaded. The fallback models are cached so that they can display without any asset load delay and there is a distinct fallback model for each race/gender/armor-class combination. As a result of this change players will be able to see characters represented as fallback models as soon as those characters are reported to the client. Once the specific, detailed model for a given character is completely loaded from disk the fallback model will be replaced with the detailed model. This visual compromise will help to ensure that players see other characters as quickly as possible in WvW. Please note that this change does not eliminate delays due to culling, it only addresses delays due to asset load times. Players on higher spec machines would therefore expect to see fallback models less often than players on lower spec machines. This change also lays the groundwork for more extensive uses of fallback models in future updates.
In December we ran a one matchup trial of an updated culling system. Based on all the feedback we received, both during and after the trial, we will be transitioning to the updated culling system that we used in the trial. This update allows the culling system to handle allies and enemies separately so that being surrounded by a group of allies will not impact the culling of enemies (and vice-versa). The general consensus after the trial is that this system lead to a better player experience in WvW. We further saw that some of the issues people had with the new system were related to asset load times rather than culling issues so making this change in combination with our character loading improvements should lead to an improved overall experience. It is important to note, however, that while we believe this change is an improvement to the WvW experience it does not fully address the issues with culling and we are still working towards our goal of removing culling from WvW completely. This change is intended to give players an improved WvW experience while we continue work on our more comprehensive solution.
While this update only contains a couple of visible changes to WvW it lays a lot of important groundwork for future updates. We have some exciting changes coming and this update is just the beginning!
------------------
Krakah, no, the behavior that you’re describing is the server culling which characters get reported to your client. This update doesn’t eliminate that, though it biases the algorithm such that being surrounded by allies won’t cause you to be unable to see any enemies (and vice versa). Disabling culling entirely is something that we’re working on still and this update lays some of the groundwork we need to do that.
--------------------
That capability isn’t part of the January update but in future updates we’ll be using fallback models more extensively to help with performance in high population scenarios. The fallback models are cheaper in a number of ways including poly count, texture size, and animation count & complexity. I don’t think it would be visually satisfying to have nothing but fallback models on the screen but we’re definitely exploring the right balance. You will see these additional changes related to fallback models in the coming months.
------------------
Hi all, I think a little more explanation is in order.
First, let’s call the culling system that we’re switching to “affinity culling” just to make it easier to talk about. Under affinity culling the system handles enemies and allies independently. This means that the maximum number of allies that you can see under affinity culling is 1/2 the maximum number of characters (combined enemy & ally) that you could see under the original culling. Ditto for enemies. In exchange for that cost he benefit that we get is that running with (or through, or past) a large group of allies (e.g. a guild) won’t prevent you from seeing the enemies who are closest to you.
During the initial trial of affinity culling we found that a number of players reported asset loading issues that were highlighted by culling. Any time that your client is aware of another character at all (dot on the map, targetable in world, nameplate is visible, etc.) then culling is no longer a factor because that character has already been reported to your client. In that case if you can’t see the character the issue is one of asset load time. The fallback model feature which is shipping this month directly addresses those issues by providing a cached model to show immediately when the character is reported to the client.
The order of operations looks like this:
1) Character X enters player’s visibility
2) delay due to the mechanics of culling
3) Server reports character X to client
4) delay due to asset load time
5) Character X full model is visible on-screen to the player
Using fallback models we end up with this instead
1) Character X enters player’s visibility
2)delay due to the mechanics of culling
3) Server reports character X to client
4a) Character X fallback model is visible on-screen to the player
4b) delay due to asset load time
5) Character X full model is visible on-screen to the player
As you can see we’ve made the asset load delay unimportant (or at least less important) and allowed the player to be aware of character X sooner (in some cases quite a bit sooner).
The combination of affinity culling and fallback models provides a better experience than affinity culling alone. Even so, the affinity culling is not intended to be our last change to the system, but rather to hold players over until we can make more extensive updates to the system (which take time to implement and test). In future updates we’ll be making changes in an effort to eliminate the delay due to culling (step 2 above) and to tell each client about character X as soon as the server decides they have become visible again. We hope to do this by removing culling completely and preserving client performance though a mix of network and engine optimizations, the more extensive use of fallback models, and sundry wizardry.
As I’ve said in the past our ultimate goal is to remove culling and we’re pushing hard to make that happen. This update represents the first steps in that direction and much of what it accomplishes is to lay the groundwork for our upcoming updates. The next few months are an exciting time for us on the WvW team and we’re very excited about the changes are coming.
I don't see any communication problem or pretending the problem exist.
Currently playing: GW2
Going cardboard starter kit: Ticket to ride, Pandemic, Carcassonne, Dominion, 7 Wonders
Notice that ANet keeps on harping about models and how it doesn't render them and how the bandwidth / processing isn't there on the server / client etc etc?
Notice that they don't say that clipping could be why? Notice that they never say it is their 'engine'?
I have some very basic understanding of this but even I can see that they wrote a whole lot of 'stuff' without actually telling us it is their engine that's the problem.
Edit 1: if you want to refute Quizzical with technical knowledge go ahead. I'd love to see someone try cause it'll be hilarious.
Gdemami -
Informing people about your thoughts and impressions is not a review, it's a blog.
Culling is only buggy when you notice it.
If you can't see it working - then it's doing what it's supposed to.
http://lyrics.iztok.org/verse/Lynyrd_Skynyrd/Simple_Man/80615
I had a blast reading this post. It reminded me of my 3D computing courses and exams at Computer Science
I always kept thingking about GW2 culling issues and always said that it could not be just the computing of objects and trimming out what is not supposed to be rendered; being a developer (not 3d rendering, but server developer) I see very often the impact of poor server code on client machines.
If I were to guess what is the issue with the "culling bug" I'd say that the server code on ANet servers that deals with the player's positioning in the world is badly written and the client side computation is rather OK; I base my assumption on the fact that when the groups that fight is small the game seems to handle things well, but when one of the group has a size of 30+ things start behaving strange:
- I fight an emeny in melee range and suddenly it dissapears and 10 enemies apear at 1500+ range
- I see projectiles, spells cast and then the player is rendered but the AoE spells do not render anymore, just the damage, when suddenly the player is gone, but his/her spell is visible
- Friendly NPCs dissapear in world (not WvW) without a reason; I am the only one in the area.
All these to me point to be bad algorithm which decides the priority of models to be displayed and it seems that given the same input (or a small variation) it produces a different state of the rendered world.
I might be wrong on this, so do not quote me!
V.
What do you think renders the models? What do you think send the information regarding player position?
Their engine mom?
The order of operations looks like this:
1) Character X enters player’s visibility
2) delay due to the mechanics of culling
3) Server reports character X to client
4) delay due to asset load time
5) Character X full model is visible on-screen to the player
Using fallback models we end up with this instead
1) Character X enters player’s visibility
2)delay due to the mechanics of culling
3) Server reports character X to client
5) Character X full model is visible on-screen to the player4a) Character X fallback model is visible on-screen to the player
4b) delay due to asset load time
I think the OP is underestimating the extensive bandwitdh required as the main culprit rather than anything regarding the physic engine (which is something I bring often since I feel most people have no real perception of how taxing is a good physic engine and how that lead to zones connected by loading screens opposed to semaless worlds that have no collision detection).but to the high amount of information going not only in the server but between server and client.
Which is why one of the solutions pointed is to initially send a standard representation of the enemy profession and only later send the customization details.
In fact that also goes more in line with how DEs break and how in PvE sometimes you only see players when you are almost on top of them.
Want to read more about bandwitdh management with tons of players involved?
http://www.fsegames.eu/devblog1.html
Currently playing: GW2
Going cardboard starter kit: Ticket to ride, Pandemic, Carcassonne, Dominion, 7 Wonders
Pretty much every MMORPG ever made (for that matter, every 3D game ever made, etc.) not only uses culling, but uses it in a bunch of different ways. A project I'm working on will attempt to cull things at seven different points (three CPU-side, and then four different stages of the rendering pipeline), and only things that pass all seven of those culling tests will ever be drawn. And that's with no network code at the moment; once I add that, I'll add in some network-based culling, too. Culling is an intended and necessary performance optimization.
The problem is when it's implemented wrongly and you cull things that you shouldn't. That's what Guild Wars 2 has a pretty bad case of. If implemented properly, players will almost never be able to directly see how and where you've implemented culling. For network culling, it's "almost" never because heavy lag spikes may be able to expose even properly implemented culling. You can also reasonably have a little bit of near plane clipping expose where culling is done for small objects with no physics attached. But all other culling should be completely invisible to the player because it only culls things that wouldn't have done anything but bog down performance if they hadn't been culled.
Sandbox means open world, non-linear gaming PERIOD!
Subscription Gaming, especially MMO gaming is a Cash grab bigger then the most P2W cash shop!
Bring Back Exploration and lengthy progression times. RPG's have always been about the Journey not the destination!!!
Whether computing a distance between two points is child's play depends on how many times you have to do it and how fast. A trillion times per second certainly is not.
For network code, yes, you're probably just looking at the distance between two points. But for some things, you're looking at the distance between two irregularly shaped objects, and having to ask how far one of them could move in a particular direction before they collide--and then which direction they should subsequently go if they do collide. That's computationally intractible if you have to redo it a huge number of times every single frame. That's why physics computations are completely independent of graphics computations and use much simpler shapes.
Most likely, all collision detection computations are done first client-side, and then some (but not all!) of them are verified server-side. Where to place the camera is done client-side only, as even if you verify it server-side and find that the client was wrong, it's too late to do anything about it as the client has long since moved on to the next frame.
Not only that but also when you see them it is too late.
And anet isn't talking about lag but delays in assets load and server to client communication.
Currently playing: GW2
Going cardboard starter kit: Ticket to ride, Pandemic, Carcassonne, Dominion, 7 Wonders
Synchronization over the Internet is actually a very nasty problem. Among other issues, getting it exactly right is literally impossible, as to say that an event happened at the same time on a bunch of different computers all over the world is scientific nonsense. (The best that you can do is to say that the times it happened were within some tens of milliseconds of each other.)
I don't have any special insight into how Guild Wars 2 does it as opposed to how other games do it, but I can talk about what games can do in general. For your own player, the computations are done first client-side, and then verified server-side. The client-side computations of your location are redone every frame, while server-side verification is substantially less frequent; several times per second is plenty good enough. If the client claims to have moved some particular distance in a given amount of time and the server checks and says okay, then the server just updates your position on its end. If the server says, no, that's not possible (e.g., you traveled halfway across the map without using a waypoint in the last half of a second), then it determines where it thinks you really are and tells the client to warp you back.
For other players, the server will periodically broadcast the current position and velocity of all players near you. The frequency with which this happens can vary; if a player attacks, you need to know about it right away. If the player is just standing there and not moving, the server doesn't necessarily have to send ten updates per second to tell you that that player still isn't moving. The client will attempt to interpolate where the other player was sometime after the time that the server announced it. This is something along the lines of, the player was here at this time, and moving in this direction, and 83 ms have passed, so if the player didn't stop or turn, he should now be there. If the client later receives an update saying that the other player stop and turned at some point in the past, then the client warps him to the new position (or may make him run very fast toward the new position to make it look more continuous) and uses it for future predictions.
For mobs and NPCs, the game could treat it the same way that it does other players. But it could also use more advanced AI to determine where they will be before they start moving, and broadcast to clients that, for example, this mob will start moving in this direction 200 ms from now. That lets the client know exactly where the mobs will be ahead of time. One might expect knockdowns and knockbacks to interfere with this, but if all attacks take a few hundred ms to register, knocks can be known far enough ahead of time for the player to know what is going to happen before it happens. That way, the client can know that this mob was here at this time, and will move in this direction at that time, and can draw exactly where the mobs are with virtually no rubber banding.
Some NPCs could be done entirely client-side if they never move in response to things in the game world. If an NPC can never move, then it can be done entirely client-side. If it always walks a fixed route at fixed times and will not stop for anything, it can also be done entirely client-side.
That culling is implemented in the game is not a bug. A number of particular details in the particular ways that it is implemented are bugs, however.
Trying to insist that it's not a bug because the game is supposed to have culling is like insisting that if some particular item mall item doesn't work at all, it's not a bug, because the game is supposed to have an item mall.
While that's a pretty good summary, it's not quite right. One may well be able to notice some things disappearing at a particular distance far away even though it's implemented intentionally.
I'm not aware of any game that has ever had loot bugs that were basically unfixable. That a company doesn't bother to fix a fairly simple glitch doesn't mean that they couldn't have fixed it if they made it into a major priority. To completely fix the culling bugs in Guild Wars 2 would likely cost ArenaNet millions of dollars.
There are a bunch of different culling bugs in the game, not just one. One culling bug may be network-related, but it's not the only one. If you want to blame everything on network code, then how do you explain why terrain sometimes gets improperly culled? That's done completely client-side.
In other words, the cost-benefit just isn't there?
(There's a category of bugs that can be roughly defined as "too expensive to fix, too many man-hours", without question.)
Self-pity imprisons us in the walls of our own self-absorption. The whole world shrinks down to the size of our problem, and the more we dwell on it, the smaller we are and the larger the problem seems to grow.