From: Angus Dorbie (dorbie++at++sgi.com)
Date: 01/22/2001 05:05:08
Well you could get the texture coordinates for the triangle, compute the
intersection point and look up the alpha value for that texel in the
original texture image if you still have the host copy. It's a bit long
winded but unless you do then as you say, you'll be reading some kind of
framebuffer data back.
On that subject, the one thing you might want to try is to read ALPHA
back from the framebuffer if you have destination alpha. This would be
written with the alpha value of the texture image, with the right
background clear value and an alpha func to trim zero values (so you can
get opaque data from other geometry) any framebuffer read which is non
zero should occult the sun.
Another approach might be clear the sky black and have nothing else on
the station completely black, so reading black rgb from the sun position
in the framebuffer would indicate lack of occlusion.
Finally if you draw the sun and read that region back you could test for
an exact match of the suns color in that region and flare accordingly.
Cheers,Angus.
Simon C Mills wrote:
>
> Brian Furtaw wrote:
> >
> > Could you give some more information about what you are trying to do. If
> > you have doorways or windows in buildings that are modeled transparently
> > it will require a different solution then trying to shoot through trees.
> > What are you intersecting with and why? In Performer each pfNode carries
> > an isect mask so you can have classes of objects that behave differently
> > in isect queries. You are most likely going to need to add some extra
> > information to the scenegraph to solve your problem.
>
> OK. I have a model of the International Space Station which is had lots
> of thin truss structures. To model these we use transparency in textures
> a lot to represent geometry. This is the model I'm intersecting with.
> I'm drawing a nice sun and lens flare effect (to make the sun look
> really bright and for camera simulation) and to test if the sun is
> occluded I'm using an intersection test. The test uses a vector from the
> eye point in the sun direction and the effect is drawn depending on the
> intersection result. Now, because intersections don't take the purely
> transparent areas into account, I get anomalies where the sun is in view
> but the intersection returns true and turns off the effects.
>
> So, I'm looking for a way around this problem without having to model
> the whole ISS in solid geometry (_lots_ of polygons required for this!).
>
> One thought I also had was to use stencil tests since the areas causing
> the anomalies are purely transparent (alpha = 0). By setting alpha draw
> function to alpha > 0 these pixels are not draw. At the same time I
> could update the stencil buffer and use this then as an additional test
> after by intersection test. This relies on the fact that the
> intersection uses the eye point and would allow me to combine the 3D and
> 2D (pixel space) techniques. In fact any 2D technique that indicates if
> any part of the sun's disk is not occluded would be sufficient.
>
> Thanks for your interest,
> Simon
> _______________________________________________________________________
>
> Simon Mills
> Silicon Worlds S.A.
> c/o Modelling & Simulation Section (TOS-EMM) Tel: +31 (0)71 565 3725
> European Space Agency (ESA/ESTEC) Fax: +31 (0)71 565 5419
> Postbus 299, 2200AG Noordwijk e-mail: simon++at++wgs.estec.esa.nl
> The Netherlands http://www.estec.esa.nl/wmwww/EMM
> _______________________________________________________________________
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Open Development Project: http://oss.sgi.com/projects/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
-- For Performer+OpenGL tutorials http://www.dorbie.com/"In the middle of difficulty lies opportunity." --Albert Einstein
This archive was generated by hypermail 2b29 : Mon Jan 22 2001 - 05:06:11 PST