Cool, that looks really nice!
If you would make the distribution dependent on a seed that can be accessed via a Control that wraps the vegetation code then it should be pretty easily possible to try out until no more trees are drowning :) Generally, this way you can get most parameters into the UI of the SDK most easily to visually edit stuff. Plus Controls are the best way to add something to Geometry/Nodes anyway ;)
If you need any help or want access to the contribution repository just tell me. No need to commit anything "complete" there, even if its just some beginning stages its probably best to have it in a common repo to be able to help out.
@anthyon created TerrainGrid and the noise functions. He might be able to help you with any questions you have with it.
If you need any help with making it a plugin, or need some terrain changes, let us know. This veg system is looking really nice :)
FYI, there is a new API to Terrain that allows you to create your own tiling system (living on top of TerrainQuads), similar to TerrainGrid. In particular the NeighbourFinder API
Look at TerrainTestTile.java for an example.
There were also some recent additions to TerrainGrid to make it easier to convert to/from tile cell coordinates and world coordinates, and to pick what cell tile a location is in. More info in this post.
I'd love to get as many people working on this as possible, tbh. Currently the main class for handling vegetation is a Control that starts a background thread that handles processor intensive stuff like creating impostors, placement, etc. As it stands right now, all impostors (per terrain tile) are created as a single mesh and it uses uses a bit of texture atlassing to apply different types of grass/weed "clumps".
Stuff I have in mind, but haven't really considered past the thought... and I think many of these depend on how the terrain system currently accounts for them:
Types of terrain (is it grassy fields? desert? mountains? etc) and transitioning between them.
User added vegetation models. Not all of these would potentially be custom meshes, but it should allow for additions of custom meshes/imported models. Basically a way of registering new components the system can use.
This brings up the questions of LoD on imported models and how to best implement/handle these. With a custom mesh, these are fairly easily handled... when it comes to imported models, I'm completely clueless as to how JME handles these. I see you can set them using Blender/Ogre... though... ?? This also includes the LoD of meshes to become impostors at a certain distance, which complicates matters even more.
Also, the question of... does a vegetation system actually need to be a standalone system or should it reside in (somehow... not to the point of dependancy for generating terrain of course) the existing terrain system and leverage off of it's components? The assets for vegetation are definitely a different story, however most of what is needed to produce this already exists for the terrain. For example:
Paging system... exists for terrain already
Managing LoDs... exists for terrain already
The perlin & fractal noise functions (including a cool filter system I noticed)... exists for terrain already
It seems to me, that the best approach would be to leverage these components but still keep autonomy between the two systems. With some (very) minor additions to the existing paging system, it could handle terrain or vegetation or both depending on the user's needs. Same for managing LoDs, though, I'm not sure how this is being handled by the current terrain system. There is very little involved and I am sure that it is simply doing distance checks against the camera.
Might want to mention... this is a mental dump before actually going through the terrain system code. I'm making some assumptions here... obviously.
Anyways... I'll start plodding through the terrain code to get an idea of what it consists of, make the necessary modification to what little I have put together and then push it out to where ever you all would like. If someone else would like to drive this and pull in the appropriate talent to ensure JME gets it's veggie system, I'll be more than happy to help in any way I can at that point... there are many other people here who are better suited to produce final code than myself, though... I'm fairly good at producing conceptual design and proof of concept code.