Currently my grass is made and positioned like here:
http.developer.nvidia.com/GPUGem … _ch07.html (but without shaders)
It does look a fast and good way of doing it unless your camera looks at it from higher angle. Yeah, when it does it looks horrible. Any suggestions on what to do in this situation?
PS. Also the edges of the transparent grass are kinda black, but I’m sure there isn’t a background colour. Any ideas?
It’s a conundrum, but it helps if you rotate the blades a bit (so that you don’t look at a perfect star if you look at it from the top).
I guess so.
How about loading and positioning them?
Empties and instancing?
I’ve gone back-and-forth about that in my situation. I think I settled on using a vegetation map and procedurally placing it with help of a heightmap, then flattening it and caching the result in a bam file.
Thanks for the info.
Is there any example of using ‘vegetation map’? Sounds difficult.
Isnt this going to make it slower than instancing?
Vegetation map is just a texture overlayed on the heightfield that is a specific color (e.g. white) when there’s a lot of grass, and e.g. black when there’s not.
Yeah, with hardware instancing you don’t need to do the flattening and caching, although you need to write your own shader that handles culling then.
I thought so. It still sounds difficult for me. I havent gotten a pixel colour from an image before. I thought there was a sample with vegetation map somewhere on the forums. oh well…
Grass, and similar things are an interesting problem, and I think I have thought up a rather new approach. This is not a particularly easy one (one could say it is particularly hard in fact), but I happen to have most of what I need to do it already in my terrain engine, so it if works, I’ll share. The description here is probably not very intelligible, but I’ll include if for my own reference.
As with geoClipMaping, it requires vertex textures and thus shader model 3.0 I believe (non basic shaders). And also like geoClipMaping, it requires lots of tricky shader work.
Suppose you do geoClipMapped Grass. It can be done with hardware instancing. You basically have a ton of grass patch meshes (crossed quads or what ever) and place them on the GPU using a placement map (You place one grass patch per pixel in the placement map/texture, and the pixels contain all the information needed to place the grass, probably: height scaler, a texture card index (for sticks of shrubs instead of grass for example), and maybe some other stuff like flexibility for doing sway animations. Displacements could be stored in the map, though doing basic offsets from the grid procedurally would probably be easiest. For no grass, just set the height to 0. Yes, this wastes rendering time by processing vertexes for places without grass/twigs/shrubs, but thats ok. Just have lots of texture cards in there and always least draw something small.
Basically you need a texture that is continually updated to contain the grass information for near the camera, and some shader parameters to store the offsets just like a geoClipMapped height map (which you will also need so you can place the grass on the surface of the ground). And like geoClipMapping, you can have multiple LODs, though I can’t see a way to blend the seam between them really. Might be interesting though.
The same scheme could potentially place any meshes. I bet it would work great for scattered rocks, shrubs, trees, butterflies, what ever. As long as something has roughly uniform density everywhere, this trick should work. It should be possible to do regions of higher or lower densities, but that would be hard (I may work on it. It will require CPU intervention though)