Chikai Ohazama (chikai@talula)
Fri, 5 Mar 1999 15:19:45 -0800 (PST)
________________________________________________________________________
Chikai J. Ohazama, Ph.D. Silicon Graphics Computer Systems
Member of Technical Staff 2011 N. Shoreline Blvd. ms 525
Advanced Graphics Division Mountain View, CA 94043.1389
Telephone: (650) 933-6533
FAX: (650) 964-8671
---------- Forwarded message ----------
Date: Thu, 04 Mar 1999 18:17:49 -0800
From: Angus Dorbie <dorbie@sgi.com>
To: Chikai Ohazama <chikai@talula.engr.sgi.com>
Cc: tzelin@cthulhu, don_burns@cthulhu, dorbie@cthulhu, rg@sgi.com
Subject: Re: Strange Culling of Volume in Performer Scene (fwd)
The bound box of the x29 or your volumizer geometry has not been
calculated properly or even at all, when it was added to the scene
graph.
You need to look at the geoset code, you can make bound box calculations
automatic or you can set a fixed bound box, automatic would be expensive
if you have dynamic geometry.
If you are drawing your geometry in a draw callback then what you are
seeing is exactly as I'd expect, the X29 is being culled and the draw
callback is never invoked. You need to adjust the bound volume of the
X29 to include your data, or add the volumizer output to the scene graph
as a geoset instead of using a draw callbacks. In many respects with
callbacks Performer doesn't know your data exists, it just calls your
code whenever it draws the data it knows about.
Cheers,Angus.
Chikai Ohazama wrote:
>
> I'm not that famiilar with Performer and I thought you guys may have some
> insight into his problem, so do you guys think you could help out this
> guy?
>
> Thanks.
>
> ________________________________________________________________________
> Chikai J. Ohazama, Ph.D. Silicon Graphics Computer Systems
> Member of Technical Staff 2011 N. Shoreline Blvd. ms 525
> Advanced Graphics Division Mountain View, CA 94043.1389
> Telephone: (650) 933-6533
> FAX: (650) 964-8671
>
> ---------- Forwarded message ----------
> Date: Thu, 4 Mar 1999 15:21:24 -0800
> From: Eric Webster <ewebster@spawar.navy.mil>
> To: info-volumizer@corp.sgi.com
> Subject: Strange Culling of Volume in Performer Scene
>
> I am trying to get up to speed on the use of
> Volumizer with Performer. Right now I have run into
> a strange culling effect that occurs when my scene
> contains surface geometry objects and a volume object.
>
> I started with the perfvol demo code that ships with
> Volumizer. Unfortunately, the system that I am
> developing on does not have the IFL development option,
> so I am unable to compile the code as is.
> Thanks to a suggestion from Robert Grzeszczuk [rg@hoek.engr.sgi.com]
> I replaced the IFL code in the perfvol code with the
> Raw Image I/O routines found in the woglRaw OpenGL example.
> Although this restricts me to using raw image files,
> I am able to compile and execute the (modified) perfvol demo.
>
> I then introduced a surface geometry node into the scene.
> I loaded the x29.sv object and placed it under its own DCS
> which I then placed under the "scene dcs" used for the
> trackball transformer.
>
> At first the volume wasn't "hiding" the x29, when
> the x29 was behind the volume. After checking the
> documentation and the code, I realized that I had added the
> x29 to the scene after the volume, resulting in the volume
> being drawn first. After switching the order of the two
> objects, the scene was drawn correctly--with the translucent
> volume partially obscuring the x29 when the x29 was behind
> the volume.
>
> But then I came upon a strange effect when the x29 left the
> field of view. At the instant that the center-point of
> the x29 leaves the view, the volume (and its associated
> tetra box and brick box outlines) vanish. As I move
> the x29 further out of the view, the volume remains
> undrawn until the entire boundingsphere of the x29 is
> out of view, at which point the volume and the outlines
> reappear. Then, if I move the x29 back toward the view,
> the volume disappears when the x29 boundingsphere re-enters
> the view, and then the volume reappears when the center-point
> of the x29 gets back into view. It seems as if having
> the x29 partially out of view is causing the volume node
> to be culled.
>
> I then tried several modifications to see what might
> be causing this behavior:
>
> - First I removed the line
> shared->chan->setTravMode(PFTRAVCULL, PFCULL_VIEW|PFCULL_GSET);
> from main.cxx of perfvol.
> - Next I tried changing the transformer to
> FLY mode and removing the top level DCS node.
> With this I first tried placing the x29 DCS and the
> volume object under a root pfGroup, which I then added
> to the scene. I also tried adding the x29 DCS and
> the volume object directly to the scene (without
> an intervening pfGroup).
> - I then tried adding additional copies of x29.sv,
> each under its own DCS.
>
> None of these modifications eliminated the behavior of
> the culling of the volume object. However, when I added
> multiple x29 objects, I discovered that it was the position
> of the "last" x29 that affected the culling of the volume.
> (That is, the other geometries can be partially out of
> view without affect the volume. Only when the "last" x29
> node (that was added to the scene just prior to adding
> the volume) goes partially out of view does the volume
> suddenly get culled.
>
> Perhaps there is some "normal" Performer behavior that is
> going on here that I am not aware of. Or perhaps my code
> additions to perfvol is doing something that shouldn't
> be done. Or perhaps this is some sort of bug. Regardless, I
> am wondering if others have observed this behavior, and, if
> so, if there is a solution. (Of course, I realize that
> the solution may be to "fix my buggy code." :)
>
> I have not attached my code to this email, but if someone
> desires to see it, I can supply it.
>
> Thanks,
> Eric Webster (ewebster@spawar.navy.mil)
> SPAWARSYSCEN, San Diego
-- "Only the mediocre are always at their best." -- Jean GiraudouxFor advanced 3D graphics Performer + OpenGL based examples and tutors: http://www.dorbie.com/
This archive was generated by hypermail 2.0b2 on Mon Nov 01 1999 - 12:03:15 PST