[OPTing] XWA OPT Editor

[sedenion]

Hi Jeremy, I have question about indexed color textures. I noticed that OPT editor always recompute color palette even if the imported image is PNG in indexed color. Also, it seem the palette is the same for all images, while we can got a much better result with specific palette per image. So, is this an XWA engine limitation, does XWA use a fixed 256 color palette ?

[JeremyaFr]

Hello,
OPTs in vanilla XWA were limited to 256 colors. With the hooks you can use 32-bit images.

[sedenion]

OPTs in vanilla XWA were limited to 256 colors. With the hooks you can use 32-bit images.

I know, my question is about the 256 colors palette, more precisely the colors in this 256 slot palette. For example, when you save a PNG file, you can save it with a custom palette of 256 colors adapted to the image, so the colors still match pretty well for this image. This allow to keep good visual quality for less bytes. But in the OPT editor, it seem 1) the palette is always recomputed (even if the imported image is already indexed 256 colors), and 2) the color palette seem to be the same whathever the image, which induce much quality loss. My questions are : is there a reason the color palette is always the same ? Why recomputing indexed colors while imported image is already 256 indexed color ?

[JeremyaFr]

The editor recomputes the palette because it generates the mipmaps when importing an image.
But the palette should not be the same for each texture. The palettes are attached to textures so each texture has its own palette.

[sedenion]

The editor recomputes the palette because it generates the mipmaps when importing an image.
But the palette should not be the same for each texture. The palettes are attached to textures so each texture has its own palette.

Ok, what I noticed is that once converted in indexed color, we always find the same colors, like if there is somewhere a fixed palette. Let's take a practical example:

I saw that for cockpit canopy glass textures, which are mainely made of few dark gray colors. The RGB version of the image contain less than 256 colors, which mean that we could theoretically build a less than 256 colors palette with exact correspondance of RBG colors (that is what Photoshop does if we save image as indexed color). However, in the OPT editor, when image is converted (again) to 8bpp, the few grays colors are denatured into alternatively greenish and magenta gray, and always the same colors. This lead me the idead there is somewhere a "fixed" palette.

At this stage, if there is no technical reasons for keeping these "fixed colors", I guess this comes from the color quantization algorithm (and I don't blame, I know color quantization is a very complexe thing).

[JeremyaFr]

Hello,
Can you retry with this version?

EDIT: link removed

[sedenion]

Same problem.

See images bellow. The first is the original image as saved by photoshop in PNG format indexed colors (around 220 colors), the second is the image "converted" by OTP editor.

quant_test_in.png

quant_test_out.png

This is especially visible in such case, but in a general manner, the photoshop quantizer is more accurate and produce better result.

[JeremyaFr]

In the OPTs, the colors in indexed palette are rgb565.
When importing indexed image, if each color is rgb888 then there can be a quality lost when converting rgb888 to rgb265.

[sedenion]

In the OPTs, the colors in indexed palette are rgb565.
When importing indexed image, if each color is rgb888 then there can be a quality lost when converting rgb888 to rgb265.

Okay, that is the "fixed pallet", 16 bits colors... everything makes sense now.

[JeremyaFr]

UPDATE

Hello,
I've updated XwaOptEditor.

Changes are:
- when importing a texture, generate mipmaps only for 32-bpp images
- in the viewers, add settings to control the intensity of the lights

[JeremyaFr]

UPDATE

Hello,
I've updated XwaOptEditor.

Changes are:
- add a button to scale selected meshes

[JeremyaFr]

UPDATE

Hello,
I've updated XwaOptEditor.

Changes are:
- add a setting to add or not add the opt name to the exported textures filenames

[JeremyaFr]

UPDATE

Hello,
I've updated XwaOptEditor.

Changes are:
- add support for default skins in hangar map editor

[JeremyaFr]

UPDATE

Hello,
I've updated XwaSFoilsEditor.

Changes are:
- add checkboxes to show/hide meshes

[m0rgg]

Hello @JeremyaFr ,

I'm trying to understand and optimize the workflow to import/export models OPT -> OBJ -> Blender -> OBJ -> OPT

The Replace with OBJ feature seems to work fine to keep the hardpoints and other properties. With this, in theory, it should be very easy to export to Blender, make some fixes in geometry and textures, and re-import to XwaOptEditor, adjusting hardpoints, glows, Sfoils... only if necessary.

However, discussing with @Ace Antilles and @blue_max, the fact that the materials and texture files get prefixed with the OBJ filename make it cumbersome to re-import.

I noticed it is possible to disable the "Add prefix to textures" feature in XwaOptEditor, but it seems it only removes the prefix from the image filenames and the material name in the .mtl file.

However, the usemtl lines in the OBJ are still trying to find the material with the prefix, which breaks the import in Blender (no textures assigned to the meshes by default), and also the re-impot using Replace in XwaOptEditor.
Is this possibly a bug?

Thanks!

[JeremyaFr]

However, the usemtl lines in the OBJ are still trying to find the material with the prefix, which breaks the import in Blender (no textures assigned to the meshes by default), and also the re-impot using Replace in XwaOptEditor.
Is this possibly a bug?

Yes, it is a bug.

[JeremyaFr]

UPDATE

Hello,
I've updated XwaOptEditor.

Changes are:
- fix a bug with material prefixes

[m0rgg]

Thanks @JeremyaFr !
As efficient as usual. I will test as soon as I can.

[m0rgg]

It works wonderfully, now it's possible to re-import from Blender without having to rename the textures.

However, I have found that the Replace feature does not work as I expected.
I exported to Blender, fixed some shading (normals), and then tried to replace in the OPT.
However, the normals does not seem to be taken into account when replacing, only when importing as a new mesh.
Is that expected?

Thanks!

[Bman]

Awesome. Yeah when I've exported from blender into .obj a lot of times I've had to import into my 3D modeling program and flip the normals on whole model. Then save before importing back into XwaOptEditor. Btw, I searched around the other day and I don't think it's possible to create an export plugin from blender to export to .opt format directly. Nobody really knows how the .opt file structure is laid out. All binary data. There is a generic scripting process for blender export plugins but over my head. Python I think.

[JeremyaFr]

UPDATE

Hello,
I've updated XwaOptEditor.

Changes are:
- added buttons to rotate the whole opt in XwaOptEditor