Still working on a Veggie System in my spare time... coming along some

User Code & Projects
1

This veggie system is still plodding along when I have time to work on it. Once it is finished up, I’ll throw it into a plugin (if I can ever get it to work right).



Here is a “latest” vid and then a list of crap I still need to work on. Perhaps some people could give me some feedback or suggestions for what they’d like to see out of it?



Forgive the crappy vid… my machine + fraps doesn’t get along.



http://youtu.be/4BJJ0zTWRic



Currently, the system is set up to listen for terrain tile additions and then drops vegetation over the tile using ray casting. It seems to work well.

Here is what I need suggestions for:

I'm trying to avoid the use of images all together for placement, so... I'm thinking noise generation limited to specific ranges to ensure that trees always render in the same place, facing the same direction, using the same models, etc.

Here is where I am stumbling. This would work great! Minus the fact that trees don't grow in the middle of streams or under water (usually). Questions for who implemented JME's terrain generator:

I'm thinking of piggy-backing the noise function (with the user defined settings) of the existing terrain generation, but would need to know how it accounts for placement of streams, rivers, lakes, oceans, etc?

Even better, is the generated noise accessible from outside of the classes?

Anyways... there it is.
8 Likes
2

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 :slight_smile: 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 :wink:



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.

3

@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 :slight_smile:

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

http://hub.jmonkeyengine.org/javadoc/com/jme3/terrain/geomipmap/NeighbourFinder.html

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.

4

Oh and about the noise I think its basically done in the editor. We do have noise functions in the engine but whats done to the terrain in the editor is basically stored only in the height map / texture data later, right @Sploreg?

5

TerrainQuad just stores the heighmap, no noise. All the noise routines are run before the terrain is created to create that heightmap. The heightmap terrain material reads the slope/elevation of the terrain to determine the textures on the surface, separate from any noise.

6

This looks promising :slight_smile:

You can get the underlying height map from the Terrain somehow, using this and knowing the water/sea level you can just discard all trees that are under this level.



Is there anyway of influence the placement of things? I want to say “I want this bit of the terrain to have grass with this density and no trees, and that bit should just have trees and low density of grass.”.



Anyway, I would gladly see this as a plugin :slight_smile:

7
@normen said:
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.


@Sploreg said:
@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
http://hub.jmonkeyengine.org/javadoc/com/jme3/terrain/geomipmap/NeighbourFinder.html
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.
8
@kwando said:
This looks promising :)
You can get the underlying height map from the Terrain somehow, using this and knowing the water/sea level you can just discard all trees that are under this level.

Is there anyway of influence the placement of things? I want to say "I want this bit of the terrain to have grass with this density and no trees, and that bit should just have trees and low density of grass.".

Anyway, I would gladly see this as a plugin :)


The base sea level was a definite thought (actually it is a must), though it doesn't account for streams, rivers & lakes, which almost never occur at sea level. Not sure how most terrain generators even considers these issues (or if they do at all)

Thus far, no on the placement/density issue, because I've been trying to avoid the use of image based placement maps for (not sure how these work for endless terrain to begin with). But this also has me thinking about how to exclude areas where grass/vegetation in general just shouldn't be... like building, streets, etc. I'm hoping once I pass the basics for this to the community, one of you geniuses will be able to figure out the best method for doing this. :)
9

Generally the best way to make it modular would again be Controls :slight_smile: At the same time they are also the best chance for serialization. If they just check what spatial / terrain they’ve been attached to they can determine a lot of data already. Plus if you have other Controls later that provide other functionality they can “recognize” each other. If you commit the code I can take a look at this part. PM me with your GC email to get access to the contrib repo.

10

Getting back to this and have some purdies to show.









End of line.

1 Like
11

Looking nice. Do you use your own shader for the leaves or the standard lighting shader?



I found my leaves looked better with a custom shader that treated alpha differently based on distance. Up close it has a really hard threshold and farther away it fades the same alpha to black. I did this to get rid of the gray halo. Basically, it acts like an alpha threshold except that it varies by distance and if something passes the threshold, I set the alpha to 1.0 and depending on distance I also potentially set the color to black.



Something like that. A hard on/off alpha cut-off that gives no gray halos made the trees look dead from far away.

