I’m attempting to use multiple texture coordinates in a GLSL shader (… not as actual texture coordinates, but that’s another matter ), and I seem to be having trouble: as far as I see, accessing any set of coordinates after the first (i.e. p3d_MultiTexCoord0) gives only the data in that first.
I’ve confirmed that the egg file has multiple sets of UV-coordinates in its vertex-data, that the data is different between sets of coordinates, and that my shader has “in vec2 p3d_MultiTexCoord” for each UV-map, starting with 0.
Is there something that I should do to make the UV-sets available to the shader?
p3d_MultiTexCoord0 will give the set of texture coordinates corresponding to the texcoord_name specified in the first TextureStage, MultiTexCoord1 the second texture stage, etc.
Out of curiosity, does it work if you refer to it directly by name using an underscore, as in “in vec2 texcoord_yourname” ?
Printing out the texture stages and their associated texture coordinate names, I see only two stages (one for each texture), and those stages seem to both be associated with the first set of texture coordinates.
Printing out the texture coordinates, I do see all three sets of texture coordinates that the model is expected to have.
Interestingly, this does seem to work.
I do have to rename the texture coordinates (which I did via a quick find-and-replace in the egg file): Blender’s automatic naming system adds a full-stop and a number to uv-sets after the first (i.e. “UVMap”, “UVMap.001”, “UVMap.002”, etc.), which produces invalid variable names in GLSL, it seems.
(I did try switching back to the “p3d_MultiTexCoord” nomenclature after performing the find-and-replace, thinking that perhaps the names had been the problem, but it doesn’t seem to have helped there.
I’m guessing that there’s some association that Panda is expecting between textures/materials and UV-maps that I’m not setting. Since I’m not using these extra UV-maps for actual UV-mapping, I don’t intend to associate them with any material or texture. As a result–as long a there are no issues that I’m unaware of (such as this not working in 1.10)–I imagine that I’ll stick with careful naming and the “texcoord_yourname” nomenclature that you mentioned.
Actually, scratch the report of the “texcoord_yourname” approach working.
I had previously set my additional UV-maps to be zeroed, in order to easily distinguish them from the main UV-map, and so when I saw the geometry rendered as black I thought that it was working. (I’m colouring the geometry from the UV-map in order to test whether I’m getting the expected data.) However, a subsequent test with non-zeroed data also produced black geometry.
The shader itself seems to be working, as a dissolve in the fragment shader is still taking effect.
However,
In case I’m doing this incorrectly, these are the names that I have:
In Blender, the first, main UV-map uses the default name of “UVMap”. The two additional maps are named “uv1” and “uv2”.
When printing out my list of UV-maps in Panda (via “NodePath.findAllTexcoords()”), I get the following list: “texcoord”, “texcoord.uv1”, and “texcoord.uv2”.
In my vertex shader, I have the following:
in vec2 p3d_MultiTexCoord0;
in vec2 texcoord_uv1;
in vec2 texcoord_uv2;
A quick test with replacing the first line above to “in vec2 texcoord;” seems to indicate that the first UV-map still works when accessed that way, and that doing so doesn’t seem to affect the results of attempting to access the other two sets.
bump Am I doing something wrong in how I name, export, or access those uv-maps? Am I supposed to add a new (dummy) material for each, or search the scene-graph for objects that have multiple maps and manually add texture stages to them? Is this perhaps another bug in 1.9?
Ah, you’re using blender? In the material panel where you assign the second texture, did you select the correct UV coordinate set? Yabee should export the right texcoord name as in the section.
The thing is, I’m not using them to store actual UVs, but rather per-vertex data–I’ve run out of vertex-colour channels, and as far as I see we get only one set of vertex colours in Panda, but multiple sets of UVs. Hence I hadn’t associated them with any material or texture at all.
(I even modified YABEE to export the red channel of a second vertex-colour layer as the alpha channel of the vertex colour in the egg file, since Panda supports an alpha channel in vertex colours but Blender seems to not do so.)
So, do I take it then that dummy textures are called for?
(Note that the coordinate sets are being exported by YABEE; they’re just not being used by Panda, it seems.)
[edit] Or might I perhaps look for a way to detect multiple uv-sets and add the additional sets via custom shader-inputs?
It might be easier to modify YABEE to instead export the extra vertex color layer as an " myname { x y z w }" element under each vertex, which would be accessible in a GLSL shader as “in vec4 myname;”
Ah, that’s a much better idea, I do think! I even have some support for parsing custom shader-inputs saved as tags on their nodes, which should allow me to instruct the game to apply the input. Thank you for the suggestion!
[edit] Silly me; I misunderstood: the aux-colours are automatically provided to the shader. Even better!
Yes, data in vertices automatically gets created as a vertex column with the given name, which is accessible in your shader without requiring any Python binding code.
I’ve made the relevant modifications to YABEE (they’re fairly straightforward, I believe), and he system seems to work quite well. Thank you again for your help!
), and I seem to be having trouble: as far as I see, accessing any set of coordinates after the first (i.e. p3d_MultiTexCoord0) gives only the data in that first.
