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.
Vegetation loader
Re: Vegetation loader
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
http://www.kevinboulanger.net/grass.html
Re: Vegetation loader
Hmm looks nice indeed, will take a closer look when got the time.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
Nice find
Thanks for the tips, but loading the vegetation from disk is not an options.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.
It takes to much disk space and will increase the TANK@WAR map size enormously (in MBs)