It looks like you're new here. If you want to get involved, click one of these buttons!
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.