"Curtis L. Olson" <[EMAIL PROTECTED]> said:
> David Megginson writes:
>
> Maybe a middle ground approach would be to add a branch for each
> fan/strip and then underneath that, add a branch for the objects from
> each leaf.
This is a **long** thread :-) (and I'm behind reading the list). I'm g
Curtis L. Olson writes:
> David Megginson writes:
> > Norman Vine writes:
> >
> > > Also even though we probably would be drawing more objects
> > > I wouldn't expect much of a hit in that there would be lot fewer
> > > culling operations
> >
> > When I was initially experimenting, putting all
Curtis L. Olson writes:
> However there is still an issue to worry about. The random ground
> cover code can create thousands of objects which means a branch node
> in our scene graph with thousands of kids. plib is not exactly
> efficient at deleting kids and even if you know the index, it
Erik Hofman writes:
> Could we all *PLEASE* forget about std:: in the code and use
> SG_USING_STD() at the beginning of the file instead. That way I don't
> have to correct every file that contains debugging statements like this.
I'll also recommend that all primary developers currently usin
David Megginson writes:
> Curtis L. Olson writes:
>
> > However there is still an issue to worry about. The random ground
> > cover code can create thousands of objects which means a branch node
> > in our scene graph with thousands of kids. plib is not exactly
> > efficient at deleting kids
David Megginson writes:
> Curtis L. Olson writes:
>
> > However there is still an issue to worry about. The random ground
> > cover code can create thousands of objects which means a branch node
> > in our scene graph with thousands of kids. plib is not exactly
> > efficient at deleting kid
Norman Vine writes:
> > How big is the hit if you simply delete a higher-level node and let
> > plib delete all of the branches and leaves underneath automatically?
>
> My guess is that we would gain more by having the random objects
> connected to the leaf rather then to the individual triangles.
David Megginson wrote:
> How big is the hit if you simply delete a higher-level node and let
> plib delete all of the branches and leaves underneath automatically?
Probably equivalent. The overhead is usually in all the per-chunk
bookeeping, not the function calls.
We could try playing games wit
Michael Basler writes:
>
> > I'll also recommend that all primary developers currently using G++
> > 2.95 on Posix systems switch to G++ 3.2.
>
> While I am not a primary developer I would be interested if it is possible
> to build under Cygwin's GCC 3.2 already?
YES - but be prepared for some
> I'll also recommend that all primary developers currently using G++
> 2.95 on Posix systems switch to G++ 3.2.
While I am not a primary developer I would be interested if it is possible
to build under Cygwin's GCC 3.2 already?
Regards, Michael
--
Michael Basler, Jena, Germany
Andy Ross writes:
> David Megginson wrote:
> > How big is the hit if you simply delete a higher-level node and let
> > plib delete all of the branches and leaves underneath automatically?
>
> Probably equivalent. The overhead is usually in all the per-chunk
> bookeeping, not the function calls.
Andy Ross writes:
> David Megginson wrote:
> > How big is the hit if you simply delete a higher-level node and let
> > plib delete all of the branches and leaves underneath automatically?
>
> Probably equivalent. The overhead is usually in all the per-chunk
> bookeeping, not the function
Curtis L. Olson writes:
> > How big is the hit if you simply delete a higher-level node and let
> > plib delete all of the branches and leaves underneath automatically?
>
> Big. This is the big hit people were reporting and we were discussing
> originally ... worst case scenario we are talk
David Megginson wrote:
> Curt's problem, though, is that his deletion code has to do a linear
> search in the parent for each child node to remove it; I assume that
> plib's internal code just iterates.
Ah, never mind then. :)
Yeah, O(N^2) deletion behavior with thousands of nodes is bad, and no
On Thursday 24 October 2002 8:02 am, Curtis L. Olson wrote:
> John Check writes:
> > On Wednesday 23 October 2002 11:48 pm, Curtis L. Olson wrote:
> > > I just fixed a bug in the tile freeing code which accounted for the
> > > very long pauses people were seeing after flying for a while.
> >
> > Co
David Megginson writes:
> What I meant is that you use your scheduler a little higher up the
> scene tree. The dynamic objects, for example, are under separate
> branches for each scenery triangle; just deleting the top-level
> triangle branch should be good enough, rather than recursing right to
On Thursday 24 October 2002 4:30 am, Erik Hofman wrote:
> John Check wrote:
> > On Wednesday 23 October 2002 11:48 pm, Curtis L. Olson wrote:
> >>I just fixed a bug in the tile freeing code which accounted for the
> >>very long pauses people were seeing after flying for a while.
> >
> > Cool, but i
Andy Ross writes:
> Ah, never mind then. :)
>
> Yeah, O(N^2) deletion behavior with thousands of nodes is bad, and no
> allocator hack is going to fix that for us. I'm with David now; plib
> might have trouble doing constant-time deletion of children, but it
> certainly should handle a plain old
David Megginson writes:
> Andy Ross writes:
>
> > David Megginson wrote:
>
> > > How big is the hit if you simply delete a higher-level node and let
> > > plib delete all of the branches and leaves underneath automatically?
> >
> > Probably equivalent. The overhead is usually in all the pe
Curtis L. Olson writes:
> David Megginson writes:
> > What I meant is that you use your scheduler a little higher up the
> > scene tree. The dynamic objects, for example, are under separate
> > branches for each scenery triangle; just deleting the top-level
> > triangle branch should be good enou
Norman,
This seems like a sensible optimization. If you remove the last entry
you don't need to do a memmove ... just decrement the total count. We
don't worry about freeing the memory until the entire list goes away,
and we never shrink list memory allocation.
But ok, while we are optimizing h
> From: [EMAIL PROTECTED]
> [mailto:flightgear-devel-admin@;flightgear.org]On Behalf Of Norman Vine
> So if you aren't comfortable hacking, I suggest waiting a bit yet
Thanks, Norman, so I'll prefer to wait. As a close watcher of the scene you
might give a shout to the list when you think it's t
Curtis L. Olson writes:
> Andy Ross writes:
> > Ah, never mind then. :)
> >
> > Yeah, O(N^2) deletion behavior with thousands of nodes is bad, and no
> > allocator hack is going to fix that for us. I'm with David now; plib
> > might have trouble doing constant-time deletion of children, bu
Curtis L. Olson writes:
> Norman Vine writes:
> > > How big is the hit if you simply delete a higher-level node and let
> > > plib delete all of the branches and leaves underneath automatically?
> >
> > My guess is that we would gain more by having the random objects
> > connected to the leaf rath
Norman Vine writes:
> IMHO we should take advantage of our existing bucketing by fans
> and put the LOD nodes at the 'leaf's branch' level instead of the individual
> triangle level. Just doing this would save us LOTS of nodes and should
> speed things up a bit and not require YAN set of bran
David Megginson writes:
> > No, unfortunately, it does not handle a plain old recursive
> > destruction without having to do a linear search to find each kid
> > first. (Granted it's a short linear search since it should find it
> > right at the beginning of the list, but still, a lot more ove
David Megginson
> Norman Vine writes:
>
> > IMHO we should take advantage of our existing bucketing by fans
> > and put the LOD nodes at the 'leaf's branch' level instead of the
individual
> > triangle level. Just doing this would save us LOTS of nodes and should
> > speed things up a bit and
Norman Vine writes:
> Also even though we probably would be drawing more objects
> I wouldn't expect much of a hit in that there would be lot fewer
> culling operations
When I was initially experimenting, putting all objects under a
fan-level branch gave quite a performance hit, as well as out
David Megginson writes:
> Norman Vine writes:
>
> > Also even though we probably would be drawing more objects
> > I wouldn't expect much of a hit in that there would be lot fewer
> > culling operations
>
> When I was initially experimenting, putting all objects under a
> fan-level branch gave
John Check writes:
> On Wednesday 23 October 2002 11:48 pm, Curtis L. Olson wrote:
> > I just fixed a bug in the tile freeing code which accounted for the
> > very long pauses people were seeing after flying for a while.
>
>
> Cool, but it breaks for gcc3.2 line 704 of tileentry.cxx needs std
John Check wrote:
On Wednesday 23 October 2002 11:48 pm, Curtis L. Olson wrote:
I just fixed a bug in the tile freeing code which accounted for the
very long pauses people were seeing after flying for a while.
Cool, but it breaks for gcc3.2 line 704 of tileentry.cxx needs std::cout
Could
On Wednesday 23 October 2002 11:48 pm, Curtis L. Olson wrote:
> I just fixed a bug in the tile freeing code which accounted for the
> very long pauses people were seeing after flying for a while.
Cool, but it breaks for gcc3.2 line 704 of tileentry.cxx needs std::cout
___
32 matches
Mail list logo
