Re: [Algorithms] portal engines in outdoor environments
Brought to you by:
vexxed72
From: gl <gl...@nt...> - 2000-08-18 21:31:54
|
I think the idea is that you wait for the data to be spit out at the end of the pipe, so it shouldn't stall. Of course by this time you've queued a few frames and/or are already drawing some of them, hence the delay. -- gl ----- Original Message ----- From: "Bernd Kreimeier" <bk...@lo...> To: "Brian Paul" <br...@va...> Cc: <gda...@li...> Sent: Friday, August 18, 2000 10:22 PM Subject: Re: [Algorithms] portal engines in outdoor environments > Brian Paul writes: > > The actual value of this extension is questionable. The problem > > is you have to do a read-back from the hardware to get the > > occlusion test result and the hit from doing that can be substantial. > > Someone here said that the idea is to count on frame coherence > and use results from previous frames as an indicator. But yeah, > just on gut level I would not be suprised to see any kind of > readback interfere with the performance of pipelined architectures. > > > b. > > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list > |