aeonios

Possible? Certainly. However currently the engine only supports picking between GLSL, arb, and fixed-function modes and doesn't actually check gl version and probably doesn't support picking between different shader versions based on what the hardware is capable of. That would need to be added. I think a reasonable compromise would be to drop arb and ffp support (it's not like anyone actually does any work on arb/ffp anymore anyway) and replace it with support for choosing between GL2 and GL3, with support for using GL4 in the future if we ever find a definitive use for GL4 features. If we have it choose the highest shader version supported it'd give us a lot of flexibility in terms of upgrading things incrementally.

Personally I'd prefer to see resources be rate limited rather than boom-bust exhaustion. ie metal and stone could be infinite, but with limited gatherers per node. Well, except for the small nodes which could be exhaustible but without gatherer limits. That way if you need more stone/metal income the only way to get them is to expand. It'd also be nice to have a "tree farm" for gathering unlimited but slower/gatherer limited wood. I think delenda est's incremental expansion mechanism is more in the right direction. That way you only need to build an expensive CC to capture enemy eco structures or to prevent your own from being captured (or maybe to create territory pressure). Maybe even make fortresses fully independent as a cheaper and more flexible forward base.

Thinking about openGL in terms of version numbers isn't really useful. People seem to have this idea that higher numbers are better, but that's not how openGL works. Really we should be using the lowest version number that has features that are highly useful to improving the performance and/or appearance of the game. Using a version higher than that doesn't actually do anything besides preventing people with older cards (like me) from playing. That said, I think 3.3 is a good idea, and there are some major performance and quality enhancements that could be had by upgrading. However there's also GLES to consider which I'm not actually certain about. We should really look into the consequences before making any major changes like that. Honestly we keep going around in circles with this. It'd be good to make a decision sooner rather than later. Technically only model and particle drawing would need to be changed, I'm pretty sure. Upgrading to openGL3 doesn't mean that every shader would need to change, only the ones that would need to handle instancing and depth readback for soft particles would need to be updated. That and the model drawing code would need to be updated to use real instancing. It's less of the engine than you might imagine (although if we decided to throw out arb or ffp that'd be a lot of cleanup). Hmm. That could actually be done. It's certainly worth testing though.

Ha, you're right it does. The specification says that alpha is supposed to be specular intensity, but the shader ignores it completely. Interestingly the shader actually has a USE_SELF_LIGHT define which does apply a glow effect using the alpha channel of the spec tex for intensity. Go figure.

It'd only be a small change from the existing shader. The engine wouldn't care one way or the other.

Ugh. Well, I can do that but it'll require cannibalizing the specular texture. Currently the specular texture is spec.rgb with alpha being the specular intensity and specular power being an engine global setting. If I do it you'll need to specify how you want to use the specular texture, with at least one channel left available for emit. I can implement specular in 3 channels with one for specular intensity, one for specular power, and one for metallicity (ie how much the specular color matches the diffuse color) with the alpha channel left over for glows, if that works for your particular art. If you're already using the specular tex you'll basically have to redo it for all your textures that use it. For me it's not even a 5 minute job to modify the shader though.

Unfortunately there is no direct relationship between the tex alpha and the number of fragments that it will end up generating per pixel. Basically any alpha < 1.0 is a potential offender. The angle in question is the angle between the trees' foliage planes and the camera. Since the foliage planes are nearly randomly oriented in most trees there's no escaping it. There will be at least one leaf plane at a low angle no matter what angle the camera is at. I decided to pull up f11 and do some comparisons to see if I couldn't determine more accurately what exactly I was dealing with. It seems that fps may fall based either on the number of triangles being drawn or on the number of draw calls per frame, whichever happens to be worse. The number of draw calls seem to be high on some maps and not on others for reasons I don't understand. Some maps have particle effects which makes sense, but sicilia produces tons of draw calls and doesn't really have any major use of particle effects as far as I can tell. Grass produces a ton of draw calls which isn't all that surprising, and with my awful manual grass spam it tends to be overdense so the number of triangles is also pretty high, but with a proper grassmap that fixed the spacing and kept the density only as high as necessary I doubt the number of tris from grass would be too excessive. In terms of tris I found that there are two types of trees that are serious offenders. The king offender is the cretan date palms, which seems to use around 7000 tris per tree. Maps that make heavy use of them can end up with over 3mil tris on screen even though the number of draw calls for them is very modest. I'm not entirely sure where all of those tris are coming from, although the leaves definitely use a lot it doesn't seem to account for the total. There seriously has to be some way to reduce that without making them look worse. The second major offender is the aleppo pines. They seem to use about twice as many tris as an average tree, although I'm not sure if that fully accounts for the lag they produce. The aleppo forest on the west side of sicilia produces notable camera drag. I'm honestly not really sure how bad the fragment overdraw from normal trees is, or if it's really enough to be a blocker for pcss. For the worst trees it definitely is though. Also grass doesn't seem to suffer any loss of appearance from using alpha test > 0.5 with blend disabled for the opaque part of their draw cycle. In fact it actually looks a bit better that way. EDIT: The aleppo pines and cretan date palms both use 2000 tris each (6000 for a cretan palm patch). That's nearly 10 times as many tris as any other type of tree, and three times as many as the other non-cretan types of date palm. There are a couple of other trees like that but I don't think they get used much.

