You need to use the 8-bit, 256 colour palette that Quake uses. The tool ignores the colour values and just reads the palette index values directly(for good reasons I will explain below). This means that the palette you use has to be in exactly the same order as the original palette. You also need to avoid any options that try to reduce the palette when saving the file, e.g. an option which removes duplicate colours.

You might be surprised to learn that the Quake palette features duplicate colours, but it's too late to change that now. There is a red colour which appears once in the 2nd row, and once in the second to last row. The latter row is a fullbright (glow-in-the-dark) row, so there's a difference in game to using these two colours even though the RGB values match. This is why the tool reads palette indices instead - if you only read RBG values you have no way of telling if the pixel was intended to be fullbright. 

easy way, load up any random model in qme, import your file as a skin, then export as pcx. 

Hello Preach.

I am indeed using the quake 256 color palette. I've done this with many level textures in the past. And it has the correct color order as well which is why I am confused with why things are getting all messed up using the MD3toMDL compiler..

As for the duplicate colors I am also aware those are used for fullbright rendering FX like the fire and muzzle flash FX.

I wanted to try and use QME indeed to replace the texture but the program crashes with MDL's generated using the compiler. 

Yeah, how do you create the skin using QMe if you don't have a model yet? The answer, as necros said, is to use any old existing model, like shambler.mdl. Resize the existing skin in QME to the target skin size for your new model. Now import your new skin and export it to .pcx format.

If your models are crashing QME, check that you don't have skin UVs positioned outside the extents of the skin, and QME and software renderers don't like that. 

to understand why the colours get messed up requires understanding a bit about pcx.

pcx is a simple format where pixels are all stored in one long line as palette indices.

now, one option is to store the palette in the pcx, so the start of your image file has 256 * 3 bytes wasted on colour information.

save a pcx file from your image editor. now open it with windows preview. chances are, it looks fine.

now, open any model in QME and export the skin as pcx. now open that with windows preview. it will look black and white and the shading will be wrong. this is because QME exports pcx files without a palette. this type of pcx assumes your application will know what colour is what index.

ok, that's fine, so why does a pcx from your image editor with the proper 256 palette from quake still look wrong?

the problem is with the palette order. Your editor saves the image with the 256 palette so when you open with windows preview, it looks fine because, while the colours are not stored in the same order they are for quake, the image viewer will look at the palette and use the right colours anyway. but when preach's md3tomdl opens it, it doesn't care about the palette. it's only looking at the indices.

Now, preach could look in to dealing with that. doing comparisons on colour values and guessing the correct index in a pcx with a palette is pretty trivial. the only problem is where there are duplicate colours. there's no way for an algorithm to know that one red pixel is fullbright while the other is now. I think this is why he hasn't done that, because it would just lead to confusion. 

PCX info makes sense. I remember quake2 had similar issues with some textures looking truely odd back in the day but fine in engine. As for the model crashing QME... no UV's outside the UV space. I have some overlapping islands where parts share but that should not be an issue I think.

I've been reworking and finalizing a new proper revamp of the shambler model. That is what all this MDL messing about is for.

What version of QME are you guys using? It can only export and import bitmap files with the one I have... 

Ok got it working! and even figured how to remove fullbrights and such other lovely things similar to texmake for map textures. My MDL pipeline is pretty solid now sweet.

So yea here is a sneak peak then... :)

https://dl.dropboxusercontent.com/u/1849053/Shambler_Remake_2015_Alpha.jpg

So um is there much use to naming frames? Right now its just generic fromase01 and so forth... If there is a reason then I need to figure out the python tool from Preach with all those lovely rename options and so forth... 

Thanks for the help everyone and Preach for the tools making all this retro min maxing possible! 

Frame names are just for convenience and not used for anything! 

I would love a tutorial if you can ever get around to it. :) 

About what I figured out or something else folks are talking about in this thread? 

About making quake models 

I thought Preach manual on his site goes pretty well.

I am doing lots of modelling but if I was asked to make a tutorial it would be more about knowing engines like Blender and Max.

It is rally not that lot of work, in blender it's easy to import a model, giving it bones takes more care but certainly the joy of animating it.
Qmle can be a harsh editor, quiet old but effective to import the dxf models.

The greatest kick for me is to see the thing jumping in game! 

 

Double entendre all up in the body. 

http://image.noelshack.com/fichiers/2016/03/1453323519-wip-bfg9500.png
yeh yeh 

"FUCK THAT IS BRILLIAAAAAAANT!!!!!!!!!!!" 

It's taken from Q2's BFG, I added more polys to the cylinders and redoing the entire texture 

That BFG is nice but the skin looks a bit like plastic. 

After I'm done doing the bases, I plan on darkening it, put some noise, and apply the quake palette. This is the method I did for all my models. 

This model needs to be released. 

If all goes well I might release it on the weekend. At least a alpha version for folks to try out and comment while I clean up animation looks and refine the texture a bit. 

why has nobody - read: Tronyn and Ericw - done this in quake yet? 

That is my theory at least....

For the shambler I will be able to add a bunch of additional animations at the end btw... for maybe some new abilities like running and clawing at the same time? Or some new AOE lighting shockwave attack.. always thought the shambler could use some additional tricks on higher skill levels. Or variants! we have a zillion ogres in Arcade Dimension... now that I have this bases I would be up for making some extra Shambler variations. Zombie shamblers anyone? :) 

keep in mind, max number of frames in a model (for compatibility with most engines) is 255. i know how easy it can be adding in new animations. :)