[osg-submissions] Possible mipmap-bug for all kind of textures
Robert Osfield
robert.osfield at gmail.com
Sat Sep 8 00:48:19 PDT 2007
Hi Art,
I'm just heading off for the weekend. On my return I'll review this
topic. In the meantime feel free to experiment with changes to the
code.
BTW, thanks for making the changes to int texture support, haven't had
a chance to review yet, but will do on my return.
Robert.
On 9/8/07, Art Tevs <stud_info2 at yahoo.de> wrote:
> Hi Robert,
>
> Yes there is nor real definition how the mipmaps
> should looks like for the integer textures. But
> however the bug also appears if the hardware just do
> not support glGenerateMipmapEXT (I do not know if ATI
> has support for this, but this bug could also appear
> there).
>
> It is likely that the user wants to fill the mipmap
> levels by himself (with a shader program). So there
> must be a way to create the empty mipmap levels by the
> osg. For example I need mipmap in an integer texture,
> however I do fill the levels by my self. But since
> glGenerateMipmap and probably also gluBuildMipmaps is
> not supported, so there were no empty levels
> generated. Here I excpected something like:
>
> for (i=0; i < maxlevel; i++)
> glTexImage2D(i, ...)
>
> be done by the osg. This behaviour must also appear
> when the internal format is changed or if the
> minification filter changes (from non-mipmapped to
> mipmapped). I think it has also be done by size
> changes.
>
> I propose to add a new method to the texture (i.e.
> buildMipmapLevels()) which will either rebuild the
> levels immediately or on a next ::apply call.
> The method could either call the glGenerateMipmapEXT
> (move it from the framebufferobject away, since it
> actually corresponds to the textures and not to the
> fbos) or regenerate the levels manually by the various
> calls of glTexImage. This can be choosen by the check
> of the internal format or by the specified parameter.
>
>
> What do you think?
>
> Art
>
>
>
>
>
>
> --- Robert Osfield <robert.osfield at gmail.com> schrieb:
>
> > HI Art,
> >
> > This does sound like a bug, although not one that
> > will be hit by most users..
> >
> > W.r.t integer textures and mipmapping, one issue
> > will be the
> > associated filtering, do you just assume the int is
> > actually a float
> > do the filtering then cast back to int?
> >
> > I would also wonder if glu's mipmap generation would
> > support int textures.
> >
> > I don't know what you are expecting in terms of
> > functionality, with so
> > much on the OpenGL side not supported.
> >
> > Robert.
> >
> > On 9/7/07, Art Tevs <stud_info2 at yahoo.de> wrote:
> > > Hi Robert.
> > >
> > > I think I found something wrong. Assume your
> > hardware does not support
> > > glGenerateMipmapEXT. Now you create an empty
> > texture (not from an image) and
> > > you want to be able to render to the mipmap levels
> > of the texture through an
> > > fbo. So the mipmaps are never generated through
> > the glTexImage* (level, ...)
> > > since there is no such call. For texture created
> > from an image it works, but
> > > for empty texture it doesn't.
> > >
> > > If you also change your texture minification
> > properties from non-mipmapped
> > > to mipmapped (e.g. NEAREST_MIPMAP_NEAREST) after
> > the texture is already
> > > generated (i.e. in the next frame or after some
> > time) then there is no code
> > > which checks for this changes to regenerate
> > mipmap-levels.
> > >
> > > As I already said, this happens only if the
> > hardware does not support
> > > glGenerateMipmapEXT, since otherwise it will be
> > generated by the next call
> > > to the apply of the fbo.
> > >
> > > I am working on a workaround. I need this mipmap
> > behaviour for the integer
> > > textures and it seems that the driver or hardware
> > does not support automagic
> > > generation of mipmaps for integer textures. Even
> > just a simple generation of
> > > mipmap levels with undefined data is not
> > supported, if I am right.
> > >
> > > Art
> > >
> > >
> > >
> > >
> > >
> > > ________________________________
> > > Heute schon einen Blick in die Zukunft von E-Mails
> > wagen? Versuchen Sie´s
> > > mit dem neuen Yahoo! Mail.
> > >
> > >
> > > _______________________________________________
> > > osg-submissions mailing list
> > > osg-submissions at lists.openscenegraph.org
> > >
> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
> > >
> > >
> > _______________________________________________
> > osg-submissions mailing list
> > osg-submissions at lists.openscenegraph.org
> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
> >
>
>
>
> __________________________________
> Alles was der Gesundheit und Entspannung dient. BE A BETTER MEDIZINMANN! www.yahoo.de/clever
> _______________________________________________
> osg-submissions mailing list
> osg-submissions at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>
More information about the osg-submissions
mailing list