No, there is no emit shader in 0ad, but if you make a custom mod you can also make custom model shaders to support such a feature. I don't know that much about how the engine handles material textures though. You need at least one texture channel for emit intensity, but as far as the shader is concerned it's ridiculously easy to apply a glow effect. EDIT: you do need bloom enabled for it to look like anything though.

Yeah, openGL3 is still beyond what I'm prepared to do right now. I'm not really sure whether the lag from grass is draw calls or fragment writing or what though. That'd be a good candidate for profiling. I've been editing model_transparent.xml for that. Actually depending on how you set it up they don't necessarily look that horrible. Well, technically I didn't completely disable alpha blending, I just turned it off for the opaque pass. There are lots of different ways of going about that, although none of them work particularly well. I actually saw that, but from the searching around I did I couldn't actually locate anything in the code that would use force alpha test. It doesn't seem to be implemented.

I just made it so that transparent models use regular pcf rather than pcss and it works fine. It's not ideal but until a better solution becomes available.. That's only an appearance concern, not a performance concern. The grazing edges of the planes are normally nearly transparent but if you use alpha test they become very obvious and it looks bad. It's the planes facing the camera that produce lots of fragments and perform badly. The issue with palms is just that the sharp edges of the fronds look really really bad when using alpha testing, especially at lower mip levels. Trees aren't supposed to sparkle. The transparent shader already does that, but that's not the issue. The issue is that the more opaque parts of the leaves are actually partly transparent and use alpha blending, so they produce a ton of fragments even though you might not be able to see through them very much. It didn't seem to be that bad unless the density was excessive, which it tended to be since I didn't have much control over it using the standard prop placing method. It lagged more in game than in atlas, which suggests that a lot of the cost was CPU bound, which could be reduced a lot through instanced rendering and a coarser frustum culling method. Of course that's another motivation for using a grass map, ie the ability to control the density or to disable grass entirely. The texture size didn't seem to be much of an issue, nor did enabling shadows for grass change the performance noticeably.

For grass type foliage I actually want something more specific, with a uniform spacing but random rotation and different grass field sizes available for controlling density and handling smaller spaces. The main motivation for using a texture to store the distribution is ease of instancing and overwriting the existing distribution to replace certain elements with others to create variety. Ultimately it would allow for more compact storage and would also serve as a source of randomization inputs for the model rotation that could be fed directly into a shader.

I take that back, with the ridiculous amount of grass I spammed it does in fact lag fairly significantly, although it's still less than the lag caused by the palm tree spam on gold oasis or siwa oasis. I'm glad you brought up grass though. Not only is it freaking gorgeous but it also highlights some interesting lighting concerns that have convinced me of the need for custom shaders for different kinds of transparent models. In particular the dark lines you see on grass when looking straight down at it are caused by using NdotL lighting on grass, which is dumb given how translucent real grass is and bad because all it does is highlight the grass model's true shape, which is undesirable. The same thing but with the sun directly overhead: As for increasing grass usage, now I'm seriously thinking about implementing a grass map feature so that you can paint and unpaint grass/flowers/etc as easily as you can do with terrain texture. Having nicer grass models/textures would also be nice. A lot of the current textures use fake lighting where the grass is darker towards the bottom, which also creates ugly grey lines. A fancy profiler wasn't necessary. If I enabled soft shadows for transparent objects I literally got zero fps when panning over the trees in the center of gold oasis, and when I disabled soft shadows for transparent objects it became playable again. They work fine for terrain and solid models.

The fancy grass textures are weird, but not particularly laggy that I can tell. Basically, I'm wondering if we should be looking for new art (probably?), or looking to create more specific shaders for different types of transparent models(maybe?), or some combination of the two or if someone knows of another approach to getting good looking trees without eating your gpu.

I honestly have no idea what you're talking about. I literally painted greek acropolis into a giant field of grass and could not produce any lag. :| I think grass might actually count as a solid model but I'm not really sure. To be fair I was honestly surprised that it didn't lag hardly at all even after painting that much grass. It even receives shadows!

