So guys, how many polygons is acceptable for a tree? I'm seeing 100~ cited as common for a low poly tree on the net; with about 1,000 trees on a map, that means 100,000 polys will be eaten up by vegation. Or should we shoot down for 50 polys?

So guys, how many polygons is acceptable for a tree? I'm seeing 100~ cited as common for a low poly tree on the net; with about 1,000 trees on a map, that means 100,000 polys will be eaten up by vegation. Or should we shoot down for 50 polys?

NewTree.x

100 polys is just fine

remember that if you define a LOD model like this

NewTree_LOD.x

along with your main model and make it a lower poly version again (say 25 polys) then the high level tree version gets unloaded at distance. So up close you have detail, but far away you save polys.

Thanks for taking on the tree improvement business Ryan. It is sorely needed.

It's on the Panda3D site (not a bad 3d engine for any 3d programmers amongst you, provided you like programming in Python) and is a decent summary of available tools for content creation. All of the links are interesting, but it is the first link - to a program called Tree[d] - that I want to draw your attention to. I haven't tried it myself, but it may be worth a look. Anyway, FWIW ...

I've got Tree D installed and have been playing with it sorta. It's very high poly, and each X file is like 2~ MB. Might be because of the animation though....It's looking like a good billboard tree generator though.

It's on the Panda3D site (not a bad 3d engine for any 3d programmers amongst you, provided you like programming in Python) and is a decent summary of available tools for content creation. All of the links are interesting, but it is the first link - to a program called Tree[d] - that I want to draw your attention to. I haven't tried it myself, but it may be worth a look. Anyway, FWIW ...

I'm getting ready to rededicate myself to "sprucing up" the trees. As my free time is severely limited for the next 4 months, this may be a slow process.

For our purposes, these great programs seem to produce models that are too high poly- is this correct? So are we stuck with the system that the game currently uses, and will I/we just need to make better looking textures?

_____________________________

"Fear is a darkroom where the devil develops his negatives" Gary Busey

I'm getting ready to rededicate myself to "sprucing up" the trees. As my free time is severely limited for the next 4 months, this may be a slow process.

For our purposes, these great programs seem to produce models that are too high poly- is this correct? So are we stuck with the system that the game currently uses, and will I/we just need to make better looking textures?

Thank goodness you are taking these on board. With your artistic prowess we should start getting some nice looking trees!

My 2 cents

TreeD produces some really nice trees and if you get the settings right they are not too expensive (see SS below). The trick is to model the tree in planes which are then mapped to a whole branch via a texture (again see SS right corner).

TreeD can make virtually any tree (see the included examples), so it will be a great start, but you will need to do some post processing in MS3D or fM I bet.

The trick is to have a high quality tree model of ~ 200 -300 triangles and then a low poly LOD version ~ 20 - 30 polys. That will keep the frame rate up.

Here is a first test of a tree. It's roughly 300 triangles. It's marginally better than the stock trees, so I'm still working on color schemes and such. I also am still tweaking them in MS3D, as fM seems to map the textures differently.

I did the output of this one in fM. It looks fine in the game, but the textures are odd in the fM program. I'm using the exports as Stridor has them listed, so I hope all will be well with lighting effects etc once I get the models looking better.

How does the poly count for revised trees compare to the existing trees. I like the looks of your trees, and I like lots of trees and on map to help break up sight lines, but if there is a big performance hit, that would be a problem for me at least.

Alright, I have a day to deal with this again (and maybe part of Sunday).

After looking at a few schemes, I think the complex 3D model of the tree isn't working. The lighting ends up reflecting in odd ways on the planar "leaves", and we risk taking a bit of a hit for the lower end users with little return.

I am trying different textures on the existing 2-plane rectangular models we now have, and they look good in fM so far. If anyone knows the answer to these following problems, it would help a great deal:

I am having some issues with the way the game handles alpha channels. In fM, you can set the color for a transparent area. Does this over-ride any alpha settings? Or is it better to just do the alpha channel in PSD? If PSD is the solution, what are the best settings to save as- .bmp, .dds etc. PzC has 3 different texture types for trees(!), though one must be the LoD one.

_____________________________

"Fear is a darkroom where the devil develops his negatives" Gary Busey

Alright, I have a day to deal with this again (and maybe part of Sunday).

After looking at a few schemes, I think the complex 3D model of the tree isn't working. The lighting ends up reflecting in odd ways on the planar "leaves", and we risk taking a bit of a hit for the lower end users with little return.

I am trying different textures on the existing 2-plane rectangular models we now have, and they look good in fM so far. If anyone knows the answer to these following problems, it would help a great deal:

I am having some issues with the way the game handles alpha channels. In fM, you can set the color for a transparent area. Does this over-ride any alpha settings? Or is it better to just do the alpha channel in PSD? If PSD is the solution, what are the best settings to save as- .bmp, .dds etc. PzC has 3 different texture types for trees(!), though one must be the LoD one.

Ben,

The reason why PzC has some many different texture types is the following.

The game engine wants everything in dds (DXT1 bit alpha) for video memory reasons. However as you have noticed this is a compressed format which does some compression damage to your original pure/pristine source textures. For this reason K released the source textures as bmps and pngs so users would have their original source to make changes to.

Unfortunately this really swelled the size of PC for very very little benefit (most true moders are gonna start from scratch anyway).

So in terms of the engine you want do all transparency in your dds (eg via your nvidia photoshop plugin). However make sure you set your fM material settings correctly:

This will give the tank strong highlights on its textures! (or you could do this for a window or bino glass, etc)

Howvever as no stock model (or mod model) has yet done any of that, and there were lots of emissive and specular errors in the code, my fix up program basically defaulted all the materials to the very first set of numbers so at least everything was reasonable and consistent and worked in different lighting conditions. However a good texture/material designer can do better for the future I think.

Thanks for that, it will help keep the trees from looking like they are made of shiny tin!

The .dds processing is brutal on the sharpening. I'm trying to get rid of as much black background "fringe" around the model as possible, but the .dds plugin keeps resharpening it back. I've tried multiple blurs on alpha layers to try to fool it, but it keeps coming back. The picture below is the best I could get it thus far.

These are the two intersecting, very low poly tests. Rick, these are probably going to run faster than the current ones, as those utilize 3 or more extra faces.

I fired up CM last night, and re-noticed that the trees look pretty good as plain billboards (as another possible option). There are lots of ways to do this, so I will get some more done then put up samples for gauging what people prefer in the future (as my schedule will allow).

Edit- never mind, I figured it out. Like most problems, it was the user.

When facing the camera, the billboard test looks pretty good. I wonder if the simplest solution isn't maybe the best in this case. We gain lots on the processing for lower spec comps, the tree models don't look like a vehicle after an accident and they are (fairly) simple to make.

< Message edited by benpark -- 2/14/2009 8:35:43 PM >

_____________________________

"Fear is a darkroom where the devil develops his negatives" Gary Busey

You may want to test the "billboard" trees in the game ... I don't know how the dynamic LOS would behave when it's a rotating flat plane. I'm thinking it would block LOS in reference to it's initial palcement on the map ... and 90 degrees from that facing it wouldn't block LOS.

Maybe the models need be adapted in some fashion to allow more LOS around the trunk area, and less in the leafy area. Like a "T" shape. I've seen some of the models have this form, so I'll try some tests on those in a few days.

_____________________________

"Fear is a darkroom where the devil develops his negatives" Gary Busey