Re: [Plib-users] clipping performance question.

[Steve B. <sjb...@ai...>]

"Curtis L. Olson" wrote:
> 
> Gouthas, Themie writes:
> > Just an optimization question for frustrum clipping, which would better be
> > directed to an OpenGL format, but this forum is more convenient at this
> > point in time..
> >
> > For basic line strips, say of 100's to 1000's of points. Is it worthwhile
> > going to the trouble of calculating a bounding spehere  for clipping to the
> > view frustrum, or is line clipping pretty efficient.

Depends on:

  1) How often your points are updated. (Do you have to update the bsphere
     every frame).

  2) How fast they move relative to the radius of the sphere. (You could for
     example increase the radius of the sphere by the speed of the fastest
     point every frame until the size of the sphere hit some magic limit,
     and only *then* go and recompute it.  If your points are *basically*
     buzzing around in a small area then this could be a big win.)

  3) Is there some incremental way to update the bounding sphere?

  4) The number of points in the cluster.

  5) (Critically) Do you want to run on older hardware without hardware
     Transforms & Lighting. (If you *do* then doing work in the CPU to
     save work in the CPU might make a lot of sense - but if you have
     hardware doing the clipping, it may be easier to simply squirt the
     points at the hardware and let T&L do the work.)

For line strips, you only need to find the six points with the largest
and smallest X, Y and Z coordinates - imagine a bounding cubeoid around
those limiting coordinates and then wrap your bounding sphere around
that.  That makes the bsphere a bit too large - but it's pretty cheap
to compute.

> > You would think that an
> > intelligent implementation would check the end points of a line segment
> > first and not attempt to draw it if both were out of the clipping rectangle.
> > Anyone have an idea what OpenGL does?

Probably uses the Sutherland outcode test.

> The middle of the line strip could intersect the view volume even if
> niether end point was visible.  Also, there's nothing that says a set
> of points have to be in a straight line, so it could wind in and out
> of the view volume several times.

The Sutherland algorithm gets around that efficiently.
 
----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net