adib it's interesting you're thinking of a revolver, because for the redoing of the shotgun I thought of a similar thing, by taking inspiration from this: http://www.smashbros.com/images/character/mii_fighter/screen-9.jpg (minus the fact they're arm canons). I already changed the shooting sound to TF2's scattergun to make it more punchy, and the big change would come in animating and coding the barrel for every shot. It could be renamed as a Revolver that's big and shoots tightly-spread shells.

Same thing for the Super Shotgun, by taking inspiration from Bioshock 2's 2-barelled Shotgun with the 3-shot upgrade: http://bioshock.wikia.com/wiki/File:2BarrelShotgun-2.jpg

So with what's happening now I feel more inclined to work on this. 

Great! I also regret that you're already in a mod, because I have some ideas for one and was hoping to drag you in. It would be sort of steampunk. If you like to talk, send me an email. 

Smart way to patch the vertices.

I was trying something with animated texture,
but in game it is too slow 

http://image.noelshack.com/fichiers/2015/53/1451554446-which-best-shape.png 

The one that looks best in a first-person view 

@Daya:
Top right. 

 

For software rendering, none.

The fact you're modeling with quads means there's no way to know what the actual triangle layout will be, and good triangle placement is crucial to avoid bad distortions in affine texture projection.

Triangle placement also affects the gouraud shading (Both in software and GL renderers), but that's mostly a problem in organic animated models with high contrast lighting. 

Also, without a textured view of the models, there's no way to know if your textures will work well with the triangles. 

I was just asking which shape was better aesthetic-wise 

Yellow has been left untouched (just like in the HUD) and is here just for comparison sake:
http://image.noelshack.com/fichiers/2016/02/1452786366-armors.png 

Posted by Skiffy [115.132.145.180] on 2016/01/18 15:37:14

Does anyone here know what palette format I need to use on PCX files for Preaches MD3toMDL tool to remap the colors correctly for the final compiled MDL file?

I'm using an .act file I've been using for ages making normal Q1 textures for levels but for some reason its not working with this tool. The colors come in all sorts of wrong.

Thanks for any help or tips you might have!

Cheers. 

 

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