I don't know if it reapplies the palette when you edit it, have you tried saving the palette, changing the colour depth to RGB, and then changing it back to indexed with your saved, fullbright-free palette?

Otherwise there's always QMe... 

Well, what it seems like is that there are two identical reds, but only depending on the index in the palette is it determined to be fullbright or not.
It's weird because in PS, the palette would show up in the same order it was in when I created it from the palette image.
In Gimp, the colours are just all random in the palette.

Otherwise there's always QMe...
What do you mean? 

Try grabbing the file from http://www.btinternet.com/~chapterhonour/notbright.pcx and importing the palette from there. If you still have trouble, is it possible that some other tool is interfering? There is a shade of fullbright red with the same RGB values as a regular palette entry, so anything that converts skins from palette index to RGB and then back to palette index will inevitably lose information on some files.

re: QMe, you can use it as a cheap fullbright remover by importing the texture in question as a skin, then using the QMe palette filter tools (which are quite good actually, being custom built for quake itself) 

Thanks, I will try that out with the pcx file directly.

QMe palette filter tools
Which tools are those? I've honestly never touched that part of the program. 

Thanks, that seems to have worked! Just took importing the palette directly from a pcx file! 

The skin editing in QMe is probably the most polished part of the program. You can even undo edits that you make while drawing on the skin using ctrl-z! (*)

http://www.btinternet.com/~chapterhonour/qme-pal.png highlights the button (top right) and shows off the dialog. You can remap colours one by one if you double-click them, then pick the replacement colour from the pop-up. It's pretty laborious to do that though.

The quicker way to replace colours all at once is to untick the boxes to the left of the row. This replaces all the colours in that row with the closest match in the remaining checked rows. That last bit is important - if you have lots of fullbright oranges and reds you want to remove from your skin, make sure that all the non-fullbright orange and red rows are ticked first. Otherwise you will get poor results!

(*) 3d view only 

Ah ok, I saw that dialog but couldn't figure out at a glance what the heck it did.

Seems like a cool way to do some quick palette swaps, thanks for cluing me in on it! 

nice model, what is that from? 

It's a sneak preview of an upcoming pack of models... 

Since there's no way I can squeeze all this on the model I might as well post it here:

The defective packs (pictured left) were manufactured between July 2087 and February 2088. We advise all customers to inspect your medikits for the following indicators:

� Unusual or pungent odour
� Discolouration
� Liquid discharge from base
� Inoperative indicator light

Any pack displaying one or more of the above symptoms should be returned unopened to your retailer for exchange or a full refund.
Remember, in an emergency situation your life could depend on your medikit - be safe, not sorry. 

Awesome! 

Hm... I think I have found why .mdls have to be split the same way the verts are split on the skin map...

OBJs (for example) allow a face to contain it's own s/t tex coords, but MDLs have the s/t coords bound to the vertices themselves...

Oy... I guess I will need to figure out how to split up the OBJ mesh so that skin verts and mesh verts are split the same. 

OBJ files store verts in clockwise order, but (I guess because of OpenGL?) they need to be in counter clockwise order to draw properly. 

It's called 'ne_modelEditor' but all it can really do right now is edit UV mapping on models. :P

File->Open to open a model (.mdl but will load .obj)

RMB Drag on the 3d view rotates
MMB Drag on the 3d view pans

Click the "Show UV Mapping" button at the top.
Click and drag to move UV verts around.
Dark Blue verts are normal skin verts.
Light Blue verts are verts that share front/back tris. Moving a light blue vert moves the two together.

File->Save to save a new model. Don't overwrite your models... who knows what this program could do?! Oh right.. me. Just keep some backups of your models.

- There's no undo (there will be)
- You can't split/merge skin verts (you will eventually be able to)
- Can't select verts/tris in 3d view (you will eventually be able to)
- Can't edit 3d mesh at all (don't know if I bother with this, there are better modelling programs out there)

ne_modelEditor 0.01
Made out of java, so you can just unzip this into a folder and double click ne_modelEditor.jar
If double clicking doesn't work, you probably don't have java or it's not set up right.
Also, this requires OpenGL 1.1 compatible card... which should be like every card out there. 

