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
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::cout
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 quite a
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
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 not
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 overhead
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
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, but it
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 rather then to
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
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 time
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 enough,
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
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.
Cool, but it
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 calls.
We
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 with
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
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 and even
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
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
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 and
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 glad
you
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.
After a while the tile cache fills up and the oldest entries need to
be purged.
The problem is that to free an entire tile takes mroe that a frame's
worth of time so
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
25 matches
Mail list logo
