[sldev] Improving trees (Re: About Viewer Performance)

[Argent Stonecutter]

> Oh, and the rendering of trees is terrible.  Good opportunity to make
> the open source community look good there.  It's no secret that we
> licensed speed tree awhile back and have been planning on integrating
> it.  Those folks aren't too keen on the idea of open sourcing their
> library, so it will be another one of those terrible situations where
> you guys essentially get left out in the cold, unless *ahem*  
> someone can
> provide a compelling alternative to speed tree that is open source.

That's very interesting. One of the things that I've wanted for some  
time was a hook into the Linden vegetation for resident-created  
content. I wasn't sure how this can be implemented in the viewer  
only, though: you really need the ability to feed a set of parameters  
and textures into the viewer from a prim, the way you do in  
llParticleSystem. This could be done behind SL's back in the interim  
by looking at prim attributes the right way. Either the prim  
attribute tags suggested elsewhere, or by treating "a hollow profile- 
cut cube that's been given a 1% path cut at each end by prim torture  
and the invisiprim texture on the hollow face" as a "tree prim":

The "tree prim" would be rendered as a tree, and treated as an  
extension to trees.xml:

The prim name would be "name".
Hollow color x -> "species_id".
Hollow color y -> "depth".
Hollow color z -> "repeat_z".

face 0 texture -> trunk texture (which seems to be the only texture  
in the xml file)
face 0 color x -> droop, y -> twist, ... etc ...

Other face attributes like alpha, and particle system attributes  
could carry more data...

My guess is that there's multiple layers in the jpeg 2000 file that I  
can't pull out, and the rest of the textures are in there. Since you  
can't upload a file like that, we'd need to use multiple textures to  
get the same result. Eight available textures should cover it.