Tree Improvement Project

[spellir74]

Mraah said:
"[tree types in region]"

Nice job Mraah.

[benpark]

Great chart, thanks. I'll need to be careful with my Google image search for the "hornbeam" tree.

Here are the 2 basic types of models so that you all can see the possibilities for LOS blockage.

The first is a very simple model (really the same as is in the game now with different textures). It's very low on processing power:

[benpark]

The second is the larger model. It looks much better from all angles in-game, has a realistic form.

[Mraah]

Ben,

Both look good ... however ... since your branch planes don't go all the way to ground then I don't know how the LOS will behave.

Remember, there are two sight rays, upper/lower. If the rays don't hit the trunk mesh and passes just left/right then the lower ray will pass cleanly through whilst the upper ray gets blocked ... What these means ??? ... It might take an average (of sorts) and may not block as you intended.

I dunno ...[&:]

You'll have to throw them onto a flat map and see.

If it's a problem then you can create new planes next to the trunk extending up to the branch planes and then assign them to the "invisible.dds". You see, the polygon is there but we can't see it.

Rob

[Mobius]

ORIGINAL: benpark
The second is the larger model. It looks much better from all angles in-game, has a realistic form.

What kind of tree is this suppose to be? It looks tropical. Sort of fern-like.

[benpark]

It's a test tree (actually the same one from the last page). I'm still working on ways to make them appear "full" without too many triangles. The finished ones will be more rounded.

[Erik Rutins]

ORIGINAL: Mraah
Both look good ... however ... since your branch planes don't go all the way to ground then I don't know how the LOS will behave.

Hm, what do the existing tree models have?

Remember, there are two sight rays, upper/lower. If the rays don't hit the trunk mesh and passes just left/right then the lower ray will pass cleanly through whilst the upper ray gets blocked ... What these means ??? ... It might take an average (of sorts) and may not block as you intended.

I think the lower ray was used primarily for determining ground obstruction/hull down, though it may be that the results were averaged. I have to look back at notes and/or code to recall for sure.

[benpark]

I may have a solution for the tree trunk (using the higher detail models)- I could add two faces of "brush" at the base of the tree. This would add some more density to the forests. Or just add two of the invisible faces along the trunk. Either way should do it.

[Mobius]

ORIGINAL: Erik Rutins
I think the lower ray was used primarily for determining ground obstruction/hull down, though it may be that the results were averaged. I have to look back at notes and/or code to recall for sure.

I never fully understood the explanation Kevin gave on what made up the woods factor. If it was just ray vs pollys or ray vs pollys plus terrain map color. There was some posts on the old development forum on this several years ago but I think those have expired.

[Erik Rutins]

ORIGINAL: benpark
I may have a solution for the tree trunk (using the higher detail models)- I could add two faces of "brush" at the base of the tree. This would add some more density to the forests. Or just add two of the invisible faces along the trunk. Either way should do it.

Sure - I'd like to make sure this is necessary though. I don't think we did anything special like that with the existing trees and they work fine even though they don't look great. In any case, anything that obstructs LOS should be visible, so that if a ray goes through a gap in the trees (and is therefore unobstructed) the player can see that too if he gets down to the soldier's eye view.

[Erik Rutins]

ORIGINAL: Mobius
I never fully understood the explanation Kevin gave on what made up the woods factor. If it was just ray vs pollys or ray vs pollys plus terrain map color. There was some posts on the old development forum on this several years ago but I think those have expired.

Oh, that's all explained in the manual. I worked that out with Kevin and we documented it all, I'm just not sure off the top of my head if we used the second ray to create an average obstruction value or just to check for ground level obstructions.

[Mobius]

ORIGINAL: Erik Rutins

ORIGINAL: Mobius
I never fully understood the explanation Kevin gave on what made up the woods factor. If it was just ray vs pollys or ray vs pollys plus terrain map color. There was some posts on the old development forum on this several years ago but I think those have expired.

Oh, that's all explained in the manual. I worked that out with Kevin and we documented it all, I'm just not sure off the top of my head if we used the second ray to create an average obstruction value or just to check for ground level obstructions.

I just read the rule.
Now I am concerned that we should set a standard for the number of model trees per unit area for each woods type. Because of the tree hit count needed to degrade sight. The distance in the woods really does not count for anything unless a ray hits a tree. There is some factor added for the terrain the unit is located on but if it is in the open and the LOS goes through a great distance of heavy woods terrain without hitting a tree it acts like it is clear.

