[osg-submissions] EXT_texture_integer submission ShaderModel 4.0

[Art Tevs]

Hi Robert.

--- Robert Osfield <robert.osfield at gmail.com> schrieb:

> HI Art,
> 
> I have just reviewed your changes, and am not
> comfortable with all the
> changes.
 
> First up I am not convinced by the value of adding
> all the Vec classes
> as the these are related primarily to vector maths
> or vertex arrays
> managed in osg::Geometry, rather than texturing.  It
> would seem the
> only need for this your addition of int and uint
> border colours to
> Texture, and for these I feel that they are not even
> the right way to
> tackle this problem - having duplicate border
> colours is not
> appropriate.  A better way would be just to case the
> Vec4 into a ints
> format as required, or to moving the responsibility
> of setting the
> border colour into the Image.  Perhaps changing to a
> Vec4d would be a
> way of keeping the precision of a int/uint better
> than the Vec4(f) -
> this is what Lua does for maths.

I see. Yes I thought about this, but I decided to add
an extra int/uint border color, to prevent type
casting. 
For a simple application a type casting might be the
answer, but for a GPGPU approach a float or even
double border color is not the answer. 

1. What if I like to have an integer texture with
border set to a certain int value. I mean I specify a
real bit string of 32 bits. Thus to call
tex->setBorderColor(osg::Vec4((double)0xABCDEF12),
...); is more or less not intuitive, since you might
do not know what double type conversion will do with
this value on your System.

2. Having type conversion you also have to check if
you have to call glTexParameterIiv or
glTexParameterIuiv for unsigned and signed
values/textures. 

I understand that having more setBorderColor functions
might be confuse. But there is no real way to overcome
this, since you want to have osg also be usefull for
GPGPU. I think we have to blame the extension
developers that they give us a lot of more or less
redundant functions ;-)

What about void* border color?

 
> Second, having two bools to represent whether the
> internal format is
> int or unit is not appropriate.  If you have to have
> a format flag
> then this would be best done as a single enum, and
> possible one that
> is not stored in the Texture but rather computed on
> the fly when
> required.

I agree with that. This would be my second choice.
Would you like to make changes or should I do this. I
would suggest to make something like this
enum{
 UINT = 0x2,
 SINT = 0x1,
 INT = UINT | SINT,
}

probably with some extra addings for float and for
standard normalized formats. What do you think?



Art

 
> Robert.
> 
> On 9/6/07, Art Tevs <stud_info2 at yahoo.de> wrote:
> > Hi folks,
> >
> > I attached a patch to the latest osg svn, which
> does
> > implement integer textures as in the Shader Model
> 4.0
> >
> >
> > Features:
> > 32, 16 and 8 bit unsigned and signed integer
> textures.
> > see EXT_texture_integer for more details
> > New Vector types added Vec2i, Vec2ui, Vec3i,
> Vec3ui,
> > Vec4i, Vec4ui
> >
> >
> > Testings:
> > - I have tested it by loading a raw integer image
> into
> > a texture. Texture was readable by the fragment
> > shader.
> >
> > - Write to integer texture is more tricky, since
> it
> > require changings to the Shader.cpp (thus will
> follow
> > next days)
> >
> >
> > ToDo:
> > - Robert please correct following in the
> > Texture2DArray submission, which I have submitted
> > before:
> > void Texture2DArray::computeInternalFormat() const
> > {
> >     if(_image.valid())
> > computeInternalFormatWithImage(*_image);
> >     else checkIntegerInternalFormat();
> > }
> >
> > - Please add new Vec*i and Vec*ui into the list of
> > include files which will be installed (since I am
> not
> > able to find this ;-))
> >
> >
> > I would be very appreciated if it could be
> included
> > into the osg core. I would also be very happy if
> the
> > Texture2DArray submission would also be included
> into
> > the core. More Sh4.0 patches will follow soon.
> >
> >
> > Best regards, Art
> >
> >
> >
> >        __________________________________
> > Yahoo! Clever - Der einfachste Weg, Fragen zu
> stellen und Wissenswertes mit Anderen zu teilen.
> www.yahoo.de/clever
> >
> > _______________________________________________
> > 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
> 



      Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: 
http://de.yahoo.com/set