Texture conflict?!?

Pipeline
1

Recently I got an issue when dealing with multiple models referring to the same texture.
Said models are different (e.g.: spear.egg and Spear1.egg yes, my naming is silly), but each uses as texture spear.png.

During the game I load Spear1.egg at the very beginning, and after some time i load spear.egg: well, at that moment both show no texture, as they had vertex color=white.

So i tried copying the texture file: i created spear.png and spear1.png, and assigned the first to spear.egg, and the second to Spear1.egg.
That solved the problem!

I guess it comes from the behaviour of TexturePool, anyway is there a less expensive way (I don’t want to have tons of the same texture!) to workaround?

2

There should be no problems with different egg files sharing the same texture filename. Indeed, the whole reason the TexturePool exists is to unify these references, so that the texture image only gets loaded once, and both egg files share a reference to the same Texture object.

Problems can arise, however, if your two different egg files attempt to load the texture in different modes. In particular, if the first one does not specify mipmapping, for instance, but the second one does. In this case, when you load the first egg file, no mipmaps will be created for your texture; but when you load the second egg file, it will attempt to enable mipmapping on the already-created texture. Depending on your graphics driver, this may succeed, or it may simply fail, rendering the texture invalid. I suspect you have run into the latter case.

The solution is to ensure that all references to a given texture filename specify exactly the same texture properties. If you really do need to load an image with two different texture properties, then you really should have two different filenames.

David

3

You were right!
On one of the models I hadnt mipmap required, and the other did.
Now I made them load the same way, and it works.
Thank you!

4

A side note but can we make mip mapping default texture mode? The only reason i can think of not wanting mipmapping is software renderer. I think most cards even render mipmapping faster then nearest. Oh and if its such a global thing like software vs hardware render shouldn’t it be global not individual texture specific?

5

Well, the faster/slower thing is kind of moot. Mipmapping is often faster, of course; even with a software renderer; but depending on the nature of your scene and where the performance bottlenecks happen to lie, it can also be slower. The difference is almost always very subtle, though, so I wouldn’t ever adjust mipmapping on or off looking for major changes in performance.

On the other hand, mipmapping also costs an additional 33% texture memory, and complicates loading and reloading of textures; and it isn’t always a satisfactory visual result either. So I think it’s not always desirable.

I think the vast majority of egg files either explicitly request mipmapping on or off. It’s true, for the occasional egg file that doesn’t specify, Panda understands it to be off. I think that is probably the safest decision. If that bugs you, I’d suggest you should take it up with the converter program that generated your ambiguous egg file. :slight_smile:

David

6

Well I been using this code for a year now:

def loadTexture(textureName):    
    texture = loader._loadTexture(textureName)
    if texture :
        texture.setMagfilter(Texture.FTLinear)
        texture.setMinfilter(Texture.FTLinearMipmapLinear)
    return texture

loader._loadTexture = loader.loadTexture
loader.loadTexture = loadTexture

Most of the textures in my game are set with setShaderInput to work around texture bleeding problems when using standard texture stuff.

7

I recommend using egg-texture-cards to load up your textures via egg files, instead of calling loadTexture() directly. The advantage being that the egg file can precisely describe the set of desired properties, which the image file itself cannot do. Your workaround is appropriate only when all of your textures require mipmapping, which might be true in your case; but I think it is not true in general.

It is true, though, that egg-texture-cards by itself has no feature to specify the mipmapping state. This is an unfortunate omission, though easily corrected; we never noticed it before because we also use egg-palettize to post-process all of our egg files, including those generated by egg-texture-cards; and egg-palettize does include features to specify mipmapping, color mode, and all of those esoteric texture features that become so important.

David

8

Addendum: I’ve just added -minf and -maxf to the egg-texture-cards command, and tagged it for 1.6.1.

David

9

It’s good of you to add a needed feature, but what does all that mean? As in, what’s an egg-texture-card? What are -minf and -maxf?

10

Mipmapping on a particular texture is enabled by specifying a particular minfilter setting, as described in the manual. (A texture has both a minfilter and a magfilter setting, and the default for both is “linear”, which means no mipmapping.)

egg-texture-cards is a command-line program that generates a simple egg file that contains a reference to one or more textures. I’ve added the parameters -minf and -maxf to this program, to allow you to specify minfilter and magfilter for the textures you are wrapping. If you then load these textures by loading the egg file and doing model.findTexture() (or, even just load the egg file before you call loader.loadTexture()), then these texture settings will be applied to the texture in question automatically.

But, I’ve persuaded myself that I’m being a little too stubborn here. There’s no reason we shouldn’t have minfilter and magfilter optional parameters to the loader.loadTexture() call, so you can specify these parameters in code, for people who aren’t willing to use (or aren’t familiar with) the egg-texture-cards utility. Also, I can easily add a set of Config.prc variables to specify the desired default texture parameters, for people like treeform who just want to enable mipmapping globally and be done with it.

I’ll make these changes too, shortly.

David

11

OK, I’ve made these changes. Loader.loadTexture() now accepts an optional minfilter and magfilter parameter, and this has been tagged for 1.6.1. Furthermore, you can also just put:

texture-minfilter mipmap

in your Config.prc file, and all explicitly-loaded textures will default to mipmapping on unless you specify otherwise. I didn’t tag this new config setting for 1.6.1, though, since it seemed a little too extensive for a minor bugfix release. It’ll be picked up in the 1.7.x series.

David