Hi Pau,
Thanks Ulrich, but I think this set one parameter for each vertex, and I really
need 32 values for each vertex (that's what I'm using multitexcoord) Finally I
think I have this problem solved, I had some problems with the glew
initialization. Now I'm having other problems uploading a texture to the GPU :P
Small correction, attribute arrays are vec4 arrays, so you can have 4
32-bit float attributes per vertex with one attribute array. Most cards
support at least 16 attribute arrays, and in OpenGL 2.x the standard
vertex attributes take up spots in those 16+. Including TexCoords! So
when you're using texcoords for multiple texture units, you're actually
using attribute arrays, just with a less general name.
I had a project where I needed 27 floats per vertex (spherical harmonics
coefficients) so I used 7 attribute arrays (9 to 15) to store them, then
used a = i / 4 and b = i % 4 in the shader to get the ith coefficient
(where a+9 gives the attribute array to index into and b gives the
element in the vec4).
I would recommend using attribute arrays (use arrays numbered 6 and up
or just count down from 15 so you don't collide with the standard
attributes) since in OpenGL 3.x that's how all rendering works (i.e. you
choose in which attribute array your vertices go, in which your
texcoords go, etc. - there are no predefined arrays named "vertex array"
and "texcoord array for unit 0" anymore.). It's also much more general
and makes it clear that you don't actually want to do texturing with
these values, but something else. For your 32 floats you would use 8
arrays, perhaps 8 to 15.
On a general note, avoid using straight GL code wherever you can. Even
if you wanted to use straight texcoord arrays for what you want to do,
you could have just used geometry->setTexCoordArray(unit, array) instead
of glMultiTexCoord4f. It leads to cleaner code, less problems, and OSG
can find ways to improve the performance of your app in ways you might
not know about. In this case, I assume you are using glMultiTexCoord4f
between glBegin and glEnd, in which case using vertex+texcoord arrays in
an osg::Geometry would be a big speed gain for anything but non-trivial
geometry (even if your geometry changes per frame, in which case you'd
do geometry->setUseDisplayLists(false) ).
Hope this helps,
J-S
--
______________________________________________________
Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
