I prefer to hit less steps on exporting to be honest - Quake can be pretty finicky about exporting and the more steps there are the more likely things are to screw up.

And its more work.

I'm still using Qme for many things, which can throw a wobbler every now and again and refuse to work.

Holy shit I'm disagreeing with Preach. 

The way I look at it is that it lets me cut out the step which involves QMe entirely. Before I'd get the model geometry designed and animated in gmax, then do the conversion and finish off the model in QMe. Usually the finishing off is just stuff like rotating and scaling properly, handling the skin.

The problem I had was that then if I realised I wanted to make some deeper change to the model, like un-mirroring a section of skin or adding extra detail to the mesh, it would mean ditching all that work in QMe and going back to the gmax version. So for me running an extra batch file to compile and copy the model to the right place is a timesaver, but it depends on your workflow.

(PS: cutting out QMe means you can use smoothing groups on your mesh!) 

(PS: cutting out QMe means you can use smoothing groups on your mesh!)

Quake's model lighting uses smoothing groups?? 

i don't think that's what he meant???(??) because it doesn't. it smooths wherever faces are connected. 

There's gouraud shading on the models from the normal vector that each animation vertex encodes. The quake format is a bit crude in how the normals are stored, they get a single byte which is used in a fixed lookup table of normal vectors.

How these vectors are calculated is entirely up to the exporting program. QMe calculates this every time you save a model by averaging the normals of all the faces attached to a given vertex(per frame of animation), then calculating which of the fixed normal vectors best approximates it.

If you split the vertices at a point then this changes the averaging calculations because each triangle now joins to a different vertex. It might be necessary to split some vertices for skinmapping purposes or other nefarious tricks. This can create visual seams on a model if not handled correctly, tomorrow I will post a before and after example model and some more tools for messing with vertex normals... 

wow, that's more complex than i imagined it would be.

are you saying there's a way to remove or at least reduce the seam on split edges with some normal trickery? 

For an example see:
http://www.btinternet.com/~chapterhonour/azoth.zip
The model azoth_pre is the version in the released travail mod, and seams are visible on the insides of his legs. azoth_post has been fixed in this regard through use of a perl script. The script was designed to unify the normals of all sets of vertices which
a) occupy the same position on the model in every frame
and
b) have the same colour pixel lying under their position on the skin

The script applies b in this case for the sake of the metal prongs that protrude from the belt. Their trianges form a continuous mesh with the torso, but because the colour at the vertex is different from the torso they get a distinct normal. This gives us a smoothing group!

I will admit that I discovered this worked well on the model by luck. My plan was to create an extra skin for the model with just solid blocks of colour to define the smoothing groups, then have the script just delete the extra skin when it was done. As it happens, if your seams are skinned carefully then this isn't necessary.

Another example that might be quicker to test is the waterfall: http://www.celephais.net/board/view_thread.php?id=60335&start=90&end=90
If you open the model in QMe and save it again so that the vertex normals get reset, then you should be able to see the difference it makes by looking at the water coming over the lip of the waterfall, the "squareness" is higher. In this case a script was necessary to fix the normals because even in gmax the segments of the model were physically disconnected. 

I think we can all agree time hasn't been kind to Qme.

I'm having the same problem just now actually - sank too much time into Qme and ended up having to sacrifice it all to make some changes.

I've wondered about the smoothing before actually, since Qme visually breaks the mesh, or forms it into one depending on one of two options.

Next up is the IQM format, which basically allows boned models in Quake. Apparently Gb has it exporting meshes directly from Blender into Quake - no other steps involved at all. 

It's worth mentioning that IQM needs engine support. RMQengine has it, and I think DP and others are considering it. 

Ok, so I have a brush and have applied a texture of a fence, which I need to be transparent... Where do I apply the shader? On the sides of the brush? 

Engine support - RMQ has that as well. I think DP supports it also, but I'm not the guy to answer the question well.

Basically yes, apply the texture to the brush and it'll work. We're using { in front of the texture name to designate partial transparency, same way that * makes a texture 'liquid'. 

The fence texture goes on the face that's visible to the players ("inside"), all other faces get the nodraw texture (or nodraw_nonsolid depending on the shader settings). Also check if the shader is one-sided or double-sided - if it's the former, and the fence is supposed to be seen from both sides, then the texture needs to be applied to both sides (or the shader changed, which would be the better solution). 

I was given a shader called transparent.shader, which apparently does the same thing. But when i say i want a transparent fence, i mean i was the black bits on the texture to disapear. On the texture, there is a fence, and in between each piece of metal on the fence, is black, which should really be nothing. I need to remove this black. Negke, was that what you were talking about, if so. Thank you, I will try you method 

*Radiant. How to display the number of points for the clipper tool? I see only the points. 

Something to keep in mind: if you run a long fullvis during which you are afk, for instance at night or while off to work, make sure your OS has energy saving disabled or adjusted so the VIS process won't stall and make you lose several hours. <- Just saying, because it happened to me. 

is there a way to make vis keep the computer awake the way playing a video does?

that'd be nice as this has happened to me too. 

It might be a pain but can't you just change your power management settings to never go to sleep if you're going to do a long VIS? 

obviously that's what we do now. in fact, that's exactly what negke said in his post. 

http://msdn.microsoft.com/en-us/library/windows/desktop/aa373208(v=vs.85).aspx 

anyone know some things that might cause bsp to go totally bananas?

In this shot, it decided to cut a series of thin bands right through the map (this craziness slices through the entire map, even into areas that are not (yet) spatially connected:

http://dl.dropbox.com/u/61424391/Quake%20Stuff/bananas1.jpg

http://dl.dropbox.com/u/61424391/Quake%20Stuff/bananas2.jpg

It's not due to that light fixture, 'cause I func'ed it and the issue was still there.

Here's an area where it decided to subdiv these bars for no reason:

http://dl.dropbox.com/u/61424391/Quake%20Stuff/bananas3.jpg

Anyway, there's shit like this everywhere in the map. 

Take stuff kut of the map systematically and see if it goes away. Maybe there's a fucked up brush somewhere or something. 

i have seen that; often it appears in a leaky map and the problem goes away if the map is sealed. If your map is already sealed then i don't know what will help, but it might fix it self later from geo changes in neighboring areas. 

try rebuilding a few brushes in that area? but yeah, not much else you can do. qbsp will even cut up stuff that's already in triangles and smaller than 480 units (i think 480? that's supposed to be the max face size). 

See a couple of posts above.
It doesn't make any sense - seems to be some inexplicable qbsp hiccough. Though maybe BJP could explain. The weird thing is that in most cases no direct modification will get rid of it, like upscaling the texture, trisouping the brushes, and so on. Sometimes it just goes away as you add more stuff like metl said, sometimes even if you make a seemingly unrelated change elsewhere. You can try moving the whole structure 64 units to the front so as to 'hide' the random splits. This sometimes works, but it's a surrender. 

i have seen that; often it appears in a leaky map and the problem goes away if the map is sealed.

Might be that actually :} *blushes* - i'll have a go sealing it and let you know