First of all, thanks for replying
Antwort auf:
But it is also inferior, because even if you have a speed increase, it decreases on wide scaled levels and areas. This is because you have to have different shapes of your grass sprite to fit the flexibility of nature. Nevertheless you have a lot of entities and polys too. So you need nevertheless a more flexible system.
Search for "dynamic tree solution" here and try it with smaller mdls with grass bunches. This works fine!
Yep I already saw that and I know it's working well. Anyway, I believe that this method is better as it is limited only by the graphics card (the only impact noticeable in the status panel will be the "ref" value which means -in this case- the time needed by the GPU to perform the alpha test), not by the CPU or any other means.
However, you've got a point when it comes to pretty big levels. In that case, you'd need more models than you would with some that are generated around the player, and only there. I think you would never need so many that it would really hit fps badly, but if you do, I can't help it since this is clearly the code's major disadvantage.
Maybe I'll combine this and have only one model that always follows the player and is deformed in realtime since deforming seems to be really fast...
Last but not least,as for the code itself, I'll try adding some comments. This was intended to be used as a whole so I thought you probably would'nt need this. But if one wanted to tweak something on his own, he'd obviously need comments, so I'm going to add some.
