Tree[d]

[Argh]

For our purposes around here, it's hard to make good trees. I haven't been happy with most of the tools I've tested, and have done hand-built trees, because it was the only way to keep the tricount down and look good.

I think this one, along with a modified shader specifically for trees, will be a big winner. It's the only program I've used that is pretty close to doing it by hand.

The program is called tree[d]. I tried it out awhile ago, and walked away annoyed, because it was nice but it only exported B3D and X formats, both of which are distinctly non-portable unless you can afford Polytrans or like being frustrated with the free tools.

The coder apparently came back to it, and the current version allows for OBJ export, can be used to build branches for billboards that you can then use in the program very easily, has good low-poly functions using simple billboards (if there's interest, I can prolly explain how to do it, as that's not entirely easy) and is, in short, a very very nice tool to make good trees with at different polycounts, and it has built in tools for rendering LODs for billboards.

This is for a high-poly environment, 965 tris:



RTS spec, 163 tris (not optimised for underside faces, it could probably shave down to 120 or so):



Oh, and lastly, it allows for dynamic changes to the number of branches whilst retaining fairly good shape. So you can build LODs for trees pretty much by just reducing the branches. Not quite perfect, but that's basically impossible.

[bobthedinosaur]

Does any one have a working demonstration of LOD for the spring engine?

[Argh]

Trepan said it worked, but I've never seen a working demonstration.

[jK]

It just works for units.

Also:

RTS spec, 163 tris (not optimised for underside faces, it could probably shave down to 120 or so):

You have to double the face count then! cause Tree[d] doesn't use culling, so if you don't want that leaves are missing dependent on the view direction you need to ceate for each leaf polygon a 2nd with inverted winding (I don't even know how you do that in 3d tools).

[trepan]

Here's an old test gadget that I used while developing
the lua based LOD feature. Instead of using different
meshes for LODs, it removes parts of the unit the further
away you get (IIRC).

P.S. I have no idea as to the state that I left it in, or if
it will work at all with the engine changes that have been
made since it was written.

[Argh]

Well, I just go into UVMapper Pro and tell it to make those facets double-sided, and it does that. Most modeling applications can do it.

But yeah, I didn't see that problem until after I'd gotten done importing elsewhere. That takes them up to 300 triangles or so, which is about what I get with some hand-builts anyhow.

Not bad, and the way that they're designed, one tree + multiple textures or an atlas can feel like many trees.

Hrmm... Pieces go away? Can it do the reverse, and just say which Piece to render if <> some distances? I don't want to have to hand-section the leaves to try and prevent too much obvious pop-in; that's kind've a pain in the ass.

[trepan]

"an old test gadget"

Treat it as an example, not final product.

Ideally, you supply different display lists for different LODs.

[Argh]

Okie doke. I'll read it over sometime next week.

[bobthedinosaur]

P.S. I have no idea as to the state that I left it in, or if
it will work at all with the engine changes that have been
made since it was written.

Code: Select all

[      0] [unit_normalmap_shader:Initialize] shader1 compilation successful
[      0] Fragment shader failed to compile with the following errors:
ERROR: 0:7: '=' :  assigning non-constant to 'const 4-component vector of float'
ERROR: 0:9: '=' :  assigning non-constant to 'const 3-component vector of float'
ERROR:  compilation errors.  No code generated.

It causes an error in the normal map gadget, that otherwise runs fine.

It also choose pieces to hide very strangely, like middle or large sections of the model that make it look like an error.