aeonios
-
Posts
229 -
Joined
-
Last visited
-
Days Won
5
Posts posted by aeonios
-
-
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.
-
2
-
-
1 hour ago, WhiteTreePaladin said:
There is a point where cards that don't support more recent standards won't have enough power to run the game well anyway. I don't know what that level is, but I somewhat doubt we need to support less than OpenGL 3. OpenGL 4 would be debatable, but 8 years is a still a long time.
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).
10 hours ago, vladislavbelov said:I meant to calculate a end pixel shadow color with different number of probes that depends on the alpha value. It's not exactly what did you say about, but just a near idea. Because for more transparent pixels we can have a lower quality of shadow, because it's less visible.
Hmm. That could actually be done. It's certainly worth testing though.
-
3
-
-
31 minutes ago, stanislas69 said:
Really it's the alpha transparency that defines the specular intensity ? We do not use that in any of our spec maps. I always thought it was the whiter the shinier and RGB would be color. I even disabled the alpha channel on some of those and some of the PNG are grayscale, even though the game just plainly ignores that.
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.
-
25 minutes ago, asterix said:
Thank you very much, also as a side note: it would need to be compatible with Alpha 23.
It'd only be a small change from the existing shader. The engine wouldn't care one way or the other.
-
24 minutes ago, asterix said:
@aeonios please would you make such a shader, because Neph is not a graphic engineer/programmer?
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.
-
2 hours ago, vladislavbelov said:
Hm, about transparency, you can try to reduce number of probes for low alpha: make a function like f(alpha) that returns a number, how many shadow texture the shader should do.
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.
2 hours ago, vladislavbelov said:It's only for low angles. right? For usual playing angles it's not really visible, at least shouldn't be.
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.
-
15 minutes ago, wraitii said:
Some grass and some trees use alpha blending (necessary for making leaves look halfway good). This means we render them twice, and once with transparency enabled.
Furthermore, the game has no real instancing (we merely sort stuff in a semi-clever way) so lag is to be expected, we start doing a looooot of draw calls.
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.
16 minutes ago, wraitii said:edit: btw you can disable the alpha blending somewhat easily, and you'll see that our leaves are horrible without it. There might be some trick to that, but I don't know it.
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.
15 minutes ago, wowgetoffyourcellphone said:Here's a tip if you don't already know it: Use this in local.cfg for performance testing alpha test.
forcealphatest = true
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.
-
1
-
-
7 hours ago, vladislavbelov said:
Hm, so currently your patch can not be applied as is because of lags. But, we can a little bit optimise it or add an options, which algorithm to use.
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..
7 hours ago, vladislavbelov said:I'm not sure, that it's the major reason, because for near to perpendicular triangles only a pixel line will be rasterised.
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.
7 hours ago, vladislavbelov said:I think there is a reason, why it's slower than it can be up to 2x times: many transparent things have a bigger (up to 2x times) transparent area, than it needs. Example: palms.
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.
7 hours ago, vladislavbelov said:Also did you test shadows with discard-like way? When you don't calculate shadows when the pixel is fully transparent.
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.
6 hours ago, Alexandermb said:It does in mass amount, if a huge amount of grass its going to be added it will need to have some slider or setting controlling the amount of grass i've tested in skyrim Grass Performance mods and the vanilla as well tweaking the grass amount and texture resolutions from 2k to 128 (Its very easy to tweak when it comes to graphical settings) they have quite low plane polys for flowers and basic grass with some 512 or 4k texture resolution, and i imagine this is what any1 wish to achive "Video link" but it drains too much fps when the amount is too much even at low resolutions i hope that will not be the case in 0 AD.
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.
-
11 minutes ago, stanislas69 said:
See #2103
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.
-
1 hour ago, Sundiata said:
Huh... Interesting... I could have sworn grasses caused lag. Guess not, never mind me
In that case, a lot of maps need to make much more use of grasses (that screenshot is pretty)
, maybe some new types as well (shorter and longer grasses).
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.
1 hour ago, vladislavbelov said:How did you check that exactly the fragment shader is most expensive (the grass has transparent things too as mentioned above)? Could you post you profiler.txt results here?
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.
-
2
-
-
15 minutes ago, stanislas69 said:
That's weird but not that weird. Trees have way much more polygons than grass. Around ten times more for some.
I believe the grass Sundiata was referring to is the fancy grass terrain texture which is different. You can find it in Atlas.
@aeonios what kind of suggestions are you looking for exactly ?
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.
-
1
-
-
2 hours ago, Sundiata said:
Lots of grasses, which are preferable for a realistic looking map, also cause lots of lag. Related?
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!
-
2
-
-
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?
-
1
-
1
-
-
On 4/5/2018 at 8:12 AM, Alexandermb said:
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.
-
2
-
-
43 minutes ago, vladislavbelov said:
Yeah, and it works good, but it costs the bandwidth. But I like it, it's simple and pretty effective (as most of tree-based optimizations).
As a just possibility example we can pass the only one quad and the heightmap texture, the rest of work will be completed by GPU on the tessellation step (don't know how much it's expensive, but for something like GTX 1080 it should work good
).
Tessellation can't make art, it can only smooth existing polygons.
-
12 minutes ago, vladislavbelov said:
Not sure, it'd be useful for the terrain, but it's not necessary.
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.
-
8 minutes ago, vladislavbelov said:
Nobody was talking about it. I'm talking on a higher level, about a choice between multiple renderers (modern and legacy) and single renderer (that supports most of popular videocards), about the renderer architecture at all. With good architecture we can support multiple renderer very easily. But we don't have one (probably yet). But do we really need it? I.e. OpenGL 3.3 was released in 2010 (8 years ago) and is widely available these days, so why not drop OpenGL2 and go to OpenGL3.3 (why 3.3 and not 3.0, because it's nearest to 4.0 for old videocards).
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.
12 minutes ago, vladislavbelov said:There is a problem, that we will always have a modern things and legacy things. Probably not so hacky but still (i.e. GL3.3 vs GL4.0 for tessellation).
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.
-
1
-
-
21 minutes ago, vladislavbelov said:
So it needs to test how it works and looks and then discuss with artists.
Something like that.
22 minutes ago, vladislavbelov said:There is a complicated task to add a new OpenGL support (btw one of reasons why we need the actual feedback statistics) without dropping not real old cards. Also we have a GLES "support", so probably we need to count it too.
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.
-
4 minutes ago, Imarok said:
Do I assume correctly, all this only works with a newer OpenGL version? If so shouldn't we/you first make 0ad ready for the newer version and then discuss about how to use the new possibilities?
Sort of. It would probably work under the current renderer, but wouldn't necessarily perform well.
-
1
-
-
3 hours ago, vladislavbelov said:
Not necessary to use ray-* techniques for volumetric, but other techniques like direct volume rendering or volumetric particles have an own cost. Btw, we use a parallax mapping, and it's a kind of the ray marching.
Yeah, that what I'm talking about.
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.
-
23 minutes ago, stanislas69 said:
Huh guys what about commiting the current fix ?
see:
1 hour ago, vladislavbelov said:If we're using volumetric particles it should be ok. But for flat/smooth particles it I'm not sure that the number will be enough for all cases. There is a question, how much different types of clouds we want to support.
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.
Tree performance
in Game Development & Technical Discussion
Posted
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.