It looks like the key to getting shaders working with multiple texture units has to do with the texture target geometry knowing about the proper texture coordinates. A while ago SetVertex() was modified to set up the first 8 multitexture coordinates. Right now only square uses this call as far as I can tell. All of the Geos could be changed to use this function or a different SetTexCoord() one could be made to deal with the glMultiTexCoord2fARB calls. The code would be pretty ugly if each Geo added 7 more texture calls per vertex otherwise.
Also, I quickly added a 'texunit' message and glActiveTextureARB() call the pix_texture which allows for the use of multiple texture units in shaders without pix_multitexture. I don't know if this is duplicate work or goes against plan, but it seems pretty straightforward when working with shaders.
cgc
I committed the pix_texture changes to use multiple texture units. Not sure if the calls need to have an ifdef around them or not?
cgc
On 8/30/06, chris clepper cgclepper@gmail.com wrote:
It looks like the key to getting shaders working with multiple texture units has to do with the texture target geometry knowing about the proper texture coordinates. A while ago SetVertex() was modified to set up the first 8 multitexture coordinates. Right now only square uses this call as far as I can tell. All of the Geos could be changed to use this function or a different SetTexCoord() one could be made to deal with the glMultiTexCoord2fARB calls. The code would be pretty ugly if each Geo added 7 more texture calls per vertex otherwise.
Also, I quickly added a 'texunit' message and glActiveTextureARB() call the pix_texture which allows for the use of multiple texture units in shaders without pix_multitexture. I don't know if this is duplicate work or goes against plan, but it seems pretty straightforward when working with shaders.
cgc
On Aug 31, 2006, at 2:51 PM, chris clepper wrote:
I committed the pix_texture changes to use multiple texture units. Not sure if the calls need to have an ifdef around them or not?
..."GL_arb_multitexture" has been a core part of OpenGL since 1.3, so most modern gl drivers will have it...however, I don't know what the GL version of the "open source" gl drivers for linux is (not just the Intel ones, either), so we should check that out, because there are several people who use them...
...I'm not against this addition to pix_texture because it doesn't change any default behavior, and it solves a current need today, allowing much experimentation with the glWrappers...but, I think it could lead to confusion once we have a better multitexture system in GemState/GemShape...one problem is that once you assign a pix_texture to a texunit, then you can't use it in a different unit until the next render cycle/frame...
On 8/30/06, chris clepper cgclepper@gmail.com wrote: It looks like the key to getting shaders working with multiple texture units has to do with the texture target geometry knowing about the proper texture coordinates. A while ago SetVertex() was modified to set up the first 8 multitexture coordinates.
...I don't remember seeing this: still on your HD?
Right now only square uses this call as far as I can tell. All of the Geos could be changed to use this function or a different SetTexCoord() one could be made to deal with the glMultiTexCoord2fARB calls. The code would be pretty ugly if each Geo added 7 more texture calls per vertex otherwise.
...seems like we need a new GemState item for "multiTexUnits", by default 0, ranging 0-7...then we could add a loop to SetVertex() to call the MultiTexCoord2f calls as needed...by default, SetVertex() would behave the same as it does now...of course this would then require us to rewrite the geos to only use SetVertex(), but so far that doesn't seem to be much more than passing on values...
...one limitation I see with this is it kinda ignores the possibility of setting up the texture matrix/filtering/environment parameters, but this could addressed by adding the proper messaging to [pix_multitexture] on per a texUnit basis...
...hmm, so i guess it's off to see if it can work?
jamie
-
chris clepper -
james tittle