Lwjgltexturestate and numFixedTexUnits

the water-texture bug that recently popped up on the forum was related to lwjgltexturestate.apply only doing certain initializations when the texture unit was < numFixedTexUnits.

we need to discuss where and how to handle numFixedTexUnits vs. numVertexTexUnits/numFragmentTexUnits.

it's a bit awkward now, with setTexture checking if the unit is within bounds for numTotalTexUnits, but the apply method only does work for units below numFixedTexUnits…textures above that, used by shaders will not get any texturematrix etc set…

my first two suggestions on solutions are:


  • let it be completely up to the user to check for avaliable textureunits, depending on his implementation(like i'm checking against the getNumberOfFragmentUnits() in the waterrenderpass), and thus, remove all checks against numFixedTexUnits etc(but keep the check against numTotalTexUnits)

  • don't check against the numFixedTexUnits in the apply method at all
  • make the texturestate.setTexture check against numFixedTexUnits instead, and add a method setTextureHardCore or something :slight_smile: that doesnt check at all. this to keep noob-users from not making 32 texture multitexturing errors…

I'd vote for number 1.  Maybe we could log a low level warning that the user does not have enough texture units to support that state as well somewhere in the code.

Heh that check-in had me confused.

Up to not so long ago jME would work with fixed texture units only in any case. I think it was Tora that wrote the patch to enable use of all texture units.

I guess users should check the number of texture units in any case if they want to target a broad range of cards… however not having any clear warning of any kind might make this a little hard to debug for some, no? Imagine writing a game, sending it to someone and getting the vague bug report that it "doesn't work".

Anyway, the (biggest?) difference between fragment only vs. normal textures units is that you can't set texture coordinates for the fragment only ones. Maybe we can put a warning there? (right now I think it silently ignores if you try to go over)

cool…i totally agree with finding good ways for minimizing erros and finding out why a client doesnt work on a comp…i'll give this some thought as well

Hmm… first thought about putting this in setTextureBuffer, but then you could load a model and still not notice. Now either I could put the warning in LWJGLRenderer which means you'd get it every time you try to render it, or I could also put the warning in the Savable method. I'm kind of leaning towards that last one… but if anyone else has other thoughts…

Savable method seems useful, but wouldn't take care of all cases…

setTextureBuffer (and copyTextureCoordinates, addTextureCoordinates) and loading through Savable should cover everything though, unless you extend GeomBatch. Correct me if I'm wrong…

I'll implement a little check method for this.

Checked in. Almost forgot the setTextureBuffers method.

will you check in a removal of the numFixedTexUnits from lwjgltexturestate.apply too?

I'm not sure what you need here.

AFAIK you can't set a matrix, or TEXTURE_ENVs for a fragment only unit, can you? What are you still missing?

damn it, you are probably right, should be so…i'm an idiot :slight_smile: thanks