aeonios

I really don't know. It's possible though. Those are called impostors, and they only work at long as the angle between the camera and the object doesn't change by much. For games where you control a character with a fairly low camera angle and relatively slow movement across the terrain this can work fairly well. For 0ad it wouldn't really work at all.

I'm pretty sure I've seen texture lod flickering artifacts on both terrain and models (particularly grass props) due to the lack of trilinear filtering. You'd likely only see it in atlas though, or if you remove camera restrictions since the transition distance is pretty far. If they use geometry mips then they're probably pre-generated using a human-guided process. There are also techniques for mipping terrain geometry dynamically, even though it isn't technically closed, but the concerns are different than for something like palm leaves. This isn't even really an LOD issue though, since you don't necessarily have to be zoomed out far enough for LOD to kick in for the trees to eat your GPU. If it could be fixed automatically I'd be working on that instead.

We don't. Mostly the game doesn't produce use enough triangles or texture bandwidth to justify it. These trees are basically the worst cases, and mostly because there are often 9001 of them on screen. We do use texture lod though (which is why certain terrain textures do a weird flickering thing when zooming in and out). No. Instancing only reduces the number of draw calls, which helps in certain cases, but in the case of these trees the number of draw calls isn't all that high but the number of triangles processed per frame is huge (3-4 million sometimes, vs 750k max just for units and buildings). The only way to reduce that is to reduce the number of triangles in the models. The engine can provide additional opportunities for reducing the number of triangles, but ultimately that still requires editing the models as well as the settings regarding the way they're drawn. The engine can't remove triangles from models without destroying them, pretty much. There are ways for automating that for closed geometry, but not for open geometry like leaf planes, as far as I know.

No. Millions of triangles sent to the graphics card is expensive and there's no way around that. The best we could do would be to add support for geomips and for double-sided geometry, both of which would require overhauling the art. Geomips are unlikely because they have lots of potential problems, and supporting double-sided geometry still requires culling all the redundant (ie reversed normals) leaf planes from the existing tree models. And that means all the tree models, as well as bushes and pretty much everything else similar.

What do you mean? Hmm.. for that it wouldn't much matter. The biggest problem with a falling animation is the fact that the trunk extends below ground on most trees, so you couldn't just have it rotate over. I don't know much about animations but I doubt a falling animation would be a huge stretch in terms of engine support. I suspect it'd be mostly mod-side since you'd have to make the animation play on resource depletion.

Yeah I figured they were mostly enrique's. Do your best I guess. We'd need to send wind intensity as an instance attribute, which would be open GL 3.1, maybe 3.3, I'm not entirely sure. Seems like it'd be a lot of work and possibly expensive for something people will hardly notice. You could. CPU-side animations would just change the input vertices, but the vertex shader wind anims don't really care what the input vertices are. It'd be expensive and pointless to animate trees though.

I said it does support 3.3. Can you describe a specific case?

We're not looking to require 3.3. Currently 2.1 is required for GLSL, and anything 3.0+ will be optional.

He uses multidrawindirect, so no it isn't. GeForce 240GT PCIe edition which does support 3.3. The number of drawn tris isn't actually the issue here, since the vid card has to do work to cull triangles even if it doesn't draw them, which is why it's bad that we don't support double-sided transparent geometry because then each plane has to be duplicated. If we supported double-sided planes then the number of triangles in those trees could be basically cut in half for free. http://feedback.wildfiregames.com/report/opengl/feature/GL_VERSION It's a bit outdated but still probably relevant. It isn't really possible for us to collect exhaustive statistics but probably still representative. That's why I said we should only combine the quads near the trunk, since you can't see those parts of the leaves well and they don't curve as much. The leaf ends which curve a lot can still use 4 quads to get the fine curvature. That would be a more modest reduction that I had originally intended, but if we can get rid of the redundant planes then we could still meet the original goal of a more than 50% reduction that I was looking for.

What I meant was geometry mips. We don't support those, period. I can't because as is the case for over half of the playerbase my GPU does not support openGL4. And like over half the playerbase my GPU suffers serious framerate loss when rendering over 1mil triangles, even if half of those triangles are hidden. There's nothing "right" about wasting that many triangles, either for giving leaves more detail than is strictly necessary, or for using too many leaves in general, or for using redundant quads for a double-sided transparent 2D plane. If we can cut the number of triangles in half by removing something that shouldn't have been needed in the first place then why not? Backface culling isn't free, but disabling backface culling is.

Why are there random '3's in the late egyptian text? That seriously looks like a bug in game.