12
@pspeed said:
Looking nice. Do you use your own shader for the leaves or the standard lighting shader?

I found my leaves looked better with a custom shader that treated alpha differently based on distance. Up close it has a really hard threshold and farther away it fades the same alpha to black. I did this to get rid of the gray halo. Basically, it acts like an alpha threshold except that it varies by distance and if something passes the threshold, I set the alpha to 1.0 and depending on distance I also potentially set the color to black.

Something like that. A hard on/off alpha cut-off that gives no gray halos made the trees look dead from far away.


A custom shader (well... based off an old version of JME's lighting shader). I did something very similar to what you did (for the same reason) Though... I like the idea of blotting out the color at far distances. Would save un-needed lookup's... actually... quite a few of them. How does this look in bright light?

Wow... this makes me want to go back to shader-based fog again. This was one of the factors in making transparency such a bitch, unfortunately :( Which got me going on the fog filter rewrite, etc, etc. But it sounds like you came up with the best of both worlds.
13

Oh… speaking of the standard JME lighting shader. Some weird shit is happening with that lately. It doesn’t play nice with custom shaders at all now. Any clue whats changed in it?

14
@t0neg0d said:
A custom shader (well... based off an old version of JME's lighting shader). I did something very similar to what you did (for the same reason) Though... I like the idea of blotting out the color at far distances. Would save un-needed lookup's... actually... quite a few of them. How does this look in bright light?

Wow... this makes me want to go back to shader-based fog again. This was one of the factors in making transparency such a bitch, unfortunately :( Which got me going on the fog filter rewrite, etc, etc. But it sounds like you came up with the best of both worlds.


I don't know what fog approach you use now... but I do fog in my lighting shaders and not as a post pass.

I tried to find an existing screen shot that showed near and far but this is the best one I had in the galleries:
http://mythruna.com/wordpress/wp-content/uploads/2012/01/Mythruna1321007275332%20copy-1024x576.jpg

Without tweaking these had serious gray halos.

So, trying to translate my shader to see exactly what it does... it looks like:

If alpha is less than 0.5 then I always discard it.

If alpha less than 0.75 and z (in view space) less than 80 meters, I always discard no matter what. This gives me my hard gray-less edges up close. It occurs to me that every pixel in the above image is nearer than 80 meters.

Where they start to get foggy in this image is probably 80 meters or so:
http://mythruna.com/wordpress/wp-content/uploads/2012/01/Mythruna1318830036439%20copy-1024x576.jpg

And then before I do fog, I have this:
[java]
if( alpha < 1.0 ) {
gl_FragColor.xyz = mix( vec3(0.0,0.1,0.0), gl_FragColor.xyz, alpha );
alpha = 1.0;
}
[/java]

So I mix in a really dark green based on how much alpha there is. You could also fade this effect in based on distance as mine does have a hard cut-off right now and you can see it happen if you are watching for it right.
15
@pspeed said:
I don't know what fog approach you use now... but I do fog in my lighting shaders and not as a post pass.

I tried to find an existing screen shot that showed near and far but this is the best one I had in the galleries:
http://mythruna.com/wordpress/wp-content/uploads/2012/01/Mythruna1321007275332%20copy-1024x576.jpg

Without tweaking these had serious gray halos.

So, trying to translate my shader to see exactly what it does... it looks like:

If alpha is less than 0.5 then I always discard it.

If alpha less than 0.75 and z (in view space) less than 80 meters, I always discard no matter what. This gives me my hard gray-less edges up close. It occurs to me that every pixel in the above image is nearer than 80 meters.

Where they start to get foggy in this image is probably 80 meters or so:
http://mythruna.com/wordpress/wp-content/uploads/2012/01/Mythruna1318830036439%20copy-1024x576.jpg

And then before I do fog, I have this:
[java]
if( alpha &lt; 1.0 ) {
gl_FragColor.xyz = mix( vec3(0.0,0.1,0.0), gl_FragColor.xyz, alpha );
alpha = 1.0;
}
[/java]

So I mix in a really dark green based on how much alpha there is. You could also fade this effect in based on distance as mine does have a hard cut-off right now and you can see it happen if you are watching for it right.



The first pic really show this off and looks fantastic. I'm definately gonna play around with this and see how it goes. Possibilities! I can think of tons of uses for this idea.