[Erik Rutins]

ORIGINAL: Mobius
I just read the rule.
Now I am concerned that we should set a standard for the number of model trees per unit area for each woods type. Because of the tree hit count needed to degrade sight. The distance in the woods really does not count for anything unless a ray hits a tree. There is some factor added for the terrain the unit is located on but if it is in the open and the LOS goes through a great distance of heavy woods terrain without hitting a tree it acts like it is clear.

Well, part of the rule has always been that LOS is "WYSIWYG" for the most part. With that said, we always worked with the artists to make sure the number of trees in an area matched the terrain type well so that woods would not be sparser than light woods, for example. In general though, as long as the map maker sets the trees in a way that looks like what that terrain type would look like in real life, it will work well.

It's really hard to find a "keyhole" shot like that through a dense forest (pretty much impossible) but if you do fine one such angle, the cool thing is that you can generally see in the game just how that ray passed through. Also, the minimum modifier for the terrain type the target is on is not insignificant, but for vertically obstructions it's mainly mean to represent units at the edge of the terrain area that would not benefit from any "hits" on the terrain by the ray.

Based on my testing and the feedback we've had, it works well in the vast majority of cases (with the existing maps) and I haven't seen anything in the new maps so far that would make me concerned.

Regards,

- Erik

[rickier65]

ORIGINAL: Mobius

ORIGINAL: Erik Rutins

ORIGINAL: Mobius
I never fully understood the explanation Kevin gave on what made up the woods factor. If it was just ray vs pollys or ray vs pollys plus terrain map color. There was some posts on the old development forum on this several years ago but I think those have expired.

Oh, that's all explained in the manual. I worked that out with Kevin and we documented it all, I'm just not sure off the top of my head if we used the second ray to create an average obstruction value or just to check for ground level obstructions.

I just read the rule.
Now I am concerned that we should set a standard for the number of model trees per unit area for each woods type. Because of the tree hit count needed to degrade sight. The distance in the woods really does not count for anything unless a ray hits a tree. There is some factor added for the terrain the unit is located on but if it is in the open and the LOS goes through a great distance of heavy woods terrain without hitting a tree it acts like it is clear.

Mobius,

This was a concern of mine a while back. I know in the MM Guide (not in any official PCK documentation), there was a statement about making sure you used appropriate tree density to distinguish light, medium and hvy woods.

