You could try some form of "imposter rendering" to handle the wheat in the distance, but I would say this should be tried after moving things onto the GPU and seeing what kind of performance you get. Imposters are a useful technique but have their own cost which really needs to be taken into account since it could slow things down if used improperly.
If you're fillrate limited you can opt for alpha testing instead of blending for your textures which will help speed things up. On modern hardware you can get this to look very nice with some transparency anti-aliasing. Good luck E. --- Eric Maslowski Research Computer Specialist University of Michigan 3D Lab Autodesk 3D Studio Max Certified Trainer email: [EMAIL PROTECTED] office: 734-615-9699 mobile: 734-730-9904 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jesse Lane Sent: Thursday, October 18, 2007 00:58 To: [email protected] Subject: Re: [Opensg-users] Particle tricks Thanks. We'll be viewing the wheat from the viewpoint of a combine or tractor so from the ground. We are batching the wheat into "cells" of about a meter or so wide, so quite a large bunch. I have the GPU Gems books and have read that particular article and may try to implement some of the ideas there. My only problem with putting entire rows on a single object is that the wheat is harvestable so I'd have to recalculate the different LODs all the time. Is this done often? Is it reasonable(possible)? Thanks again. -jesse On 10/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Hi Jesse, How will you be viewing the fields of wheat? Will you be viewing it from above, on the ground, or both? Generally speaking, try to batch your strands of wheat if possible. Avoid one stalk per particle for everything. Try putting multiple stalks on a single particle. For particles in the distance, try putting entire rows on a single object instead of keeping individual particles. This works particularly well with distance LODs that "fade" between levels. If you animate the foreground then the switch is rarely noticed. There's an article in the first GPU Gems Book (and on NVIDIA's website I believe) entitled "Rendering Countless Blades of Waving Grass" by Kurt Pelzer. It a great article and would be a good place to start. :) Best, E. Quoting Jesse Lane < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >: > 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 advance. > > Jesse Lane > ------------------------------------------------------------------------- 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 ------------------------------------------------------------------------- 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
