==[TASK]== Tree poly reduction

[aeonios]

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.

Edited May 6, 2018 by aeonios

[wowgetoffyourcellphone]

6 hours ago, aeonios said:

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.

 

There's got to be something else going on here with the model or the render stats counter. 2000 triangles would mean each frond would have 60+ triangles if you had 30 fronds per tree.

[aeonios]

13 minutes ago, wowgetoffyourcellphone said:

There's got to be something else going on here with the model or the render stats counter. 2000 triangles would mean each frond would have 60+ triangles if you had 30 fronds per tree.

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.

[wowgetoffyourcellphone]

27 minutes ago, aeonios said:

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 really like the look of the Cretan palms. Perhaps reducing the foliage from 30 fronds to 25 would help (that's a reduction of 320 tris right there), also making the bottom frond geometry cheaper (use flatter geometry for the downward pointing fronds, 4 quads per instead of 8; for, say, 5 fronds that's another 160 tri reduction), and rounding out by taking out any back faces that are obscured from the camera (maybe another 100 triangles gone, for a total of 580 triangles removed from each tree, which could be significant if you have 50 trees on screen).

I'm no good in Blender and my 3DS Max subscription had lapsed long ago.

 

@stanislas69 @Alexandermb @LordGood

 

Quote

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.

I actually don't think the Aleppos look that great to begin with. Mostly a texture issue as far as looks, but the geometry could use work too.

Edited May 6, 2018 by wowgetoffyourcellphone

[vladislavbelov]

42 minutes ago, aeonios said:

My guess is that it's actually 32 triangles per leaf

You can use the wireframe mode to see actual triangles, if you didn't find it yet.

I think the current version of tries shouldn't be removed, but can be used as LOD0. At least for close cinematics our tries (and not only tries  ) aren't ready, they need higher details and textures.

[aeonios]

11 hours ago, wowgetoffyourcellphone said:

I really like the look of the Cretan palms. Perhaps reducing the foliage from 30 fronds to 25 would help (that's a reduction of 320 tris right there), also making the bottom frond geometry cheaper (use flatter geometry for the downward pointing fronds, 4 quads per instead of 8; for, say, 5 fronds that's another 160 tri reduction), and rounding out by taking out any back faces that are obscured from the camera (maybe another 100 triangles gone, for a total of 580 triangles removed from each tree, which could be significant if you have 50 trees on screen).

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.

11 hours ago, vladislavbelov said:

You can use the wireframe mode to see actual triangles, if you didn't find it yet.

I think the current version of tries shouldn't be removed, but can be used as LOD0. At least for close cinematics our tries (and not only tries  ) aren't ready, they need higher details and textures.

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.

Edited May 7, 2018 by aeonios

[vladislavbelov]

1 hour ago, aeonios said:

We don't have geomips so there is no lod0

LOD for model, not for terrain. We can introduce it separatelty.

1 hour ago, aeonios said:

Also we don't need our cinematics to run at 5fps

Try Yves OpenGL4 branch, and you will see, that it's not a problem to show many tries. With LOD it'll be even faster. And with few other techniques it'll be stable 60fps. So I don't see a problem in current models with using right things.

P.S. It looks like 3+ million of triangles is pretty normal for modern AAA games.

[aeonios]

1 hour ago, vladislavbelov said:

LOD for model, not for terrain. We can introduce it separatelty.

What I meant was geometry mips. We don't support those, period.

1 hour ago, vladislavbelov said:

Try Yves OpenGL4 branch, and you will see, that it's not a problem to show many tries. With LOD it'll be even faster. And with few other techniques it'll be stable 60fps. So I don't see a problem in current models with using right things.

P.S. It looks like 3+ million of triangles is pretty normal for modern AAA games.

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.

[vladislavbelov]

4 minutes ago, aeonios said:

I can't because as is the case for over half of the playerbase my GPU does not support openGL4.

As I remember, it was GL3.3 compatible. But I'm may be wrong, it was quite a long time.

10 minutes ago, aeonios said:

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.

I wanna write some hacky things for GL3.3 to reduce number of drawn triangles for tries. It'd be good, if you'll be able to test it. Btw, what videocard do you have?

15 minutes ago, aeonios said:

And like over half the playerbase

It's very interesting sentence, because we don't have actual statistics for the game. And I didn't find real world OpenGL statistics with a large sample (mostly few thousands). There was something on Steam, but currently it doesn't show OpenGL for me.

7 minutes ago, aeonios said:

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?

I absolutely agree to reduce the number of triangles, if it won't be noticeable. My point is only about noticeable changes.

[aeonios]

31 minutes ago, vladislavbelov said:

As I remember, it was GL3.3 compatible. But I'm may be wrong, it was quite a long time.

He uses multidrawindirect, so no it isn't.

31 minutes ago, vladislavbelov said:

I wanna write some hacky things for GL3.3 to reduce number of drawn triangles for tries. It'd be good, if you'll be able to test it. Btw, what videocard do you have?

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.

36 minutes ago, vladislavbelov said:

It's very interesting sentence, because we don't have actual statistics for the game. And I didn't find real world OpenGL statistics with a large sample (mostly few thousands). There was something on Steam, but currently it doesn't show OpenGL for me.

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.

39 minutes ago, vladislavbelov said:

I absolutely agree to reduce the number of triangles, if it won't be noticeable. My point is only about noticeable changes.

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.

[Nescio]

1 hour ago, vladislavbelov said:

As I remember, it was GL3.3 compatible. But I'm may be wrong, it was quite a long time.

I wanna write some hacky things for GL3.3 to reduce number of drawn triangles for tries. It'd be good, if you'll be able to test it. Btw, what videocard do you have?

