Really nice trees, could they replace engine default ones?

[Beherith]

I like the pine trees we use from 0 AD, (usually named ad0_pine****), originally posted in the feature resource thread.


But after a couple of years of use of them, I started to become annoyed with some of their issues:
-They suffer from massive overdraw (too many areas with are fully transparent), as they use very large triangles for each level of foliage.
-They are missing back-faces, so they look horrible when viewed horizontally
-They are very striated, especially visible when looking at them non-vertically
-They are over simplified, and triangle count is no longer a big issue for models, are GPU's are becoming better and better.

oldtree_w_backfaces.png

(402.55 KiB) Not downloaded yet

Adding backfaces to the old trees up's the tri count to 193, while only looking marginally better

So I started to draw some trees, using the same texture (the texture is excellent anyway), my new trees have the following benefits:
Tri count is 230, while retaining a higher level of detail.
As little as possible overdraw
Looks excellent from every angle

I screwed around with various edge hardness configurations in the branches, which do have a marked effect on the looks, especially ingame.

newtree_edgehardness_variations.jpg

(349.81 KiB) Not downloaded yet

They look like this with scene lights:

newtree_scene_light.jpg

(151.23 KiB) Not downloaded yet

I also went forward and added a bit more detail to each branch, this doubled the tricount to about 400, but looks even better:

besttree.jpg (177.88 KiB) Viewed 17737 times

Would there be interest from an engine developer to replace the default engine trees with these models, with a little bit of parameterization on the:
- Size / scaling (supported in mapping format already)
- Rotation (supported in mapping format already)
- Texture offsets so that only a single U or V offset would provide us with multiple new trees without switching the model
- Instanced rendering with Uniform buffers for unparalleled tree density and rendering performance?

I will gladly prepare the model and texture files for the above parameterization, if desired, or I can just update the old trees with these better ones, and mappers can use them in traditional way.

I have attached the wings file and the texture as well.

[Forboding Angel]

I've already done this in evo and elsewhere (simple replacement). It makes maps with engine trees look MUCH nicer.

[Silentwings]

I've already done this in ...

