Erik Hofman writes:
> Ouch, that's too much for me. I've 192 Mb internal memory which is
> shared with the video adaptor (and textures).
I've figured out the solution, but will need some time to implement
it.
Right now, I have top level transformation and range nodes for groups
of objects on every surface -- that way, if a tri-fan (for example) is
more than, say, 10km away, all of the objects on it will be skipped,
saving hundreds or thousands of individual LOD tests.
My plan is to extend the ssgRangeSelector to have an additional member
for over the maximum distance, so the range array would look something
like this:
float ranges = {0, 10000f, 99999999f};
Under the ssgRangeSelector, I will put two empty ssgBranch nodes, one
for within the range (i.e. <=10000m) and one for outside the range
(i.e. >10000m). Each of these will have a reference to the same user
data structure containing information about the objects should should
be generated and a flag indicating whether the objects currently
exist.
I will then add a pre-traversal callback to each branch that examines
the user data. The callback for the in-range branch will check
whether the dynamic objects currently exist; if not, it will generate
them, add them to itself, and set the flag in the user data. The
callback for the out-of-range branch will check whether the dynamic
objects currently exist; if so, it will remove them from the in-range
branch (so that their memory is freed) and clear the flag in the user
data. As surfaces move out of the user-specified range for dynamic
objects, their memory will be freed automatically, and then
reallocated later if needed.
Any comments or suggestions?
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
