[Solved] UV texturing and priorities


I modelled a cube in Blender (just for testing) and UV mapped it. The resulting model loads perfectly into panda. Then i took the UV mapped texture modified it and saved it as tga file, which again loads perfectly with pview alone.
As I try to override the texture with


the model turns red (don’t ask me why it turns red, the material set ‘under’ the texture is light grey) and doesn’t display any texture on it. If I try


the red and the texture get combined which looks something awkward. Reading the manual I didn’t find anything that UV mapping is priority related (is it?)

I also tried to remove the texture reference from the egg file (by simply removing all references but leaving the uv coordinates in it) and the model again turns red.

So the question is, how to load a texture so it’s uv mapped? Or did I oversee sth?

if your egg is correct the uvmap aswell as the texture will be loaded automatically. can you paste the egg’s content so we can see whats wrong?

Hm, I think I made my problem not clear enough:
The texture specified in blender is loaded perfectly. All I try is to replace this texture dynamically at runtime, and get the results mentioned above.

I put together a tiny script with the model and the two textures showing how I tried.


wow… thats definetly intresting. it looks like the red cube of shader-death.
thought it works great with other models, and loading another texture inside the egg works fine,too. i see no reason why it should show up the way it does. really strange. need to investigate this after math classes, cya later

The egg file is specifying custom named UV coordinates:

<Texture> cube_1_Cube.tga {
  <Scalar> uv-name { UVTex }
  <Scalar> envtype { modulate }

This means that the egg loader cannot use the default TextureStage to apply this texture; it instead creates a custom TextureStage that references the named UV coordinates.

This, in turn, means that when you apply a new texture in code, using the default TextureStage, you are not replacing the existing texture, but are instead adding to it (since you are applying a second TextureStage to the geometry).

It also means that, because the default TextureStage references the default texture coordinates (which do not exist on your model), then when you apply a new texture, it will not find any texture coordinates on the model. This gives undefined results, but in your case what’s happening is that a red pixel on your texture is getting stretched over the whole model.

So there are two easy solutions. The easiest would be to change your model to use the default texture coordinates instead of a custom name. Presumably this can be done somehow in Blender; I don’t know what convention the Blender-to-egg converter uses to determine the intended texture coordinate name.

The second solution, if you can’t fix the model, is to use the same TextureStage for your new texture:

ts = cube.findTextureStage('*')
blah.getParent().setTexture(ts, tex,1)


Thanks for that explaination and for looking into my problem!
Both solutions are working perfectly, thanks for working this out!

If I remove any reference to the UVTex uv-name in the file it also works perfectly.

I’m a little curious why this problem didn’t happen before? Because the chicken exporter doesn’t seem to have any means of defining a default texture:

(line 818)

		if self.uvname:
			ln.append('  <Scalar> uv-name { %s }'%self.uvname)


(line 1096)

			for name, uv in self.uv:
				ln.append('%s<UV> %s { %f %f }'%(padding2, name, uv[0], uv[1]))

And I didn’t find any references to UVTex which is the default Blender name for uv textures. Is there an more recent version out as which one can download from the sourceforge site?

Anyway I will mark the topic as solved, since my initial questions have been answered.