So recently I've been working on implementing PCSS for soft shadow rendering, and I noted some performance issues when it came to trees. Ultimately I ended up disabling soft shadows for transparent models, but it's still apparent that trees present performance issues regardless of whether they receive soft shadows or not. After tinkering around with the drawing process to see if I couldn't fix it, it became clear that the reason was that virtually all of the trees in 0ad use highly translucent leaf planes. What that means in a nutshell is that each tree might generate half a dozen fragments or more per pixel covered by its leaves, each with full lighting calculations applied. If you have more than one tree worth of foliage stacked up then the number of fragments can rapidly become unreasonable. Additionally, terrain drawn under the trees that may be obscured partly or completely also gets drawn with full lighting calculations, which in the case of PCSS are quite expensive. Now ideally trees/foliage would be drawn with a depth-only prepass before terrain in order to early-z reject any terrain fragments or other foliage fragments that would be obscured, and then draw color and alpha blending in a second pass after terrain and water have been rendered. However the current trees don't allow for that because for at least two major reasons: 1. LOD. When using lower mip levels more of the foliage becomes less opaque for trees with dense foliage. Actually these are the easiest to deal with by setting alpha test >= 0.5 and promote to 1.0 alpha, but it makes for a lot of special cases. Palm trees are even worse, since the spikes on their fronds will sparkle horribly from aliasing artifacts if alpha test/alpha promotion is used. 2. Leaf plane visibility. Leaf planes that are nearly perpendicular to the camera (ie edge on rather than face on) become dramatically more obvious when using alpha testing. That could be dealt with by multiplying the alpha value by abs(NdotV) before alpha testing, but again this leads to a lot of special cases since not all trees use randomly angled leaf planes and might look dumb if such a strategy were employed globally. Also the vast majority of the trees look really bad when viewed from any angle besides top down, notably in water reflections. A lot of the trees also looked notably better with alpha test due to shadows being applied more consistently rather than being washed out by the lighting from the terrain behind the leaf planes. So basically, for the sake of better performance and better looking trees I think it'd be worthwhile to look for a solution to these problems. Any ideas?

The wrists should always be held straight so that the pinky finger is mostly lined up with the forearm. Both for punching in martial arts and for playing the drums this is true, because if you hold your hand in any other position then it cannot withstand as much force. (and you risk carpal tunnel) Of course there are other possible techniques for drumming, but for punching you pretty much always keep your wrist straight. There's no way you could get much force if you were thrusting with a spear with your wrist bent like that.

I think the formations panel should have its own border. Being only half-connected to the unit info panel looks bad.

That looks freaking awesome. It'd be cool if there were unique themes for each civ.

Tessellation can't make art, it can only smooth existing polygons.

There's actually a better solution to that- namely geomips. We could support higher resolution terrain for art but use lower res terrain for pathing and building construction so that the passability checks remain cheap, and use geomips for LOD. We could generate geomips statically a la http://reports-archive.adm.cs.cmu.edu/anon/1999/CMU-CS-99-105.pdf or we could use a dynamic method like ROAM. Neither of those options require tessellation, and both allow more artist control over what the high-res terrain looks like. You can get some really amazing effects by printing height textures to add details, things like sand dunes, rough rock surfaces, etc.

Eh, the real reason for 3.3 is the features that it supports, like drawinstanced for animated models, RGB10A2 textures and so on. Yes 3.3 is ancient now, but I don't think the dev committee would be too keen on dropping support for old video cards or people who don't have real video cards. There was a discussion a year or two ago and that was the general consensus. I remember there being a poll and quite a few people were still using openGL2.x video cards or only supported 3.0. Do we really have a need for tessellation? AFAIK tessellation has horrible performance and isn't terribly practical for real games, and less so for 0ad where the models that could make use of it still have really low res textures with not-so-great materials. Also you'd need to be zoomed in really-really-really far for it to even be relevant. I'm not really aware of very many things that would actually be practical that require openGL4.x and there's no real point in pushing forward farther than there's an actual use-case for.

Something like that. Not really. Adding support for updated openGL is indeed a monumentous task, but retaining support for old openGL just requires forking the renderer and keeping the old one. Allowing the renderer to be switched in-game might be a pain, but it'd be easier just to force it to be one of those "must restart to take effect" options. The new render could even be simpler since it doesn't require any of the old FFP/arb shader hacks that the existing renderer uses for compatibility.

Sort of. It would probably work under the current renderer, but wouldn't necessarily perform well.

Horrible hacks are possible. We don't necessarily need super-realistic clouds, just a reasonable approximation. For example we could just have all cloud particles below a certain height be considered shadowed.

see: I doubt it would matter much anyway. Volumetric clouds require ray marching and ray marching is expensive. I'm not really sure if we can get good cloud lighting for cheap though.