Specialising in UV maps is probably a good niche to aim for, as all the existing mdl format editors are lacking in that department. I already prefer using this tool to QMe, which doesn't even select the vertex under your cursor correctly. Quick wish-list in that department:

* Drag select
* Select adjacent vertices command
* Select entire component (all vertices connected to the current selection)
* Rotate tool
* Scale tool
* Mirror tool

That ought to be enough to let people create efficient skins.

Also one nitpicking detail: Quake actually places vertices in the middle of the pixel at the given skin coordinates, not in the top left corner of that pixel. It's a kind of unhelpful design because it means you can't get even borders on the edges of carefully aligned polygons. But it's the design we have been given so the editors have to follow it. 

Quake actually places vertices in the middle of the pixel at the given skin coordinates, not in the top left corner of that pixel.

Oh shit! I actually uncorrected this because I thought it was due to integer casting somewhere along the line!

As for your wishlist: yup. :)

Other things:
- selecting tris and being able to detach them as one piece
- being able to "relax" tris in UVs to match their shape on the mesh.
-displaying coordinates and allowing editing of UV vertices by typing in 

http://necros.slipgateconstruct.com/downloads/ne_modelEditor002.zip

v0.02
ESC now closes UV Editor. This is mainly just a convenience shortcut.

Shift-selecting multiple frames in the sidebar of the 3d window will auto animate the frames in the selection... Just a lame way to preview animations for now until I make some proper representation of the frames... maybe with JTrees or something.

Box selection is in. Holding Ctrl while selecting will add new verts while just box selecting will clear the previous selection, as per usual windows UI standards.
Alt+Box selection to deselect vertices within the box is NOT implemented yet. (it will be)

There's no 'select element' function, but something almost as good... I emulated 3dsmax's Grow/Shrink Selection functionality. With a single vertex selected, pressing the grow selection button will select all vertices surrounding it (that are connected). Shrink selection works in reverse.
So you can select a whole element just by repeatedly hitting the + button.

