Helping with Textures

JohnnyWalker2001 · Post by **JohnnyWalker2001** » Wed Mar 12, 2014 12:06 am

theraineydaze wrote:I figured it out!

http://i.imgur.com/0Ybbel0.jpg

It's really odd. Everything that you want to show up as black should be #010101 and it looks 100% black. But everything that you want transparent should be #000000. So with Glottis mouth I have a thin circle of 010101 with a center of 000000 so you see his black edges filled with clear.

Edit: So theoretically when you index these and apply the ACT they should work. I'm not sure where the CMP was so I couldn't test it.

https://www.dropbox.com/s/yzrdr6wr1g2jd ... 20hole.bmp

https://www.dropbox.com/s/6cz2d09txzo1l65/card.bmp

Woo!!! Fantastic stuff! Wow, what a weird system the game uses. (I wonder if 000000 gets assigned to the earliest value, to Color #1, and 010101 gets assigned to that nearest value - Color #x.) Great job!

Nitrus · Post by **Nitrus** » Wed Mar 12, 2014 9:23 am

Actually, some *.MATs have transparency and some don't. In the GrimReaper Deluxe version you can see I've added a flag for "Has Alpha" in the right panel. So, if the *.MAT has the flag, one of the palette colors should act as the transparent color.
I think it's always the first or second slot (I use the word 'slot' for lack of a better word, please bear with me). I'm not sure if ResidualVM handles that flag, though I think it does.

So for example, if it really ALWAYS is the first or second slot, we can add new colors to palettes.

For example, in cafe.cmp the first 8 colors are #000000. If the transparent slot is always the first or second one for all the images, we can add colors we'd like in the rest of the 6 slots.

Hypothetically, this should happen:
Engine reads MAT, sees transparency flag, checks for what color is in the first/second slot of the palette, and then makes all the image parts painted with that color transparent.
(There is no way of differentiating if you had painted with the color from the n-th slot, so having same colors as the transparent color in the other slots is useless)

Now on the other hand, in the palettes I've taken a quick look so far (cafe and glottis), either the first 8 slots are always #000000, or the second one is the bright pink #ff00ff, and the remaining 7 are #000000.
Four possibilities remain:
- One of the first two slots are always used for transparency (possibly always the second one)
- Different *.MATs use different slots for transparency, one of the first 8 slots
- Some of those slots are #000000 without a good reason
- Maybe there is a flag in the *.MAT somewhere, which specifies which slot number holds the transparent color.

I should like to investigate, though I'm not sure when I'll have the time. Maybe guicam or somaen already know the answer to this?

P.S.: In truth, it's been a couple of months since I wrote the code, I can't remember if the transparency flag was for the whole *.MAT or whether each image in the *.MAT had it's own transparency flag.

EDIT: As for the cards, out of inventory.cos:

...
# ID TagID Hash ParentID Name
...
43 4 0 15 card.3do
...
55 3 1 43 item.cmp
56 5 0 43 card.mat
...

So since both item.cmp and card.mat share the same parent, I _think_ card.mat uses the item.cmp palette.
SECOND EDIT: Only other place that references card.mat is ms.cos, and it too holds the same values.
Tip: I don't like how Windows searches through file content btw, so I use a little software called grepWin for searching through them.

JohnnyWalker2001 · Post by **JohnnyWalker2001** » Wed Mar 12, 2014 6:06 pm

Nitrus wrote:(There is no way of differentiating if you had painted with the color from the n-th slot, so having same colors as the transparent color in the other slots is useless)

No, this is wrong, as you illustrate below. Each pixel in the image has a palette "slot" number (I'm sure there's a better word than "slot", but I can't think of what it might be). That's why the palette files exist -- there is no colour information in the .mat files, as I'm sure you know!

Nitrus wrote:Now on the other hand, in the palettes I've taken a quick look so far (cafe and glottis), either the first 8 slots are always #000000, or the second one is the bright pink #ff00ff, and the remaining 7 are #000000.
Four possibilities remain:
- One of the first two slots are always used for transparency (possibly always the second one)
- Different *.MATs use different slots for transparency, one of the first 8 slots
- Some of those slots are #000000 without a good reason
- Maybe there is a flag in the *.MAT somewhere, which specifies which slot number holds the transparent color.

I would guess that the several black spaces are reserved for use by commonly appearing items. (I bet they're not always black in every .cmp.)

Nitrus wrote:I _think_ card.mat uses the item.cmp palette.

You are correct! I couldn't remember the cmp's name, but that's definitely it.

Yep, I have grepWin installed somewhere. Extremely handy and reliable!

Nitrus · Post by **Nitrus** » Thu Mar 13, 2014 8:20 am

JohnnyWalker2001 wrote:No, this is wrong, as you illustrate below. Each pixel in the image has a palette "slot" number (I'm sure there's a better word than "slot", but I can't think of what it might be). That's why the palette files exist -- there is no colour information in the .mat files, as I'm sure you know!

Yes of course, you're right, though I was talking about the process of painting in Photoshop, should have made myself clearer. When you choose a color to paint with, it just finds a color which is most similar from the palette, and then just paints with that. It doesn't care which slot number the color is. If you've got two colors with the same value, it's able to use just one of them (probably the one with the lower index number), which makes the other one obsolete.
Indexed image formats such as Indexed PNG, BMP, or TGA all use a number of the palette to depict a pixel. This means that pixel will use color from the palette number it's depicted with.

JohnnyWalker2001 wrote:Unfortunately we're apparently being hamstrung by modern editing software losing capabilities which aren't used very often any more -- or which may seem undesirable today.

That's exactly what happens here, it's Photoshop's own attempt at optimising.

So, it depends which way we want to go I guess.

We can let Photoshop reassign all of the same color to one slot, or do a bit of HEX editing ourselves.

E.G. We take the card.mat for example, each byte after the header with a hexadecimal value of 0x00, will use the first color of the palette (zero based), each byte with the value of 0xFF will use the 256th color, the last one in the palette (also zero based, otherwise 0xFF is 255). So, we could manually select these and assign them different palette numbers. This would be tedious.

I guess I could write a separate piece of software which would let us load an image from the MAT, select pixels from it with E.G. something like the lasso selector, and then tell it which slot to use.

Or just find either a Photoshop plugin that does this, or a better suited alternative than Photoshop (if we can't achieve this within PS), which I think would be the least complicated solution

EDIT: I also saw that the earliest color used in card.mat is the one with the number 0x08, which is the 9th color from the palette. The previous ones (except for 0x00, which is used in transparent parts) are not used here. Perhaps they're used in one of the other mats.

JohnnyWalker2001 · Post by **JohnnyWalker2001** » Thu Mar 13, 2014 10:08 pm

Ah, sorry I misunderstood you.

I tried GIMP, and it does handle palettes a little differently from Photoshop -- but maybe not quite in the way we need. For a start, it reordered the palette and stripped out any duplicate colours. *sob*

I'm tempted to try and install a version of Paintshop Pro from 2000 on my Windows XP VM.

At least RaineyDaze has found a decent work around for now.

JohnnyWalker2001 · Post by **JohnnyWalker2001** » Thu Mar 13, 2014 11:55 pm

I tried putting the card in the game... and RaineyDaze's trick worked great! The transparency was as hoped.

Unfortunately:

Still need to x4 the 3do file. Doh!

The finished mat is here:
https://dl.dropboxusercontent.com/u/30449117/card.mat

theraineydaze · Post by **theraineydaze** » Fri Mar 14, 2014 12:16 am

Haha! It's still progress!

ezekiel000 · Post by **ezekiel000** » Fri Mar 14, 2014 12:25 am

JohnnyWalker2001 wrote:I tried GIMP, and it does handle palettes a little differently from Photoshop -- but maybe not quite in the way we need. For a start, it reordered the palette and stripped out any duplicate colours. *sob*

I'm not sure why it would reorder the palette but you can edit the palette however you need; add/remove slots, rearrange the order etc.

Nitrus · Post by **Nitrus** » Fri Mar 14, 2014 6:47 pm

JohnnyWalker2001 wrote:I'm tempted to try and install a version of Paintshop Pro from 2000 on my Windows XP VM.

Hahah, if you do, let me know how it goes

I'll take a look at resizing the card UVs this weekend (if someone else hasn't done them in the meantime), tell me if anything else need resizing.

JohnnyWalker2001 · Post by **JohnnyWalker2001** » Fri Mar 14, 2014 7:12 pm

I believe it was somaen who wrote a simple command line tool that that converted all the UVs -- but I'm not sure if he ever got the bugs out.

It would be useful to have something that x4 the UVs of a given 3do. Sometimes a new model isn't required.

Nitrus · Post by **Nitrus** » Sat Mar 15, 2014 2:03 pm

Really? I'm not familiar with it, I do it via 3D software and scripting inside...

JohnnyWalker2001 · Post by **JohnnyWalker2001** » Mon Mar 17, 2014 11:36 am

Nitrus wrote:Really? I'm not familiar with it, I do it via 3D software and scripting inside...

I believe this is it:
https://dl.dropboxusercontent.com/u/304 ... opatch.exe

Once 3do files have been converted to OBJ format, they're essentially human readable text files, right? So maybe that's part of it. I wish I could remember, it's been so long.

I guess it's not especially useful if you're building a new model/tweaking the old one, but if you want to try out new textures on existing models, it's very helpful.