Is a level of detail system planned? I noticed that the game is rendering everything on a planet from a considerable distance. Seeing individual tanks or trees or even pebbles from orbit shouldn't really matter. Especially when they are obscured by strat icons. I appear to be bandwidth limited on a lot of units and a good LOD would help that immensely.
As long as I know its already here for effects system, planet textures and possible features like stones and trees. I do thing there is LOD for features because few versions ago many AMD users seen lighting bugs with trees when see them from some distance. Are you talking about network bandwidth? I don't think LOD will help here at all because server don't know anything about unit models or animations, it's all done on client-side.
Afaik, FSB isn't the limiting factor in the game at the moment, from what the devs have said the issues are all due to cpu bound code (which is most of it atm). That said, there is a definite need for a LOD system, this is less of an issue on windows, but on macs the game is unplayable with multiple earth like planets, because ofo the extremely large amounts of foliage and rocks on the planets; this -although not problematic when focused on one planet- is a major issue when you can see a second planet on the edge of your screen, from what i can tell it devolves into a fill rate issue (or something along those lines).
There already batching system for features on planets, but it's don't work on Mac due to OpenGL 2.1 core profile usage, e.g shaders they use for that purpose need newer GLSL Since next version PA should use 3.2 core profile on Mac so it's will work better.
We are already doing LOD on trees, pebbles, etc. The reason why we keep rendering all of the trees, pebbles, and rocks when you zoom out is because varrak and I spent a good chunk of time making the transition from the full models to the LOD version as nearly seemless as possible. Texture resolution on planets is dynamically changing all of the time, so planets in the distance might be using a surprisingly small texture. Though as SXX mentioned, not all of this works on OS X because of limiting ourselves to OpenGL 2.x context, which we're moving away from. But yes, we don't do LOD on units yet. We haven't even done any kind of optimization work on unit rendering. There's a ton of work to do with instancing units like we already do with trees that should make them significantly faster to render.
I certainly appreciate a good seamless transition but I still have to question the value of rendering pebbles at all from high orbit.
No it's quite certain. Under and overclocking different parts reveals where the bottleneck is. And FSB is my result. I am running a core 2 and they have very low bandwidth compared to even weak newer CPU's. So to support older chipsets you need to have options that cut down on that load. It also makes sense because with a lot of stuff on the screen the main factor is how fast you can pump that stuff into the GPU to be rendered. Polygons are free, but everything else isn't.
The game is very memory intensive, on both GPU ram and System RAM, and even the Virtual RAM in the page file gets hammered on my system.. I agree ram to gpu speed would help lots, i have discussed this with varrak, and one of the reasons my crappy acer tablet running an i5 3317u 1.7ghz cpu with intel hd 4000 performs better than some high end systems is because of the unified memory architechture.
Not everybody want to see icons all the time. I'm personally use "range dependent" option for "show terrestrial" and like how battles/units looks from orbit. Though I don't have anything against some option for low-end PCs that will disable rendering of everything for performance.
I don't think icons and pebbles are related concepts. What I mean is the only way you can even tell they are there is by the aliasing of their lighting. They add nothing to the visual experience at such a distance. Even units appear as little more than aliased dots at this altitude. There's just no visual value to rendering much of anything from such a height.
Sorry didn't read to carefully. I think main reason it's that everything still need tons of adjustments. I doubt that rendering system can know exact size of some rock because technically it's usually one model with multiple small objects. E.g if you check assets used for planet generation you'll find what I mean.
It just makes it seem like there is no LOD system of any kind when tiny details don't disappear even long after they've stopped being "visible" other than through rendering artifacts.
Isn't LOD mapping related to models and how complex they are based on range. As far as i know from all the models i have imported and looked at are very low in geometric complexity, around 600-800 tris. commanders are around 9,000-17,000 from ones that i remeber importing too. It maybe possible uber could use a 3d renderd sprite system like TA used back in the day, 15 or so year ago. have them as Imposter units or very low geometry imposter units for renereing zoomed out.
This doesn't work so well when you have a floating camera. TA could do some crazy optimisations like render-to-sprite for structures and wreckages that weren't animating, because the camera angle could not be changed to expose them as fake. Pretty much anything that wasn't moving (except mobile units, I don't think they were ever cached) was generally turned into a flat 2D image.
I would argue this is the original goal of a level of detail system; there should not be a noticeable visual change. For especially small and sparse objects, like some of the small rocks, we could quite easily just stop rendering these at a certain distance and no one would be able to notice. Trees, however, can be quite small individually, but if we turn them off the look of a planet can change drastically. We did this in the past in our first pass at LOD when all we did was turn off features (as we refer to trees, small rocks, etc.) when you got far enough away from a planet. There's still some work we could do here, like not rendering the small sparse rocks, but right now they're fast enough to render that they're not the bottleneck in our rendering performance. Once (if?) features become a notable fraction of the rendering frame time again they'll become a focus of further optimization. As slow as you might think rendering 20,000 trees is, or as slow as the game current gets when rendering 1000 units, the actual rendering of those trees and units still aren't yet on the top of the list for worst performers, though I suspect units rendering will be shortly.
The issue of rendering imposter for a sphere was an issue we kind of solved already for rendering features. Everything is replaced by 3 quads with renders from the three axis of the object. The result is a surprisingly convincing approximation for most shapes. Some might note that only 3 renders isn't actually enough to be accurate as it's one on side of each axis, but at the ranges we're switching to these imposters the silhouette is more important than the interior details. We've had discussions of doing the same style impostors for units once we get to doing LOD for units. It'll take some experimentation there as we do things like animation and procedural aiming that can significantly change the appearance of a unit in ways features do not have to deal with. In all likelihood it will not be a significant enough change to matter, but in case it is we could split the body of a unit and the turret into separate impostors.
The goal of a LOD system is to improve performance in a way that scales with perspective. If it is less noticeable that is great, but it isn't the goal. Additionally, not every machine is identical, each one has different weaknesses and strengths, which is why you need graphics options to begin with. I know that my machines main weakness is FSB bandwidth and so I need an option to cut down on the amount of stuff being pushed through that pipe. Scaling the LOD down would do just that.
