To be honest, I might have a go at banging out some melscript that takes a bunch of triangles from maya and projects them up (or down) to turn them into tri prisms, and then spits out a quake .map file. Shouldn't be too hard to do... (another thing to add to my ever growing list of shit :)

dude... if you did this... my god, it would be amazing.

i really wish there was a way to extrude a triangle to create a brush this way.

but... if you do decide to, would it be possible to have it work for more than just maya? maybe support ASE for full compatibility? 

I'm sure it would be a similar amount of work to write a maxscript version, although I don't have max, and have never done any scripting in it before. 

with quake and terrain though rears its head when it comes to the issue of placing architecture in the terrain. I've been taught that letting brushes arbitrarily intersect each other is bad for quake, which lead me to carefully tessellate my tri-soup terrain around any architectural elements to avoid intersection, which feels precise yet at the same time messy and annoying to do (it feels inefficient as it means you use more triangle brushes). I did it like this in marcher (when a 12-sided stone column butts into the terrain, the terrain triangles all perfectly meet up to each side of the column.

Now though, I'm thinking this is annoying to do and might put me off making areas where architecture melds with terrain. I think also, my OCD had a large part in me doing it like that.

Considering how quake chops up faces into ugly shit anyway, even in a pure tri-soup with no intersection - would it really matter if I just let random architecture intersect the terrain? How did you approach it necros? 

Something that reads an OBJ file of triangles and spits out a MAP file of extruded brushes should be dead simple. Just saying. :) 

"I've been taught that letting brushes arbitrarily intersect each other is bad for quake"

This has never been explained in a way that would convince me it as true. QBSP chops up the world and removes any inter-penetrating geometry. That's what it does. So how do intersecting brushes cause problems? 

Generated terrain is only ugly if you use large grid. And even then its really easy to adjust it the editor to your liking, making it as irregular as you want. Big timesaver.

Willem: precision problems that cause collision errors. Never experienced falling through irregular angled geometry?

There are several model-to-map progs and scripts, but none that I'v tried output geometry that is friendly to shitty quake compilers. Again precision loss, gaps, edges don't match, collision errors.

Q3map2 solves all the problems. But I know that quake mappers are too afraid of technology advancements. 

I've experienced that but I've never found that manually aligning brushes is a magic fix. As often as not, making them intersect MORE will fix it.

And why the hostility towards Quake mappers? 

Willem, i guess that it may produce more faces than is necessary and odd things like tiny sliver triangles, I have no idea really. I did a really quick test to see what happens in two cases: a square pillar meeting some tri-soup. On the right, i just intersect it into the triangles, but on the left, I chop the tris up and carefully stitch around the pillar, making sure the overall topology matches the first case as close as possible.

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

Results shown in r_drawflat. I guess there's not much in it. The one on the left looks "nicer" and has slightly less faces when all the chopping's been done, but I think the only question that needs answering is "will intersecting like this actually cause any problems when done on a large scale?"

Who knows - certainly letting them intersect is a million times more friendly and flexible for the mapper.

Q3map2 solves all the problems. But I know that quake mappers are too afraid of technology advancements.

Cool - let me know when I can use that to compile a working quake .bsp 

well that small test above is too limited to really prove much so i did something larger scale with bigger terrain and more stuff sticking into it. I conclude that Quake chops up the faces of trisoup terrain into such nasty shit anyway even at the best of times, that it really doesn't make a whole lot of difference whether or not you butt other random things into it. 

it's more to do with hull expansion, but aguirre's bsp has a much better expansion algorithm or whatever which handles all kinds of brushwork that would have normally killed the compiler.
in some cases, it might even be pointless to trisoup around intersecting brushwork.

the ruins start map has both fitted and unfitted intersecting brushwork. i built the fitted stuff first but what i started loosing interested, i just started plopping things down into the terrain and when i noticed nothing overly bad happening, i just let it be. (the map sources are available if you want to look) 

guys!

it runs fine in my mac quakespasm engine, but a friend is having trouble running it in his windows qs.

whenever he types -zone 2048 -heapsize 192000 -game ne_ruins, it doesn't run. the game runs with the command -game ne_ruins, but his console in quake tells him 'unknown command' when he attempts typing the heapsize/zone commands.
i know that the - + switches do not function in the quake console, as they only work in the mac qs command line box.
is there a way to enter the command line via windows qs, without having to do it through the quake console?

and lastly: breathtaking stuff necros! 

He can create a text file in the Quake directory and put the whole line inside, eg:

quakespasm.exe -zone 2048 -heapsize 192000 -game ne_ruins

Then name the file for example quakespasm-ne_ruins.bat and now doubleclicking should launch the game properly. It needs to be a .bat, not a .txt, so make sure he has disable the hiding of "known extension". 

