When I'm making models for quake, I've got a very complicated/convoluted process involving six or seven different programs for making the model, making the skinmap, painting the skin and converting the model to quake 1. Some of the steps aren't required though, so I'll recommend the bare minimum set first.

For making the actual shape of the model, I use http://www.wings3d.com/ as it's simple and intuative to use. If you don't like that, blender(http://www.blender3d.com/) or gmax(http://www.discreet.com/products/gmax/)

For simple models, I'd skip straight to converting it to a quake model. For this, I'd recommend QMe(http://www.xs4all.nl/~renep/quakeme/)
QMe can import .3ds and .dxf files, but gmax will only export to .md3 format. If you use gmax, you can get round this by getting a copy of 3Dexplorer(http://www.dsmith.gmaxsupport.com/downloaditems/3dexplor1_5.exe). 3Dexplorer will open .md3 files and export them to 3ds.

Finally, when you've got it in QMe, you can use that to make a skin, animate the model and save it. The skin won't usually work out perfect, but to fix that you need to use a load of plugins and mess about with Gmax a lot. If you want the details of how to make a quake model with a proper, unfolded skin, just ask and I'll type that up. 

those brackets broke the URLs, here they are in clickable format
http://www.blender3d.com/
http://www.discreet.com/products/gmax/
http://www.xs4all.nl/~renep/quakeme/
http://www.dsmith.gmaxsupport.com/downloaditems/3dexplor1_5.exe 

Any leads on where to download the full version of QMe? 

I dunno if that still supports Q1 or if it's still free or whatever, but that seems to be a popular modeler. I think they used it to make the CounterStrike models. 

I am using WC3.3
You can use a different compiler to compile the maps; of course. Export them to .map and run whatever compiler you like. The problem is the texture alignment will be completely fucked up. My advice would be, find someone with a compiler you like that's still supporting it, and ask them to include the texture alignment stuff from dubsp.

I've had a problem of this sort too, in which a map is entirely fucked up after compiling it with dubsp (despite the fact that the texture alignment is fine, lol)... missing faces on many brushes, sky going through everything, etc. 

You completely rocks, thankyou!

Tronyn: summa summarum, it will be hax0ring t3h source code of the compiler I'm most familiar with? 

tell qurnel to finish his q1sp, his DM maps are excellent. 

I think Milkshape as a modeler is lacking in certain ways but it has excellent conversion utilities. For Quake I models I use the fallowing set up -- Wings3d, id's ModelGen http://www.gamers.org/pub/idgames2/utils/graphics_edit/model_tools/ for converting 3ds files to mdl,
and Quark for generating a skin file. 

and corresponding wads (zipped, please, and no rmfs/bsps) to test a quick fix I've just made for my compilers. It looks promising on the few Hammer maps I have.

At this time, it only enables my compilers to interpret the Hammer map files (with its native texture definitions), wads must manually be converted into WAD2s using e.g. TexMex and there's no support for extra hulls or other frills. I hope this is not a big problem.

Since MisYu initiated this issue, maybe you could send me some test material? But anyone with Hammer source maps is welcome to contribute. 

I'll send you everything today, both my and qurnel's stuff. 

You can get full Qme 3.0 here:
http://www.edgefiles.com/files/9100.html 

I'm downloading it now to check it out. I remember making a search for it last year and not being able to find it. BTW, my set up includes Blender as well. You can use its IK tools to position the models cycles pretty easily, though animation is still a pain compared to modeling. I can model a decent monster in 4 hours or so, but animation for even a basic set up (at ease - walk cycle - fight) takes at least a week. 

I was gonna try making a program that would add the animation frames from one model onto the end of another, to work around the problem, but this is far FAR better. Also, a quick recommendation I'd make now is to get a copy of the 3.1 demo. It has a program that will upgrade 3.0 full to 3.1 full, which has proper bones, a generally friendlier interface and IK. Thanks again!

(PS, LTH, are you still making tanx? I have a helipad model you might find useful...) 

I just tested and confirmed that it's very possible (and easy) to convert a Hammer map into standard Q1 (or QuArK ETP) format using QuArK 6.3.0 (probably other versions too).

The resulting bsp is very close to the ones I've been producing with my new versions, very few (if any) texture errors.

Just load the map file into QuArK in Q1 mode and save the map and you're done. It will preserve/translate all texture orientation info.

Of course, I still want Hammer source maps to test my compilers so you won't need the extra conversion step using QuArK. 

Preach - that would be great! Could you drop it into my pq mail: lth@planetquake.com

Cheers 

(Valve 220 format) is now available at http://user.tninet.se/~xir870k .

Any comments are welcome. 

Where? Which file? Docs? etc. 

above work? There are files and readmes directly available, what is unclear? 

if i want to compile my map I have to switch my HL .wad files with the original quake .wad files to get it to compile without the "wad not found in worldspawn" error (or whatever it was) ? 

different from DuBSP, I've only added the capability to interpret the Valve 220 map file format.

See also post #9 above. 

into adding the wad3 support also. However, I'm experiencing problems using the code from DuBSP. It appears as if some wad3 files (produced by TexMex) cannot be read by DuBSP, it aborts with a "ERROR 35: Failure reading from file".

When reading the wad3 file, DuBSP always seems to expect some palette data for each HL texture which doesn't always seem to be there.

Is this a known problem with DuBSP? 

I haven't ever had that problem, but then again I didn't use TexMex to convert my textures, I used wadconv which came with DuBSP. The only real problem with that is limitations, it can't convert a wadfile that has above a certain amount of textures, and some textures are too big to be converted. But other than that it works prefectly. 

well, all i know about half life wads is that they are supposed to contain palette data all the time

it's done this way to get over the palette problem of q1, where some textures look like shit because q1 didn't have the colors in the palette (like greens).
so all hl textures have their own palette info which allows nearly unlimited colors in the engine (why all textures, regardless of colors, look pretty good ingame)
sort of like how Cyan did all the images in Myst with their own palettes, so that they could save space but have 32bit looking images. 

I think I've a picture of what's happening. DuBSP absolutely requires the palette data in the wad3 file, whereas the wad3 format only has it optionally.

This is also why Riot requests on his site that the wad3 files must be created by his wadconv tool (which always appends the palette data). This appears to me as a violation of the wad3 specification. It's also why wad3 files produced by e.g. TexMex don't work with DuBSP.

DuBSP also seems to append some garbage data to the end of each texture so the total texdata size in bsp is bigger than if wad2 had been used. This had me puzzled for a while.

I've tried to clean this up and now my compilers can hopefully read any wad2/wad3 file without any problems.

If anyone knows more of this issue, please let me know. 

my bad. i thought they needed that palette data. ;)