Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Evan M. Carey <levan@ca...>  20000412 21:28:11

I tried looking in the archives and the FAQ but didn't find an answer to my question so forgive me if this has been answered already. I'm making a 2D map. Some of the polygons in this map are very very small. It appears that if a polygon is sufficiently small Mesa throws it out. I've got sections of my map which are always going to be composed of _lots_ of little polygons and when they are not rendered I end up with a big hole in the map. If I change my orthographic projection to look closer in at the hole I see that the geometry for the polygons is valid cause they'll show up at close inspection. In my application I don't mind that while rendering these small polygons that the pixel used to represent them will be repeatedly updated until I've scanned over far enough to start in on a new pixel. I.E. last polygon rendered gets it. That's actually desirable for my domain. Any suggestions? Thanks in advance!  // Evan M. Carey Camber Corp. // evan@... 4885 Alpha Road, Suite 110 // 9729915322 x145 Dallas, TX 752444633 // 9729915352 fax. http://www.cambertx.com 
From: Stephen J Baker <sjbaker@ht...>  20000413 13:19:34

On Wed, 12 Apr 2000, Evan M. Carey wrote: > I'm making a 2D map. Some of the polygons in this map are very very > small. It appears that if a polygon is sufficiently small Mesa throws > it out. I've got sections of my map which are always going to be > composed of _lots_ of little polygons and when they are not rendered I > end up with a big hole in the map. If I change my orthographic > projection to look closer in at the hole I see that the geometry for the > polygons is valid cause they'll show up at close inspection. I agree that Mesa should not throw out polygons no matter how small  for precisely the reason you say...and the OpenGL specification does not permit such a thing to be done. However, I'm pretty sure I heard of such an "optimisation" being added to Mesa (and I protested at the time). Steve Baker (817)6192657 (Vox/VoxMail) L3Com/Link Simulation & Training (817)6192466 (Fax) Work: sjbaker@... http://www.hti.com Home: sjbaker1@... http://web2.airmail.net/sjbaker1 
From: Brian Paul <brian@pr...>  20000413 14:37:12

Stephen J Baker wrote: > > On Wed, 12 Apr 2000, Evan M. Carey wrote: > > > I'm making a 2D map. Some of the polygons in this map are very very > > small. It appears that if a polygon is sufficiently small Mesa throws > > it out. I've got sections of my map which are always going to be > > composed of _lots_ of little polygons and when they are not rendered I > > end up with a big hole in the map. If I change my orthographic > > projection to look closer in at the hole I see that the geometry for the > > polygons is valid cause they'll show up at close inspection. > > I agree that Mesa should not throw out polygons no matter how > small  for precisely the reason you say...and the OpenGL specification > does not permit such a thing to be done. However, I'm pretty sure I > heard of such an "optimisation" being added to Mesa (and I protested at > the time). There was a problem with FP over/underflow when rendering very small triangles. It wasn't an optimization. Evan, in src/tritemp.h you can try changing the area test for small triangles and see what happens. The code in question is: if (area * bf < 0  area * area < .0025) return; Try replacing the .0025 with a smaller value, or zero. Brian 
From: Evan M. Carey <levan@ca...>  20000413 15:57:09

Brian Paul wrote: > if (area * bf < 0  area * area < .0025) > return; > > Try replacing the .0025 with a smaller value, or zero. > > Brian Brian, I made the predicate like so: if (area * bf < 0  area * area <= 0) return; I realize there might still be problems with excessively small areas but for my app this seems to work OK...so far. Thanks for the reply. I _really_ appreciate the quick solution. If I do end up having problems I know where to go to play with the limit. Thanks,  // Evan M. Carey Camber Corp. // evan@... 4885 Alpha Road, Suite 110 // 9729915322 x145 Dallas, TX 752444633 // 9729915352 fax. http://www.cambertx.com 
From: Stephen J Baker <sjbaker@ht...>  20000413 17:11:21

On Thu, 13 Apr 2000, Evan M. Carey wrote: > I made the predicate like so: > > if (area * bf < 0  area * area <= 0) ^^^^^^^^^^^^^^^^ A number times itself can't be less than zero, so '== 0' might be better...then you might as well save the multiply and go with 'area==0'. Steve Baker (817)6192657 (Vox/VoxMail) L3Com/Link Simulation & Training (817)6192466 (Fax) Work: sjbaker@... http://www.hti.com Home: sjbaker1@... http://web2.airmail.net/sjbaker1 
From: Evan M. Carey <levan@ca...>  20000413 17:16:06

Stephen J Baker wrote: > On Thu, 13 Apr 2000, Evan M. Carey wrote: > > > I made the predicate like so: > > > > if (area * bf < 0  area * area <= 0) > ^^^^^^^^^^^^^^^^ > A number times itself can't be > less than zero, so '== 0' might > be better...then you might as > well save the multiply and go > with 'area==0'. > > Steve Baker (817)6192657 (Vox/VoxMail) > L3Com/Link Simulation & Training (817)6192466 (Fax) > Work: sjbaker@... http://www.hti.com > Home: sjbaker1@... http://web2.airmail.net/sjbaker1 Duh. What was i thinking. Your right. Save that one for you stupid code page Steve.  // Evan M. Carey Camber Corp. // evan@... 4885 Alpha Road, Suite 110 // 9729915322 x145 Dallas, TX 752444633 // 9729915352 fax. http://www.cambertx.com 
From: Brian Paul <brian@pr...>  20000414 00:47:34

"Evan M. Carey" wrote: > > Brian Paul wrote: > > > if (area * bf < 0  area * area < .0025) > > return; > > > > Try replacing the .0025 with a smaller value, or zero. > > > > Brian > > Brian, > > I made the predicate like so: > > if (area * bf < 0  area * area <= 0) > return; > > I realize there might still be problems with excessively small areas but for my > app this seems to work OK...so far. Thanks for the reply. I _really_ > appreciate the quick solution. If I do end up having problems I know where to > go to play with the limit. Great. Understand that I'm still hesitant to put this change into Mesa by default. I distinctly remember problems with FP over/underflow and tiny triangles. I don't have time right now to reexamine this problem in any detail now. Brian 
Sign up for the SourceForge newsletter:
No, thanks