* Massive Tree Feature Set *

[SirArtturi]

Made some trees...
Use these to pimp up your map!

License: CC-BY Attribution 3.0 Unported

Please inform about any missing files, bugs or errors.
Gonna release more complete package with lua definitions and .mtl files. Maybe some spruce trees will be added too...

Package contains both high poly and low poly trees. Low polygon trees are
recommended for better performance.
High poly average 800-1000 polygons and around 1500 vertices
Low poly average 100-300 polygons and around 500 vertices
These may vary drastically though...

Thanks to Beherith for all the help!

Download link:
http://www.springfiles.com/show_file.php?id=2504

Features:



Some sweet screenshots:

[Beherith]

The power of awesome exuded by this magnificent feature set compels you to make maps with them!

[Das Bruce]

*Das Bruce flicks water*
The power of the feature set compels you!

[Gota]

Whatever happened to setting trees on fire?

[Jazcash]

Wow these look awesome. But yeh, each tree could use a new fire animation depending on their size. The default animation is for a much smaller tree size so looks fugly when these big mofos light up.

[SirArtturi]

Ah yes, forgot to mention that hitboxes are not working properly atm. Instead of hitspheres I tried to make hitboxes via tdf collisionVolumes, but they seem not to work for some reason.
That may also explain why flammability is working odly and is so small, because currente hitsphere is just tiny little sphere at the root of the trunk.

If anyone could help with this issue i would be more than greatful. Though, I assume that lua definitions will fix the hitboxes as soon as I include them to the package...

Btw, Is it possible to set "falling" animation for features, like default trees have? It looks dumb when features just dissapear when crushed...

[SirArtturi]

Tip for tree and feature makers:

In upspring, add at least -1 y position for features so that part of it gets slightly underground. In this way you make sure that your feature looks good also when placed on slopes.
Though, I think you already knew this...

[Forboding Angel]

Ehh, these will drag performance into the dirt tho (the high poly ones)

[Beherith]

Ima test that theory now.

[KaiserJ]

i like the bushes great work man

[Beherith]

So, 180 low poly trees render at 150 fps, while 180 high poly ones render at 93. Thats still pretty damned good.

Im fucking sick and tired of designing everything for the past and not the future.

[Gota]

Im fucking sick and tired of designing everything for the past and not the future.

Hell yeah.
It's similar to TA remodels.
Modelers are scared of making high poly units even though remodeling will finish only in several years(if at all) so models can actually be made much more detailed even if ATM they will hit the system harder.

[KaiserJ]

i think these trees (and indeed others from recently) will look amazing even if used in moderation... i can't imagine anyone thinking that filling a map with them would be a good idea in the first place; certainly that wasn't the intention...

i'm going to use a few of these (especially the bushes) in my WIP.



i would also say... if you DID want to put a ton of trees into the map, just put 5 metal or so in each of them to be sure that they will all be reclaimed before serious spam occurs.

[Forboding Angel]

So, 180 low poly trees render at 150 fps, while 180 high poly ones render at 93. Thats still pretty damned good.

Im fucking sick and tired of designing everything for the past and not the future.

Tale of two hills has a little over 1000 trees. 180 trees on a map really isn't much. Would you mind re-running with around 1k trees?

[Beherith]

So, the engine does not have built in support for falling animations for other than default trees.

The fire size is defined by the radius of the model itself; so decent fire can be achieved by defining a small radius and using a different collision volume.

Now I looked through at the featuredef class, and found these:

Code: Select all

	std::string collisionVolumeTypeStr;  // can be "Ell", "CylT" (where T is one of "XYZ"), or "Box"
	float3 collisionVolumeScales;        // the collision volume's full axis lengths
	float3 collisionVolumeOffsets;       // relative to the feature's center position
	int collisionVolumeTest;             // 0: discrete, 1: continuous

So I noticed you defined "box" in your tdfs, might need to be "Box", since its likely case sensitive. Also collisionVolumeTest defaults to 1, so dont worry about defining that.

Edit: disregard the case sensitivity, the C code looks for "box".
About the fire:

Code: Select all

CFireProjectile(midPos, UpVector, 0, 300, radius * 0.8f, 70,20);
where:
CFireProjectile(const float3& pos, const float3& speed, CUnit* owner, int emitTtl, float emitRadius, int particleTtl, float particleSize GML_PARG_C):

[FLOZi]

cylinder is probably better than box for a tree?

[SirArtturi]

@ Map looks very sexy. Looks like its bumpmapped? How come? Instead just bragging, I'll try to critize it a bit. As lot as seems you love splatting the texture, you could do it moderately and simplify it a bit since your texture otherwise looks really win. So, get rid of the "grass" splats on the dirt and on the edges of the cliff for example...

So, the engine does not have built in support for falling animations for other than default trees.

The fire size is defined by the radius of the model itself; so decent fire can be achieved by defining a small radius and using a different collision volume.

Ok, So Engine does not support. But why? Darn, coult it be possible to drag the animation out from the engine and make it as an independent lua animation attached to the map?

About the fire animation, Do you mean that fire size is defined by the hitsphere?

@ Flozi
Yes, you are absolutely right, cylinder will be better :)

[Beherith]

About the fire animation, Do you mean that fire size is defined by the hitsphere?

Yes i think so.

[Beherith]

Also, 1k low poly trees still run at 90 fps. 50 for high poly ones.

[Argh]

To make them fall, interact with Units (i.e., proper knock over) etc., they would have to be Units atm; it's possible to build some code to handle them as Features now, but I haven't gotten to it and am very unlikely to, because I can't draw them with shaders that way and that would kinda be beside the point.