The point that the rendering is done engine side - and as a result can have significantly less impact on performance than a game side version (e.g. https://springrts.com/mantis/view.php?id=5371#c16801).

[Jools]

Last time I checked, the old AD-0 trees still had a quite significant impact on performance. The issue is of course that some maps have *a lot* of these trees.

[Kloot]

I'll support this.

An instancing GL4 foliage renderer is obviously the way to go.

[Beherith]

Jools, the reason the old AD-0 trees were so bad is mostly because of overdraw. This is especially apparent when zoomed into one, or when many are on-screen.

Forb, your approach is also valid, but this addresses two things, 1. Better model than old 0ad tree, with better performance to boot (feel free to open the wings file and check it out in 3d), 2. engine-level replacement with gl4 rendering (high performance boost especially with large numbers)

Kloot:
I have a total of 12 texture variants set up for a single mesh:
3 green pines with different looking foliage structure (the foliage structure is inhereted to the textures below)
3 more of the above with a bit of browning added in place for a more organic look
3 partially snowed in ones
3 heavily snowed on ines.

For the texture planning and UV offset would you feel it would be a better way to use an array texture, or just use UV offets with one large texture?
S3O's are fine for you, right?

Edit: Would you prefer the 200tri simpler version, or the 400 tri version with the arching branches shown on the last picture in the OP?

[Beherith]

Forb, could you link me to an example map where you use this? Or a screenshot?
Are the models/textures in spring features, or in evo?

[Kloot]

For the texture planning and UV offset would you feel it would be a better way to use an array texture, or just use UV offets with one large texture?

Array textures, to avoid mipmap issues.

S3O's are fine for you, right?

Yup, so long as they consist of a single piece.

Edit: Would you prefer the 200tri simpler version, or the 400 tri version with the arching branches shown on the last picture in the OP?

Both, two available LODs are better than one.

[Beherith]

Both, two available LODs are better than one.

Just one thing, while creating the trees, i found it marginally better to have 3 separate models for the foliage types. Would it be much better if I focused on making just a single model for all textures, at the cost of a minor amount of overdraw, or can I make more than 1 model?

Regarding LOD's: If LOD's are a good thing, then should I try to include a very far LOD type ( e.g. at around 32 pixels screen size) that consists of only 3 orthogonal quads? I'm asking because there is extra space on the texture, and it might be a good idea to include these billboards on the textures.

Also, if LOD's are a good thing, i would maybe aim for a higher tri count of ~1000?

So in total, in the best case, we would have a total of 3 s3o's
1. Closest LOD, approx ~1000 tris
2. Medium LOD, the current 200 tris
3. Far billboard LOD, which amounts to 12 tris

Is this all OK?

[Forboding Angel]

Engine Trees:


OAD Trees:


In evo I use assets from spring features. In BA the models are actually in the game. To see for yourself, load up any map using engine trees with evo.

[raaar]

The engine trees look really BAD at the moment:



Performance is still important. On some maps highly detailed trees seem to cause framerate drops.

Also relevant is size or scale. The replacements should be aproximately the same size.

A quick fix might be to just improve the existing sprite system to use higher resolution sprites, and instead of what appears to be 2 vertical + 1 horizontal for each tree, use 4 vertical + 4 horizontal, or 6 vertical + 6 horizontal.

[Jools]

The engine trees look really BAD at the moment:



Performance is still important. On some maps highly detailed trees seem to cause framerate drops.

Also relevant is size or scale. The replacements should be aproximately the same size.

raaar writes really well. Do not forget that the purpose of the trees is to enhance the game, it's not the purpose of the game to showcase that I can make some really nice trees. Sometimes, we do not see the forest for the trees. Scale is important, many maps have too large trees.

[FLOZi]

Doesn't even appear to have 3d trees on, or LOD is just crazy. That is not what engine trees normally look like, see numerous above posts.

[Super Mario]

The trees should take advantage of tessellation feature, so when the camera zoom in it's highly detail, zoom out it's low detail.

[PicassoCT]

Also: Engine Trees do not recive the current sun-Lights Colours in LOD Mode. But that is another bug fixed at another time.

If this is requested and rewritten, can we add a 3d-Model override? As in, changeable by game?

[aeonios]

I don't think tesselation would work well for that, since texture lod on trees does not play well with messing with triangle counts. I expect that the primary cost comes from draw calls anyway, which tend to be pathological in spring.

Also I didn't particularly like the last "extra detail" tree. The other trees have a softer and more fully foliated look, while the last one looks empty and like the overall appearance is being sacrificed just to make the needle-bunch things look more independent.

None of that really matters for engine trees anyway, since they're so small you can't see them unless you're zoomed in so far that the trees are all you can see. Also maps that use engine trees tend to use an entirely unreasonable number of them in a nonsensical way anyway, so performance would probably be prohibitive. As features for maps that actually use features in a sensible way I'd much rather have bigger trees, which there aren't nearly enough of, and in those cases performance is also much less of an issue.

[PicassoCT]

The truth is that any tree will look out of place, the moment the map is not tailred to it. Unless.

Unless you can set the colour and hue of bark and foliage.
Its the only way.

[aeonios]

The truth is that any tree will look out of place, the moment the map is not tailred to it. Unless.

Unless you can set the colour and hue of bark and foliage.
Its the only way.

I haven't found that to be the case. I could imagine you'd need some rather psychedelic trees for any of your maps though.

[PicassoCT]

I have some psychedellic trees ironically those work well with all maps. They are not be part of the scenery.

But no matter how well you craft the model and how well you design the decal- it always- looks like a dropped external object.
Not like something that has stood there for a thousand years.

It usually starts with the treetype not fitting to the biome he is currently in.
Then its the windyness, that would usually deform the tree.

After that there is the problem of selfshading and translucency... which even on zoomed out level has some subtile impact.

How to capture the



Trees near rivers are green and might have moss, trees up from the waterlevel change in type- too deprooted ancients - or flatrooted dryresisted types.

This might seem slightly obsessive, but your instincts know everything else stincs.

[raaar]

Doesn't even appear to have 3d trees on, or LOD is just crazy. That is not what engine trees normally look like, see numerous above posts.

It seems you were right. On springsettings' "expert mode" I couldn't find any setting for tree detail (only distance), so I tried the highest quality on simple mode and....it worked. The trees look decent now.