stein@dhw68k.cts.com (Rick Stein) (01/17/89)
Sender: Reply-To: stein@dhw68k.cts.com (Rick Stein) Followup-To: Distribution: na Organization: Wolfskill & Dowling residence; Anaheim, CA (USA) Keywords:BSP, Moving Objects, Henry Fuchs Summary: I wrote Fuchs in June '87 and he never answered! In <2441.@kalliope.rice.edu>, Mark Hall writes: >If your plane will not interract with moving objects, I suggest >you drop the sorting to get hidden surface removal. A good article >is >"Near real-time shaded display of rigid objects", >by Fuchs, Abram, and Grant. SIGGRAPH 1983 Conference proceedings >(Computer Graphics 17, No. 3. July 1983 pp. 65-72) >It describes a BSP (Binary Space Partitioning) scheme where a one-time >process is used on the environment you want to fly through. >Thereafter you can draw the scene from any position/viewing >direction WITHOUT sorting (by walking a tree structure). > >This will not work for objects which can move, like other planes. >I think you could use this for the "earth" if you can assume that >the moving objects will not be "hiding" behind parts of the terrain. >I am thinking of other planes which will not be below ground level, >hiding behind trees, etc. You could use BSP to draw the terrain, and >any other technique for the other objects as a second step. > >As I remember, the article talks about trying to overcome the >problem of moving objects. Does anyone know of a later paper that >addressed this? > >- mark Having had the experience of building a BSP code for a flight simulator, I certainly would have been grateful for a followup paper on this topic. After writing Fuchs for an answer to the question which Mark has raised and not receiving a reply was a disappointing experience. About the only way that I know of to circumvent the shortcomings of the static BSP is to do line of sight computations. Find out whether or not a moving object is behind a hill or in front of it. If it is in front of the hill, and the LOS is clear between the moving object and your eyepoint, then draw the sucker. Otherwise don't draw it. Sure, this technique is not perfect, but I believe that the big boys (e.g. Singer, Evans&Sutherland, etc.) don't do much more than this. Then again, I could be wrong ( :-) ). If you got really good at it, I imagine that you could concatenate a BSP tree for the moving object in real-time to the terrain BSP tree. This would certainly require some serious horsepower. Since the terrain is organized as a tesselation, and remains fixed during the entire simulation, whats to stop you from moving a few pointers around at a 30 Hz rate :-). -- Rick 'Transputer' Stein ( My mother was a clairvoyant. :-) ) uucp:{felix, spsd, zardoz}!dhw68k!stein Internet: stein@dhw68k.cts.com
elf@dgp.toronto.edu (Eugene Fiume) (01/18/89)
In article <18654@dhw68k.cts.com> stein@dhw68k.cts.com (Rick Stein) writes: > >Having had the experience of building a BSP code for a flight >simulator, I certainly would have been grateful for a followup >paper on this topic. After writing Fuchs for an answer to the >question which Mark has raised and not receiving a reply was a >disappointing experience. That's because you should have been corresponding with Bruce Naylor about it. He developed the algorithm and, in my experience, is more than willing to talk about it at length. I'll respect his privacy and not publicise his address, but if you are really interested, send me mail, and I'll send you the latest address I have (although I think he reads this newsgroup). -- Eugene Fiume Dynamic Graphics Project University of Toronto elf@dgp.toronto.edu