Real men don't use glu, eh?
Deluxe Reverb
viable techniques to downsize and filter the image appropriately? Thanks.
Danny
Jason Allen
to do all the mipmap generation for you :)
Jason A.
"Deluxe Reverb" <deluxe...@SPAMMENOTcolumbus.rr.com> wrote in message
news:8h3Y8.163720$%U3.45...@twister.columbus.rr.com...
Deluxe Reverb
hoping to implement something fairly generic. Here's what I've got so far:
1) Load image from disk
2) Resample up (if necessary) to dimensions that are powers of 2.
3) Give to glTexImage2D. Break at 1x1.
4) Box-filter and reduce.
5) Goto #3.
I know that a box-filter is rather crude, but is that all gluBuild2DMipmaps
does? My results certainly appear to look the same, but are at least twice
as fast as glu (which makes me think glu might be doing something more
sophisticated). If I'm missing out on a better filter, lemme know.
I'm looking into how to take advantage of GL_SGIS_generate_mipmap now.
Thanks for the info.
Danny
"Jason Allen" <jra...@yahoo.com> wrote in message
news:JM5Y8.114811$q53.2...@twister.austin.rr.com...
fungus
> If your video card supports GL_SGIS_generate_mipmap you can use the hardware
> to do all the mipmap generation for you :)
>
The mipmaps are the easy part - just average four
pixels.
The hard part is when you have a 673x227 pixel image
and you have to produce the top level mipmap.
--
<\___/>
/ O O \
\_____/ FTB.
Deluxe Reverb
resample routine out of an image processing kit I wrote some years ago.
Works like a champ.
I just figured a four-pixel average was just too simplistic for the job (I
was playing around with various convolution matrix filter weights), but I
guess not - it works great. All my references to glu have now been deleted,
so I guess I can consider myself a man now.
Thanks, all!
"fungus" <sp...@egg.chips.and.spam.com> wrote in message
news:3D315D74...@egg.chips.and.spam.com...
Alex
just the, say, upper left corner of a larger 2^^x texture with the image and
stretch the texture coordinates accordingly when applying to a surface.
Alex
"Deluxe Reverb" <deluxe...@SPAMMENOTcolumbus.rr.com> schrieb im
Newsbeitrag news:_w9Y8.164173$%U3.48...@twister.columbus.rr.com...
fungus
> Instead of resampling up the original image it's easier and faster to fill
> just the, say, upper left corner of a larger 2^^x texture with the image and
> stretch the texture coordinates accordingly when applying to a surface.
>
So how do you repeat the texture across a landscape?
Ruud van Gaal
Why not download MESA, copy the gluBuild2DMipmaps() source, and call
it 'internalBuild2D...'? :)
That gets you out of GLU (not that you'd want to).
Ruud van Gaal
Free car sim: http://www.racer.nl/
Pencil art : http://www.marketgraph.nl/gallery/
fungus
> On Sun, 14 Jul 2002 00:07:32 GMT, "Deluxe Reverb"
> <deluxe...@SPAMMENOTcolumbus.rr.com> wrote:
>
>
> ...gets you out of GLU (not that you'd want to).
>
gluBuild2dMipmaps() *will* crash with certain image
sizes, you shouldn't use it in any software where
the users supply the image files.
Wim Libaers
news:3d32d779....@news.xs4all.nl:
> On Sun, 14 Jul 2002 00:07:32 GMT, "Deluxe Reverb"
> <deluxe...@SPAMMENOTcolumbus.rr.com> wrote:
>
>>Sadly, I'm still dependent on it for gluBuild2DMipmaps. What are the most
>>viable techniques to downsize and filter the image appropriately? Thanks.
>
> Why not download MESA, copy the gluBuild2DMipmaps() source, and call
> it 'internalBuild2D...'? :)
>
> That gets you out of GLU (not that you'd want to).
The license allows that, but it would be fairly pointless to use that code
when you wanted to avoid it, no?
--
Wim Libaers
Remove DONTSPAM from my reply address to send me mail.
Deluxe Reverb
Now, with the addition of three relatively simple routines to my library (a
net increase of less than 3K), I've got a gluBuild2DMipmaps replacement that
works much faster and won't crash regardless of what size image I throw at
it.
"fungus" <sp...@egg.chips.and.spam.com> wrote in message
news:3D32D93D...@egg.chips.and.spam.com...
Ruud van Gaal
<wim.DONTSP...@pandora.be> wrote:
>ru...@marketgraph.nl (Ruud van Gaal) wrote in
>news:3d32d779....@news.xs4all.nl:
>
>> On Sun, 14 Jul 2002 00:07:32 GMT, "Deluxe Reverb"
>> <deluxe...@SPAMMENOTcolumbus.rr.com> wrote:
>>
>>>Sadly, I'm still dependent on it for gluBuild2DMipmaps. What are the most
>>>viable techniques to downsize and filter the image appropriately? Thanks.
>>
>> Why not download MESA, copy the gluBuild2DMipmaps() source, and call
>> it 'internalBuild2D...'? :)
>>
>> That gets you out of GLU (not that you'd want to).
>
>
>
>The license allows that, but it would be fairly pointless to use that code
>when you wanted to avoid it, no?
Avoiding GLU is I think only useful to avoid it in the linking phase.
Now why you'd want that? For one, I had a hard time getting GLU back
on Linux, where a de-install of MESA deleted GLU, and the nVidia
OpenGL pack didn't put one back in. ;-)
But at what sizes does gluB2DMM crash then? Any non-power-of 2? That's
easily checked. Would be hard to write a routine I think that DOES
crash when everything's neatly 2^n. :)
César Blecua Udías
>
[...]
>
> But at what sizes does gluB2DMM crash then? Any non-power-of 2? That's
> easily checked. Would be hard to write a routine I think that DOES
> crash when everything's neatly 2^n. :)
I'm interested about this. For some years, I've been testing my
applications with ElectricFence, and some of them call
gluBuild2DMipmaps. ElectricFence never caused a crash on such function,
and I tried several images for testing (not power of 2).
César
cesar...@ono.com
fungus
>
> ...at what sizes does gluB2DMM crash then?
>
All I know is a user sent me a file which crashed
my program in gluBuild2dMipMaps(). It was a really
weird size like 753x237 or something like that but
unfortunately I don't remember what it was exactly.
> Any non-power-of 2? That's
> easily checked. Would be hard to write a routine I think that DOES
> crash when everything's neatly 2^n. :)
It's definitely not a simple rule like that.
Anybody up for writing a program to try all possible
sizes?
It might take a while to run.... :-)
Maybe it would be faster to pick through the source
code for glu and look for the problem.
Wim Libaers
[...]
> Avoiding GLU is I think only useful to avoid it in the linking phase.
> Now why you'd want that? For one, I had a hard time getting GLU back
> on Linux, where a de-install of MESA deleted GLU, and the nVidia
> OpenGL pack didn't put one back in. ;-)
[...]
Sure, but why delete MESA? No need to do that, just leave it and install
the nvidia drivers, then instruct X to look for that driver instead of
MESA. Keeping MESA for glu is recommended.
A better reason might be if your system doesn't have glu, or you're
extending the functionality of a routine.