How to get proper skins from QME 3.1

[gnounc]

For some reason QME 3.1 does not save skins correctly.
Maybe its just my setup, but in case its not I thought I would
post what FINALLY worked for me.

export the skin from qme 3.1

then use sajt's qwalk to convert the mdl to mdl
and point the -tex argument to your exported skin

I have a bat file that says

modelconv.exe -i armor.mdl armor2.mdl -tex bomb.jpg

for instance.

uuuurgh, upon further inspection, they still dont show up nicely in directq but they look fine in darkplaces.

[Sajt]

Your skin width is probably not a multiple of 4. If I remember correctly QWalk takes care of that though, by padding the texture and the texcoords...

However, importing MDL then exporting MDL in QWalk is bad, because it will duplicate some vertices and possibly the vertices will drift a bit or be requantized badly (it's not designed for MDL's old-fashioned way of storing triangles). I don't know why it would not show up properly though, whatever that means. Maybe you could post your model?

I could make a tiny tool called "FixMDL", if you want, which would fix these sort of problems in MDLs without any kind of recompression. It would only take a few hours, probably.

You can also fix it in QME by changing the skinwidth to a multiple of 4, then manually fixing the skin to line up again with the re-fudged texture coordinates...

[ceriux]

you should make a tool which fixes the .mdl problems when making/editing a model using qme 3.1

[gnounc]

http://dl.dropbox.com/u/1776436/bomb.mdl

thats my model.

I'll look into texture sizes.

But definately, if you can write a program to fix qme problems, I'd
be very grateful.

[Sajt]

I don't know why the models that have been run through QWalk show up funny in old engines. I assume you are talking about the funny lighting where it looks like there is a black stair-step pattern across the bomb?

I've been working on a program to fix various MDL problems, along with a few other features like the flat-shading thing Urre wanted. It's a Windows GUI program, unlike QWalk.

Could you upload the original model, the one with the messed up skin? I'll be able to upload the first version of my MDL-fixing program once I test this. The program should be able to fix both messed-up versions of your model.

[gnounc]

http://dl.dropbox.com/u/1776436/nofix.mdl

There ya go. That shows up fine in QME 3.1 but not in game, or in
your viewer.

After using qwalk, it shows up fine in the viewer and darkplaces, but not DirectQ.

Thanks again.

[Sajt]

Man, the way QME stores non-multiple-of-4-width textures is incomprehensible. The QWalk step worked because you were reimporting the skin from an external image. I'm trying to figure out how to salvage what QME pukes into the model in these cases...

edit: I did finally figure it out. You may notice a black horizontal stripe that QME "inserts" into the top right of your skin if your skin's width isn't a multiple of 4. Mr. Rene Post when he did this was clearly smoking some unsavoury hashish in the slums of Amsterdam. "Decoding" these skins involved flipping the image upside down, then "unshearing" it by ignoring certain inexplicable black pixels (or relocating them to the end), then flipping the image again.

Unfortunately, further complications seem to have arisen in the texture coordinates for these models. I highly recommend sticking to a texture width multiple of 4 from the very start... even though that isn't possible when generating the skinmap using QME.

[Sajt]

http://www.icculus.org/qshed/fixmdl/Fix ... -ALPHA.zip

Give this a shot, use it on your OLD model with the messed-up skin. I haven't yet implemented the fix for the model you ran through QWalk.

[gnounc]

Thanks a bunch. Model displays properly now.

Planning on unifying these tools into 1 Gui eventually?

[Sajt]

Maybe, but I'd prefer not to use the Win32 API. I would rather it be an OpenGL application with hand-written GUI components. Unfortunately, all the code I've written to do that sort of thing (as well as improved file handling, image loading, etc.) is not currently GPL. So for now I doubt there will be new versions of QWalk, unless somebody asks. There's no way I'm recoding all that stuff for the tenth time in my life (nine is enough!), so we'll just have to wait until I can decide to make all my personal work GPL... Or, I suppose, I could make a closed-source follow-up to QWalk, but people probably wouldn't like that.

[frag.machine]

I'd suggest you to pack everything in a lib and release it under the LGPL. So somebody else can try to make a GUI for that.

[gnounc]

Thats too bad, it would be great to be able to convert a model, fix any misalignments and instantly view them all in the same window.

[mh]

I'm gonna download this model and test it a little later on. I'm guessing that what's happening here is that DP has some special case code for loading non-standard MDLs which may be why it works OK there. If I was a betting man I'd be pointing my finger at skin floodfilling as being the particular thing in the engine to blame.

[mh]

I'm gonna download this model and test it a little later on. I'm guessing that what's happening here is that DP has some special case code for loading non-standard MDLs which may be why it works OK there. If I was a betting man I'd be pointing my finger at skin floodfilling as being the particular thing in the engine to blame.

Good thing I'm not a betting man!

Here's what I get when I dump the skin from DirectQ:



This is just raw data as it comes directly from the MDL before my own code (or ID's for that matter) has it's evil way with it, so it definitely seems to be a case of QME weirdness.

I wonder does it also mangle the texcoords to make it work (for certain definitions of "work")?

Neither width (306) nor height (43) are a multiple of 4, which will actually cause a Sys_Error if you try to use it in regular GLQuake.

Man, the way QME stores non-multiple-of-4-width textures is incomprehensible. The QWalk step worked because you were reimporting the skin from an external image. I'm trying to figure out how to salvage what QME pukes into the model in these cases...

edit: I did finally figure it out. You may notice a black horizontal stripe that QME "inserts" into the top right of your skin if your skin's width isn't a multiple of 4. Mr. Rene Post when he did this was clearly smoking some unsavoury hashish in the slums of Amsterdam. "Decoding" these skins involved flipping the image upside down, then "unshearing" it by ignoring certain inexplicable black pixels (or relocating them to the end), then flipping the image again.

Unfortunately, further complications seem to have arisen in the texture coordinates for these models. I highly recommend sticking to a texture width multiple of 4 from the very start... even though that isn't possible when generating the skinmap using QME.

If I was a betting man... (which we've established I'm not! ) I'd say he came up against the occasional upside-down BMP (BMPs allow that, like TGAs) and hacked in something ugly to handle them.

[Sajt]

Probably. Anyway, I don't think that model works in even DarkPlaces. I did manage to figure out how to decode the skin. If you want the code I could post it. In any case, the code for FixMDL will go up on the QShed SVN one of these days.

The model that I thought you were going to look at was not nofix.mdl, but bomb.mdl. This model was run through QWalk, which resulted in some duplication of vertices (since QWalk doesn't support the old facesfront/onseam Quake texcoord system). I think QWalk must have recalculated the normals after that, which results in hard lighting seams along where the vertices were duplicated. But it looked fine in DarkPlaces for some reason.