taking that one step further:

make a text file called "qs.bat"

in it, type:
quakespasm.exe -zone 2048 -heapsize 192000 %1 %2 %3 %4 %5 %6 %7 %8 %9

now, in a command prompt, you can run qs -game ne_ruins (or any mod you like) and it will always use the extra ram and zone settings. 

Or in Linux you just use an alias like
alias qs="cd ~/quake && ./quakespasm -zone 2048 -heapsize 192000"
for example in your ~/.bashrc, then you source ~/.bashrc once and then you can use it the same way (from any location, or if you are in ~/quake already you could use tab completion for the game). 

cheers guys,

i'll ring him 2moro and tell him to try those out. 

yep, that sorted his problem out, so excellent stuff all round.

thanks again, guys. 

Been meaning to post my thoughts on the map anyway, so here goes. I have to say I am seriously impressed with the quality of the QC work on display here - the attention to detail is awesome - the "physics" door in the start map would have made my monocle fly off had I happened to have been a Victorian gentlemen.

On one playthrough when I was just checking stuff out casually, I ran past the enemies at the start to reach the building - and whilst I was bumbling around in there, a bunch of dogs (who were miles off when I left them) had seemingly pathed perfectly to track me down inside the building. I wtf'd for a bit, until I vaguely remembered a func post where you were talking about implementing A-Star in QC and it was at that point when my second monocle became airborne.

In general I liked all the new QC and the new monster stuff - I found them mostly tough but fair - and the fast zombies nearly made me shart my pantaloons on a couple of occasions. The spawns-in-a-vase were annoying until I realised what was going on, then they became cool. I must admit that this map (along with Tronyn's stuff) has reminded me again just how much I friggin' love the Hexen II monster models.

I loved the architecture in general although I think a bit more variety would have helped with my orientation, but that's a minor quibble. For me it was all about the gameplay setpieces and there were heaps of them and all were stellar.

A special mention must go to the final boss fight which was seriously the most impressive finale I've ever seen in a quake map. The way the lava spawns froze was fantastically cool and is another example of the amazing attention to detail I mentioned earlier.

Really, really awesome job :) 

thanks!

yeah, the hexen2 models are really quite good. some of the animations i find are a bit iffy, but the meshes themselves are solid.
it's too bad that the hexen2 and quake styles are not a little closer together to allow them to be used more often in quake. 

it's too bad that the hexen2 and quake styles are not a little closer together to allow them to be used more often in quake.

some good skin-fu can fix that :} - I'm working on a super quakey reskin of the archer for my new stuff.

With H2 models i'm always tempted to use their full 20hz anim framerate but imo it doesn't fit with quake's 10hz crustiness, so i always skip every other frame in the QC - I keep all the frames in the model unchanged though because I always felt that if i chopped them out and resaved the .mdl then i'd probably get "noise" (can't think of a better word right now) introduced into the vertex coords as the model might have new bounds or something, so the verts might get shifted around or some bollox. I haven't tested it. 

i removed a LOT of frames from eidolon. in ruins i left the animation rate of the h2 monsters at 20fps because i didn't really notice much problems with it at that rate. in retrospect, it does change other things like ai updates and such, plus you need to halve the yaw_speed because at 20fps, the monsters think twice as much and so turn twice as fast, so i should have just gone and reworked the animations for 10fps. oh well. :P 

I'm a pernickity old fuddy-duddy of only the mustiest leather-elbow-patched tweed, who these days will only play Quake in software-rendered WinQuake (or Aguire's WinQuake for those maps where a little more muscle is required). In fact, I played ne_ruins in software mode so I'm afraid I missed out on some of the intended graphical flourish...but my point with all this is that if you use an engine that interpolates frames then I suppose a 20hz animation gels a lot better with the overall visual style, and the difference between 10 and 20hz is not very noticeable.

In non-lerped software quake, a 20hz monster stands out like an elegant ballerina amongst a rabble of peg-legged drunks, which is why I tend to "cripple" them a little bit to make them fit in better. There have been a couple of exceptions in extreme circumstances - in my maps the Gauroch's charge attack uses the full 20hz anim because he moves so fast it would look crap otherwise. 

Is this almost fully coopable?

During a coop attempt of this, I found myself dead by the ice golem and couldn't progress back to that area due to a rock in the way that was blocked by noclip all the way up (preventing even rocket jumping over it.)

I've noticed that among map authors, your maps are almost always very consistently entirely coopable in every way. 

likely some graphics breakdown would occur for some players if you trigger the final lava flood before they have all entered the final stairwell.

Also monsters just pop in so if a player is triggering them, another one will suddenly have monsters in their face for no reason.

so yeah, not super good for coop. 

Just realised I still haven't played this. Shall add it to my list.