From: Angus Dorbie (dorbie++at++sgi.com)
Date: 05/24/2000 15:51:45
I think you've misunderstood what I was trying to say, especially since
you are still asking for a 'fix'. There is no fix, isectors are not
supposed to operate the way you assumed they would.
I was trying to point out that this is not a bug which had previously
been suggested in the thread. Your application may require the results
depth ordered but my original response was not intended to be about your
requirement. I was trying to correct the assumption being made that they
should be depth sorted by performer in the isector. I'm sorry you've
been waiting on a further response, I hoped that the solution presented
by Dirk was sufficient when combined with my offering that the
functionality you desired was not part of the isector behaviour.
To depth sort hit results you do not require a square root, just compare
the sum of the squares and for HAT results you probably only need to
test the z component of the return value, you don't even have to
subtract to produce the vector components before the test. This should
be a very fast test.
Cheers,ANgus.
"Braun, Tom" wrote:
>
> I originally posted this question in February. Unfortunately, I still don't
> know if there is a fix for this problem in Performer. Can anyone help?
>
> "Braun, Tom (UNKNOWN)" wrote:
> >
> > Has anyone had a problem with the return vector values from a isector
> test?
> > I have set up a isector segment to look straight down in order to perform
> > terrain following. Over most all of my terrain the Terrain Height that is
> > returned to me is correct. However, over some parts of the terrain, the
> > height of the terrain that gets reported back to me is 10 to 50 feet below
>
> > the actual terrain height. Every polygon of my
> > database has been flagged at "terrain".
> >
> > Here is a snippet of how I perform my intersect:
> >
> > double PerformerDisplayWindow::GetTerrainHeight (double x, double y)
> > {
> > pfSegSet segset;
> > long isect;
> > pfHit **hits[10];
> > double z= 10000.0f;
> > double TerrainHeight = 0.0f;
> >
> > segset.activeMask = 0x1;
> > segset.isectMask = 0xFFFF;
> > segset.discFunc = NULL;
> > segset.bound = NULL;
> > segset.mode = PFTRAV_IS_PRIM|PFTRAV_IS_NORM|PFTRAV_IS_CULL_BACK;
> > segset.segs[0].dir.set(0.0f, 0.0f, -1.0f);
> > segset.segs[0].length = 50000.0f;
> > segset.segs[0].pos.set(x,y,z);
> > isect = Shared->model->isect(&segset,hits);
> > if(isect){
> > pfVec3 pnt;
> > (*hits[0])->query(PFQHIT_POINT, pnt.vec);
> > TerrainHeight = pnt[2];
> > }
> > else {
> > cout << "Warning: No terrain found at this location. TerrainHeight is
> > being set to zero."<<endl;
> > TerrainHeight = 0;
> > }
> > return(TerrainHeight);
> > }
>
> Dirk Lüsebrink was kind enough to send me a response and said that he had
> the same problem. His solution was to "get all intersections from the
> isector vector and sort this list by hand. with just seven hits and a 300
> MHZ cpu that is not such a performance problem, even when there are some
> square roots involved."
>
> To this Angus Dorbie wrote "I don't think intersection results are intended
> to be in depth sorted
> order. "
>
> Dirk's solution sounds reasonable to me. Has anyone found another method
> for getting the HAT isector to work?
>
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/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 : Wed May 24 2000 - 15:52:10 PDT