Jesse Lane wrote: > Hello all. I'm currently working on a project that simulates a large > field of wheat that is harvestable. I'm currently using particles to > represent the wheat. I need to be able to render quite a lot of > pieces. Right now my frame rate is dropping to about 5fps when > rendering 10,000 particles, and if possible we'd like to push this up to > another order of magnitude (or even 2). I'm not an expert in particle > systems, or graphics for that matter, and I could use any suggestions, > tips, or tricks that can be tossed my way for optimizing this field. > I'm contemplating pushing some of the work out to shaders, especially > since I'd like to add some effects like wind and noise. I've done some > rudimentary profiling and the lion's share of the time is being spent in > the render call (I'm using VRJuggler and my application is a > cannabilized version of OpenSGApp so the render call is in draw()). > Thanks in advan ce.
Pushing stuff to the GPU is a good idea, if your app can handle it. Braindumping techniques that could apply: * Animating in a shader (apply wind direction/velocity increasingly with distance from ground). * Billboarding completely in vertex shader. (a bit difficult to get it right, if you want to draw a "textured line-strip", but possible) * Generating patches of 1x1m to be drawn in a single draw call is good. (somewhere above 1k vertices is a good thing). Generate a few different on each LOD (using noise) to avoid repetitiveness, see texture-splatting.) * Shifting between precomputed fixed LOD geometries, for efficiency. * Interpolating the LODs using alpha-test & a grainy alpha map, to avoid popping. See http://www.speedtree.com might help. They actually have something called SpeedGrass too, which is nifty (but you have to e-mail them about it). Good guys, good product. * Using vertex texturing to compute "harvested" state in a vertex shader might work too. Useful if your "harvest map" is more coarse-grained than each wheat. (If not, using a single vertex attribute for that could work, but AFAIK 1.8 doesn't allow attribute streams on a geometry to have different static/dynamic VBO-properties.) If you need to stick to CPU generated geometries, it is vital to disable display lists, i.e. call Geometry::setDlistCache(false) to get any sort of performance. Also, make sure you use a vertex format that can be used by glDrawElements/glDrawArrays (i.e. preferrably a single gl-geometry type (GL_POINTS/LINES/TRIANGLE_STRIP). If glVertex() shows up in your profiling, you need to do something about that.) Cheers, /Marcus ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
