From: Evan M. C. <le...@ca...> - 2000-04-12 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. // ev...@ca... 4885 Alpha Road, Suite 110 // 972-991-5322 x145 Dallas, TX 75244-4633 // 972-991-5352 fax. www.cambertx.com |
From: Stephen J B. <sj...@ht...> - 2000-04-13 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)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@ht... http://www.hti.com Home: sjb...@ai... http://web2.airmail.net/sjbaker1 |
From: Brian P. <br...@pr...> - 2000-04-13 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. C. <le...@ca...> - 2000-04-13 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. // ev...@ca... 4885 Alpha Road, Suite 110 // 972-991-5322 x145 Dallas, TX 75244-4633 // 972-991-5352 fax. www.cambertx.com |
From: Stephen J B. <sj...@ht...> - 2000-04-13 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)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@ht... http://www.hti.com Home: sjb...@ai... http://web2.airmail.net/sjbaker1 |
From: Evan M. C. <le...@ca...> - 2000-04-13 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)619-2657 (Vox/Vox-Mail) > L3Com/Link Simulation & Training (817)619-2466 (Fax) > Work: sj...@ht... http://www.hti.com > Home: sjb...@ai... 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. // ev...@ca... 4885 Alpha Road, Suite 110 // 972-991-5322 x145 Dallas, TX 75244-4633 // 972-991-5352 fax. www.cambertx.com |
From: Brian P. <br...@pr...> - 2000-04-14 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 |