Sharing textures problem

Engines, Libraries and Tools Xith3D Forums
#1

According to the Java3d javadoc you’re allowed to share Texture2D objects among different Shape3Ds.
However I notice strange effects when I do this and load a shared texture in the following way:

BufferedImage bimg; // loaded in an own way
Texture2D texture = (Texture2D) TextureLoader.loadTexture(bimg, "RGBA", true, Texture.NICEST, Texture.NICEST, Texture.WRAP);

There’s the following problem then: when I zoom in one of those Shape3ds sharing this texture, the textured surfaces of the Shape3d become white.

Is it maybe a problem that I use the TextureLoader.loadTexture method with an BufferedImage instead of a file name?
Do I have to use a seperate BufferedImage with this call for each Shape3d wanting to use the same texture file?

#2

I intensively use texture sharing, both mip-mapped and non-mip-mapped, and it works fine for me.

Can you please create small test caseso we can test? [and file an issue with the test case as an attachment]

Thanks for testing,
Yuri

#3

Hi
I share them too, take a look at my ac3d loader, even has a texture resource pool to cache them all :slight_smile:

I know it’s a ‘works for me’ type answer, but it points to something in your code or a change in xith. Like Yuri says, a small test case would be good.

Cheers

Endolf

#4

Hi,

That’s definitely nothing to do with MipMaps, but something wrond happens with texture sharing - you are right. I don’t know yet if this is in your code or somewhere in Xith3D, but we definitely should check this.

With your test, the sphere looses texture ONLY in the case when the bigger shape (opaque one) is visible, i.e. not culled.

Try to do the following: open the app, click on the big square shape, and using a,s,d,w keys move it off the visible area - you will see that texture on the sphere will appear.

Looks like this shape is rendered before the sphere, and causes wrong behavior of TexCoordGeneration [somehow?]. Note that transparent shape always rendering after the sphere and does not cause such problem.

So, as a bottom line, if it would be a bug report in IssueZilla, I would mark this issue as confirmed :slight_smile:

What can I say - we definitely need to put this test in a simple test case, say, based on the test code from com.xith3d.test…

Yuri