Megalomaniak I agree, there's no such thing as too much paranoia when it comes to copyright, even if it's naming it something like Godot vegetation generator, that's far safer than having it be linked to any kind of previous project, I've been doing the same with my stuff you may have seen. It's why I give them silly names like Total Bean or Nuclear New Bean Town. Everyone else will know what it means, but I can safely argue in a court setting they have nothing to do with each other 
lovely english accent 
such a tool. is very welcome, good luck!
I took a look at the presentation. The project is certainly very interesting, but there are a few questions. The fact that it will be using C++ certainly allows you to expect good speed and performance. But, it is planned to use its own engine Bright Engine. It is quite suspicious. I'm currently watching the development of the in-demand project on its own developer engine and each new version brings along with fixing old bugs a bunch of new ones. A developer's own engine is a very time consuming thing.
What will be the basis of vegetation modeling — what is the mathematical model?
It is not clear what form of commercialization is expected.
I expected mor dev-ing in the devlog 
@Tomcat Custom engine is not necessarily a big burden for a project like this because it needs only a limited set of engine-level features.
I'm also curious about the model. It'd be cool to base it on a novel idea, instead of standard L-systems approach. I'm not exactly sure what that could be or if it's even possible to escape L-systems when doing tree generation 
The only thing I'm certain about is that I like my trees to be fluffy and puffy, with lots of apparent volume in their crowns. This possibly boils down to good options/tools to control crown normals. I wouldn't mind seeing 'fluffiness' slider somewhere in the gui
xyz Custom engine is not necessarily a big burden for a project like this because it needs only a limited set of engine-level features.
There are a lot of craps in a project like this, it needs a lot of testing. It seems to be understood here, though.
It'd be cool to base it on a novel idea, instead of standard L-systems approach. I'm not exactly sure what that could be or if it's even possible to escape L-systems when doing tree generation
There was an interesting idea of modeling tree development, while accounting for nutrient supply... But I did not find it, although I think I marked it.
Oh, I found it:
Transport-Oriented Growth and Procedural Trees
Oh I've been looking for quite some time, but haven't found an alternative so far.
There was broccoli tree for Unity (paid) and the free TreeIt, but I never liked those really.
And speedtree removed paypal as payment option in december 2021 and never brought it back.
So, yes, an (cheap/free and easy to use) alternative is very welcome!
Tomcat I actually looked closely at TreeIt (along with other software solutions) when first planning out this project. It's a neat piece of kit with interesting features, some of which I'm keen to integrate in the future.
However, one key difference is that this project will primarily focus on non-tree flora models—for example, mushrooms, ferns, bushes, river weeds, flowers, etc. There are already a plethora of tree-generating solutions out there, yet not many in terms of other plants. At least, not ones which are affordable or quick, from what I've seen.
Time-based vegetation growth is a very cool idea that not many programmes offer. It's definitely something I've been researching more actively since the first devlog video was published. However, the priority at the moment is to get a minimum viable product up and running before iteratively improving it with new features and capabilities such as this one
Megalomaniak You're spot on there! The project has since been titled "Bright Life" as it's being built on top of my Bright Engine SDK
Tomcat You bring up some excellent points. Bright Engine has been in development since 2017, and its render pipeline is more than capable of handling everything that this project will need. Bright Engine is designed to be highly scalable and flexible, and while it's far from bug-free, the systems that will be used in this project are rock-solid. Not to mention, it's a very lightweight SDK (1.6Mb) relying on very few external libraries, ensuring maximum performance.
As for commercialisation, a business model has yet to be determined. However, anyone that subscribes to the YouTube channel during development will get a lifetime license free of charge once the software is ready!
The feedback from this awesome community has been overwhelmingly positive, and I'm glad to hear that many of your indie game dev projects can benefit from such a tool. 
Since announcing Bright Life, I've been busy getting the project off the ground, building up the base of the UI, integrating OpenGL, and establishing the PBR render pipeline. As promised, I recorded the entire process and have uploaded a new Devlog video, which goes live on Friday:
It would be awesome to see everyone who's interested in a new rapid flora generation solution tuning in. Apart from securing a free copy for yourselves, I'd love to hear your thoughts and feedback on the project so far, as well as any feature requests that matter to your indie game projects the most.
Development has slowly been chugging along, and I've now finished the first iteration of the node editor using C++ and .NET. I created a devlog explaining the entire process and think it will be interesting/useful to other developers venturing into this space.
And for those looking for an alternative to SpeedTree or PlantFactory, subscribing to the YouTube channel will land you a free copy of the software once it's finished.
As always, I'd love to hear the community's thoughts on this project. And if you have any specific feature requests, feel free to leave a comment below! 
