That looks very good.
about elevation and dispersion i’d think of a height map or/and and alpha map. These data can be packed into a single texture.
@nehon said:
That looks very good.
about elevation and dispersion i'd think of a height map or/and and alpha map. These data can be packed into a single texture.
Does the terrain generator store it's height data as a texture? And is it accessible via a get method?
I had this really stupid thought on setting min/max height for different types of vegetation that would use the impostor method of displaying and "dropping" them using ray casting prior to actually creating them. If the ray reaches it's target within the limits set, the impostor would be created and appended to the mesh buffers. This would keep it from being closely coupled with anything else, but sounds like the initial creation would be more expensive (plus the target would have to exist prior to adding the vegetation). Any chance this is worth looking into? Or is it a bad idea from the start? I'm not exactly sure how expensive ray casting can be considering the potential size the terrain grid it would be applied to.
oh ok forget it , i thought you were talking about grass height.
I don’t know how androlo does it, but he might have an idea.
@nehon said:
That looks very good.
about elevation and dispersion i'd think of a height map or/and and alpha map. These data can be packed into a single texture.
Also, vertex colors can be used. RGB.
Sweet stuff but you should move the camera in your videos a little bit slower. It’s hard to look at the grass if you move so fast and often.
I got a couple minutes yesterday to try out the ray casting idea for height placement. This is SUPER raw atm as I am using the main render loop to add the grass over the terrain. I haven’t optimized anything or given any real thought to paging. But the results are promising!
http://youtu.be/D6-v-2dciBo
Next question...
Is there a way of getting the dimensions of a bounding box?
2 Likes
@t0neg0d said:
I got a couple minutes yesterday to try out the ray casting idea for height placement. This is SUPER raw atm as I am using the main render loop to add the grass over the terrain. I haven't optimized anything or given any real thought to paging. But the results are promising!
http://youtu.be/D6-v-2dciBo
Next question...
Is there a way of getting the dimensions of a bounding box?
Soooo much grass with sooo few triangle and looking sooo gooooood?? This makes me wanting a grass system too. I assume you are using a heightmap based approach?
It kind of suck when your using a other map system you can't use any of those extensions others write for the jme terrain :(
@t0neg0d said:
Is there a way of getting the dimensions of a bounding box?
Geometry.getModelBound().getCenter() in combination with Geometry.getModelBound.getVolume() should work AFAIK
1 Like
@zzuegg said:
Soooo much grass with sooo few triangle and looking sooo gooooood?? This makes me wanting a grass system too. I assume you are using a heightmap based approach?
It kind of suck when your using a other map system you can't use any of those extensions others write for the jme terrain :(
Actually, I tried something kind interesting. I'm using ray casting from above the terrain to place the grass height. This is limiting in one respect, as grass isn't able to be placed under overhangs... but works rather fast, considering there is no paging happening yet.
The really interesting part of the test is, I'm not doing any sort of texturing with the terrain, so I really had to put a significant number of impostors into each mesh to cover the ground (I think it is based on vert count from the terrain mesh it is covering... so in this case 42*42 impostors per tile). Once the terrain is textured properly and I have added in limiting factors like dispersion mapping and min/max height ranges per impostor type, I'm hoping to get a better looking effect out of fewer triangles (I hoping WAY fewer).
But we'll see. I got lucky with my last guess. I doubt my luck will hold forever!
Adding a bit more info about the how’s and why’s for my benefit.
Random thoughts on vegetation types, dispersion & placement:
- Ray casting from above the terrain tile (or multiples depending on what Node is passed to the vegetation system for evaluation): Doing this to keep the system from having to be tied to any particular terrain system. Heck… you should be able to add grass to your player characters if you really want to.
- I need to narrow down an interface for creating new types of vegetation and a way of registering them with whatever manager is written for paging, etc, etc.
- I want to allow multiple min/max height ranges for placement and exclusion. I can’t really think of another way of ensuring vegetation isn’t growing inside buildings without this. If anyone has any thoughts… please share!!!
- Multiple ways of producing dispersion maps… noise function, passing in a texture, etc, etc. This way, you can use the alpha maps used in terrain texturing to place the types of vegetation over the appropriate areas per tile. i.e. Grass is placed over grass texture and so forth.
A couple questions for anyone who likes to think about solutions:
- Which would be better… a single mesh containing all types of vegetation that use impostors with a LARGE texture using atlasing… or multiple meshes splitting vegetation groups (grass, hay, weeds, flowers) each containing a smaller texture with the variations of the vegetation type? The first carrying the extra issue of placement by vegetation type… it’s doable, but a little confusing from the start.
- Chunk size… matching the terrain tile? Or splitting this into multiples? I know JME handles vertex count better than object count… however, the larger the vegetation tile, the less options will be available to handle distance issues (like using an alpha fade based on distance from camera, to smoothly transition new tiles into the scene without the use of fog to hide what is going on). This also would allow much more detailed vegetation without worrying some insane amount of distance needing to be covered with veggies, freeing up the resources that would be used for rendering stuff that is far enough away to not really be necessary. Which would be the better approach?
Anyways… much thanks for any input, suggestion, mandates, demands, etc!
I love what are you’re doing! Amazing things!
I hope you will make everything in one repository… like gCode…
@mifth said:
I love what are you're doing! Amazing things!
I hope you will make everything in one repository.... like gCode...
I'm going to piggyback on your's me thinks. I can't get certain issues resolved. I have NO clue how you got the SSAO filter to compile asa plugin.
@t0neg0d nice idea about the ray casting and your grass looks really great 
But I think that using a heightmap would be easier and more performant, you are basically creating a height map when doing the ray casting anyways 
One crazy idea I got right now is to render the terrain page that should be covered with grass from above with no perspective and using a shader that outputs only linear depth (or any other suitable mapping). Then you basically have a “heightmap” computed which can be sampled on the CPU to place the impostors
1 Like
Idk if this is physics raycasting, BIHTree or “other” but basically you’ll put grass on the collision shape, which may or may not be the “visual” mesh. So I’d think like kwando says, maybe a reasonable optimization is to assume a float[] for heightmap + some offset + scale as input to the grassification. That should be rather decoupled from the underlying terrain implementation. You can always keep the raycasting as an “advanced” method to put grass on stuff that isn’t a heightmap rather than use it as the default method.
1 Like
@mifth said:
hey! do it like this:
http://www.youtube.com/watch?v=uxgJdHW7MCs&feature=player_embedded
This is awesome looking. But!! OMG... that head-bob thing with the camera is just nauseating hahaha.
And... I love ANYTHING zombie... seriously. But jebus... that game looks BORING. It was like 10 minutes of running around seeing and doing NOTHING. Well, aside from getting queasy from the camera. I think they spent so much time on the terrain generation, they forgot to write a game :(
@kwando said:
@t0neg0d nice idea about the ray casting and your grass looks really great :) But I think that using a heightmap would be easier and more performant, you are basically creating a height map when doing the ray casting anyways :P
One crazy idea I got right now is to render the terrain page that should be covered with grass from above with no perspective and using a shader that outputs only linear depth (or any other suitable mapping). Then you basically have a "heightmap" computed which can be sampled on the CPU to place the impostors :)
This is a cool idea for sure. Are you sure that rendering the terrain tile to a depth map wouldn't be a ton more expensive than the ray casting? I have no clue what the cost of ray casting is, so I'm not sure where the shortcomings are. So far, even the initial creation of 12x12(ish) tiles placing 42x42 impostors seems fast (even on my sloooooow machine). I'm open to trying anything though... especially if it's the better way to go. NOTE: "seems fast" does not mean I am convinced that the ray casting idea is a good one... actually, I'm more concerned that I didn't hit any issues when throwing together a first attempt.
Hmmm... actually, if the entire visible scene (terrain) was rendering all at once and then sectioned out my question above is sorta moot. I was thinking along the lines of rendering each tile... probably wasn't the smartest thought I've ever had :)
@jmaasing said:
Idk if this is physics raycasting, BIHTree or "other" but basically you'll put grass on the collision shape, which may or may not be the "visual" mesh. So I'd think like kwando says, maybe a reasonable optimization is to assume a float[] for heightmap + some offset + scale as input to the grassification. That should be rather decoupled from the underlying terrain implementation. You can always keep the raycasting as an "advanced" method to put grass on stuff that isn't a heightmap rather than use it as the default method.
Ok... this is something I am completely unfamiliar with and really glad you brought up. are the collision meshes stored in the same node as the rendered mesh? Or do you choose where they go? I would have thought collidables would reside in there own portion of the scene graph. If they don't reside in the same nodes as rendered meshes, this wouldn't be a concern... however... I have no clue if that's the case or not :(
EDIT: @normen sorry to bother... just wanted to find out if you could answer this for me :)
The brute force way of doing ray casting is to check every triangle in every mesh to find intersections, this can be costly since we need to traverse all mesh buffers…
Therefor the scenegraph is also maintaining a bounding volume hierachy. Every spatial have a bounding box, both Geometry and Nodes. The bounding box for Geometry is the smallest axis aligned box that can fit all vertices inside it, (that’s why you have to call updateBounds() on a custom mesh everytime you change the mesh buffers…).
A nodes bounding box is the smallest axis alligned box that can encapsulate all childrens bounding boxes.
This gives you a hiearchry of bounding boxes. Ray casting works on a node by first checking if the given ray intersects the nodes bounding box (this is a cheap test and we can return early if it fails, no need to check all meshes/triangles in it’s children). If the ray intersects the bounding box then do the same for the children until you have found out which mesh buffers to traverse.
If one use physics one can also let the bullet physics do ray casting inside the physics engine, how this is done is vodoo and black magic and can be found out by tracing the code… A thing to note is that the meshes/collison shapes used by bullet have nothing to do with the scenegraph, they live in their own space (physicsSpace) For instance we use a RigidBodyControl to connect a collisionShape instance in the bullet physicsSpace to a Spatial in the jME scenegraph.
The jME scenegraph bounding volume hierarchy is also used in the frustum culling step, since it’s cheap to find out if a bounding box is inside the frustom or not.
Phew, I hope my explanation makes some kind of sense. If I'm misstaken by something, please correct me :)
Edit: added some more...
I don’t think it matters were they are stored, but I can for example use a bounding box or sphere as collision shape for a node. So depending on what you ray test against it might not match the visual mesh. For terrain it matches pretty good anyway but the collision mesh isn’t the same as the visual, so in theory at least, they might differ. But as usual, if it looks ok and works don’t worry
Edit: Didn’t see kwandos answer before I submitted mine but that is essentially why I asked if it was physics ray casting or BIHTree (Scenegraph).