My preference for LoD has always been enabling high quality assets close up, rather than making low quality assets disappear at a distance. There may have been a time, back in software rendering, when LoD was about performance, but then I also seem to remember the popularity of ideas such as procedurally scaling back the number of polygons per model to adhere to a fixed polygon budget. Ah, such primitive times. One tricky thing about LoD is that, as your screen resolution gets higher, you can perceive more detail, making LoD transitions more obvious (imagine 3840x2160 screens from the 4k revolution). The higher resolution, the less aggressive the LoD must be, and the less benefit you get from LoD at all. What bmb really needs is the -nofeatures flag back. Possibly as an in-game option. Though, I have a Core 2 Duo and I don't remember it being much of a bottleneck, just a modest boost.
It's not a preference, a LOD system does both of these things. They are not exclusive. Remove details that aren't useful at a distance, and reveal them up close. A higher resolution reveals a lack of details at all LOD levels, so it doesn't matter. I don't see why lower resolutions should be punished so higher ones can benefit. A good LOD system would scale to both situations. LOD will always be about performance. It certainly has nothing to do with software or hardware rendering. And it will not go away because the law of perspective will not go away. We will never have infinite power so no matter how much detail you are rendering, it will always make sense to remove the details that you aren't seeing. Procedural reduction makes no sense because LOD is about reducing the amount of processing, whereas reduction procedures add processing. Tessellation makes more sense because it adds more detail without increasing the memory or bandwidth requirements. And it is important for systems such as these to scale. LOD systems are typically based on a distance from the camera, and it easy to apply a multiplier across the board and scale those distances, including the distance at which it completely stops rendering. This is how most games I know of scale LOD. Polygons are of course not everything, and more intelligent LOD systems batch up multiple objects that would require several draw calls up close into a single draw call from afar.
The no feature flag won't be returning, and the game already renders each type of feature visible per planet as a single draw call using instancing. In the past we used the approach of batching meshes together into single meshes for reducing draw calls, but this resulted in mesh data for planets using > 1 gigabyte of memory by themselves. Most of our LOD systems currently use user defined distances. I would actually contend this is the wrong way to do things, though it's the easiest to implement. A more correct way is to base it on relative pixel size, which can scale with both high and low resolution. This would work well for many objects, but for some things even this is wrong since it's not always about the size of single objects but the group, like particle systems which can vary in size significantly, or the forest of trees situation I mentioned earlier. This ends up making the idea of just hiding things "too small to see" harder than it seems. Procedural reduction gets used pretty frequently in games. Sometimes as a pre-process to generate discrete LOD meshes, sometimes in real time. For games where much of the content is dynamically generated doing pre-processed LOD isn't an option. Spore for example does dynamic LOD on everything in real time. Just because it takes processing power to generate the LOD, as long as it's less than the difference between rendering the full detail version of a mesh vs. the low detail version + processing it is still a performance win. Usually any kind of dynamic LOD generation will be cached too, so you only need to spend the processing power to do it once. The imposters we use for features are generated like this. Tessellation has for a while been talked about from the software side as being a way to reduce bandwidth and increase detail like normal maps had before. On the hardware side it hasn't proven to be as useful as people wanted. Part of the problem has been GPU performance hasn't been fast enough to actually handle the processing of tessellation efficiently, so just transferring and storing a high poly model ended up being faster. Now GPUs are fast enough and stalls caused by the memory access patterns of using tessellation mean it's still too slow to use for most things. A third problem that Pixar has been trying to fix, and I hope does start showing up in games more, is many of the best methods of handling tessellation have been tied up in patents. OpenSubdiv and its related patents have all been released for free public and commercial use, but it'll still take a few more generations of hardware before it becomes something truly useful on the PC. It might start getting used on the new consoles though which I find exciting.
This is not the correct way because LOD needs to scale with the performance of the system, not the size of the object on the screen. While screen size is a good guide for making it look good, it should only be treated as secondary to the performance concerns. It is good for creating the defaults, not for an absolute setting that ignores the system it is running on. It is extra wrong because it mixes up fillrate and render overhead, tying two unrelated performance aspects together. If you have good fillrate but is limited on the other hand you might be running at a high resolution which the LOD system will punish you for. GTA IV had a thing exactly like this where the detail of the water reflections was tied to the resolution instead of what the machine was actually able to render, causing a massive performance loss for most people with little to no visual benefit. All because someone at rockstar had to be fancy and tie two unrelated concepts together and hardcode it. Don't be that guy.
Have patents slowed down any other improvements? I have read extensively into patents and their role in technology, so this peaked my interests. ( sorry if this is slightly off topic to LOD) I would hate for the patent system to slow down the development of faster and easier graphic rendering methods for games and other digital media.
Yes, actually. There's been a ton of recent tech that have become quite common that didn't happen earlier due to a particular patent. Marching Cubes. Up until 2005 the most efficient and straight forward implementation for iterating through a 3d grid of data was patented, so the graphics industry as a whole simply avoided it. As such our hardware and research is usually focused on techniques that don't overlap. Marching cubes is an important algorithm for dealing with voxel data, specifically creating smooth meshes from voxel data. I suspect water in Minecraft and caves in the Crytek engines both use something like marching cubes to generate the surface mesh. This does actually relate to LOD as well; a popular preprocess LOD generation system works by taking a high polygon mesh, creating a voxel representation of it, resizing the voxel data like one would a 2d image to fit a specific pixel size, and creating a new mesh from the voxel data. The results can often be nearly perfect LODs that look exactly like the original mesh. Recent Halo games use a similar technique for their LOD system which can even run in real time if need be, and Pixar has been using a similar concept as well for reducing detail and increasing rendering speed of things in the distance or that will be obscured by depth of field and / or motion blur. I will say the topic of patents is a nasty one. The nature of patent law is that it is better to infringe on a patent you don't know exists than one you do. If you know a patent exists, even if you didn't know your technology infringed on it, it can be argued you could have and thus you willfully infringed. This is ugly because often software patents can be in the form of arguably obvious mathematical reductions of known common algorithms. Carmack's Reverse is a famous example of this, which you can read about here: http://en.wikipedia.org/wiki/Shadow_volume
The ideal for any LOD is for the change to be unnoticeable, I still contend this is the ultimate goal of LOD. The reason to make the change at all is of course for performance reasons, but if performance is the only reason then not rendering something is a far more efficient technique. If you look back at older games the solution was almost always a wall of fog or for the world to just simply end. Granted, this is a type of LOD, but it's a last resort. Basing something on pixel size for LOD is the "best case", max detail starting point. For the PC performance settings should of course alter this base value to switch to the LOD version of objects sooner, and possibly eventually hide stuff. A perhaps unknown element of LOD in the Supreme Commander games is the strategic icons hide the units being turned off at distance. This is something we'll probably eventually implement as well. The silly thing is rendering the strategic icons in PA can be slower than rendering the units... we're working down the list right now, we'll get there eventually.
I don't think the claim that the "ultimate goal" is one thing, then admitting right after that the whole purpose is in fact another is a very consistent position to hold. The least noticeable approach is of course no LOD with some decent antialiasing. If perfect detail was your goal you wouldn't bother with a LOD to begin with yeah? Also another thing, I noticed the strat icons render at different distances depending on the size of the planet. When of course it should render only when the units are too small to see otherwise, which would be the same distance regardless of planet size. I imagine this is just a temporary hack?
Strategic icons don't just show when you can no longer see a unit, they should show when they will be more useful than just showing the units themselves. Also since each unit varies in size and the curvature of the planet varies the distance a unit is from the camera purely basing when strategic icons show based on the visible size of each unit would result in a messy mix of 3d units and strategic icons. What you want, and what we do, is turn on all strategic icons at once at a specific zoom level. I believe this is a constant number, regardless of planet, though this is muddied somewhat by being based off of the planet's radius as passed to the planet generator and not the actual radius as generated after some amount of randomness is applied in the planet generation. I had a conversation just a week or two ago with two of my coworkers about expectations surrounding those kinds of numbers and their actual meaning in regards to the final planet dimensions. (Hint: they can often be wildly different, because we add noise as well as artist made mountains and valleys on top of these supposed "fixed" numbers.) To say strategic icons are an area of continued investigation and experimentation would be an understatement. Oh, and for why strat icons are so damn slow... this kind of goes back to the original topic of LOD methods as well. I mentioned how we used to batch together all the trees and rocks on a planet into a single mesh and upload it to the video card in one chunk with the expectation they would render faster (and instead used more than a gig of RAM on the GPU which caused them to stall rendering). This is what we do for the strategic icons, and for particle effects. Every frame we take every strategic icon (and health bars, and ammo bars, and a few other things) and build a giant polygon mesh and upload it to the video card. The next frame we destroy that mesh and make a whole new one. If you're thinking "gee, that seems awfully inefficient when all you're rendering is the same square with a different texture on it" you'd be right, perhaps even more than you realize. This is why varrak has been focused heavily on optimization work on just this kind of thing. Units, however, exist as meshes that have already been sent to the video card and don't need to be updated. Each update it's just the position and bone locations that get updated which can be far less data than the giant mesh for the strategic icons for the same number of units. Eventually the time it takes to transfer all that data about the giant strat icon mesh from the CPU side (where it's created) to the GPU can be longer than it takes the GPU to render the units. Once we get instancing setup for strategic icons, like we already do for trees and pebbles, it should be way faster to render those than the units. At that point we'll look to get the units instanced too... which won't mean they'll become faster to render than the strat icons again, just that the'll hopefully be even faster to render than they currently are. Edit: And for those of you who might ask, "why would you do it like that to begin with". Because that's the way these things work most of the time, and it's not really a problem until you're trying to render 10,000 of them at once. It's also because many of these things were built on top of systems never intended to handle what we're doing with them but it was the fastest way to get it working.
I love all this information. Now I want to see just how much icons affect my framerate. Up until this point I've thought units and mountains have been the two worst things affecting my framerate. *flips Show Unit Icons to 'never' * Are selection squares or focus trails part of the same system as the icons? There's a mod for translucent icons that would probably have mixed feelings about that.
If you start off with bad framerate turning off icons probably won't help. But yes selection squares are part of that same family. Basically they're all using a system intended purely for debug rendering so it was designed for robustness rather than speed. Focus trails are slightly different in that they're done with the particle system, but they suffer from the same issues. Also, a little trick if you're experiencing slow framerate when zoomed in on groups of units: Ctrl+J, the default for hide fog of war rendering. Guess what else is super duper slow.
How much do they pay you to be wrong all the time? No offense. If you could make out units clearly from high altitude then no icons would be needed. You are correct that icons should kick in all together and not for individual units. But it still needs to be at the altitude where unit meshes, in general, are no longer useful for telling what a unit is. For the sake of the argument lets say that this is about 1000 meters away from that mesh. All planets should render icons when the camera is 1000 meters off the surface then. What is currently happening is that they seem to render them as a function of how far the camera is relative to the radius of the planet. What that means is it could be hypothetically 100 meters for a very small planet, and 5000 meters for a very big one. Obscuring meshes long before they become too small, or way too late, long after they are little more than useless dots. As a minor critique I don't find the current icons very useful at all in terms of their design. It just becomes a big blob of nothing to me. So I actually zoom in past their render distance when I can, which is also difficult on small planets. I am working on modding in an alternate set that fits my preference.
Everything is a trial & Error Process, can't be right the first time. Sometimes things have to get done and then polished later. Thanks for dropping some serious knowledge @bgolus .I'm pretty sure I learned more then I anticipated in LOD. also, Critics gonna critique
This statement alone is fairly silly, Have you ever flown in an airplane in real life or flown a UAV, even at low altitude things on the ground get so small it begins to make it hard to tell what is what, with lower resolutions on a uav it gets worse. The only way to render units at a high altitude and have them visible would be with a massive resolution in HD you would need a 60+ inch HD tv with an immensely high resolution too or multiple monitors in a grid. How many people do you think can afford this kind of setup too? not many... In my opinion strategic icons work if they were toggle-able so a player can hotkey them on and off. Strategic icons work amazingly well when you have mixed units in blobs or when you need to do a quick update on the positions of things on the visible area of the surface you can see (if i had a second window with the view of the other side of the planet, id have those icons on all the time.)
Do you propose icons is all that is needed? Then why bother with 3D graphics at all then? It's a GUI concession to the fact that zooming out leaves units as tiny dots on the screen. Other RTS games never used this concept, TA didn't use it, because these games are always "zoomed in" and the unit graphics are enough to represent themselves. The latest fad to cover the screen in icons in games really to me is criminal first and foremost to the 3D artists whose work it covers up and replaces. Credit must be given though, when zoomed in Planetary Annihilation is one of the few games I've played lately that can actually be played completely without any kind of overlays or things obscuring the game world. No bars or stats or numbers or indicators or nothing. It's zen. And I hope it stays this way, and only invokes overlays such as strategic icons when absolutely necessary.
While I agree that rendering them to-scale is not a good way to go about things there are ways to render the 3D models in all their glory and have a clean view, too. Take a look at R.U.S.E., irrespective of zoom level most unit models took up the same amount of screen-space. Zooming in/out gave the impression of them shrinking/growing, actually. When zooming out units models would start to overlap eventually - at which point those units are aggregated and shown as a stack of tokens with the unit model on top. Rinse and repeat for more distant zoom levels. The same could be applied here. If there are different unit types present, one representative of each group might be shown, perhaps annotated with a small number denoting the individual unit counts. So always rendering models would be possible. If such an approach is feasible or even desirable in the context of PA is another matter entirely, though. All coming down to personal preference again I would say - which for me is icons. As an aside, are there plans to bring back the awesome cartographic view from SupCom? That was priceless to have on a second monitor.
