Re: [Celestia-developers] Improved visibility culling patch

[Chris L. <cl...@gm...>]

On Wed, Feb 27, 2008 at 4:35 AM, Selden E Ball Jr
<se...@le...> wrote:
> Unfortunately, converting to using Visible instead of hiding
>  pieces in the distance would be a major rewrite: elimination
>  of many different ScriptedOrbit functions, plus addition of code
>  to modify Visible when buttons are pressed.
>
>  The effects of changing the bounding radii aren't obvious to me.
>  Would be appropriate to set them to (for example) somewhat larger
>  than the model sizes but setting the distances to much larger values
>  when hiding the models?

The bounding sphere needs to be large enough to contain every point in
the orbit. The consequence of specifying a too small a bounding radius
is that Celestia may not draw the object. It occurs to me that since
the whole point of some of your scripted orbits is to hide objects
that aren't supposed to be seen, it should be ok for you to specify a
smaller bounding radius. As long as it's large enough to contain the
range of points at which the object is meant to be seen, everything
should work fine. In fact, if the ScriptedOrbit just allows an object
to be either at a fixed position or hidden off at some distant point,
a bounding radius of zero is ok. You don't need to worry about the
model size: Celestia should automatically account for this.

Specifying a huge bounding radius for an object 'pollutes' the
bounding sphere hierarchy all the way up the reference frame tree.
When one of the Hale telescope objects has a one light year bounding
radius, the so does the Earth--culling of any immediate child objects
of Earth becomes impossible, and each of their orbits must be
evaluated.

>  Of course, I'm most interested in the performace when the components
>  are all within view, where culling couldn't help much.

Your performance tests suggest that culling still plays some role. I'd
be interested to hear what results you get by reducing bounding sphere
radii for your ScriptedOrbits.

--Chris
>
>  s.
>
>
>
>  > That's very strange . . .  But, I think that I know what the problem
>  > might be. If I recall, the Hale add-on uses ScriptedOrbits that have
>  > enormous bounding radii. This will effectively prevent any culling
>  > whatsoever, as Celestia cannot make rough guesses about where anything
>  > is located. Does the new visible allow you to do away with those large
>  > bounding radii?
>
>  > That said, I'm not expecting a big performance improvement from this
>  > fix for your Hale add-on. I don't think that there are many chances to
>  > cull geometry when the viewer is near the telescope. However, when the
>  > camera isn't near the telescope, the new culling code should do a good
>  > job of preventing any ScriptOrbits from executing, thereby boosting
>  > the frame rate.
>
>  > --Chris
>
>  > On Tue, Feb 26, 2008 at 6:12 PM, Selden E Ball Jr
>  > <se...@le...> wrote:
>  > >
>  > >  I'm sorry to say that the render patch does not improve
>  > >  performace in all situations :-(
>  > >
>  > >  The following fps values were obtained by rerunning my previous tests,
>  > >  but with a new window size: full screen window (not "full screen mode").
>  > >  Previous tests were with a smaller window.
>  > >  These were recorded while viewing the Hale control desk,
>  > >  run under WinXP 32, sp2,
>  > >  compiled with VS2005 Express and makerelease.bat
>  > >
>  > >  Celestia  fps w/o switches    fps with switches drawn
>  > >  v 1.5.0          15.5         11.1     (baseline)
>  > >  r 4138           25           13.5
>  > >  r 4149           24           13.9     (current svn code)
>  > >   " +render patch 21.2         12.4
>  > >
>  > >  I'm not sure the fractions are meaningful. Although they were quite
>  > >  stable in a given run, r4138, for example, got 28fps (w/o switches)
>  > >  in one run, and then 25fps when I ran it again after running
>  > >  4149+render patch. r4149+render patch also varied between runs.
>  > >
>  > >  I think it would help if the fps value didn't take so long to
>  > >  display a new value. Currently it seems to sit for 5-10 seconds
>  > >  at one value (e.g. 3.5fps right after loading the models),
>  > >  and then steps to a new value (e.g. 20fps)
>  > >  It would be better, I think, if it were to display a "running value"
>  > >  updated several times a second, averaged over the past few updates.
>  > >
>  > >  s.
>  > >
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by: Microsoft
>  Defy all challenges. Microsoft(R) Visual Studio 2008.
>  http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>  _______________________________________________
>  Celestia-developers mailing list
>  Cel...@li...
>  https://lists.sourceforge.net/lists/listinfo/celestia-developers
>