Hah, that tutorial is brilliant. 

So I'll post a more constructive reply.

Yeah what ijed said, even if you make it detail, it's far from being optimal and will be cut up pretty randomly and in some engines you have no detail brushes (like quake1) so can't get away with such sloppy brushwork.

For spiral staircases, try starting out with a cylinder with a specific ammount of sides (usually something logical, divisble by 4), snap those sides to the grid, then align brushes along it to create your steps (you can use a second smaller cylinder with the same ammount of sides as a central wall too for larger stairs). Edge edit is your friend. 

ZIP would be my preference.

czg's curves are here: http://www.quaddicted.com/stuff/curv_tut.htm 

Eyeballing edge manipulations like that to use as a 'template' has it's own inherant problems especially when using cylinders with more then a dozen or so sides. If you want steps to be *exact* then you have to duplicate and rotate by calculated values. 

"(and it also works on a mac, though command line only). "

It actually doesn't. It's a classic application (aka OS9) and modern Macs won't run it.

I'd love it if we could start using regular ZIP. The demos that guys delivered for Evil Exhumed in ZIP form were awesome and compressed just as well. 

If you work with a small enough grid the steps don't have to be exact, you won't see a difference visually, and the result will be much cleaner.
I've done plenty of pretty complex (much more than 12 sided cylinders) spiral staircases this way, and they compile fine even in quake1. I can tell you that you're stairs would just make q1 qbsp kneel down and start cying in most common cases.

In the end your tutorial is for quake3, so yeah it'll work fine, it's just not very clean. 

Ummm someone remind me, what do I use to zip so I don;t have to use the trial version of Winzip that reminds me I've exceeded the trial limit by 8 decades?? 

12 and 24 sided cylinders are pretty nice and with his ingenious clip-stretch-shear method you can curve very complex geometry. 

7zip is your friend: http://www.7-zip.org/ 

Dzip does work on OS X, because I compiled it, and gave Nolan the executable for the dzip page (that's a PPC binary though), and use it all the time.

So, er, nyah? 

mwh

OK, well, it didn't work for me. So I dunno. Can we not just use standard ZIP files? 

Clean? It's horses for courses Bal, if you're throwing brushwork around to do some interesting designs with stairs (other than a tube with stairs and openings top and bottom) the chances are you're going to cut across a spiral and create nasty floaters at compile time anyway, and that's regardless as to how you made them. So it really is a completely moot point to say that; even using smaller grids isn't a cure-all as it has a tendency to introduce precision errors as you know.

Every method has it's problems, just use whatever you think suits what you're working with and trying to do and how quickly you want it done. Having said that the tute wasn't intended to be read in the context of Q1 level design.

I've updated the tute regardless to take into account what's been discussed here. 

I don't watch any demos anymore because I refuse to download and install the absolutely worthless DZip.

Lame excuse, aguirRe's current engines and (iirc) JoeQuake can playback Dzips like demo files, as long as dzipname = demoname. Place the demo files in ID1 and do playdemo demoname as usual.

(yes it's necessary to rtfm sometimes, but it's worth it as SDA keeps pumping out awesome demos like Stubgaard's fairly recent e3m4_120: http://speeddemosarchive.com/quake/demos/NH/e3m4_120.dz )

Also, aguirRe's 3.09 (current beta) will have even more useful features regarding demo playback.

7zip is good because it's free/stable and the compression rate with large demos is indeed better, but 'installing' Dzip is a matter of 10 seconds... 

"Lame excuse, aguirRe's current engines and (iirc) JoeQuake can playback Dzips like demo files, as long as dzipname = demoname."

Plz add to FitzQuake, kthx! :) 

are on a minimum grid of 4 at the smallest. They were easier to work with, line up with the curve patches for the trim a lot more cleanly, plus the compile-side benefits. I'd post a grid shot but I'm at work.

http://www.lunaran.com/images/maps/lun3dm3_2.jpg

ijed:
Why is lunsp3 takign so long?

because lunsp2 isn't done yet. 

Sorry, moot points again, those are all 'attributes' that can and have been argued for and by proponents of every method there is to make spirals, Quake 3 and beyond. 

Get it here:

http://www.hrimfaxi.dk/diverse/CurveTutorial.zip 

 

where's my... your es pee five?! 

I've read some misconceptions here concerning quake and detail brushes, such as they would require bsp or engine modifications to support. This actually isn't true. There's a set of compilers called "eUtils" that support detail, hint, and skip brushes. Hint brushes are added to the bsp first, and detail brushes last. Simple right? Well I dunno really, I'm no coding guru.

The qbsp looks for brushes grouped into "am_detail" entities.

Two catches: one, vis and light need to be aware of the changes, and such versions are included. Two, there is source, but it's a Carbonized mac app, so maybe not many of you could try it. I use it as my main compiler and they work fine. But it would be interesting to see the features added to the linux-ified bjptools that are being worked on.

It was made by frank "pOx" condello, same guy that did the extras qc mod. http://quake.chaoticbox.com/downloads/equakeutils.sit 

I remember that concept being tossed about (hint added first, detail added last, but they are still part of the bsp structure), and I seem to remember some people saying that the order that brushes are added to the bsp tree really isn't that important (even though conceptually, it seems like it would be.)

I think in radiant at least, any time you select and deselect a brush it gets added to the end of the map file, so you could manually do this sort of thing by selecting/deselecting brushes that you want added last. Not sure if this is that helpful. 

what are the biggest differences between func_walls and detail brushes?
How hard would it be to add an intermediate form of solid geometry to an engine, one that is rendered quite like walls (without the func_wall penalties) but is not part of the bsp somehow (could affect collision hulls somehow, dunno how). (how do you accomplish that I do not have the faintest idea...)
Maybe just generate an entityish class for func_walls only. 

It's not entirely accurate to refer to the "order" that things are "added" to the tree - hint faces have the highest priority for splitting the tree, and afaik details have none. What order the brushes are listed in the map file has nothing to do with anything because split priority is based on brushes' size and shape and angularity. If order mattered you couldn't have major structural leak-stopping brushes "last" because the BSP tree would have been largely finalized already.

An aguire or a lordhavoc would be useful right about now. 

i guess i thought qbsp adds brushes to the tree in the order it finds them in the map file. Didn't know it scanned the entire list of brushes and then optimized the order in any way.

Either way though, a leak plugging brush will plug the leak regardless of the order you add it, assuming there are no precision errors or bugs.

P.S. I'm talking about quake 1, if that's any confusion. 

I'm almost certain that QBSP adds the brushes in the order it finds them in the MAP file. It has to, otherwise overlapping brushes with different textures wouldn't work. The ordering has to be deterministic.