17 minutes ago, aeonios said:

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.

According to that sample, 20% has 2.1 and 30% 3.0, so requiring 3.3 would alienate many players.

 

 

[aeonios]

1 minute ago, Nescio said:

According to that sample, 20% has 2.1 and 30% 3.0, so requiring 3.3 would alienate many players.

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

[vladislavbelov]

51 minutes ago, aeonios said:

GeForce 240GT PCIe edition which does support 3.3.

Ok, I'll try to use only 2.1.

1 hour ago, aeonios said:

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

I'm thinking about a case when all tries are drawn.

56 minutes ago, aeonios said:

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.

We're working on it, I really hope we'll have actual statistics for the game.

[aeonios]

20 minutes ago, vladislavbelov said:

Ok, I'll try to use only 2.1.

I said it does support 3.3.

20 minutes ago, vladislavbelov said:

I'm thinking about a case when all tries are drawn.

Can you describe a specific case?

[Stan`]

Spoiler

 A few threads about trees and how to make them and whether they should be animated (which would likely have a performance hit).

1. I had a look, but I'm not sure what I can do.

2. Aleppo pines were introduced in 17452 where I believe the goal was to make flora a bit better. 600 triangles seem low to me but maybe it's achievable if you look at the video in the above spoiler.

3. About Palm Tropical agree it's way to much the trunks are 1000 tris in total (so around 333 each for simple cylinders)

5. Half of the fig polycount is in the trunk (654 triangles)

6. The new oaks were also made by Enrique and introduced in 17452  So same, He used to have a very precise idea about polycounts. That's something I will update in the documentation in the coming months.



 

[vladislavbelov]

14 minutes ago, aeonios said:

I said it does support 3.3.

Oh, sorry, I misread it.

14 minutes ago, aeonios said:

Can you describe a specific case?

I wanna try to render many tries without art changes at far zoom and lowest angle (with camera constraints), when camera is on a hill.

8 minutes ago, stanislas69 said:

 A few threads about trees and how to make them and whether they should be animated (which would likely have a performance hit).

Currently tries are animated in the vertex shader, hopefully it can be improved with cooperation of artists, because we can add specific information inside vertex attributes. Also we can use a wind map instead of const wind data.

[Stan`]

I am not even sure one can use basic_trans_wind.xml with animated meshes.

[aeonios]

36 minutes ago, stanislas69 said:

  Reveal hidden contents

 A few threads about trees and how to make them and whether they should be animated (which would likely have a performance hit).

1. I had a look, but I'm not sure what I can do.

2. Aleppo pines were introduced in 17452 where I believe the goal was to make flora a bit better. 600 triangles seem low to me but maybe it's achievable if you look at the video in the above spoiler.

3. About Palm Tropical agree it's way to much the trunks are 1000 tris in total (so around 333 each for simple cylinders)

5. Half of the fig polycount is in the trunk (654 triangles)

6. The new oaks were also made by Enrique and introduced in 17452  So same, He used to have a very precise idea about polycounts. That's something I will update in the documentation in the coming months.



 

Yeah I figured they were mostly enrique's. Do your best I guess.

34 minutes ago, vladislavbelov said:

Currently tries are animated in the vertex shader, hopefully it can be improved with cooperation of artists, because we can add specific information inside vertex attributes. Also we can use a wind map instead of const wind data.

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.

29 minutes ago, stanislas69 said:

I am not even sure one can use basic_trans_wind.xml with animated meshes.

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.

[Stan`]

32 minutes ago, aeonios said:

Yeah I figured they were mostly enrique's. Do your best I guess.

I have a lot of things to do beforehand. Isn't there any way we can make the engine able to support more details ?

33 minutes ago, aeonios said:

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.

Yeah. Was mostly for a potential falling animation.

[aeonios]

3 minutes ago, stanislas69 said:

Isn't there any way we can make the engine able to support more details ?

What do you mean?

3 minutes ago, stanislas69 said:

Yeah. Was mostly for a potential falling animation.

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.

[Stan`]

4 minutes ago, aeonios said:

What do you mean?

Boost the rendering engine so it is able to render more stuff without that much performance loss.

5 minutes ago, aeonios said:

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 it would mostly be playing different anims/ models/particles/depending on the level of depleted resources.

[aeonios]

5 minutes ago, stanislas69 said:

Boost the rendering engine so it is able to render more stuff without that much performance loss.

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.

[Stan`]

How come we can have stuff such as tessellation then ? Just curious.
Is it just because we are missing a lod system that the game can be so slow ? I mean I'm pretty sure there are way more polygons on the screen when you play assassin's creed.

What about instancing, would that help ?

 

[vladislavbelov]

8 minutes ago, stanislas69 said:

Is it just because we are missing a lod system that the game can be so slow ? I mean I'm pretty sure there are way more polygons on the screen when you play assassin's creed.

What about instancing, would that help ?

I think, @aeonios tells about all videocards that we support (OpenGL 2.1). It's always possible to add a support of modern videocards, but it requires an additional code. I.e. my desktop renders 0 A.D. on High with 20+ millions of triangles with 30fps on high resolution (so with optimizations it'll be even faster), but my laptop - only 1million with 30fps or even lower.

So for many users it's pretty expensive, but for players, especially very active players (playing in modern games), it's cheaper.

[aeonios]

13 minutes ago, stanislas69 said:

How come we can have stuff such as tessellation then ? Just curious.

We don't.

13 minutes ago, stanislas69 said:

Is it just because we are missing a lod system that the game can be so slow ? I mean I'm pretty sure there are way more polygons on the screen when you play assassin's creed.

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).

15 minutes ago, stanislas69 said:

What about instancing, would that help ?

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.