RTG needs a new tree system. You only need to look at DecoTree to see why.

I propose the following...

After all of the biomes have been upgraded to the new decoration system in 0.8, we will have a very good understanding of how the current tree system is failing us and how it can be improved, and we should look to come up with a new system for the 0.9 release.

Previous discussions regarding trees can be found in #157.

Well, codewise the different treetypes should be sub-classes or dispatch classes, but that' s pretty straightforward. What are the aesthetic/play issues we're looking at with trees? My only complaint is that in some forests they seem excessively dense. Well, that and the trees that cross color boundaries but that's a wicked tough problem.

Aesthetics-wise, yeah, the trees are too dense in some areas, although I do like how they're concentrated in certain areas of the biome rather than the entire biome being laden with trees.

Other than that... the max Y issue should be resolved after the biomes have been upgraded to the new system, so that won't be an issue for long.

There's also a few biomes that could benefit from either different distributions of trees, or some new/different trees altogether. Savanna I think probably has too many trees at the moment, and they're all just the vanilla Acacia tree iirc. Would be nice to get some variety in there, whilst reducing the overall quantity of trees. But that's something we can look at after the new tree system is in place.

How do you see the subclass/dispatcher system working? (generally speaking)

Well, where there's the big case statement you'd call an abstract routine, which would just contain the appropriate code for each type of tree, which would be its own subclass
One thing to look at is: do those vars even get used? The logs and leaves don't in that class. Are there subclasses?

Could be worse - the old vanilla rendering system was a 9,000 line case statement. Literally.

9,000 line case statement?!?! Ugh

Whaaat, that's insane..

I'm going to work on this next, but if anyone wants to get involved, feel free to jump in.

@topisani I've had a look at doing this myself, but it's just a bit over my head (maths and stuff), but I'd love to work with you on this in some capacity.

do we really need this for 1.7? there are quite a few tweaks to do to the decoration system to make it fit in more with the new surface system, but thats all in v2. Im not saying we shouldnt do it here, and if we do it id be glad to do so, i just thought we should consider keeping it for v2. Apart from the long switch statement the current system looks allright

Good point.

To be honest, there are only a few biomes that I've seen that could benefit from a little tree re-working, and for those I'm totally comfortable using the existing system, so not sure it's worth re-writing the entire tree system (which is a major project).

So unless anyone else wants to re-work the trees in any biomes that they're interested in, I'm happy to leave this for 1.9. And even then, just let me know what you want to achieve tree-wise and I can make it happen with the existing system.

we could add in available modded trees dynamically

If I'm understanding you correctly, we can already do that with the existing system. For example, in DecoEBTree, we're calling EB's trees directly, allowing us to have control over how they're distributed, etc. It's definitely not ideal, but it works.

We might be able to do something similar with Highlands' trees despite not having access to the trees directly via the API. Although, we only have access to the log blocks, so we'd have to figure out a way to replicate its trees somehow.

Unless you meant something else by 'dynamically', in which case ignore everything I just said 😛

The big advantage I see to a flexible tree system is that we could add in available modded trees dynamically. These monster case statements are ugly, but if they're working, there's not an issue until you want to change it. It doesn't seem like a big priority for getting a working system out - maybe you should move it to the 1.9 branch?