Front Warrior's Instanced Grass 100k-384k polygons per frame

[ACE247]

Hm, yeah wanted to suggest this earlier, however there's also some other article from GPU gems 2 on 'moving towards photorealistic virtual botany' or something like this.

[devsh]

Yeh I read them all...

anyway the grass in Far Cry isn't that epic, http://primagames.files.wordpress.com/2008/10/04.jpg

it looks modeled because it bends smoother on the wind because it is tesselated, let me illustrate. It also has normal maps == overkill


To achieve better results I might ask eigen to make more LoD levels so the thing runs faster and there is less popping and the patch sizes can be smaller

[ACE247]

Well ,em no that far cry 2 image doesnt show the scale of the grass, view distance is super epic! Will post one from my pc just now, in say 15minutes.
And i think that is some extreme vertex wastage in that image from FW.
Ok maybe its not so impressive, but still theyre using camera facing 3d volume billboards if you play the game and pay attention you will notice what I mean. And its very fast. 100fps only grass and schrubs on 9800GT.

[/img][URL=http://img197.imageshack.us/i/grassha.png/]

[devsh]

oh goodie then ours is comparable. I can pat myself on the back, anyway the geometry shader is slow again and I need to update it so it runs just as fast with the bloody wind and lighting. Once I am done with these I shall make a powerpoint outlining my techniques. My future plans for Front Warrior:

Dynamic Shadow Maps,
Dynamic Lighting,
Good Explosions, Fire which casts soft shadows and causes heat shimmer.
http://http.developer.nvidia.com/GPUGem ... _ch06.html
Retexturing the Whole game to have normal and relief maps

[ACE247]

Well for Fire you could also look at spark partcile engine, but get the svn version, it has spark 2 in it with dx11 features i think.

[devsh]

i do not care about dx11, but it would be a good idea to compress FW's textures. I will talk to eigen about it. About textures as a whole, because some are undersampled, some time ago I wrote a C++ function that loaded textures and had a stub for streaming, it basically loaded in 4k textures and downscaled them to whatever the user chose, most common for FW target minimum hardware would be 512 or 1k, and people like me could load the proper 2k or 4k versions. Compression would speed up render time...

I have my own idea about how particles should be made batching FTW. I hope to be able to emit 200 to 2000 billboards and do the rotation in the vertex shader instead of the irrlicht CPU way.

[ACE247]

Yeah, but you have to keep CPU and GPU calculations balanced, so dont chuck too much on either!
In my game I use CPU for AI, particles, sound and physics(ode). While GPU does all rendering, shaders, and Geometry etc.
This combo tends to yield highest Frame rate.

[devsh]

billboard rotation should be done in the Vertex shader though...

anyway if one has a second graphics card, physics should be done on that gpu, especially if its an embedded into the motherboard (new mobos have opencl/cuda capable embedded card which are of no use anyway because they wont crossfire or SLI, http://www.nvidia.com/object/main_mobo_gpus.html

[ACE247]

Yeah but my game architecture still had more than enough free cpu time so I did physics on there rather than the gpu, coz gpu had less process time left. Try analyzing front warrior with Nvidia Perfhud. You'll probably need a Windows pc for that, except if it runs in wine.
I'm quite interested in that streaming 'stub', maybe you could post the could if you want.

[devsh]

welll the implementation varies. basics

a reference count for a texture from static nodes that use it
then a separate one from dynamic
calculate a 5 second average of your speed
when starting the app carry out four tests, pack a 4x4k texture with zlib and write to a paging file on disk (like Virtual RAM), a reading test and two tests for uploading a texture to opengl and downloading it. get a pixels/msec speed. Then scale it by the time in msec allocated to the process each frame (tweakable by user), and then multiply by some variable which changes with the number of CPU cores present. You have to multithread this even on single core machines so there is not a lag in FPS.
So if the closest node that uses a given texture is you Far Distance (draw range) away + the distance you would travel in the time you need to download a texture from ogl and write it, then offload texture into RAM. And then if the distance increases, so its that distance+the one you would travel within the time needed to write the texture to disk and read it then offload from RAM.
Two problems:
1) if you suddenly need to load a lot of textures
spread loading and offloading over several frames
2) if you cant load the textures before they appear in the viewing distance
have a backup set of 128*128 or 64*64 ones that you can load quickly and swap untill the proper ones load

[ACE247]

Thanks, will get on trying this soon.

[ent1ty]

devsh: do you calculate the position and rotation of grass nodes on runtime?

[devsh]

get the terrain max XZ and min XZ, get the terrain splat map which tells you where the grass texture is, plant at different densities according to the map, use irrlicht's terrain's getHeight to get the position, + add some random seed to make the grass placing less uniform, then get the terrain's normal at the final position, get the grass model's up vector do some matrix or quaternion magic to work out the rotation needed to make the up vector point the way that the terrain's normal does.

[Virion]

interesting topic. looks like you 2 are cooperating happily.

[ent1ty]

Behold!


Thanks to ACE for grass mesh and texture!
The rotation is still somewhat buggy from time to time. Fix that, and then for the normalmaps..