A very rudimentary Undo action is implemented for UV vertex edits only. (Which is fine considering it's the only thing you can do anyway!)
Of everything, I'm the least happy with the undo implementation. I've never coded an undo system before and I realize I should have been making it along side everything else. As it is, I seem to be working around my classes which is never a good thing.

You still can't select stuff from the 3d view... Sorry, I'm just not sure how to do the traces. I realized when I sat down to code it I had no idea how a "traceline" actually works! All I could think of was doing a search in a sphere along a vector in small increments and hope to find a vertex within the radius... but that seems lame. :P


Next will be some basic functionality like rotating and scaling verts and at least edge and face selection/movement. 

You still can't select stuff from the 3d view... Sorry, I'm just not sure how to do the traces. I realized when I sat down to code it I had no idea how a "traceline" actually works! All I could think of was doing a search in a sphere along a vector in small increments and hope to find a vertex within the radius... but that seems lame. :P

There's a better way based on this fact:
The closest approach of a point to a line is where the vector between the point and the line is perpendicular to the line
You can create some linear equations which can be solved simply to give you the correct point on the line. Then calculate the length of the difference and reject the vertex if that distance is too great. I can expound on the maths later today 

Ok, so here we go. In the following maths any variable in bold is a vector, non-bold are scalars:

We can define a line in 3d space using two vectors, origin and direction. The origin a can be any fixed point on the line. The direction r is a vector parallel to the line. The equation of the line is:

x = a + k r

where x is any point on the line, and k is a scalar which can vary. For fixed a and r we can choose k to find any point on the line.

In this specific case the natural choice of a is the viewpoint of the 3d render. In quake we would find the vector r using makevectors(self.v_angle), in your java thing you're on your own...

If we let b be the coordinate of a particular vertex we are testing we get (from the post above)

r . (a + k r - b) = 0

We solve for k:

k = (b - a) . r / (r . r)

In a third post I'll bash through some algebra which uses this value of k to calculate the (squared) distance on b from the line. 

...will now not be taking place.

If we let x = b - a from above, the end product of all the algebra is

(x . x) - (x . r)� / (r . r)

which gives the square of the shortest distance from the vertex at b to the line. You can get this by substituting the value of k back in and doing lots of expanding, grouping, cancelling etc. I'm going to take a short cut which explains it from a different angle.

We will look at projection: flattening the 3d space onto a 2d plane with our line sticking out as the plane's normal vector. Since this plane is perpendicular to the line, we can just measure the distance from the vertex to the line in this plane to find our shortest distance.

We will start with a simplifying assumption which we can generalize later: assume that r is a normalized vector (of length 1).

We can split x up into two components: parallel to the line and perpendicular to the line. We ultimately want the latter one, but it turns out the former is easier to calculate. The parallel component is in the direction of r with length |x| cos C. Because r is length 1:
|x| cos C = r . x ��� �(1)

So we end up with the parallel vector being:
(r . x) r ��� �(2)

To get the perpendicular vector we subtract this parallel vector from x:
x - (r . x) r ����(3)

This is the vector we want, so we just do the usual trick of taking the dot product of (3) with itself to get the length squared:

(x . x) - 2(x . r)� + (x . r)�(r . r) ����(4)

Under our assumption (r . r) = 1 so (4) reduces to

(x . x) - (x . r)� ����(5)

What happens if we relax the assumption? We need to divide the right hand side of (1) by |r|. We then have to divide (2) by |r| a second to normalise the additional r term. But because |r|� = (r . r) we can calculate the normalizing factor without any expensive square roots. If you work through equations (3) and (4) you should find the same cancellation of the latter terms occurs to get the formula at the top of the post.

After all that cleverness to avoid a square root, I'd still suggest doing one for this specific application. The key thing is that r doesn't change within your loop through the vertices. You can normalise r outside of the loop, and avoid a division operation within the loop. For models of 300 vertices I'm sure this will prove to be faster. So just use (5) with a normalised r.

PS: Why does func_ let me do   and • but not θ ? 

Thanks for taking the time to outline the whole process, Preach. I was going to reply yesterday, but it seems I can't even get my 3D Picker working to translate on-screen clicks into world coords.
I'm sure I just messed something simple up but I got frustrated with the damn thing and just went and mapped instead. :P 

Finally straightened out the screen coords -> world coords shenanigans and thanks to your posts, I now have vertex selection in the 3d view! :)

For edge selection, I'm thinking make a plane perpendicular to the camera, find the point where the trace hits the plane, then use the same stuff you posted above except in reverse-- find a perpendicular line of shortest distance to the edge from that point.

Face selection, again with a plane, this time of the triangle. Find the point where the line intersects the plane, then check if that point is inside all 3 edges of the plane. (make sure the intercept point is on the same side of all 3 edges as opposite triangle point of the edges). 

Good that all of that stuff is working. I thought of one need little optimisation for selecting the best vertex when multiple vertices meet the criteria and forgot to mention it. If many vertices are within n units of the line you are probably best off choosing the vertex which is nearest the camera (rather than just taking the first result on the list which might be on the back of the model and confusing). The neat thing is that in (5) we already calculate (x . x), so we can save that value for the best point so far, then compare it to any subsequent point which is near enough to the line.

Your plan for the edge selection seems sound but one warning - you will need to special-case the situation where the edge is already perpendicular to the camera, because when you project the line into the 2d subspace it will collapse into a point, meaning r goes to (0, 0, 0). The danger is that you will then attempt to divide by the length of that line's r value and crash because it's a divide by zero. Check for the zero length, in that case you need only measure distance between two points - easy! 

A couple more models coming from further experiments with gmax animation: a force-field effect and a smoke plume. Download from:

http://www.btinternet.com/~chapterhonour/effects.zip

There's a test map included, extract the whole thing to your quoth folder - the models themselves are in a folder called test (in the hope you'll remember to delete it once you've had a look around the map). As with the waterfall effect from a while ago, the models work in engines as far back as winquake but are better in something with interpolation and alpha support. 

... announcing a Quoth 3 mod ? <- just wondering :P