Re: [osg-users] Thousands of trees

Oded,

I wasn't just making a comment, I'm trying to get you to analyse the
problem. 50,000 trees at 30 fps is 120 MB of data, just to transfer to
the graphics card in vertecies and texture coordinates if you use simple
quads. This is probably doable, but it requires that you approach the
problem understanding your hardware limitations and specific bottlenecks.

If you are using billboards, then even spatializing your database won't
help because each billboard must be visited anyway to do the eyepoint
rotation, which means that you also have to send down a matrix with each.

The more I think about this, the more I think that your solution is in a
vertex program. The GPU should be able to handle this easily enough, but
you are really up against system bandwidth issues otherwise.

-don

On Wed, 5 Jan 2005, Oded Argon wrote:

> Well, I agree with you.
> I am trying to keep the boss happy :-)
> The need is to try and make sure not to drop from 30 FPS.
> The amount of trees is kind of a special scenario, not something we
> need to deal with on a regular bases.
>
>
> On Wed, 5 Jan 2005 10:40:52 -0800 (PST), Don Burns
> <don@andesengineering.com> wrote:
> >
> > 50,000 trees is a lot by any standards. What are your expectations and
> > what are the expectations based on?
> >
> > -don
> >
> > On Wed, 5 Jan 2005, Oded Argon wrote:
> >
> > > Hi Don,
> > >
> > > I am "playing" with the osgforest example to try the best way to go.
> > > As I understand dividing the tree is exactly what the example does...
> > > but running it with 50,000 trees seems to be pushing it too much.
> > >
> > > Oded
> > >
> > > On Wed, 5 Jan 2005 10:19:12 -0800 (PST), Don Burns
> > > <don@andesengineering.com> wrote:
> > > >
> > > > Ok, there's two ways to fix your problem. Yes, the vertex program would
> > > > help your cull time. Actually, you'd just do a trivial accept (disable
> > > > culling) on all your trees.
> > > >
> > > > But the second way is to better spatialize your trees. If you have all of
> > > > your trees under a single group (or billboard) then Cull must visit every
> > > > single tree at cull time. If you break your trees up into spatialized
> > > > groups, and, in fact, heirarchical spatialized groups, then cull can do
> > > > trivial accepts/rejects of large areas of trees without having to visit
> > > > every single one.
> > > >
> > > > -don
> > > >
> > > > On Wed, 5 Jan 2005, Oded Argon wrote:
> > > >
> > > > > Hi Don,
> > > > >
> > > > > My bottleneck seems to be the cull time of all those trees as each
> > > > > tree is a clone of a model under a static transform to position the
> > > > > tree. I'm still not sure of what kind of deep copy I should use, but
> > > > > it looks like I did something right.
> > > > > I get rid of the transforms using the optimizer but the problem is
> > > > > probably still having every tree as a different geometry (the loaded
> > > > > model).
> > > > > I think your suggestion of a vertex program will not help my cull
> > > > > time, or am I missing something ?
> > > > >
> > > > >
> > > > > On Wed, 5 Jan 2005 09:19:43 -0800 (PST), Don Burns
> > > > > <don@andesengineering.com> wrote:
> > > > > >
> > > > > > Beat me to the punch. The right way to do thousands of trees is to use a
> > > > > > vertex program. The botteneck is likely bandwidth between memory and the
> > > > > > graphics card, not the capability to render the geometry.
> > > > > >
> > > > > > This is quite a similar situation to a demo I've colaborated with Russ
> > > > > > Smith (of ODE fame) recently on. The demo was done for SGI and shows a
> > > > > > building with a couple of thousand bricks. The building is then blown up
> > > > > > and all the bricks behave with all the proper collisions and physical
> > > > > > behavior provided by ODE. Russ threaded ODE to work across multiple CPUs,
> > > > > > and thus show off the multi-CPU architecture. With 6 CPUs the simluation
> > > > > > updated at a reasonable rate (30 fps, or so).
> > > > > >
> > > > > > The graphics trick to update the positions of the bricks worked like this.
> > > > > > A group node placed above all bricks enables a vertex program. A custom
> > > > > > drawble was written for each brick, which still used a display list for
> > > > > > the brick, but also sent down a color and secondary color for each brick.
> > > > > > The brick's position was defined in the RGB (or XYZ) of secondary color
> > > > > > and its attitude in the RGBA (or XYZW) as a quaterion encoded in the
> > > > > > primary color.
> > > > > >
> > > > > > When not using vertex shaders, it would be necessary to place a matrix
> > > > > > transforms over every single brick Geode. This caused an update time of
> > > > > > 12 ms and a cull time of 30 ms. THe draw time was also long because of
> > > > > > all the matricies that had to be sent to the graphics.
> > > > > >
> > > > > > With the vertex shader, update was negligible (about 200 microseconds) and
> > > > > > cull was under 4 milliseconds.
> > > > > >
> > > > > > -don
> > > > > >
> > > > > >
> > > > > > On Wed, 5 Jan 2005, Robert Osfield wrote:
> > > > > >
> > > > > > > Hi Oded,
> > > > > > >
> > > > > > > Group trees on the same local area into a single osg::Geometry would help, as
> > > > > > > would using VBO's (depending upong your hardware/drivers though..).
> > > > > > >
> > > > > > > Another route would be to use a billboards but instead using osg::Billboard
> > > > > > > use standard osg::Geode/osg::Geometry + a vertex program to rotate the quads
> > > > > > > towards the viewer. I haven't personally tried this but it certainly be
> > > > > > > doable.
> > > > > > >
> > > > > > > Robert.
> > > > > > >
> > > > > > > On Tuesday 04 January 2005 19:07, Oded Argon wrote:
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > I am trying to figure out the best way to go trying to add a lot
> > > > > > > > (~50,000) trees (double quads for example).
> > > > > > > > I looked at the osgforest example and read a discussion in the archive
> > > > > > > > from about a year ago.
> > > > > > > > As far as I understand what I want to do is not to share the geometry
> > > > > > > > in order to get rid of the transforms (using the optimizer) but it
> > > > > > > > still seems to be a bit too much... trying to increase the tree count
> > > > > > > > to 50,000 in osgforest didn't give a lot of hope for getting good
> > > > > > > > frame rates.
> > > > > > > >
> > > > > > > > Is there any thing else I should do trying to get good performance
> > > > > > > > rendering that much trees ?
> > > > > > > >
> > > > > > > > and another question related to this subject.
> > > > > > > > When trying not to share the geometry for my trees I should use the
> > > > > > > > clone method right ? but which parameters should I give it ?
> > > > > > > > I tried deep copy drawables and arrays and that seemed to be OK, but
> > > > > > > > it is just a guess... (trying deep copy all for the 50,000 double quad
> > > > > > > > trees kind of "killed" my machine consuming more memory than
> > > > > > > > possible...
> > > > > > > >
> > > > > > > > Thanks for any help and ideas,
> > > > > > > > Oded
> > > > > > > > _______________________________________________
> > > > > > > > osg-users mailing list
> > > > > > > > osg-users@openscenegraph.net
> > > > > > > > http://openscenegraph.net/mailman/listinfo/osg-users
> > > > > > > > http://www.openscenegraph.org/
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > osg-users mailing list
> > > > > > > osg-users@openscenegraph.net
> > > > > > > http://openscenegraph.net/mailman/listinfo/osg-users
> > > > > > > http://www.openscenegraph.org/
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > osg-users mailing list
> > > > > > osg-users@openscenegraph.net
> > > > > > http://openscenegraph.net/mailman/listinfo/osg-users
> > > > > > http://www.openscenegraph.org/
> > > > > >
> > > > > _______________________________________________
> > > > > osg-users mailing list
> > > > > osg-users@openscenegraph.net
> > > > > http://openscenegraph.net/mailman/listinfo/osg-users
> > > > > http://www.openscenegraph.org/
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > osg-users mailing list
> > > > osg-users@openscenegraph.net
> > > > http://openscenegraph.net/mailman/listinfo/osg-users
> > > > http://www.openscenegraph.org/
> > > >
> > > _______________________________________________
> > > osg-users mailing list
> > > osg-users@openscenegraph.net
> > > http://openscenegraph.net/mailman/listinfo/osg-users
> > > http://www.openscenegraph.org/
> > >
> > >
> >
> > _______________________________________________
> > osg-users mailing list
> > osg-users@openscenegraph.net
> > http://openscenegraph.net/mailman/listinfo/osg-users
> > http://www.openscenegraph.org/
> >
> _______________________________________________
> osg-users mailing list
> osg-users@openscenegraph.net
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
>
>

_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Received on Wed Jan 5 11:10:58 2005