The WYSIWYG concept seem reasonable to me. If it looks dense then it probably is dense. Some guidelines about what density of woods "appear" dense could be put into the MM Guide. (knowing that it will vary by season and type of tree, and by tree model used - but a guideline wouldn't hurt). I can't recall what I used in a Map Template I through together month or so ago.

Rick

[benpark]

Alright, now I'm back on track thanks to Stridor helping me out of my latest quagmire.

I just ran a test of two different tree models that were about 150 triangles apiece, each with 550 models on the map. I am running on a Mac/Bootcamp (2gig RAM-all that it will recognise) with WinXP and an ATI 3870 card. It was chugging. These are really using the bare minimum in terms of faces to obtain a decent looking, 3D tree (vs. two intersecting planes with textures on them).

At what point will the LOD model kick in (once I have made them)? I'm trying to figure out how I am going to make a smaller model size for these that looks the same visually for the LOD. I'm not certain it's possible to just lop off a set of faces here and there to make these smaller and have the same LOS blockage.

So, maybe we are back to the same basic models as PzC has, but with better textures. I have one more method to try with the 3D models. If that also brings my computer down in flames, I'll defer to the more experienced minds for ideas. Barring that, it's back to the old method.

Any ideas as to what is feasible as far as having these bigger, nicer looking models vs. the ye olde method?

[Erik Rutins]

ORIGINAL: benpark
an ATI 3870 card. It was chugging. These are really using the bare minimum in terms of faces to obtain a decent looking, 3D tree (vs. two intersecting planes with textures on them).

Yeah, this was why we originally only had the one evergreen truly 3D tree in the Winterstorm release, but I think LODs are the key in being able to do more and the Kharkov engine is also more optimized than Winterstorm was.

At what point will the LOD model kick in (once I have made them)? I'm trying to figure out how I am going to make a smaller model size for these that looks the same visually for the LOD. I'm not certain it's possible to just lop off a set of faces here and there to make these smaller and have the same LOS blockage.

The first LOD kicks in very quickly, like 100-150m or so IIRC? The second one takes longer but then you also get to the point where it starts clipping away the trees and eventually the map itself. I think getting the first LOD in is key, the second one a bit less so.

Regards,

- Erik

[benpark]

Thanks, Erik.

I think this looks pretty good for using two faces. It only falls apart when viewed from directly above. Does anyone play from that angle? I tend to play from just above ground level to 75 degrees above. These look good to there and beyond.

These block LOS just about the same as PzC stock trees do, maybe a bit more as I added some height and width.

What to people think of this style over the true 3D ones?

[RyanCrierie]

Ben, why not do both types?

For example, you could use the high polygon trees for places where a few trees would be found, like a few alongside a road inside a village, while you use the low poly ones for mass forests etc?

[Stridor]

ORIGINAL: benpark

Alright, now I'm back on track thanks to Stridor helping me out of my latest quagmire.

I just ran a test of two different tree models that were about 150 triangles apiece, each with 550 models on the map. I am running on a Mac/Bootcamp (2gig RAM-all that it will recognise) with WinXP and an ATI 3870 card. It was chugging. These are really using the bare minimum in terms of faces to obtain a decent looking, 3D tree (vs. two intersecting planes with textures on them).

At what point will the LOD model kick in (once I have made them)? I'm trying to figure out how I am going to make a smaller model size for these that looks the same visually for the LOD. I'm not certain it's possible to just lop off a set of faces here and there to make these smaller and have the same LOS blockage.

So, maybe we are back to the same basic models as PzC has, but with better textures. I have one more method to try with the 3D models. If that also brings my computer down in flames, I'll defer to the more experienced minds for ideas. Barring that, it's back to the old method.

Any ideas as to what is feasible as far as having these bigger, nicer looking models vs. the ye olde method?

Ben some performance tips for trees.

1. Use only one max 512x512 texture per tree (DXT1 format)
2. Don't double side every branch plane. Eg as most horizontal branch planes (esp those near to the ground) won't need the "underside" plane because the user will never be able to move the camera into a position to see the undersides.
3. I notice the very base of the tree has a face, you can get rid of that as it will be stuck in the ground and never seen.
4. LODs are key. Experiment with what you can delete. Surprisingly the trunk (if it is thin) can probably go, so can probably many of the smaller branch planes. If you play with the treeD settings carefully it is easy to just through a few switches to get a good LOD (see my very early post on this topic). Even multimillion dollar engines have some degree of pop-in. I think most users will accept some minor degree provided that it is done right (as an artist you will know when you have got this right).
5. When you export your tree do in in compressed X format.
6. I am not 100% sure put I think for things like trees without bones/mount points that they should be exported from fM flat (ie with no mesh hierarchy). This means that PCK doesn't need to walk the mesh for each tree.

I too have been seduced by the sexiness of the new mac pro unibodies. On my 2.53C2D 4G 9600MGT 512MB in boot camp (windows 7 beta) PCK works really really well (40-60fps for the stock scenarios). Remember you can press F1 ingame to get the FPS which is helpful in testing.

Regards

S.

As an aside do some trees exported from fM and the same tree exported from MS3D (you only need to do this once) and then test if there is a difference in frame rate. I think treeD puts lots of extraneous stuff (not needed for PCK) in the X export which fM leaves in (eg animation, mesh hierarchies) but MS3D being a simpler program strips out. Even the models may look the same one may be more PCK efficient that the other. Worthwhile doing as a test but only once.

Regards

S.

[benpark]

Ryan, I may do a few "specials" could be a higher count model. Maybe a few large trees, a few tall ones and a few stands of trees.

Stridor, thanks for the tips. I'm rolling along now. I'm only using the Tree[d] program for the trunks and a few textures now. Everything else model-wise is being done by hand.

One question:

The 2 face model above is so small in comparison to the 3D models-how do you do an LOD for something that is already so basic of a model?

The new MacBookPros are nice. I'm still on the previous generation, but my MacPro tower is only a few months old. I guage how much work vs "play" I am doing by how much time I spend on the bootcamp/XP partition vs the Mac OSX side. I'm not getting a lot done lately work-wise!