Two Textures On Single-Part Model

[AGP]

Is there a way for me to assign two diffuse texture maps to a single-part model, much like 3ds max can do for object ids (say, a texture map just for the head, another one for the body)? I have some critical models that need this.

[EgonOlsen]

Either export them as separate models or as one model that uses two textures. You then have to let the loader to the assignment by adding the textures with the proper namens before loading the mesh. You can't do it with setTexture, as you will have noticed.

[AGP]

I can't export as separate parts because it's a rigged model. I don't understand your second suggestion.

[EgonOlsen]

The loader assign texture to the mesh at load time. You don't have to use setTexture() for this. Their names in the TextureManager just have to match the names in the file. Like described here: http://www.jpct.net/wiki/index.php/Loading_models

[AGP]

I have the exact same names, added to the TextureManager before the model, and my model is still being loaded texture-lessly.

[AGP]

I should mention that I'm using the software renderer in this case.

[EgonOlsen]

The renderer doesn't matter. If it doesn't assign the textures at load time, the names are not correct. Have a look at the log output, it should print out the names.

[AGP]

This is the log. No complaints about the texture:

Java version is: 1.7.0_25
-> support for BufferedImage
Version helper for 1.5+ initialized!
-> using BufferedImage
Software renderer (OpenGL mode) initialized
Software renderer disposed
Software renderer (OpenGL mode) initialized
Loading Texture...QG1_body_Difuse.png
Software renderer disposed
Loading Texture...QG1_head-Difuse.png
Loading Texture...QG1_Weapons-difuse.png
Wrapping input stream in a BufferedInputStream
Is animatedGroup null? false
Adding Lightsource: 0
New WorldProcessor created using 1 thread(s) and granularity of 1!
Creating new world processor buffer for thread Thread-2

[EgonOlsen]

That's just the loading of the textures, not of the model. At least not using jPCT's loaders. If this is a Bones object, then i can't comment on that. What i said about this topic applies to jPCT's Loader class only.

[AGP]

Arrrgh. I will repost it on the Bones board, then.

[AGP]

It turns out that although the head and body are merged in Max, Bones is getting them as separate objects. The problem should be done with, except for the fact that the texture coordinates are broken. The original textures are 2048x2048 in size. But at that size, after calling setTexture on both the head and the body, all I get is black (clearly because only the black part of the texture is being textured on the model). When I edit the textures to rescale them to 1024x1024, I get some of the non-black texture parts (albeit the wrong parts in the wrong places). The following textures are producing the following model:

[EgonOlsen]

Just like raft mentioned in the other thread, a call to recreateTextureCoords() after assigning the new texture should actually help, given that the coordinates are correct. This is needed for the software renderer only, btw. The hardware ones don't need this call (it doesn't hurt though).

[AGP]

But just like I mentioned there, I tried that and nothing changed. Besides, I'm not scaling the textures at runtime. I edited the files. And I'd rather not HAVE to edit them, but when unedited I only get black.

Your given isn't a given at all: the coordinates are not correct.

[EgonOlsen]

"given that" means that it's a precondition. If the coordinates in the file are bogus already, no call to any method will be able to fix that.

[EgonOlsen]

And I'd rather not HAVE to edit them, but when unedited I only get black.

Texture coordinates are normalized. It actually doesn't matter if you are using a 4*4 or a 4096*4096 texture, the coordinates will be the same for each. That doesn't fully apply to the software renderer, because it doesn't work with normalized coordinates internally. Instead, it creates an additional data set with coordinates that match the texture size. It does that at load time (with the assumption that the texture will be 256*256 because it doesn't know any better), at build()-time (with the dimensions of the texture currently assigned) and if you call recreateTextureCoords() (also with the texture currently assigned).
You might want to use a PolygonManager to print out the actual texture coordinates (the normalized ones...) to see how they look. Also make sure that clamping has been disabled (Texture.setClamping(true)) Edit: (Texture.setClamping(false)).

If nothing else helps: Have you tried to render it with the hardware renderer instead? The software renderer has a limitation regarding repeating textures, which might apply to models with texture coordinates far outside of the [0..1] interval.