Vegetation loader

Post your questions, suggestions and experiences regarding to Image manipulation, 3d modeling and level editing for the Irrlicht engine here.
devsh
Competition winner
Posts: 2057
Joined: Tue Dec 09, 2008 6:00 pm
Location: UK
Contact:

Re: Vegetation loader

Post by devsh »

First off... you need to stream the patches from disk... asynchronously
Secondly... it's going to take absolute FREAKING ages to stream if you don't compress your data (one idea is to store the mesh data once, and then all the transformations of the instances)

The actual patches that you have hanging around in memory should be determined so all the patches you are drawing are streamed in + a few around the edges

You'd need to modify irrlicht slightly so there would be a way of updating/creating the Static Hardware Mapped buffers(possibly while your physics is running or something).
Alternatively if the mesh you're instancing is below 512 indices/vertices then don't bother with that and save yourself a lot of trouble.

Then obviously HW instancing to reduce the meshbuffer size. This can be API native instancing (DX9 and OGL 3.0) or geometry shader instancing (OGL 3.0), you should let the user choose which one to use. You'd need to call ->draw() 'instance_number/max_no_of_instances' times, but you'd use the same meshbuffer.

All should be fine, since you multiply the verts by AT LEAST ONE matrix. But that WILL MEAN premultiplying every instance matrix with the viewproj matrix, because if you were to multiply by 2 matrices in the vertex shader, then your performance would drop compared to the "static mesh buffer batch".

Also beware, vegetation causes a lot of overdraw.... you'd need to use occlusion queries for your patches. Which could actually be very helpful in determining the LoD to use (because if would depend on the number of pixels on screen).

THIS WOULD GIVE BEST PERFORMANCE VEGETATION

P.S. look at my portfolio website and go into the "downloads" section, I have a neat grass generator which will populate your terrain based on a painted map(it's MULTITHREADED TOOO). Have a play around with it.
hendu
Posts: 2600
Joined: Sat Dec 18, 2010 12:53 pm

Re: Vegetation loader

Post by hendu »

I recently read Boulanger's thesis on vegetation rendering, it focused on grass and trees. I must say the grass solution is fairly nice:
http://www.kevinboulanger.net/grass.html
RdR
Competition winner
Posts: 273
Joined: Tue Mar 29, 2011 2:58 pm
Contact:

Re: Vegetation loader

Post by RdR »

hendu wrote:I recently read Boulanger's thesis on vegetation rendering, it focused on grass and trees. I must say the grass solution is fairly nice:
http://www.kevinboulanger.net/grass.html
Hmm looks nice indeed, will take a closer look when got the time.
Nice find :D

devsh wrote:First off... you need to stream the patches from disk... asynchronously
Secondly... it's going to take absolute FREAKING ages to stream if you don't compress your data (one idea is to store the mesh data once, and then all the transformations of the instances)

The actual patches that you have hanging around in memory should be determined so all the patches you are drawing are streamed in + a few around the edges

You'd need to modify irrlicht slightly so there would be a way of updating/creating the Static Hardware Mapped buffers(possibly while your physics is running or something).
Alternatively if the mesh you're instancing is below 512 indices/vertices then don't bother with that and save yourself a lot of trouble.

Then obviously HW instancing to reduce the meshbuffer size. This can be API native instancing (DX9 and OGL 3.0) or geometry shader instancing (OGL 3.0), you should let the user choose which one to use. You'd need to call ->draw() 'instance_number/max_no_of_instances' times, but you'd use the same meshbuffer.

All should be fine, since you multiply the verts by AT LEAST ONE matrix. But that WILL MEAN premultiplying every instance matrix with the viewproj matrix, because if you were to multiply by 2 matrices in the vertex shader, then your performance would drop compared to the "static mesh buffer batch".

Also beware, vegetation causes a lot of overdraw.... you'd need to use occlusion queries for your patches. Which could actually be very helpful in determining the LoD to use (because if would depend on the number of pixels on screen).

THIS WOULD GIVE BEST PERFORMANCE VEGETATION

P.S. look at my portfolio website and go into the "downloads" section, I have a neat grass generator which will populate your terrain based on a painted map(it's MULTITHREADED TOOO). Have a play around with it.
Thanks for the tips, but loading the vegetation from disk is not an options.
It takes to much disk space and will increase the TANK@WAR map size enormously :( (in MBs)
Post Reply