Bug in .OBJ format with Colors (v1.15)

[sbaltes]

Hi, I've a problem loading the following .OBJ file:

http://88.198.204.8:8080/IsoDemo/MAnn1.obj
http://88.198.204.8:8080/IsoDemo/MAnn1.mtl

In this .mtl there is only color information, no texture image. The colors doesn't look right: It should be a blue jacket, but in JPCT it looks a little bit different (more like a teenage rap star, the jacket is white / blue / golden). This is the first time I load a .OBJ from Poser with plain color textures. I can import this file in Milkshape with correct colors so I think it's a JPCT Bug (or a Bug in the .OBJ format that JPCT has no workaround for ;-)

Best Regards
Sebastian

[EgonOlsen]

It's a bug in jPCT's loader. Or to put it in other words: The OBJ-format stinks so much IMHO, that it makes me feel sick. Why on earth can everything be located everywhere in the file? There seems to be no rule for that except that there is none...anyway, i'll fix this.

[EgonOlsen]

Ok, please try this: http://www.jpct.net/download/beta/jpctapi116pre3.zip

[sbaltes]

It works, thank you very much for this super fast reply 

I'm sorry that we have to use this strange format, but after all it's working best with poser. Ok, poser itself could be considered a bug ;-)

[sbaltes]

Just one more question, a missing feature: Poser seems to use a .tiff and additional color information for it's textures. The texture is overlaid with some color. JPCT seems to ignore the color information if a bitmap is present. An example from the .mtl-file:

newmtl jacket
Ns 30
Ka 0 0 0
Kd 0.317647 0.317647 0.317647
Ks 0.00784314 0.00784314 0.00784314
map_Kd Biz Man Texture.tif

Would it be a problem to add support for this in JPCT?

[EgonOlsen]

I'm sorry, but that's not possible. jPCT uses textures if available. If there are none, the diffuse color will be used. There's no way to combine both, because that would require the definition of additional vertex colors per polygon and that isn't supported.

[sbaltes]

That sounds difficult... so I've implemented a workaround: I parse the .mtl file myself and add the color for each image with the following code:

Code Select Expand


    BufferedImage result = new BufferedImage(image.getWidth(), image.getHeight(), BufferedImage.TYPE_INT_RGB);
    int cr = color.getRed();
    int cg = color.getGreen();
    int cb = color.getBlue();
    for (int y = 0; y < image.getHeight(); ++y) {
      for (int x = 0; x < image.getWidth(); ++x) {
        int v = image.getRGB(x, y);
        int r = (v >> 16) & 0xFF;
        int g = (v >> 8) & 0xFF;
        int b = (v >> 0) & 0xFF;
        r = r * cr / 255;
        g = g * cg / 255;
        b = b * cb / 255;
        v = ((255 & 0xFF) << 24) | ((r & 0xFF) << 16) | ((g & 0xFF) << 8) | ((b & 0xFF) << 0);
        result.setRGB(x, y, v);
      }
    }


Then I add the image under the name of the mtl-material to the TextureManager, and I create my own transient .mtl file where each texture has the name of the mtl-material and give that to the Loader.

The result looks the same like in poser.

But I think there is a little bug in Loader.createOBJObject, at the moment it is:

Code Select Expand


tid = tm.getTextureID("mtlName");


if it were

Code Select Expand


tid = tm.getTextureID(mtlName);


then I wouldn't need to create a transient .mtl file.

[EgonOlsen]

But I think there is a little bug in Loader.createOBJObject....

Yes, it is...what a stupid mistake. I've updated the zip-file with a fixed version. The problem never surfaced, because that code is never used for regular models.