You can't remove the back faces because of water reflections. Plus the leaves have an upwards facing V shape so both sides of the leaves are always visible. I think the leaves could at the very least be reduced to 6 quads by merging the inner four that are closest to the trunk and leaving the outer four to produce the curvature. The dangling leaves at the bottom could definitely be reduced to only 4 quads though. Now if we were to allow double-sided triangles for transparent objects we could reduce the number of triangles by nearly half at the expense of nearly doubling the number of draw calls, but if we use drawinstanced (and for trees, buildings, and the transparent parts of animated models we most definitely can) the extra draw calls would be negligible. That would require drawing the tree trunks and leaves separately though, which would require re-wiring the models' configs, and it'd also require removing all the backside leaf quads from all tree models. I knew that, although it's not easy to see when you have a dense mass of triangles since the wireframes ignore depth and aren't solid. We don't have geomips so there is no lod0, just 3.5 million triangles on screen. Also we don't need our cinematics to run at 5fps, and bigger textures would probably be a lot more expensive not to mention unnecessary.

My guess is that it's actually 32 triangles per leaf (8 quads x 2 triangles each x 2 for back facing surfaces), rendered twice for opaque and blend passes. When you add in shadows they get rendered a total of 3 times, which I wasn't counting in the 2000+ figure (I only had the tree on the cursor for the test, so it wasn't casting shadows). One way or another that's still a lot of triangles per frame.

I think they're set to hold pos by default, and if not then they should be. We need real attack move and we need better defaults for unit stances. The current default unit stance is "suicide".

Soon. Based on the activity on Phabricator it looks like they're working on mac OSX packaging issues. I don't know anything more specific than that though.

People often complain about performance issues regarding trees, but in reality there are only a few tree models which are the prime offenders in causing performance problems. After investigating this I found that a few of the tree types use models which have excessively high poly counts that are many times higher than other trees (5x or more), and even higher than character models and buildings, and can easily lead to several million model triangles being rendered per frame. I'm listing them in relative order of ubiquitousness. 1. Cretan Date Palm (all variations). It uses 8 quads per leaf, while the older palms use only 4 quads per leaf, and also uses a much larger number of leaves than the older palms. I can understand the 'dense leaf whorl' effect that the original artist was trying to convey, but even then the number of leaves is higher than is strictly necessary. The models use over 2k triangles on average (according to how render stats counts them) and 6k for the cluster version, and the tri counts need to be cut by more than half. Whole maps get covered in these, and palm_tropical_tall also uses the same models. 2. Aleppo Pines. These models look great but they also use ~2k tris each on average, and are major contributor to performance issues. Preferably the triangle count should be cut by more than half for all aleppo pine models. The source of the excessive poly count is probably the leaf planes, although tbh I have no idea how it manages to be that much higher than other similar trees. It seems like it should only need 400-500. Used in a lot of maps, often in large numbers. 3. Palm Tropical. Very high poly, also very ugly so never gets used. Probably needs an overhaul. I think the concept is unique though, and deserves attention. 5. Fig. Uses ~1400 triangles and I have no idea where they're hiding. It doesn't seem to use a lot of leaf planes, so I suspect the trunk is just extra-high poly. Similar looking baobabs use only ~500 triangles. 600 would be an acceptable target. 6. New oaks. I'm not sure if I've ever seen them used, but they're all ~2k tris each. Blender isn't my forte but this is pretty important for overall performance. If someone who knows what they're doing could look into this it'd be greatly appreciated.

Vertex structs are a special case. One that has nothing to do with using a struct for the settings and data of every class. I'm not suggesting that we use setters and getters for everything. Just that we should maintain a proper separation of concerns and avoid making structs for every class's data, and avoid keeping options spread all over the place or creating a mess of interdependencies in the process. Why keep something in a struct when it could work just as well as an instance variable?

Eh, after looking it up it seems like the only difference between a C++ class and a struct is that a struct's members are all public by default. The real issue is that dumping everything into a struct turns the renderer into a render-options-manager rather than just a renderer. Things like init params are usually based on some external data, which should just be encapsulated in its own class, which is then passed as an argument in the constructor or initializer. The current way things are constructed and initialized does not make sense, and there are lots of classes that should really have an init() method and don't. In other words what I would do is something more like this: class TextureManager { public: TextureManager(CUserOptions userOptions); // it reads what it needs and initializes its own private variables with no struct } In other words, using PODs in an OO language is bad form.

Yes, a struct doesn't use inheritance, which makes function calls direct and can improve performance if the compiler doesn't support class hierarchy analysis (which you can do the same thing by declaring a function as final). Otherwise there's no difference. The bad is that it uglies up the code a lot by creating a whole sub-class within an existing class file, and then you have to make function calls that explicitly reference the struct rather than just calling the function normally as a local function or class method. The class which should normally be self-managing now has to manage another "class" inside itself for no good reason.

Hmm.. the requires for shader techniques don't work quite the way we'd need them to. Those aren't "minimum version" requires, they're "selected this mode" sort of requires. Materials have fallbacks but shader techniques don't. We need a clear means for specifying that.

No, spaghetti code is what we have right now. We have a mess of "shader techniques", "materials", and all kinds of hacks for supporting fossilware. If anything it should be a lot cleaner to only have to worry about GLSL versions and draw call techniques (although we may need to modularize the draw call techniques since they may require very different things, but that shouldn't be too difficult). I mean the current renderer uses structs inside of classes for some unfathomable reason (object instances are structs!) and keeps options settings in 50 different places with all kinds of backwards interdependencies (like the options-parser needing to call the postproc manager directly). It's an unholy mess and it should probably be cleaned up along the way.

That sort of abstraction isn't really necessary. Farms are already limited to a few workers each (4 or 5, I'm not really sure), so a similar thing could be done for stone and metal. For wood I was thinking of just having a "forest" that you could build for a fixed cost in food, that would work just like farms but for wood. Replacing map trees or using a special combination resource producer/resource depot would be overly complicated. Same for stone and metal, we don't have the infra for building special resource extractors, but we do have the infra for limiting the number of workers that can be actively gathering a resource at the same time (like farms). Game length and balance are not really correlated. The best RTS I ever played was Zero-K, and the average game length was around 20 minutes. It had rate-limited resources with incremental expansion and strong territorialism, and strong role-based unit balance so unit choice was very important. There was basically constant action from minute zero, lots of potential for back-and-forth and comebacks, a good balance between eco and unit micro, and the balance between factions (although technically there were no strict factions) was very good. 30 minutes to an hour is a long freaking game. If anything I think 0ad could use some mechanics to speed things up, like a super cheap dedicated worker class and higher pop/cost housing density.

It's come to my attention that there was an approved plan for dropping FFP and ARB shader support some 6 years ago, but the dev that was working on it left so it never got done, and we've been arguing about it on and off ever since. According to a survey taken some 3 years ago or so over 95% of our users have support for at least openGL 2.1 (shader version 120) and more than 45% have support for openGL 3.3 or newer, while a good chunk support 3.0 or 3.1 as well. So this is what I propose: - We remove all traces that FFP ever existed, from config, shader effects, and anything in the codebase relating to those things. - We remove all traces that ARB shaders ever existed. There is basically no one using them and no one working on them. The legacy support is cluttering up the codebase and making it more difficult to support newer and more useful things. Additionally, I propose we add support for: - Automatically detecting hardware GL version to support whatever 3.0/3.1/3.3/4.x features the user's hardware allows (and that we can find good use for). - Allowing for choosing different GLSL shader versions automatically based on GL version support. - Creating a config/command line option for spoofing older GL versions for testing purposes, so it's possible for devs to manually choose which shader versions will be loaded. - And of course support for draw-call reducing features from GL3.1-3.3, based on whatever the user's hardware supports. Since some things have lower version requirements than others it makes sense to allow such things to be enabled incrementally so users can get as much as their hardware can provide. Finally, I think we should establish shader version 120 as the standard for legacy OpenGL 2.x support, since basically no users have GL 2.0 graphics cards and virtually everyone has support for 2.1. GLSL version 120 supports a couple of very convenient features that allow for efficient shaders, at least as far as what 2.x supports in terms of performance. Not every shader needs to be declared as #version 120 (if it doesn't matter then who cares), but it should at least be made allowable without question wherever it's needed. Note that a lot of shaders will likely remain as GL2.x simply because there's no benefit to upgrading them. The water shader and postproc shader(s) and even the terrain shader are good examples. At the moment the only shaders that I'm aware of that would benefit from GL3.x are model_common and the particle shader, to support drawinstanced and soft particles.

I don't think there is such a thing, and apple seems dead set on never supporting anything correctly (including the technologies they themselves vetted, like openGL). Linux even supports D3D through MESA, although I don't actually know how to make that work. If we wanted to upgrade our media library I'd suggest the Small Fast Media Library. Apparently it compiles properly on all platforms and is better than SDL or even GLFW in terms of features and usability.

I don't think so. It's the engine and not glew that loads and manages the shaders. That means we need to change the shader management code to be version aware. glew can't turn a drawinstanced call into regular draw calls, either. The engine needs to know which one to use. EDIT: Also back to the main topic, I tried reducing the number of samples based on tex alpha for transparent objects, but the improvement was only marginal. Still far below playable for gold oasis.