Light vector bump mapping issue

PowerVR Insider
1

I am going over the bump mapping code in the multitexture exercise, and on line doesn’t make a whole lot of sense.





In the bumpmap itself, the normal’s xyz components are mapped to rgb. Yes, easy enough. Yet when the lighting vector is calculated and submitted via glColor, mapping is different: red is now “y”, green is z, and blue is x.





Can anyone clarify why this apparent inconsistancy?

2

Hi distantsuns,

The reason seems to be fairly arbitrary, some combination of originally being in bgr order and a swapping of the z and y channels (the latter is possibly due to the way PVRTexTool handles bump data - something I need to look into).

In any case it’s just because of the way the texture is ordered, and this is going to vary depending on how you created the texture. Any combination is effectively valid as long as you order your channels correctly.

Thanks,

Tobias



3

Well, neither my bumpmap or image are in PVR, they’re standard PNG files. Could the ordering still change when loaded into GL?





If you could see if the bytes are reordered when sending the texture to GP vs. the way glColor sees the world, that would be a big help. I’d rather not have to annotate the code in my article when explaining the inconsistency as “just because”.





mike

4

Hi Mike,

The demo was written for a texture that was created with the normals in the order yzx, so the color is uploaded in that order. If you were to use a texture (such as from a png) which is in xyz order, then the light vectors should be submitted to glColor4f in xyz order too. OGLES does nothing to re-order the channels, it is entirely up to the user’s input.

Thanks,

Tobias



5

Thanks Tobias, I had a bug in my own software such that the visuals worked with the vector as specified in your own code. So now since I know I wasn’t going mad, the both issues have been fixed and peace shall now guide the planets…





Also, FYI, the demo suites are very well done. Crisp, to the point, minimal clutter. Thanks!





And while I have you here one other quick question:





Also in the same demo setting up the combiners, is the order of the following two snippets equivalent?





#1


    glTexEnvf(GL_TEXTURE_ENV, GL_SOURCE0_RGB, GL_TEXTURE);


    glTexEnvf(GL_TEXTURE_ENV, GL_SOURCE1_RGB, GL_PREVIOUS);





#2


    glTexEnvf(GL_TEXTURE_ENV, GL_SOURCE0_RGB, GL_PREVIOUS);


    glTexEnvf(GL_TEXTURE_ENV, GL_SOURCE1_RGB, GL_TEXTURE);





Mike


6

Hi Mike,

Glad you’re finding our SDK to your liking :slight_smile:

The way you’ve written it they are not equivalent no, however…

Switching the two lines in the second example will make them equivalent.

#1


    glTexEnvf(GL_TEXTURE_ENV, GL_SOURCE0_RGB, GL_TEXTURE);


    glTexEnvf(GL_TEXTURE_ENV, GL_SOURCE1_RGB, GL_PREVIOUS);





#2




    glTexEnvf(GL_TEXTURE_ENV, GL_SOURCE1_RGB, GL_TEXTURE);


    glTexEnvf(GL_TEXTURE_ENV, GL_SOURCE0_RGB, GL_PREVIOUS);



GL_PREVIOUS will just use whatever was previously computed, so if it’s after the one with GL_TEXTURE, then that’s fine. If it’s before the call with GL_TEXTURE then it might be the same but it would be down to what your last colour compute was, and so pretty much a coincidence.

Thanks,

Tobias