From owner-quake-dev-digest@gamers.org Tue Jul 2 15:08 MET 1996 Received: from gamers.org (thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id OAA08704 for ; Tue, 2 Jul 1996 14:45:00 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id IAA20949 for quake-dev-digest-outgoing; Tue, 2 Jul 1996 08:44:04 -0400 From: owner-quake-dev-digest@gamers.org Date: Tue, 2 Jul 1996 08:44:04 -0400 Message-Id: <199607021244.IAA20949@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #20 Reply-To: quake-dev@gamers.org Errors-To: owner-quake-dev-digest@gamers.org Precedence: bulk X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 25392 X-Lines: 708 Status: RO quake-dev-digest Tuesday, 2 July 1996 Volume 01 : Number 020 ---------------------------------------------------------------------- From: steve@activesw.com (Steve Jankowski) Date: Fri, 28 Jun 1996 09:29:39 -0700 Subject: Re: Added server polling functionality John Cash said: >Yes, you can get a fair bit of info out of a Quake server now. I plan >to do a fairly detailed post so you guys can start making use of it, >but I've been too busy bug fixing to do so yet. Guy said: > Also Steve, the list I give to qstat for detecting servers has > reached several hundred by now. Occasionaly the last few severs > return things like 0/1238102987 players active. Thanks for the bug report, Guy. I'll look at it this weekend. Yes, please send me your server list for testing. Should I get on the quake-dev list? Will I get swamped with discussions of level editors and Quake C? The qstat to-do list includes; Win95 GUI, meta-server, proxy-server, support for the new protocol. Steve ------------------------------ From: Bernd Kreimeier Date: Fri, 28 Jun 1996 19:14:12 +0200 (MET DST) Subject: Re: Clarification requested (was Re: distribution of id data...) - ------------------------- ADMIN ------------------------- Perhaps I am already infected with this disease of being unable to set the record straight.... id Software has designed and uses a mechanism to restrict the actual number of maps that work with the shareware. They presume it works. Anything else is OFF topic. Rest assured that (a) they prolly know what they are doing, (b) they will let us know if they need us to worry about this, (c) further futile discussion on this list will result in cancelled subscriptions. If you think you found a flaw in their concept, consider it a bug and send a report to support@idsoftware.com. Thanks. b. - ------- gee, I'm not sure they'll listen to reason --------- ------------------------------ From: John Minadeo Date: Fri, 28 Jun 1996 13:34:16 -0400 (EDT) Subject: Re: Clarification requested (was Re: distribution of id data...) On Fri, 28 Jun 1996, Terry Evans wrote: > > I ask because it sounds like Jon has gotten a user level to work with > > the shareware version of Quake and this would seem to be in contradiction > > to Jay's statement. > > > > -= Jim Lowell =- > > Along the same lines, has anyone tried the -game option with the SW > version to see if it is allowed/disallowed? I'd try myself, but I'm > at work right now. > > Terry > tevans@netcom.com It gives you : Error: You must have the registered version to use modified games / / jminadeo@nforce.com / "Cheer up, the worst is yet to come." / __ /_ __ / -Philander Johnson / / ) / ) / ) /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (__/__(__/__/ /__/ /__ Minadeo / http://www.nforce.com ------------------------------ From: bstastnX@td2cad.intel.com Date: Fri, 28 Jun 1996 10:58:43 -0700 Subject: Compiled Source Hi, I have a Intel Pentium optimized compiled sources to the vis/light/qbsp programs and I am looking for someone to do a simple benchmark with them. I just used the default optimize settings on the "compiler" if someone would like to do this email me dirrect, also if anyone is interested in a Intel Pentium Pro optimized complie they can email me dirrect also. If the benchmarks are poor I will mess with the compile options and see if we can shave some more time off the times. These are WinNt 32bit console apps by the way bret bstastnX@td2cad.intel.com ------------------------------ From: Ben Morris Date: Fri, 28 Jun 1996 08:22:36 -0700 Subject: Re: Standard Brush Format FiSTY wrote: > a bsp is completly static... you cannot move anything in the bsp... > for > moving floors, doors, etc. you need to make separate entities and > associate > QuakeC code to them... yesyesyes. what he is asking is: can you rotate these separate entities? is there a Rotate_Entity() command in QuakeC? given an entity, can it be rotated? is it possible to rotate an entity? - -/- Ben Morris: Irritant at Large "the four walls entertaining me http://www.islandnet.com/~bmorris are symbols of my contentment SavanTech/Rush/C++/DCK/Zerius of mental and legal poverty" - ime ------------------------------ From: Matthew Pearson Date: Fri, 28 Jun 1996 16:37:02 -0000 Subject: RE: Compiled Source - ------ =_NextPart_000_01BB6510.0AB92AD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm game... got all speeds of pentiums with all OSs... let me know.. - ---------- From: bstastnX@td2cad.intel.com Sent: Friday, June 28, 1996 5:58 PM To: quake-dev@gamers.org Subject: Compiled Source Hi, I have a Intel Pentium optimized compiled sources to the vis/light/qbsp programs and I am looking for someone to do a simple benchmark with them. I just used the default optimize settings on the "compiler" if someone would like to do this email me dirrect, also if anyone is interested in a Intel Pentium Pro optimized complie they can email me dirrect also. If the benchmarks are poor I will mess with the compile options and see if we can shave some more time off the times. These are WinNt 32bit console apps by the way bret bstastnX@td2cad.intel.com - ------ =_NextPart_000_01BB6510.0AB92AD0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IgUQAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAIAEAAAEAAAAMAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAARwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHF1YWtlLWRldkBnYW1l cnMub3JnAFNNVFAAcXVha2UtZGV2QGdhbWVycy5vcmcAAB4AAjABAAAABQAAAFNNVFAAAAAAHgAD MAEAAAAVAAAAcXVha2UtZGV2QGdhbWVycy5vcmcAAAAAAwAVDAEAAAADAP4PBgAAAB4AATABAAAA FwAAACdxdWFrZS1kZXZAZ2FtZXJzLm9yZycAAAIBCzABAAAAGgAAAFNNVFA6UVVBS0UtREVWQEdB TUVSUy5PUkcAAAADAAA5AAAAAAsAQDoBAAAAAgH2DwEAAAAEAAAAAAAAAl80AQSAAQAUAAAAUkU6 IENvbXBpbGVkIFNvdXJjZQCvBgEFgAMADgAAAMwHBgAcABAAJQACAAUAMQEBIIADAA4AAADMBwYA HAAQACQALwAFAF0BAQmAAQAhAAAAODZEQzEzQzBFOEQwQ0YxMTgwMkIwMEFBMDBBRjg2NjMAJAcB A5AGAMAEAAAUAAAACwAjAAAAAAADACYAAAAAAAsAKQAAAAAAAwAuAAAAAAADADYAAAAAAEAAOQBA 3cAIEGW7AR4AcAABAAAAFAAAAFJFOiBDb21waWxlZCBTb3VyY2UAAgFxAAEAAAAWAAAAAbtlEAiw wBPch9DoEc+AKwCqAK+GYwAAHgAeDAEAAAADAAAATVMAAB4AHwwBAAAAFQAAAFdpbmRvd3MvSXJl bmVGL01hdHRQAAAAAAMABhDSpu9hAwAHEGQCAAAeAAgQAQAAAGUAAABJTUdBTUVHT1RBTExTUEVF RFNPRlBFTlRJVU1TV0lUSEFMTE9TU0xFVE1FS05PVy0tLS0tLS0tLS1GUk9NOkJTVEFTVE5YQFRE MkNBRElOVEVMQ09NU0VOVDpGUklEQVksSlVOAAAAAAIBCRABAAAAPAMAADgDAADrBQAATFpGdRtS +Tv/AAoBDwIVAqQD5AXrAoMAUBMDVAIAY2gKwHNldO4yBgAGwwKDMgPGBxMCgyIzD3poZWwDIERs 6mcCgzQTDX0KgAjPCdniOxefMjU1AoAKgQ2xwQtgbmcxMDMUIAsKCxLyDAFjAEAgSSdtaCBnYQeA Lh0AHLBvpwVAB0ADIHNwCeBkBCAYb2YgHdACMGl1bRMEIAPwdGgdc09TcxUdAmwSACAHgCBrbjxv dx0ACoUgzAr0bGkIMTgwAtFpLTE0njQN8AzQIxMLWTE2CqDtA2B0BZAFQC0lNwqHI+vrDDAktkYD YTomPiS2DIIYIGJzAZAqAG5YQIB0ZDJjYWQuC4DpJOBsLgWgbSXfJu0GYA8CMCgfKSsn0GlkYXkg LCBKdW4gQDI4ATAAMTk5NiA1OmA1OCBQTSuPJu1UBm8tzykrcXVha2WyLQ2wdkAcwhHgLgWwxmcx fyyedWJqJPEzn/MpKwhQbXADEAmABgAIYcxjZSE/IkMzNiO3FcLnDAEktgqFSGkwAAqFQADUSSAR wHYgQGEccCsCnzFAHnQeIAUwB3BpejthmytROzRzO6MEIHRvQ0ApFPAgdgQALyJwZ2jodC9xKfBw CoUksQnAfxzQBCAAcDtwQDAc0B/gb+RvawuAZyACEAXAQtDvB4ACICBAQ1FkQ2BAoACQPzsgH/Ap 4AnwEbAAwHJrmx7kQ4FtILZAMGp1KgAeIEpAO2FDgg2xYXVs/wVAQaYdsBIAHpAaoB4RA6DFQ4Ii QkVyIiAGkEbm9QqFdwhgbDtwInA1oEdlex8QBAAgSXALcAMgIDFk/GlyF6AlADAAB0BC0E3C/QBw eUcyUBEq8hegKgA7YfcLgAqFQK5QA2BBnSJwR1F9FPB5QjADkVBOUVMgvUn/HkBDgkhnRYEXoB5Q RkBJ8v8D8BURB4Ee1UOCQkVBkwIgb0WEEfA75k3Rd1vRA5Fz/0BTRvIgIAWwR1EHcR4hWQTvX3If oD+mCoVUFPAR8FoDilcLgE4FQDMyYh8AT0IxAIAG8ECBcHAEIGJbVlBDgncv4CDMYhegdP9k1ioP Kxw7/z0OG9U+fRbBAgBroAMAEBAAAAAAAwAREAAAAABAAAcw4P/e/w9luwFAAAgw4P/e/w9luwEe AD0AAQAAAAUAAABSRTogAAAAAAMADTT9NwAApFY= - ------ =_NextPart_000_01BB6510.0AB92AD0-- ------------------------------ From: bstastnX@td2cad.intel.com Date: Fri, 28 Jun 1996 14:38:47 -0700 Subject: RE: Compiled Source I have some special build exes, I am not sure if I used all the right options on the builds. They should be faster then the VC4.0 compiler but I have not really sat down and set up the fastest build. I just want a few people to do some benchmarking to see if they are fast enough for me to post them for all to use. So if you would just given them a run, let me know what the speed of the same level under a "standard" build was and the speed of this build that would be great and I will make sure to get you a final build. I just hope we can shave a few minutes off some of the big levels. the files are at my personal ftp account. ftp.best.com user is jbcal and the progs are in qexes directory. thanks, bret ------------------------------ From: Jonathan Mavor Date: Fri, 28 Jun 1996 20:47:44 -0700 Subject: Re: Standard Brush Format At 01:58 AM 6/28/96 -0400, you wrote: >On Thu, 27 Jun 1996, Jonathan Mavor wrote: > >> At 11:25 PM 6/27/96 -0400, you wrote: >a bsp is completly static... you cannot move anything in the bsp... for >moving floors, doors, etc. you need to make separate entities and associate >QuakeC code to them... > That's what I was talking about. Maybe I should have made my question clearer.... the question is: Can quake-c be used to make an entity rotate? The reason I ask is that I haven't seen an example of this yet in the game (that I can recall). One would need this rotation to do things like swinging doors etc. I'm sorry I came across as such a dolt ;) I know bsp's are static. Hell I wrote a game which used bsp rendering (plug www.epicgames.com/radix.htm ). L8r, Jon ------------------------------ From: Jim Lowell Date: Sat, 29 Jun 1996 09:02:23 -0500 Subject: Any specs on QuakeC? Are there any specs available for QuakeC? I'm looking for something that will let me see how the progs.dat file is organized. Thanks! - -= Jim Lowell =- ------------------------------ From: FiSTY Date: Sat, 29 Jun 1996 13:03:58 -0400 (EDT) Subject: Re: Standard Brush Format On Fri, 28 Jun 1996, Ben Morris wrote: > yesyesyes. what he is asking is: can you rotate these separate entities? > is there a Rotate_Entity() command in QuakeC? given an entity, can it be > rotated? is it possible to rotate an entity? ah ok... I would assume so, but then again I'm not id... =========================================== FiSTY fisty@yoss.canweb.net the shaker project - http://www.canweb.net/~fisty/shaker/ ------------------------------ From: Jonathan Mavor Date: Sat, 29 Jun 1996 11:06:39 -0700 Subject: Re: Standard Brush Format At 01:03 PM 6/29/96 -0400, you wrote: >On Fri, 28 Jun 1996, Ben Morris wrote: > >> yesyesyes. what he is asking is: can you rotate these separate entities? >> is there a Rotate_Entity() command in QuakeC? given an entity, can it be >> rotated? is it possible to rotate an entity? > >ah ok... I would assume so, but then again I'm not id... It's an interesting question because I didn't see any examples of this in any of the levels (although I could be wrong). If it isn't in there goes a whole bunch of cool ideas. L8r, Jon ------------------------------ From: Mackey McCandlish Date: Sat, 29 Jun 1996 15:25:28 -0400 Subject: Re: Standard Brush Format >>ah ok... I would assume so, but then again I'm not id... > > It's an interesting question because I didn't see any >examples of this in any of the levels (although I could be wrong). >If it isn't in there goes a whole bunch of cool ideas. > Around the time just before Qtest1 was released, they were discussing possibly having entire levels rotating. Of course I haven't heard of this ever happening, so it could be that rotation was dumped. Yes, you'd think there'd be SOME swinging doors in the entire shareware episode. -*Avatar*- http://faraday.clas.virginia.edu/~fsm3m A new wacky gif every day! ------------------------------ From: Jim Lowell Date: Sun, 30 Jun 1996 14:10:10 -0500 Subject: Jon's Quake Editor Webpage To help Jon with his new Quake editor, I have collected all of the things that I know about it and put together a web page. There are several screen shots as well as some detailed information about the editor's features. Feedback is encourage. I get the feeling that Jon is very willing to incorporate good suggestions into his editor. http://www.winternet.com/~jlowell/thred/ - -= Jim Lowell =- ------------------------------ From: Jarno Paananen Date: Sun, 30 Jun 1996 23:18:13 +0300 Subject: Re: Jon's Quake Editor Webpage ------------------------------ From: Derek Nickel Date: Sun, 30 Jun 1996 18:49:01 -0700 Subject: MAP file information Everybody probably already knows this, but since I couldn't find any = specific information, I had to figure it out for myself. Therefore, I = thought I'd pass on what I found. If this information is available = elsewhere, then please let me know... (1) a point (x,y,z) is represented by ( x y z ) in the MAP file. (2) Spaces are required around all tokens, i.e., the "(", x, y, z, and = ")". (3) x is east, y is north, and z is up. (4) angles are in degrees, counterclockwise, with zero pointing east. (5) a plane definition in a MAP file is composed of: { ( x1 y1 z1 ) ( x2 y2 z2 ) ( x3 y3 z3 ) texname shift_s shift_t rotate = scale_s scale_t } (6) each square of the pink checkerboard is 8 units wide. The three points determine a plane. The points do not have to be = vertices of the larger brush. The texname is the name of the texture in = the WAD file to apply to this plane (both sides?) I think (s,t) are = texture space coordinates; how much to shift, rotate and scale the = applied texture. So far, (3) is what really tripped me up. Luckily (for me, at least), = johnc99.map was not a cube :-) I looks to me that creating maps for Quake will be easier that for DOOM. = It was too easy to trash a DOOM level (maybe I just didn't get enough = practice...) My MAP editor is Cartographer - it's dreamware, yet to upgraded to = vaporware... Derek Nickel dnickel@ccnet.com ------------------------------ From: Bernd Kreimeier Date: Mon, 1 Jul 1996 08:21:29 +0200 (MET DST) Subject: Info from John Carmack (13) - ----- Begin Included Message ----- >From johnc@idcanon1.idsoftware.com Sat Jun 29 22:13 MET 1996 You wrote: > Q: is there a chance to see the qlumpy sources as well? With > respect to mipmap generation from patches, for TC projects and > WAD2MAP conversion. Sure, I just need to get around to it. > Q: while we are already being greedy - somebody asked for the > Alias2MDL conversion. Related: no sources released so far deal with > MDL stuff. Any objections against distributing MDL related > descriptions or sources? Again, no problem. > Q: MDL skins are not mipmapped - necessity, convenience? Is it > worth the trouble? Is the triangle texture mapper less accurate > then the world's? The polygon objects seem to "stick out" at times. It probably would have been good to mipmap them. The triangle renderer IS less acurate -- integral pixel / texel, just like a sony playstation. Very fast, though. > Q: minor: would a bilinear filtering on the sky textures during > setup for 800x600+ hires be worth the quality increase? The most obvious flaw with the sky is that the parallax is integralized. I think adding bilerping before fixing that would be unwarranted. > > Q: some time ago I suggested see-through markers to indicate a > direction towards an obscured target/opponent. You pointed out that > this will destroy the illusion of a rock solid world and therefore > immersion. > > I agree that people who think visor-plane embedded augmented > reality HUD's perfectly natural are possibly a minority.. read: you > are probably right :-). > > However, I fail to understand the reasoning behind e.g. the status > bar, which is even worse for immersion. There are other solutions > (non-HUD as well), some of them already used (auditory clues, pain > reddening etc.). I was refering to a specific optical illusion that occurs when an object is properly positioned in 3d, but is misoccluded. This is distinct from simple floating text or status bars, which have no 3d positioning at all. > > Q: another design question: you did avoid partly random placement > of objects intentionally? I see some drawbacks for detailed level > design, but not unsolveable. The worlds are too complex for pure random placement. If you are concerned about just the predictability aspect, it would be easy to create fractional monsters that only spawn, say 25% of the time, so you have a huge diversity in the way the level turns out. It is an open question if that diversity is actually a good thing, though. After a player has beaten the game, sure, they would like the diversity, but for a normal player trying to work through the game, part of the sense of accomplishment is the learning of the layout. > > Just to confirm: what I presumed a now unused test map (test1.map, > aka dm1.map) is the DeathMatch1 of the registered release? Yes. There are six dm levels in registered. The three from qtest, and three new ones. American has been working on an extra one, but it will probably just be released as a free game for registered users. John Carmack - ----- End Included Message ----- ------------------------------ From: Bernd Kreimeier Date: Mon, 1 Jul 1996 10:48:08 +0200 (MET DST) Subject: Rotation of BSP objects/worlds > From: Mackey McCandlish > Around the time just before Qtest1 was released, they were discussing > possibly having entire levels rotating. Of course I haven't heard of this ever > happening, so it could be that rotation was dumped. Yes, you'd think there'd be > SOME swinging doors in the entire shareware episode. To my understanding, BSP files for BSP objects are still identical to those used with the world (entity 0). Thus my comments on NAT's in my early pages and in the Primer should still apply here: texture alignment in Quake depends on position and orientation within the world. This means that an entire level rotating requires correcting all texture offsets and scales, and even rotations, for each frame. This does not work. The alternative, i.e. (x,y,z,s,t) vertices would allow for arbitrary movements. The problem is as well present for BSP objects like doors moving within the level. As BSP objects are subject to the same rendering pipeline as the world, they are using NAT's as well. Moving a door along the major axes [sic :] requires correcting s_ofs or t_ofs. Moving a door along a sloped line requires the same, but on both offsets at once. Doable, but has not been part of qtest1, IIRC. Now consider a rotating door: as long as the axial orientation is the same, you have to adjust the s_scale and t_scale to compensate the inevitable NAT distortion. You have to calculate a rot attribute as well (easy if your axis of rotation is perpendicular to a surface, but not as easy else). This is a 90% of a pain already. As soon as the axial orientation of the surfaces flips, the texture coordinates derived from the world coordinates are completely unrelated to the previous ones. In this case, you are up for a major correction of the texture coordinates. If you look at the Infos 2,7,9 from John Carmack, you will find that this drawback of NAT's has been discussed already. Ceterum censeo: NAT's are a texture alignment mode feature for each wannabe-editor. They should not be part of the renderer. I am still hoping that the Fix will make it into Quake 2. b. P.S.: if the topic of a thread changed significantly, please take the time to change the Subject. This has been "Standard Brush Format". ------------------------------ From: Jonathan Mavor Date: Mon, 1 Jul 1996 08:46:46 -0700 Subject: Re: Rotation of BSP objects/worlds At 10:48 AM 7/1/96 +0200, you wrote: > >> From: Mackey McCandlish > > >As soon as the axial orientation of the surfaces flips, the texture >coordinates derived from the world coordinates are completely unrelated >to the previous ones. In this case, you are up for a major correction >of the texture coordinates. Damn your right... I wasn't thinking. How about a 1x1 pixel texture, that should work ;) Let's petition id to fix it. L8r, Jon ------------------------------ From: stokfam@wisdom.psinet.net.au (Michael Stokes) Date: Tue, 2 Jul 1996 19:06:19 +0800 Subject: DOOM to QUAKE Conversion Report I'd just like to report that I have full doom/doom II to quake geometric conversion working. I just played MAP30 of DOOM II in quake...FUN!! The entire set of floors/walls are converted correctly, and weapons/ammo/monsters are replaced by the closest matching quake object. Textures are in however they are not corrected for the natural orientation problem (NAT) yet. I assume from previous postings however that it is illegal to distribute such a program because Quake Addons must only work with the registered version of the game. The program is called QUAKEDM. Mike. =============================================== Michael J Stokes http://www.psinet.net.au/~stokfam =============================================== ------------------------------ From: Bernd Kreimeier Date: Tue, 2 Jul 1996 12:03:09 +0200 (MET DST) Subject: Info from John Carmack (13a) Here's one out of turn - additional tool sources released, and some insights on rotating objects - btw., are weapons and keys BSP objects, or MDL's? b. - ----- Begin Included Messages ----- >From johnc@idcanon1.idsoftware.com Tue Jul 2 09:12 MET 1996 The misc utilities (graphics, model, sprite grabbing, etc) source is now up on ftp.idsoftware.com. I still have to get the qcc code and .qc source up, but I think I am going to wait until the registered CD actually starts rolling out of the pressing houses, so I catch any last minute prog changes. John Carmack >From johnc@idcanon1.idsoftware.com Mon Jul 1 17:13 MET 1996 From: John Carmack Date: Mon, 1 Jul 96 10:11:48 -0500 To: Bernd Kreimeier You wrote: > Q: the list got some traffic on idle speculation whether entities > (BSP objects like doors) could be rotated. Is this a problem > because of NAT's? I presume that BSP object textures are rendered > with corrected offsets during axial movement, but rotation would > require rot and/or scale (to correct NAT distortions on diagonals). > Is rotation of a BSP model implemented? Movements along slopes? Rotation of BSP models works for drawing, but you do not movement clip against them properly. That was an on again - off again feature during quake's development. It was in at the beginning, but one of the major rewrites of the movement code lost it. One other issue is that all of the inline models (ones that are part of the map) have their origin at 0,0,0, so when they rotate, they fly way out of the world. If you want a spinning brush model, it needs to be a seperate map, like the health / ammo boxes. I will make that right sometime along the road to Quake 2. > Q: it seems that dynamic lighting does not take into account the > direction of the normal of the surface with respect of the > lightsource. Example is the "finished" view of e1m6 - the lava > balls in the adjacent room induce "searchlights" on the wall that > faces away from the lava. Would this check bog down performance? It > might as well be a possible gain. I did that on purpose, but I am considering changing it just so I can stop answering this question :-) Sure, just checking the normal is easy, and we have debated if that is a good idea. The issue is that if you have a light on the other side of a wall near the floor, the light shows up currently on both the floor and the wall, giving a continuous surface of light. If it was turned off on the wall by checking its facing direction, then only the light on the floor would remain, in a two dimensional bleed. Removing it from the floor is not trivial, requiring proper shadow calculations that Quake isn't set up to handle (and dynamic light allready are a big enough speed hit). I thought that keeping the light 3d and continuous was better than having it act based on surface normals. They are both wrong, so it is just a judgement call... John Carmack - ----- End Included Message ----- ------------------------------ End of quake-dev-digest V1 #20 ****************************** From owner-quake-dev-digest@gamers.org Thu Jul 4 11:32 MET 1996 Received: from gamers.org (thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id LAA16685 for ; Thu, 4 Jul 1996 11:10:18 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id FAA23028 for quake-dev-digest-outgoing; Thu, 4 Jul 1996 05:06:21 -0400 From: owner-quake-dev-digest@gamers.org Date: Thu, 4 Jul 1996 05:06:21 -0400 Message-Id: <199607040906.FAA23028@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #21 Reply-To: quake-dev@gamers.org Errors-To: owner-quake-dev-digest@gamers.org Precedence: bulk X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 23544 X-Lines: 688 Status: RO quake-dev-digest Thursday, 4 July 1996 Volume 01 : Number 021 ---------------------------------------------------------------------- From: "Brian K. Martin" Date: Tue, 2 Jul 1996 09:46:15 -0400 (EDT) Subject: rotating objects > > > Here's one out of turn - additional tool sources released, and > some insights on rotating objects - btw., are weapons and keys > BSP objects, or MDL's? > > rotating things are mdl. (armor, keys, etc..) ------------------------------ From: FiSTY Date: Tue, 2 Jul 1996 14:48:29 -0400 (EDT) Subject: .map Algorithms a couple weeks ago, I posted here about a page I started regarding .map Algorithms, in particular, how to convert from planes into vertices, etc. Well shortly afterwords, the pages got moved around and some may have not been able to find it... so here it is again... http://www.canweb.net/~fisty/algorithms/ And just recently, John Carmack's algorithms was posted... ...Fisty =========================================== FiSTY fisty@yoss.canweb.net the shaker project - http://www.canweb.net/~fisty/shaker/ ------------------------------ From: Jonathan Mavor Date: Tue, 2 Jul 1996 12:51:56 -0700 Subject: Re: .map Algorithms At 02:48 PM 7/2/96 -0400, you wrote: >a couple weeks ago, I posted here about a page I started regarding .map >Algorithms, in particular, how to convert from planes into vertices, etc. >Well shortly afterwords, the pages got moved around and some may have not >been able to find it... so here it is again... > >http://www.canweb.net/~fisty/algorithms/ > >And just recently, John Carmack's algorithms was posted... I took a look at it but there wasn't anything there I didn't already know when I looked. The Carmack algorithm was already in the QuakeEd source in code form. I figure out a bit less of a pain in the ass way to break up the stuff. It's not super efficient and it's kind of a lazy mans way out but it should work. L8r, Jon ------------------------------ From: Jim Lowell Date: Tue, 02 Jul 1996 17:21:54 -0500 Subject: Clarification (from Id this time) After reading this on the list last week: >Perhaps I am already infected with this disease of being >unable to set the record straight.... > > id Software has designed and uses a mechanism to > restrict the actual number of maps that work with > the shareware. > > They presume it works. > > Anything else is OFF topic. > >Rest assured that (a) they prolly know what they are doing, >(b) they will let us know if they need us to worry about >this, (c) further futile discussion on this list will result >in cancelled subscriptions. > >If you think you found a flaw in their concept, consider it >a bug and send a report to support@idsoftware.com. Thanks. I decided to take the advice at the end of the message and asked Shawn Green what the deal was. Here's the message: >>Hi Shawn, >> >>I'm helping Jon Mavor (a friend of mine) out with a Quake editor that he's >>writing. We're both on the Quake Dev list and there's been a lot of >>discussion over releasing editors that work with the shareware version of >>Quake. My understanding is that Id doesn't want 3rd party levels to work >>with the shareware version of Quake. > >Not only that, but I'm pretty sure we've made it illegal to do so. > >>Right now, Jon can create a level from >>scratch and load it into Shareware Quake no problem. Instant conflict, right? > >Instant. > >>1) I read this piece of e-mail that Jay had sent to someone: >> >>>1. user-developed/user-modified maps & utilities can only work with the >>>registered version. (Just to be clear here...user-developed/user-modified >>>maps & utilities cannot work with the shareware version of Quake.) >> >>Since Jon can already do this, I assume that Jay means that editors >>shouldn't work with the shareware Quake. Is this right? > >Right. > >>2) Does Id have any method for making a level *not* work with shareware >>Quake, but still work with the registered version? If so, Jon could build it >>into his editor. > >Give it a episode # > 1. Just like DOOM. So the piece of information that should be gleened from this lengthy message is: "Quake map editors should only be able to write maps with episodes greater than one otherwise the Shareware version of Quake will be able to load them." - -= Jim Lowell =- ------------------------------ From: bstastnX@td2cad.intel.com Date: Tue, 2 Jul 1996 13:54:00 -0700 Subject: Qbsp/vis/light running times Hello all, For what it is worth I have a few compiled executables that are not compiled with Visual C++, but instead with a optimizing compiler. Vis seems to run about 10% faster then the VC build and I figure that people will want to make levels on their home computers, so 10% could add up to a few hours. Here are the results Qbsp Vis Light ========================== VC4.0 78.0 208.0 35.0 P166 New 73.0 186.0 33.0 P166 New 63.0(?) 99.0 21.0 PP200* * this one crashed on reading the texutres. They were all run on Dm1.map, Dm1.bsp. There are two seperate builds one for the Intel Pentium and one for the Intel Pentuim Pro. They are located at: ftp.best.com/pub/j/jbcal/qexes ftp.best.com/pub/j/jbcal/qexes/pro I will most likely keep them there for a few days and then remove them. If anyone would like to make home for them that would be nice, just let me know and I will send you any new builds I make. Also thanks to: gregl@umich.edu & darksead@scn.org for running the programs for me. bret ------------------------------ From: "Drizzt Do'Urden" Date: Tue, 2 Jul 1996 21:17:26 -0700 (PDT) Subject: Re: Clarification (from Id this time) > >>2) Does Id have any method for making a level *not* work with shareware > >>Quake, but still work with the registered version? If so, Jon could build it > >>into his editor. > > > >Give it a episode # > 1. Just like DOOM. I hate to say it, but that just doesn't work. As far as I can tell, there is no protection from loading levels of any kind in the shareware. Technically, maps don't even have episodes/map numbers in them, this is clearly shown in the .map format. A map is whatever you name it. And with the "map " command, loading any level created is currently possible. I don't know what is up with id that they don't have their stuff together on this, but at the current time there is absolutly NO protection in the SW version. Assume they remove the "map" command in a future version of the shareware? Ppl will just unpack the .pak file and rename BSP's as needed. Or extract/insert new ones as needed. Unless id makes a new bsp format the is incompatible between regged/shareware, I don't see how they can stop users from loading custom maps. ------------------------------ From: Jonathan Mavor Date: Tue, 2 Jul 1996 21:56:47 -0700 Subject: Re: Clarification (from Id this time) At 09:17 PM 7/2/96 -0700, you wrote: > I don't know what is up with id that they don't have their stuff >together on this, but at the current time there is absolutly NO >protection in the SW version. Assume they remove the "map" command in a >future version of the shareware? Ppl will just unpack the .pak file and >rename BSP's as needed. Or extract/insert new ones as needed. > > Unless id makes a new bsp format the is incompatible between >regged/shareware, I don't see how they can stop users from loading custom >maps. Weird isn't it? I wish I knew what they meant... however there may be a key/value pair or entity that tells what episode the level is from... if you don't put it in it just works but if you DO put it in it won't load in the shareware... that's possible isn't it? Otherwise I don't see the point either. L8r, Jon PS anyone who hasn't checked it out go to www.winternet.com/~jlowell/thred and email me your comments. ------------------------------ From: Mackey McCandlish Date: Wed, 3 Jul 1996 01:10:14 -0400 Subject: Re: Clarification (from Id this time) > Unless id makes a new bsp format the is incompatible between >regged/shareware, I don't see how they can stop users from loading custom >maps. It's like DOOM all over again.. (you could still load pwads in the SW for a couple versions). Guess they'll fix it when addons start flowin in. -*Avatar*- http://faraday.clas.virginia.edu/~fsm3m ------------------------------ From: Bernd Kreimeier Date: Wed, 3 Jul 1996 11:39:22 +0200 (MET DST) Subject: Re: Jon's Quake Editor Webpage Jon wrote: >PS anyone who hasn't checked it out go to > www.winternet.com/~jlowell/thred >and email me your comments. Just one remark, publicly with reason: I do not like the term "concave brush". To my understanding, a brush is convex by definition. There is not way to define a non-convex solid by simply listing planes, right? A concave brush is as politely offending as an oxymoron... It is not only confusion - a concave pseudo-Brush, IMO, is the worse of two alternative solutions - the problem being, of course, that rooms are by definition made inside concave solids. The better solution is to stick to Brushes, and instead add a sophisticated hierarchy/grouping mechanism. This does not only solve the problem, but is useful for other tasks as well: - selective interactive preview - selective BSP/PVS/light creation (on a part of the level) - selective movement/rotation - Brush Set templates (rooms, stairs, etc.) A typical application would be that all Brushes spawned by a CSG operation on two Brushes (by definition almost always creating a concave solid as an intermediate) are automatically part of a set. See Info(9) by John Carmack for a discussion of hierarchy in MAP files. b. ------------------------------ From: Tom Wheeley Date: Wed, 03 Jul 96 08:13:26 GMT Subject: Clarification (from Id this time) In article you write: > > >>2) Does Id have any method for making a level *not* work with shareware > > >>Quake, but still work with the registered version? If so, Jon could build it> > >>into his editor. > > > > > >Give it a episode # > 1. Just like DOOM. > > I hate to say it, but that just doesn't work. As far as I can tell, > there is no protection from loading levels of any kind in the shareware. > Technically, maps don't even have episodes/map numbers in them, this is > clearly shown in the .map format. A map is whatever you name it. And > with the "map " command, loading any level created is currently > possible. Correct, and I've mailed id about it. Try this: . unpak just one of the map BSPs . copy it to ~/id1/maps/e4m1.bsp (normal filesystem :) . Noclip through the bars which say `register!' to get to the episode 4 s.g. (of course, this will work on 2 and 3). .splitbung - -- * TQ 1.0 * The 'Just So Quotes'. 'You know my motto: Forgive and uh... the other thing.' ------------------------------ From: stokfam@wisdom.psinet.net.au (Michael Stokes) Date: Wed, 3 Jul 1996 20:52:09 +0800 Subject: Pink Checkboard Texture? Sometimes in Quake I see a Pink Checkboard type texture. Obviously something is wrong. Does anyone know what causes Quake to do this? Mike. =============================================== Michael J Stokes http://www.psinet.net.au/~stokfam =============================================== ------------------------------ From: jschuur@onlinemagic.com Date: Wed, 3 Jul 1996 14:23:14 +0100 (BST) Subject: Re: Pink Checkboard Texture? On Wed, 3 Jul 1996, Michael Stokes wrote: > Sometimes in Quake I see a Pink Checkboard type texture. Obviously something > is wrong. > > Does anyone know what causes Quake to do this? it appears to be the default fill in texture quake uses when the texture refered isn't available in the .bsp file. i had this when recompiling dm1.map with a texture wad assembled from sw quake .bsps how's that doom->quake level converter coming along? - -= joost schuur tel - +44 171 820 7766 =- - -= software person email - jschuur@onlinemagic.com =- - -= online magic ltd, london www - http://www.nuqneH.org/~jschuur/ =- ------------------------------ From: Jonathan Mavor Date: Wed, 3 Jul 1996 08:07:17 -0700 Subject: Re: Jon's Quake Editor Webpage At 11:39 AM 7/3/96 +0200, you wrote: >The better solution is to stick to Brushes, and instead add >a sophisticated hierarchy/grouping mechanism. This does not >only solve the problem, but is useful for other tasks as well: > In my editor a brush is a brush is a brush. It's something that you add to the world or subtract from the world (or later on intersect/deiontersect with the world). Within my editor it is totally and completely transparent. The user doesn't NEED to know whether the brush is concave/convex or a ballahallabaloo brush. > - selective interactive preview > - selective BSP/PVS/light creation (on a part of the level) > - selective movement/rotation > - Brush Set templates (rooms, stairs, etc.) > >A typical application would be that all Brushes spawned by a >CSG operation on two Brushes (by definition almost always >creating a concave solid as an intermediate) are automatically >part of a set. > I already have brush groups implemented. You can make groups and filter what you see and what gets exported to quake using the group system. When "meta-brushes" are busted up into brushes it's transparent and they do become part of the same group. As for the brush set templates that will be supported if someone else makes them. Otherwise in my editor a "meta-brush" can be created that is any of those (a room is already in there, stairs etc will be). L8r, Jon ------------------------------ From: Denis Date: Wed, 3 Jul 1996 18:18:13 +0200 Subject: Re: Clarification (from Id this time) Hi! At 21:17 02.07.1996 -0700, you wrote: >> >>2) Does Id have any method for making a level *not* work with shareware >> >>Quake, but still work with the registered version? If so, Jon could build > I hate to say it, but that just doesn't work. As far as I can tell, >there is no protection from loading levels of any kind in the shareware. Strange, hmm. The only REAL protection would be a CRC check over all available .BSP files - unpacking the file wouldn't go around it then... On the other hand - it would be damn hard for creators of level-editors (or prolly any other quake-tool) when SW Quake (at this time) would be protected. I mean, we couldn't do anything; maybe carmack left this door intentionally, ready to close it when SW & Registered Quake ships on CD (I bet version 1.0 or above). I remember Carmack talking about CRC checks... oh well. Let's end this conversation now. cya Denis - --- Denis Moeller, author of NWTpro, quip and TiC's WAD Reviews. e-mail: d.moeller@rendsburg.netsurf.de, #irc: panza http://www.geocities.com/Hollywood/2299/ ------------------------------ From: stokfam@wisdom.psinet.net.au (Michael Stokes) Date: Thu, 4 Jul 1996 01:25:20 +0800 Subject: Naturally Aligned Textures Hello, Is there any information around about the way Quake uses naturally aligned textures? I have not been able to find any. All I need is a simple algorithm to find the texture coordinates for the upper left hand corner of a polygon. Mike. =============================================== Michael J Stokes http://www.psinet.net.au/~stokfam =============================================== ------------------------------ From: Brooks Talley Date: Wed, 3 Jul 1996 11:46:32 -0700 (PDT) Subject: QuakeEd 1.2? So I finally get a couple of NeXT boxes running (one native, one Pentium), and a killer quad P6 NT box I can rsh to for bsp and vis, and now I can't find that patched QuakeEd. Should I just use the one id released, or can someone point me to the fixed-up one? Thanks, aiken ------------------------------ From: "Ryan Drake" Date: Wed, 3 Jul 1996 15:01:21 -0400 Subject: Re: Jon's Quake Editor Webpage > In my editor a brush is a brush is a brush. It's something > that you add to the world or subtract from the world (or later > on intersect/deiontersect with the world). Within my editor > it is totally and completely transparent. The user doesn't NEED > to know whether the brush is concave/convex or a ballahallabaloo brush. But there is no such thing as a "concave brush." The two words contradict each other. Try to draw a square with three edges. You can't because a square is defined as having four edges. Same with brushes: A brush is and will always be convex. It would only confuse the user to allow him/her to make concave objects and call them brushes. - -- +------------------------------------------------------------------- - ----+ | Ryan Drake Sanity is the trademark of a weak mind. | | stiletto@psu.edu -- Mark Harrold | | http://www.crayola.cse.psu.edu/~drake/home.html | +------------------------------------------------------------------- - ----+ ------------------------------ From: Jonathan Mavor Date: Wed, 3 Jul 1996 15:04:28 -0700 Subject: Re: Jon's Quake Editor Webpage At 03:01 PM 7/3/96 -0400, you wrote: >But there is no such thing as a "concave brush." The two words >contradict each other. Try to draw a square with three edges. You >can't because a square is defined as having four edges. Same with >brushes: A brush is and will always be convex. > Why do you say that? Too me a brush is just a CSG object. CSG objects can be ANY size, shape whatever as long as they are a piece of solid material. Anyway I'm going to call my brushes "meta-brushes" so you know what I'm talking about. L8r, Jon >It would only confuse the user to allow him/her to make concave >objects >and call them brushes. I don't see why. It's going to be consistent within my editor. L8r, Jon ------------------------------ From: Bernd Kreimeier Date: Thu, 4 Jul 1996 10:54:04 +0200 (MET DST) Subject: Re: Jon's Quake Editor Webpage >>> A brush is a brush is a rose is a brush > >But there is no such thing as a "concave brush." The two words > >contradict each other. A brush is and will always be convex. > > > Why do you say that? Too me a brush is just a CSG object. > CSG objects can be ANY size, shape whatever as long as they are a piece > of solid material. As I have started this discussion, perhaps I could try to settle it. John Carmack defined the Brush as a convex polyhedron (a polytope). Originally, a Brush was an entry in the MAP files, and qbsp expects Brushes to be polytopes. However, "brush" is a very graphic [sic :] term - perfectly suited to communicate the idea of a solid with a texture pasted onto the surface of some space. Thus I understand Jon's point. The problem is that we end up with a Brush having different meanings during qbsp processing as opposed to editing. This will cause confusion. Being paranoid does not mean they aren't out to get you. > >It would only confuse the user to allow him/her to make concave > >objects > >and call them brushes. > > I don't see why. It's going to be consistent within > my editor. I admire your willingness to make sure there won't be mistakes - this is a lot of work within your editor's guts, and in the brains of its users. Let me quote from the THRED page Jim Lowell has written: >so if I misunderstood what he explained to >me and have it wrong here, let me know so I can fix it! >Quake uses all convex brushes. In a convex brush the surfaces that >make up the outside of the brush do not intersect any other surfaces >of the same brush. This means that the brushes are always solid. A >brush that does have surfaces that cross other surfaces of the same >brush is a concave brush. I do not understand this. A polytope can be defined listing intersecting planes - no ambiguity. A concave polyhedron cannot be defined this way (its convex hull could). But no polyhedron will ever have surfaces (faces, facets) intersecting. I admit that a definition of polyhedra is difficult (see O'Rourke, Computational Geometry, chapter 4), but I do not understand the definition given above. This is important. Using brushes==polytopes, you only intersect brushes, but you do not have to check the brush intersecting itself. Using boundary representations of polyhedra (even concave), you will have to check for self-intersection, or your BRep will be wrong. >A concave brush can define a hollow area, unlike a convex brush. This >means that you can create one brush that is a hollow tube, or a whole >room (it would be a hollow cube), or a hollow sphere. This I understand. Just like a concave polygon might have a hole, a concave polyhedron might be hollow. >You could, for example, create a brush that was a room, then to use >it you would just add it to the world, tell the editor how thick to >make the walls; how tall, wide, & long to make the room, and >the editor could create it for you! (in fact, this particular example >will be built into the editor) With convex brushes, you would have to >add 6 brushes (floor, ceiling, and 4 walls), then rotate & arrange >them to form the walls of the room. This is, a Jon calls it, simply a meta-Brush operation. It could be completely transparent whether the editor internally uses a group of Brushes, or a concave polyhedron to represent the meta-Brush. Jon wrote: > Anyway I'm going to call my brushes "meta-brushes" > so you know what I'm talking about. That will hopefully put the matter at rest - and, btw., I like "meta-Brush" a lot better than group or set. Or is there any difference between a gropup/set/selection of Brushes and your meta-Brushes? Connectedness? In that case I will coin the term RoseBrush. I dare ya! b. ------------------------------ From: Bernd Kreimeier Date: Thu, 4 Jul 1996 10:56:36 +0200 (MET DST) Subject: Re: Naturally Aligned Textures > explanation of NAT's The Quake Editing Primer in the QDP section on http://www.gamers.org/dEngine/quake/#QDP, and the UQS at http://www.gamers.org/dEngine/quake/#UQS. Never write an URL from memory, by hand.... Btw., I wonder if my site is that bad organized... please send private e-mail in case of problems or suggestions, what good is all the info if nobody actually reads it. b. ------------------------------ End of quake-dev-digest V1 #21 ****************************** From owner-quake-dev-digest@gamers.org Fri Jul 5 18:07 MET 1996 Received: from olymp.informatik.uni-bonn.de (root@olymp.informatik.uni-bonn.de [131.220.4.1]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id SAA22949 for ; Fri, 5 Jul 1996 18:07:31 +0200 (MET DST) Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with ESMTP id SAA23342; Fri, 5 Jul 1996 18:01:30 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id LAA00665 for quake-dev-digest-outgoing; Fri, 5 Jul 1996 11:45:30 -0400 From: owner-quake-dev-digest@gamers.org Date: Fri, 5 Jul 1996 11:45:30 -0400 Message-Id: <199607051545.LAA00665@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #22 Reply-To: quake-dev@gamers.org Errors-To: owner-quake-dev-digest@gamers.org Precedence: bulk X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 27880 X-Lines: 666 Status: RO quake-dev-digest Friday, 5 July 1996 Volume 01 : Number 022 ---------------------------------------------------------------------- From: Bernd Kreimeier Date: Thu, 4 Jul 1996 10:57:51 +0200 (MET DST) Subject: Re: QuakeEd 1.2? > sources http://www.gamers.org/dEngine/archive/, or simply the archive link on the main page. I should probably add an icon/link for this on every subpage. b. ------------------------------ From: Bernd Kreimeier Date: Thu, 4 Jul 1996 14:39:29 +0200 (MET DST) Subject: qbsp I did some work with the qbsp sources. Here are a few insights: - compiling as C++ with gcc-2.7.2 created a binary of approx. 30 MB with linux and Solaris 2.5, because of global arrays. Fix: use -fconserve-space, shrinks to 100K or less - this means that the same 30 MB are resident memory. This will swap a lot on machines with less than at least 32 MB memory. Fix: dynamic or pool allocation and garbage collection might decrease this. - at least two constructs get warnings about cast related alignment problems during Solaris compile: tjunc.c:superface and bspfile.c:dtexmap. This might be a suspect with respect to the bus errors on Solaris. Fix: do not use byte arrays. - qbsp does not do any mipmap processing besides adding them, IIRC. This task could be completely separated, removing the mipmap lump buffer memory requirements from the program entirely (and the related source). Remarks: pool allocation might require hash tables to get pointers for indices, haven't looked to closely. Replacing the byte arrays took me using derived structs (classes) and casting to base class pointer. I think that, in the long run, qbsp should only add a dummy mipmap and the mipmap names. A separate utility should add the mipmaps from a WAD2. For dm1.map, mipmaps seem to be about half of the final BSP file, and are easily added afterwards - as has been discussed on this list extensively. Finally, the Solaris 2.5 binary produces a different BSP file, the difference occuring during the passes to merge faces. I have no clue why this happens. I will have to check if the BSP file actually works (now where's that Linux quake...). No further Solaris work in any case, as far as I am concerned. Is anybody else currently working with the qbsp sources? Any comments? b. ------------------------------ From: Jim Lowell Date: Thu, 04 Jul 1996 08:13:48 -0500 Subject: Re: Jon's Quake Editor Webpage At 10:54 AM 7/4/96 +0200, you wrote: > >I admire your willingness to make sure there won't be mistakes - this >is a lot of work within your editor's guts, and in the brains of its >users. Let me quote from the THRED page Jim Lowell has written: > >>so if I misunderstood what he explained to >>me and have it wrong here, let me know so I can fix it! > >>Quake uses all convex brushes. In a convex brush the surfaces that >>make up the outside of the brush do not intersect any other surfaces >>of the same brush. This means that the brushes are always solid. A >>brush that does have surfaces that cross other surfaces of the same >>brush is a concave brush. > >I do not understand this. A polytope can be defined listing intersecting >planes - no ambiguity. A concave polyhedron cannot be defined this >way (its convex hull could). But no polyhedron will ever have >surfaces (faces, facets) intersecting. I admit that a definition of >polyhedra is difficult (see O'Rourke, Computational Geometry, chapter 4), >but I do not understand the definition given above. The reason I included that section was because I didn't understand brushes myself (and still don't to a large extent), and I thought that a lot of other people probably didn't either. What I was is a VERY SIMPLE explanation of brushes, and the difference between a concave brush and a convex brush. I don't want to use anything that sounds like "A polytope can be defined listing intersecting planes - no ambiguity." As simple as this may seem to many of you, it's over my head (and therefore other people's heads) and therefore meaningless. If anyone is interested, I would very much appreciate an accurate, simple, straightforward paragraph or two that describes brushes. I would copy this right onto the page if it was clean enough. :) Thanks! - -= Jim Lowell =- ------------------------------ From: jelson@conline.com (Jim Elson) Date: Thu, 04 Jul 1996 18:44:33 -0500 Subject: Re: Jon's Quake Editor Webpage At 08:13 AM 7/4/96 -0500, Jim Lowell wrote: >The reason I included that section was because I didn't understand brushes >myself (and still don't to a large extent), and I thought that a lot of >other people probably didn't either. What I was is a VERY SIMPLE explanation >of brushes, and the difference between a concave brush and a convex brush. I >don't want to use anything that sounds like "A polytope can be defined >listing intersecting planes - no ambiguity." As simple as this may seem to >many of you, it's over my head (and therefore other people's heads) and >therefore meaningless. Well, I too have been reading this list for a while wondering when enough will be said that I understand what is meant by a "brush" (About like reading science journals outside one's field of expertise, sooner or later the meaning of a tech term will become clear.) Although the discussion of a "brush" on the THRED page doesn't pass full technical muster, it did an excellent job of giving me a better grasp of "brushes". (Heh, as soon as I saw the illustration, I was immediately reminded of the time I worked with 3D CAD programs: it became intuitively obvious.) Jim is quite right that most ppl will need a simplified explanation of brushes that's also technically correct. (Exactly similar to dissertation defenses when you have to explain your reasoning to a professor from school outside your own or in thesis defenses when you are asked to explain your thesis to a hypothetical newspaper/magazine reporter.) - --H2H ============================================================================ Memeber of Team TNT, makers of Final Doom Other Doom projects: H2HMudFE, H2H-Xmas, and other way kewl stuff - ---------------------------------------------------------------------------- jelson@conline.com ; http://www.conline.com/~jelson/ ; H2H on #quake (IRC) ------------------------------ From: Jonathan Mavor Date: Thu, 4 Jul 1996 08:32:02 -0700 Subject: Re: Jon's Quake Editor Webpage At 10:54 AM 7/4/96 +0200, you wrote: > > >John Carmack defined the Brush as a convex polyhedron (a polytope). >Originally, a Brush was an entry in the MAP files, and qbsp expects >Brushes to be polytopes. > >However, "brush" is a very graphic [sic :] term - perfectly suited >to communicate the idea of a solid with a texture pasted onto the >surface of some space. Thus I understand Jon's point. > >The problem is that we end up with a Brush having different meanings >during qbsp processing as opposed to editing. This will cause >confusion. Being paranoid does not mean they aren't out to get you. > It shoudn't cause confusion though because why would the user ever look at the .MAP file? If they are using my editor they consider a brush to a solid thing. When they save to .MAP they have no idea it's being busted up into convex regions. See? >>Quake uses all convex brushes. In a convex brush the surfaces that >>make up the outside of the brush do not intersect any other surfaces >>of the same brush. This means that the brushes are always solid. A >>brush that does have surfaces that cross other surfaces of the same >>brush is a concave brush. > >I do not understand this. A polytope can be defined listing intersecting >planes - no ambiguity. A concave polyhedron cannot be defined this >way (its convex hull could). But no polyhedron will ever have >surfaces (faces, facets) intersecting. I admit that a definition of >polyhedra is difficult (see O'Rourke, Computational Geometry, chapter 4), >but I do not understand the definition given above. > I tried to get him to change that. Basically what I meant is that no PLANE of any POLYGON will intersect any other POLYGON in the brush in a concave brush (when it's in polygon form). Just like in a convex polygon no edge will intersect any other edge. >> Anyway I'm going to call my brushes "meta-brushes" >> so you know what I'm talking about. > >That will hopefully put the matter at rest - and, btw., I like >"meta-Brush" a lot better than group or set. Or is there any difference >between a gropup/set/selection of Brushes and your meta-Brushes? >Connectedness? Yes. Within the editor a "meta-brush" looks just like a brush. It's not broken up into convex regions. For a hollow cube it would be 16 points and 12 polygons. A group is a selection of brushes. I'm going to allow groups to be children of other groups later on too, so that you can build a hierarchy. L8r, Jon ------------------------------ From: Robert Dean Rudeseal Date: Thu, 04 Jul 1996 13:29:03 -0600 Subject: Re: quake-dev-digest V1 #21 >From: FiSTY >Date: Tue, 2 Jul 1996 14:48:29 -0400 (EDT) >Subject: .map Algorithms > >a couple weeks ago, I posted here about a page I started regarding .map >Algorithms, in particular, how to convert from planes into vertices, etc. >Well shortly afterwords, the pages got moved around and some may have not >been able to find it... so here it is again... > >http://www.canweb.net/~fisty/algorithms/ > >And just recently, John Carmack's algorithms was posted... > >...Fisty No offense, but your page as it stands now is basically worthless, none of the links go anywhere......when will you be completing it??? - --------------------------------------------------------------- Robert Dean Rudeseal Rudeseal@Seal-Industries.com HTTP://www.hemi.com/~rudeseal WebPage Development and Broadcast Services Quake has changed the Doom phrase of "If it moves Shoot it. If it doesn't move, Shoot it until it does" To: "This phrase will be released in 'Two Weeks'" ------------------------------ From: Bernd Kreimeier Date: Thu, 4 Jul 1996 16:51:41 +0200 (MET DST) Subject: Re: Jon's Quake Editor Webpage Jim Lowell lazily wrote: >> [excessive quote deleted] > >If anyone is interested, I would very much appreciate an accurate, simple, >straightforward paragraph or two that describes brushes. I would copy this >right onto the page if it was clean enough. :) Being greedy, aren't we? There might not be such a thing - simplicity and accuracy might well be mutually exclusive in this case. Hmmm, I'll have to tackle this for the Primer anyway, so let's see how close I can get. A Brush is a solid volume, a body wrapped into by some flat surfaces that define its skin - the border between "inside" and "outside". The surfaces are called polygons or faces. There have to be at least four such faces (triangles defining a tetrahedron), but there might be six (squares defining a cube), or any number >= 4 for different shapes. Thus each brush is what we call a polyhedron. But is each polyedron a brush? Take any two points on the surfaces of the brush or inside the brush. The line connecting them has to be entirely inside the brush, and cannot intersect any surface (except start and end point). This means a brush is convex. In other words, it does not have any holes or dents. A sphere (e.g. represented by lots of triangles) is convex. A tire is not, it has a hole. A bowl is not, it has a dent. You will easily find lines starting and ending inside the solid body, but being partly outside. In consequence, you cannot represent a tire or a bowl with a single brush. Moreover, the faces of a brush are always convex polygons. A convex polygon is described by the same idea in 2D: take any two points inside the polygon, or on the edges, and the line connecting them will be completely inside the polygon. As the faces of concave polyhedra might be concave polygons, I use the word "facets" to describe the faces of a brush. Btw., the classic diamond cut could be represented by a brush as well. How do we actually make a tire, a doughnut, a bowl, a key, a cup? We have to use multiple brushes right away, and glue them together, or we use a concave polyhedron, and have to break it up into brushes later... Why did I say "skin"? A brush is a fake. It looks solid to us, but Quake does not know anything about what's supposed to be inside, and will simply do its best to keep the viewer on the outside. A computer handles brushes by handling the data describing the skin: vertices, edges, faces. This is called a boundary representation. Now if you think about it, you will easily recognize why faces cannot intersect - that is, why even a concave polyhedron cannot self-intersect. Could you say Klein's Bottle? Five paragraphs, and miles to go. Why do people always think there has to be a simple answer? Now I would like to see *your* attempt :-). b. P.S.: the above description is not accurate, btw. - there are convex polyhedra with concave faces. I am sure there are more flaws. P.P.S.: "skin" is intentional. Once you got brush editing, you could create MDL models as well (except that an MDL does not have to be a valid boundary representation, IIRC). You will have to triangulate polygons following all the CSG stuff. The problem is doing frame animation - inverse kinematics moving brushes? ------------------------------ From: Bernd Kreimeier Date: Fri, 5 Jul 1996 11:46:05 +0200 (MET DST) Subject: Re: Jon's Quake Editor Webpage [ this posting got lost yesterday on delivery - if it's sibling should return from whatever place lost mails go, my apologies for the duplicate ] Jim Lowell lazily wrote: >> [excessive quote deleted] > >If anyone is interested, I would very much appreciate an accurate, simple, >straightforward paragraph or two that describes brushes. I would copy this >right onto the page if it was clean enough. :) Being greedy, aren't we? There might not be such a thing - simplicity and accuracy might well be mutually exclusive in this case. Hmmm, I'll have to tackle this for the Primer anyway, so let's see how close I can get. A Brush is a solid volume, a body wrapped into by some flat surfaces that define its skin - the border between "inside" and "outside". The surfaces are called polygons or faces. There have to be at least four such faces (triangles defining a tetrahedron), but there might be six (squares defining a cube), or any number >= 4 for different shapes. Thus each brush is what we call a polyhedron. But is each polyedron a brush? Take any two points on the surfaces of the brush or inside the brush. The line connecting them has to be entirely inside the brush, and cannot intersect any surface (except start and end point). This means a brush is convex. In other words, it does not have any holes or dents. A sphere (e.g. represented by lots of triangles) is convex. A tire is not, it has a hole. A bowl is not, it has a dent. You will easily find lines starting and ending inside the solid body, but being partly outside. In consequence, you cannot represent a tire or a bowl with a single brush. Moreover, the faces of a brush are always convex polygons. A convex polygon is described by the same idea in 2D: take any two points inside the polygon, or on the edges, and the line connecting them will be completely inside the polygon. As the faces of concave polyhedra might be concave polygons, I use the word "facets" to describe the faces of a brush. Btw., the classic diamond cut could be represented by a brush as well. How do we actually make a tire, a doughnut, a bowl, a key, a cup? We have to use multiple brushes right away, and glue them together, or we use a concave polyhedron, and have to break it up into brushes later... Why did I say "skin"? A brush is a fake. It looks solid to us, but Quake does not know anything about what's supposed to be inside, and will simply do its best to keep the viewer on the outside. A computer handles brushes by handling the data describing the skin: vertices, edges, faces. This is called a boundary representation. Now if you think about it, you will easily recognize why faces cannot intersect - that is, why even a concave polyhedron cannot self-intersect. Could you say Klein's Bottle? Five paragraphs, and miles to go. Why do people always think there has to be a simple answer? Now I would like to see *your* attempt :-). b. P.S.: the above description is not accurate, btw. - there are convex polyhedra with concave faces. I am sure there are more flaws. P.P.S.: "skin" is intentional. Once you got brush editing, you could create MDL models as well (except that an MDL does not have to be a valid boundary representation, IIRC). You will have to triangulate polygons following all the CSG stuff. The problem is doing frame animation - inverse kinematics moving brushes? ------------------------------ From: Bernd Kreimeier Date: Fri, 5 Jul 1996 11:43:07 +0200 (MET DST) Subject: Re: Jon's Quake Editor Webpage > It shoudn't cause confusion though because why would >the user ever look at the .MAP file? When they save >to .MAP they have no idea it's being busted up into convex >regions. See? I did too much sysad work, I guess. I keep seeing users tweaking MAP files by hand, and bugs in export filters, all this creating invalid brushes now and then. Now see qbsp's reporting ..... "Invalid Brush in FOOL.MAP" or "brush plane with no normal" or "brush with duplicate plane". Let me get this straight: I do not think that efficient use of Quake editing tools, and level editing is possible without getting the concepts and the basic idea of the rendering algorithms straight. Know thy engine. If somebody wants to do levels but wants to stay ignorant with respect to concepts like "boundary representations" or "aliasing", he (and anybody answering his questions) is going to have a tough time. If you don't care about how scene geometry is related to the PVS size, your levels will be dead slow. Imagine a PVS display: a simple matrix, each cell indicating that leaf i is visible from leaf j, and color indicating the distance (blue short range, red long range). It is intuitive, it is easy feedback on PVS size and structure. But you still have to know how to get rid of the many red ones, and the adjacency display does not give you a clue what PVS is all about. > I'm going to allow groups to be children of other >groups later on too, so that you can build a hierarchy. This is one of the most important features, will be a great thing to see. b. ------------------------------ From: Stephen Crowley Date: Thu, 04 Jul 1996 12:42:44 +0000 Subject: Re: qbsp Bernd Kreimeier wrote: > I did some work with the qbsp sources. Here are a few insights: > > - compiling as C++ with gcc-2.7.2 created a binary > of approx. 30 MB with linux and Solaris 2.5, > because of global arrays. > Fix: use -fconserve-space, shrinks to 100K or less > > - this means that the same 30 MB are resident memory. > This will swap a lot on machines with less than > at least 32 MB memory. > Fix: dynamic or pool allocation and garbage collection > might decrease this. I noticed a lot of the static arrays in bspfile.c can be moved out to other programs. dvisdata(1MB), dlightdata(1MB), and dtexdata(2MB) for instance use 4MB all together, these could easily be split up into other programs. > - qbsp does not do any mipmap processing besides adding > them, IIRC. This task could be completely separated, > removing the mipmap lump buffer memory requirements > from the program entirely (and the related source). good point > Remarks: pool allocation might require hash tables to > get pointers for indices, haven't looked to closely. > Replacing the byte arrays took me using derived structs > (classes) and casting to base class pointer. I have replaced most of the static arrays (dmodels,dleafs, dplanes,dvertexes,dnodes,texinfo, and dfaces) to arrays of pointers. I made a typedef for each one e.g. "typedef dleaf_t *dleaf_p" and dynamically allocated the memory on the fly. I haven't seen a whole lot of improvement but I expect it to be better once the byte arrays are moved out. > Is anybody else currently working with the qbsp sources? Any > comments? What about using realloc for the byte arrays? Don't know if that would be such a great idea though. Stephen ------------------------------ From: Daniel Dorau Date: Fri, 5 Jul 1996 14:34:56 +0200 (MET DST) Subject: Quake Level limits Hello, I wanted to know if there is some official information on "how big" Quake levels can be and if there are other level limits like in Doom, where only a limited number of "doors" (don't remeber how it was called, I mean the lines which where the connecting line between two sectors..) could be displayed at a time, else one got the hall of mirrors effect. I would like to convert it to Quake and expand it to the size I originally planned, if Quake is capable of handling it. Can maybe someone of Id give some hints about this? Daniel Dorau woodst@cs.tu-berlin.de - ---------------------------------------------------------------------------- "Wer nachts schlaeft, braucht sich nicht zu wundern, wenn er tagsueber arbeiten muss." - ---------------------------------------------------------------------------- ------------------------------ From: Bernd Kreimeier Date: Fri, 5 Jul 1996 14:32:06 +0200 (MET DST) Subject: Re: PVS generation Steve Larsen wrote: > > > this is great as long as all your doors are axial rectangles > > > > Far out idea: approximate an arbitrarily oriented and shaped > > portal by a bounding box of six axial portals. This will > > increase the PVS in pathological cases, and increase the > > number of portals, but if O(n^4) is the alternative... > Yeah, I was thinking about this myself. Create an isothetic surface > on the "wall" that contains the actual portal. The only drawback that > I saw at a glance is that this exaggeration could potentially cause > a large increase in the PVS. But to be fair, which of these approximations > couldn't? Definitely worth some consideration. According to Seth Teller, this has alrady been done. He pointed me to @InProceedings{Luebke:1995:PMS, author = "David Luebke and Chris Georges", title = "Portals and Mirrors: Simple, Fast Evaluation of Potentially Visible Sets", editor = "Pat Hanrahan and Jim Winget", pages = "105--106", booktitle = "1995 Symposium on Interactive {3D} Graphics", year = "1995", organization = "ACM SIGGRAPH", month = apr, note = "ISBN 0-89791-736-7", } from a Monterey 1995 symposium, authors from UNC. See http://www.cs.unc.edu/~luebke/publications/portals.html for an on-line version, or in the ./publications/postscript/ directory. Btw., this particular area of the net might be a very good place to look for alternative approaches to modify "vis". See PfPortals library at http://www.cs.unc.edu/~luebke/visibility.html. No matter how good the editors, w/o a fast PVS builder a lot of people will be very unhappy. b. ------------------------------ From: Jim Lowell Date: Fri, 5 Jul 1996 10:22:23 -0400 Subject: Re: Quake Level limits At 02:34 PM 7/5/96 +0200, Daniel Dorau wrote: > >Hello, > >I wanted to know if there is some official information on "how big" >Quake levels can be and if there are other level limits like in Doom, >where only a limited number of "doors" (don't remeber how it was called, >I mean the lines which where the connecting line between two sectors..) >could be displayed at a time, else one got the hall of mirrors effect. >I would like to convert it to Quake and expand it to the size I >originally planned, if Quake is capable of handling it. >Can maybe someone of Id give some hints about this? > I don't know for sure, but I've been starting my Thred levels as a cube that's 1024x1024, and at one point I had two of them stacked with a hole between them, so I could see a total distance of 2048. I wouldn't be surprised if the limits were WAY higher than that though. - -= Jim Lowell =- ------------------------------ From: Daniel Dorau Date: Fri, 5 Jul 1996 17:44:09 +0200 (MET DST) Subject: Re: Quake Level limits On Fri, 5 Jul 1996, Jim Lowell wrote: > At 02:34 PM 7/5/96 +0200, Daniel Dorau wrote: > > > >Hello, > > > >I wanted to know if there is some official information on "how big" > >Quake levels can be and if there are other level limits like in Doom, > >where only a limited number of "doors" (don't remeber how it was called, > >I mean the lines which where the connecting line between two sectors..) > >could be displayed at a time, else one got the hall of mirrors effect. > >I would like to convert it to Quake and expand it to the size I > >originally planned, if Quake is capable of handling it. > >Can maybe someone of Id give some hints about this? > > > > I don't know for sure, but I've been starting my Thred levels as a cube > that's 1024x1024, and at one point I had two of them stacked with a hole > between them, so I could see a total distance of 2048. I wouldn't be > surprised if the limits were WAY higher than that though. > What I meant is not only how long the greatest distances may be, but - for example - how many doors could be displayed at one time which were passable lines between two sectors in Doom and a problem if too many were visible at one time. Sorry if I don't know Quake's technical terms, the only experience I have is building Doom levels. Daniel Dorau woodst@cs.tu-berlin.de - ---------------------------------------------------------------------------- "Wer nachts schlaeft, braucht sich nicht zu wundern, wenn er tagsueber arbeiten muss." - ---------------------------------------------------------------------------- ------------------------------ End of quake-dev-digest V1 #22 ****************************** From owner-quake-dev-digest@gamers.org Wed Jul 10 19:59 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id TAA09985 for ; Wed, 10 Jul 1996 19:56:02 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id NAA14002 for quake-dev-digest-outgoing; Wed, 10 Jul 1996 13:55:19 -0400 From: owner-quake-dev-digest@gamers.org Date: Wed, 10 Jul 1996 13:55:19 -0400 Message-Id: <199607101755.NAA14002@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #23 Reply-To: quake-dev@gamers.org Errors-To: owner-quake-dev-digest@gamers.org Precedence: bulk X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 27377 X-Lines: 769 Status: RO quake-dev-digest Wednesday, 10 July 1996 Volume 01 : Number 023 ---------------------------------------------------------------------- From: FiSTY Date: Fri, 5 Jul 1996 12:03:53 -0400 (EDT) Subject: RE: .map algorithms >No offense, but your page as it stands now is basically worthless, none >of the >links go anywhere......when will you be completing it??? Complete? never... add-to? continuously... The point of the page is to have a archive to useful algorithms that people have comeup with with regards to editors/brushes/etc. For instance, if someone has a kick ass editor going, but wants to add the brush subtractions stuff, then they could look at the page and find out... (but someone will have to submit the algorithms so I can put it up first) This was never meant to be a lone-project. It's meant to be a collection of stuff submitted by myself and others. Many people have asked how do I do this? how do I do that? We'll here's the place to find the answers (but someone has to answer it first!) If you want to know something... tell me and I'll get the answer for you... I'm guessing that you in particular are looking for something... what? I want to know what you want to know... ...Matt BTW what do you mean the links go nowhere... they work fine for the people I've talked to and myself... =========================================== FiSTY fisty@yoss.canweb.net the shaker project - http://www.canweb.net/~fisty/shaker/ ------------------------------ From: Mads Dydensborg Date: Fri, 5 Jul 1996 18:21:43 +0200 (METDST) Subject: Re: Jon's Quake Editor Webpage On Fri, 5 Jul 1996, Bernd Kreimeier wrote: > Being greedy, aren't we? There might not be such a thing - simplicity and > accuracy might well be mutually exclusive in this case. Hmmm, I'll have to > tackle this for the Primer anyway, so let's see how close I can get. > > > A Brush is a solid volume, a body wrapped into by some flat surfaces that [..] > > Take any two points on the surfaces of the brush or inside the brush. > The line connecting them has to be entirely inside the brush, and cannot > intersect any surface (except start and end point). This means a brush > is convex. [..] > > > P.S.: the above description is not accurate, btw. - there are convex > polyhedra with concave faces. I am sure there are more flaws. Please give (or point to) an example of this. (I thought I had crasped the concept : Take any two points on the face, and the line connecting them. How can it be interily inside (the 'limit' of) the brush, if the face is convex?) Mads +----------------------------------------------------------------------+ | Mads Bondo Dydensborg. Student at DIKU, Copenhagen - Denmark. | | Email: madsdyd@diku.dk www: http://www.diku.dk/students/madsdyd/ | +----------------------------------------------------------------------+ ------------------------------ From: Bernd Kreimeier Date: Fri, 5 Jul 1996 18:31:58 +0200 (MET DST) Subject: Linux Quake 0.91 It is at ftp://ftp.lek.net/pub/quake/linux/intel_linux_quake091.tgz, and as I managed to get it this afternoon, it should be now at http://www.gamers.org/dEngine/archive/ as well, file is about 310K. Thanks heaps to Dave Taylor, again. b. = Quake ported to Intel/Linux by Dave Taylor at Crack dot Com, Inc. = To run xquake, any X server should do. To run xf86quake, you need XFree86 3.1.2E or later. To run either xquake or xf86quake, you need about 16Mb of RAM, a Pentium (any speed), an X server running in 8bit mode, a keyboard, and a video card on a local or PCI bus. You need Linux version 1.3.88 or later. You need ELF binary support. The Linux version does not support CDROM music. Mouse is supported in xf86quake. A net card will let you play net games over UDP. There is no serial support in the Linux version. To get sound, you'll need the sound driver with mmapable DMA buffers. This was definitely available in 1.3.88 and should be available in everything after that. Quake is one of the first apps to use the mmapable DMA buffers, so if it crashes, run quake with the "-nosound" option. To run xf86quake, you must have a video card that can linearly map its address space. You must also run as root. xf86quake can run faster than xquake and runs full-screen. xf86quake also allows the use of the mouse. You must also setup your XF86Config file to add lower resolution modes, typically 640x480 to 320x200. = Quake ported to Intel/Linux by Dave Taylor at Crack dot Com, Inc. = ------------------------------ From: Bernd Kreimeier Date: Fri, 5 Jul 1996 19:44:13 +0200 (MET DST) Subject: Brush definition/was: Jon's Quake Editor Webpage Mads wrote: >> P.S.: the above description is not accurate, btw. - there are convex >> polyhedra with concave faces. I am sure there are more flaws. > >Please give (or point to) an example of this. > Picking nits (i.e. convex nuts) here. Take a cube. You might define it using six squares - or twelve triangles, or other combinations of polygons. Obviously, you could add a concave and a matching convex polygon to create a square - and use that square to define a cube, now a convex polyhedron defined by convex and concave polygons. The definition I gave did not mention that we require a minimal number of polygons - i.e., I did not mention that qbsp merges adjacent faces with identical normals, and that a brush cannot have them anyway. A brush is defined by planes, and qbsp will reject map files with multiple planes having identical normals. Thus a brush is not only a convex polyhedron/a polytope, it has to have a minimal number of faces - exactly one face for each plane. I admit I'm mean. b. ------------------------------ From: Chris Carollo Date: Fri, 05 Jul 1996 16:11:13 -0400 Subject: Re: Jon's Quake Editor Webpage Bernd Kreimeier wrote: > P.S.: the above description is not accurate, btw. - there are convex > polyhedra with concave faces. I am sure there are more flaws. Are you sure about this? I was under the impression that a convex polyhedron in N-space must always have faces of convex polyhedra in N-1 space. I honestly can't even visualize how a concave polygon could be the face of a convex polyhedron, unless it was coplanar with an adjacent polygon that "filled in" its concavity. - -Chris ------------------------------ From: Jonathan Mavor Date: Fri, 5 Jul 1996 13:51:59 -0700 Subject: Re: Qbsp >X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) >From: John Carmack >Date: Fri, 5 Jul 96 01:14:49 -0500 >To: Jonathan Mavor >Subject: Re: Qbsp >References: <199607041514.AA04853@relay.interserv.com> > > >> Door #1, you totally boneheaded the shareware checks. I would never >> use a pirate beta, and I have more important things to do than hack >> quake ;) (oh wait a sec... writing an editor?) > >Well, shit. I checked for the game directory override and pak file modifications, but I missed the default id1 tree structure. I do want to strongly encourage people to use the -game override method of extending Quake, instead of directly modifying the id1 hierearchy. Have you seen the little article I released about that? > >I'll fix it on the next rev. I may gratuitously bump the bsp version number so the next release of the tools won't work with 0.91 / 0.92 shareware. > >> BTW how's your NT Editor coming along? > >Worked on it all day today. It is coming along nicely. I'm not doing any radical departure from QuakeEd, because I'm allready throwing in learning windows and GL on the project and I don't want to push too much. > >Having Very Fast accelerated hardware as a system requirement is quite liberating for the design. We are going to deploy this on the new intergraph Intense-3D boards when I am finished. > >My goals for the project are just to produce a very fast, very clean, very powerful editor. It won't be too fancy, but because I have plenty of hindsight on what is actually needed and used during the development process now, it should be an extremely productive environment. > >I will probably release the editor, but because it is targeted at a $3000 workstation accelerator, it probably won't be very reasonable on any stock hardware. > >I couldn't open the file package you sent me. Could you just drop it in as a raw .map file? > >John Carmack > > ------------------------------ From: Jonathan Mavor Date: Fri, 5 Jul 1996 13:55:41 -0700 Subject: Re: Qbsp >X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) >From: John Carmack >Date: Thu, 4 Jul 96 02:09:03 -0500 >To: Jonathan Mavor >Subject: Re: Qbsp >References: <199607031945.AA14507@relay.interserv.com> > >You wrote: >> It looks like >> either way I'm going to have to distribute custom copies of qbsp >> with my editor because of the static 16 face limit. > >I will rewrite the code to remove the face limit. I actually removed a limit on the max number of edges on a polygon that was being hit during the csg process, but I had forgotten about the max faces on a source brush. > >In the meantime, feel free to distrubute a modified version. I would like to discourage gratuitous divergence, but you have a compelling reason. > > >> Also I don't know if you've given any thought to this but it might >> be interesting to change the qbsp into a front-end backend type >> process. You could have the front-end do the CSG on the the map >> file and then the backend could actually create the bsp. > >That is indeed a good structural break point. Qbsp is really larger than I would prefer right now, and that would probably be a good place to seperate it. I might do that. > >> With my >> editor this would be much more efficient because I could just do >> the csg in my maps and export directly do the back end. > >Possibly that would be a savings, but I am a bit loathe to accept polygon input because it does not have the same guaranteed correct properties of convex polyhedrons. > >> Otherwise >> some of the geometry that I can create (and I know people will want >> to create) is just completely in-efficient using convex brushes. > >While that would be the case for the brush count in the .map file, it is abviously not true for the end product -- they both become (statistically) the same merged polygon fragments after the csg/merge phase. > >> I >> don't know what the projected lifespan of the product is but it >> would be nice to be able to really push the limits of the engine. > >I'm game for making worthwhile improvements to the quake technology over the next year or so. I may be starting on my next clean sheet of paper design soon, but I may also get drawn into some more quake exploitation. Dunno yet. > > >John Carmack > ------------------------------ From: Jonathan Mavor Date: Fri, 5 Jul 1996 13:56:39 -0700 Subject: Re: Jon's Quake Editor Webpage At 04:11 PM 7/5/96 -0400, you wrote: >Bernd Kreimeier wrote: > >> P.S.: the above description is not accurate, btw. - there are convex >> polyhedra with concave faces. I am sure there are more flaws. > >Are you sure about this? I was under the impression that a >convex polyhedron in N-space must always have faces of convex >polyhedra in N-1 space. > >I honestly can't even visualize how a concave polygon could be >the face of a convex polyhedron, unless it was coplanar with an >adjacent polygon that "filled in" its concavity. I think that's what he was saying. The .MAP format eliminates this though. L8r, Jon ------------------------------ From: Daniel Dorau Date: Sun, 7 Jul 1996 00:03:44 +0200 (MET DST) Subject: OS/2 Quake Editor? Hmm - just wanted to ask if someone in this mailing list plans to write a OS/2 editor for Quake (or already did :). If there are people reading this know other people which are doing this then they should hint me and those people. Got it? ;) Daniel Dorau woodst@cs.tu-berlin.de - ---------------------------------------------------------------------------- "Wer nachts schlaeft, braucht sich nicht zu wundern, wenn er tagsueber arbeiten muss." - ---------------------------------------------------------------------------- ------------------------------ From: Brooks Talley Date: Sat, 6 Jul 1996 14:00:24 -0700 (PDT) Subject: QuakeEd & textures? Has anyone gotten QuakeEd to work with textures and all? I've got the thing running very nicely, and can make some very nice levels and all, but QuakeEd chokes when I try to load texture libraries (base.wad, etc, as supplied on Crowbar's home page). The message is something like, "Error: not a mipmapped texture" or close to that, anyways. For those doing similar things to me, there is an excellent rsh service for NT available from cdrom.com, called rshdnt17. Combined with a decent system and NFS, it's easy to get QuakeEd's BSP building menus to work and offload that processing to a hefty NT machine. aiken - ----- aiken@illuminati.org ------------------------------ From: Stephen Crowley Date: Tue, 01 Jan 1980 05:37:13 +0000 Subject: Re: QuakeEd & textures? Brooks Talley wrote: > > X-gamers.org: quake-dev@gamers.org > > Has anyone gotten QuakeEd to work with textures and all? I've got the > thing running very nicely, and can make some very nice levels and all, > but QuakeEd chokes when I try to load texture libraries (base.wad, etc, > as supplied on Crowbar's home page). The message is something like, > "Error: not a mipmapped texture" or close to that, anyways. > > For those doing similar things to me, there is an excellent rsh service > for NT available from cdrom.com, called rshdnt17. Combined with a decent > system and NFS, it's easy to get QuakeEd's BSP building menus to work and > offload that processing to a hefty NT machine. > > aiken > ----- > aiken@illuminati.org Are you using the newer wad's off my page? I noticed that the first lump has to be 'PALETTE' so I updated all the wads. Get the new ones and let me know if it works. Stephen Crowley aka Crowbar http://www.wf.net/~stephenc ------------------------------ From: Mark Hughes Date: Sun, 7 Jul 1996 17:54:39 -0700 Subject: Re: OS/2 Quake Editor? Daniel Dorau spake: >Hmm - just wanted to ask if someone in this mailing list plans to write a >OS/2 editor for Quake (or already did :). If there are people reading >this know other people which are doing this then they should hint me and >those people. Got it? ;) I, too, would like to see an OS/2, DOS, or Java (without any native methods) QuakeEd... I have no intention of installing LoseNT or 95, and while I might consider Linux or FreeBSD, I'd *LIKE* to not waste disk space on another OS. Anyone have plans in this direction? Or at the least to write something vaguely portable, so someone else can adapt it to OS/2? -Mark Hughes Quake console command list ------------------------------ From: matt.tagliaferri@pcohio.com (Matt Tagliaferri) Date: Sun, 07 Jul 1996 23:08:00 -0500 Subject: .MAP, comments allowed? For all the .MAP parsers out there, are comments allowed in MAP files? If so, where do they go and how? I would like the user to be able to name each brush, and to store that data in a comment in the MAP file. In addition, I thought of using comment areas for data such as Meta-Brushes, so the user could group three brushes together and name the group "DoorWay". There's always the option of using my own file format to store all the data and exporting to MAP, but I'd rather not. If comments are possible, I'm willing to stick to any common format that any other editor uses for meta-brush names or whatever, so let me know matt tag - --- * PW * _ _ ------------------------------------------------------------- |_|_| PC-OHIO PCBoard Online * pcohio.com * V34+ 33.6: 216-381-3320 |_|_| The Best BBS in America * Cleveland, OH * Go Tribe ------------------------------------------------------------- ------------------------------ From: Jonathan Mavor Date: Tue, 9 Jul 1996 10:11:19 -0700 Subject: Re: .MAP, comments allowed? At 11:08 PM 7/7/96 -0500, you wrote: Man I haven't got a message from this list in so long I forgot I was on it. >For all the .MAP parsers out there, are comments allowed in MAP files? If so, >where do they go and how? > I'm interested in this also. >I would like the user to be able to name each brush, and to store that data in a >comment in the MAP file. In addition, I thought of using comment areas for data >such as Meta-Brushes, so the user could group three brushes together and name the >group "DoorWay". > I have "groups" and would like to be able to export them. >There's always the option of using my own file format to store all the data and >exporting to MAP, but I'd rather not. > This is what I do but I have "exceptional" needs. For instance my own bsp, concave brushes etc. The format I'm using is also a text so that it can easily be expanded on etc. Pretty well everything in thred has name including the groups (they also have a colour), the brushes etc. L8r, Jon ------------------------------ From: "Ryan Drake" Date: Tue, 9 Jul 1996 13:24:46 -0400 Subject: Re: .MAP, comments allowed? > For all the .MAP parsers out there, are comments allowed in MAP files? If so, > where do they go and how? I believe the C++-style double-slash comments are allowed. - -- +------------------------------------------------------------------- - ----+ | Ryan Drake Sanity is the trademark of a weak mind. | | stiletto@psu.edu -- Mark Harrold | | http://www.crayola.cse.psu.edu/~drake/home.html | +------------------------------------------------------------------- - ----+ ------------------------------ From: FiSTY Date: Tue, 9 Jul 1996 15:35:26 -0400 (EDT) Subject: Re: .MAP, comments allowed? On Tue, 9 Jul 1996, Ryan Drake wrote: > > > For all the .MAP parsers out there, are comments allowed in MAP > files? If so, > > where do they go and how? > > I believe the C++-style double-slash comments are allowed. Correct. I've done some testing and it would appear that it does allow // comments both within brush definitions and outside brush definitions. I asked John Carmack whether pairs were allowed within brush definitions and he said that they were not. But you can comment within them so there is away around that. For instance I wanted: { "classname" "worldspawn" { ( 1 1 1 )... ( 2 1 4 )... "_group" "whatever" ( 3 7 6 )... } ... But this isn't allowed however you can put a // before the "_group" "whatever" and it will pass this by without screaming. I've also noticed that if you have: { "classname" "worldspawn" "wad" "whatever" this is not a comment <- Focus on this line "more" "stuff" .... qbsp does not have a problem with this... interpret as you may... ...Matt =========================================== FiSTY fisty@yoss.canweb.net the shaker project - http://www.canweb.net/~fisty/shaker/ ------------------------------ From: Bernd Kreimeier Date: Wed, 10 Jul 1996 19:54:54 +0200 (MET DST) Subject: Info from John Cash >From Sean , who forwarded me some info he got from John Cash. He also pointed out that there is a quake-servers list (see next posting). b. - ----------------------------------------------------------------------- From: John Cash Date: Sun, 7 Jul 96 22:10:21 -0500 To: Sean Allen Subject: Re: Server datagram bytes You wrote: > Mr. Cash, > > I've written a program called Qconnect that displays servers that > are up from a list you maintain, and allows you to select one and > it automatically spawns Quake and connects to that IP (it's > freeware). > > I am polling the server with the string { 0x80, 0x00, 0x00, 0x0C, > 0x02, 'Q', 'U', 'A', 'K', 'E', '\0', 0x01 }, but I am curious about > one (well actually two) of the bytes returned. > > The fourth byte over seems to have something to do with what map > your are on (even though the name of the map is given). I can not > figure out what this byte is for. > > 1) What is the 4th byte over for/is it important? > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > 80 00 00 26 83 206.86.0.22:26000 00 bigmac 00 e1m5 00 10 10 03 ^^ I > have seen it as 0x26, 0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d and 0x32. > Playing around with a local server (both dedicated and listen) I > can only get this number to change when I'm on different maps. My > expience has been: > > 0x2b Start map 0x2a E1M1 - E1M8 0x29 DM1 (released w/ Carmacks > source) > > I don't know why other servers have numbers that vary. My guesses > are it either has something to do with the number of hops, the ping > time, what version of Quake being used, coop or DM, or something > else. I have eliminated (I think) most of these possibilities so > I'm at a loss. > > > 2) What is the last byte for? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > 80 00 00 26 83 206.86.0.22:26000 00 bigmac 00 e1m5 00 10 10 03 ^^ > My guess is the version number. This always appears to be 03, but I > saw one case where a qtest server was running test1 and it was 01. > > 01 Qtest 02 ??? 03 .91 - .92 > > (FOLLOW UP QUESTION) If it is the version number, is there a 02 > version? And, is there any plans with .94 or above on this number > (03) changing? > > > 3) Could you please, possibly send me a query string that lists the > players currently playing? Did I mention the word please - with er, > sugar on top? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Thank you so much for your time - this will help me w/ my next > version, Sean Allen srallen@nando.net Well, with all the sugar on top... I guss I have to answer you ;-) Actually a few people have been asking for this info, so it's about time I gave it to you all. Are you on the quake-servers mailing list? If so, please feel free (hint, hint) to post this info there; if not let me know so I can do it. For network play (IPX and TCP/IP), all Quake packets start with an 4 byte header: The first short (16-bit) is flags; 0x8000 indicates a control (non-game data) packet The second short is the length of the packet (including the header). For control messages, the next byte is the message type. The one you've all been using is: #define CCREQ_SERVER_INFO 0x02 The next series of bytes is a null terminated ASCII string with the game's name in it. Currently "QUAKE" is the only supported value, but you can probably imagine other possible values that will appear in the future. And the last version is a protocol version, currently: #define NET_PROTOCOL_VERSION 3 For QTEST1 it was 1. Now for the repsonse packet. First two bytes are the same format header. These two shorts are in network (big endian) order BTW. Next byte is the message type again. In this case: #define CCREP_SERVER_INFO 0x83 This is followed by a null terminated ASCII string containing the address (including socket) of the server's control socket. Some people may wonder why I return the address here since you had to know it to send the server the request in the first place. It's not for the slist function either; I can get the address out of the response there. This exists for the purpose of supporting proxy/meta/tracker servers. Quake doesn't have all the support there yet, but when it does this will become very useful. It will let a program running on a machine (like Qconnect, for example) return this response on behalf of another machine. IOW, imagine being able to do an "slist stomped" and having Quake go ask stomped (or aftershock or whatever site) for it's current server list. This will eliminate the cycle of: hunt for server, start quake, connect to server". You'll be able to do it from within Quake. Of course, I'm always open to suggestions for what people want to see in this area. Anyways... the next two fields are null terimated ASCII string. First is the server's hostname, second is the current map name. These are followed by: a byte number of current players and byte maximum number of players. The last byte contains the verion number (same one as above). The reason it's in both sides is for backwards compatability. For example, I'm planning in adding one more field to the respnse containing the version of Quake the server is running. I'll bump the protocol version number too. That way if I get a request with version 3 I won't include it, but if I get a version 4 request I will. I hope this helps. BTW, are you on the quake-servers mailing list? If not, you should be. I'm planning to release the specs for the whole protocol there Real Soon Now. Yes, there is more stuff you can get in the same manner. Like players info: name, colors, frags, how long they've been connected. And the server rules: gravity, timelimit, fraglimit, etc..... You like? - --- John Cash "I want to move to theory, everything works in theory" From: John Cash Date: Mon, 8 Jul 96 19:15:29 -0500 To: Sean Allen Subject: Re: Server datagram bytes You wrote: > I am on the "quake-dev" mailing list, I believe this is what you > are referring to. I will post it there. Let me know if there's > another list that I'm not on. Here's the little trailer from the quake-servers list: To unsubscribe from quake-servers, send a message with the word "unsubscribe" in the body to quake-servers-request@premier.net. Please address any problems with this list to owner-quake-servers@premier.net > No, I love! Great stuff! BTW, I played around with changing the > CCREQ_SERVER_INFO's byte (I tried all 256). Found two other bytes > that worked, 0x01 and 0x04. 0x01 seems to do an initial request to > log in??? The return packet also seems to have a time embedded in > it??? I have no idea what 0x04 does, it just sometimes returns 0x85 > (CCREP_SERVER_??????) and a couple more bytes. Care to send > #defines ;-) ? Yes, 0x01 is CCREQ_CONNECT... don't do that! ;-) You missed 0x03??? I'll send you info on the others Real Soon Now. - --- John Cash "I want to move to theory, everything works in theory" ------------------------------ End of quake-dev-digest V1 #23 ****************************** From owner-quake-dev-digest@gamers.org Tue Jul 16 14:48 MET 1996 Received: from gamers.org (root@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id OAA26742 for ; Tue, 16 Jul 1996 14:46:34 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id HAA00273 for quake-dev-digest-outgoing; Tue, 16 Jul 1996 07:17:28 -0400 From: owner-quake-dev-digest@gamers.org Date: Tue, 16 Jul 1996 07:17:28 -0400 Message-Id: <199607161117.HAA00273@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #24 Reply-To: quake-dev@gamers.org Errors-To: owner-quake-dev-digest@gamers.org Precedence: bulk X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 27242 X-Lines: 739 Status: RO quake-dev-digest Tuesday, 16 July 1996 Volume 01 : Number 024 ---------------------------------------------------------------------- From: Bernd Kreimeier Date: Wed, 10 Jul 1996 20:43:38 +0200 (MET DST) Subject: Quake Servers list Thanks to Sean Allen , who pointed out the Quake Servers mailing list to me: This mailing list is for the discussion of the development and maintenance of large quake servers. It is NOT for general quake discussions, quake editing discussions, or OS issues. This mailing list is a private forum and should be treated as such. Off-topic and/or abusive messages will not be tolerated. This mailing list is archived at: ftp://ftp.premier.net/pub/lists/quake-servers Subscription: at majordomo@premier1.premier.net. This is a majordomo list like this one, see the help and info files. b. ------------------------------ From: johnsond@admin.fcbe.edu.on.ca (Dan Johnson) Date: Wed, 10 Jul 1996 22:30:16 -0400 Subject: compiling qbsp util Greetings, I am attempting to compile the QBSP utility for Windows 95 using Borland C++ 5.0. The files compile properly but when it attemps to link the objects I recieve three errors: Unresolved External '_bitbytes' referenced from module soudpvs.c Unresolved External '_uncompressed' referenced from module soudpvs.c Unresolved External '_portalleafs' referenced from module soudpvs.c Does anyone know how to fix this error?? Even with these errors the linker still creates an .exe file. Trying to QBSP the dm1.map will cause an error in Windows although QBSPing lavapit.map (available from AfterShock) seems to work. Unfortunatley if I load it in Quake is gives me a Bad Surface Extents error. Now is this error realted to the QBSPing or the map file itself?? What I really hope to accomplish is to change the forward slashes '/' into back slashes '\' so that the .wad file inclusion will work. If you know of any QBSP util that will do this can you please E-mail me it's location. Thanks Fluff (http://www.geocities.com/SiliconValley/Park/2994) +-----------------------------------+ + Insanity is not a state of mind + + but + + a release of the mind + +-----------------------------------+ ------------------------------ From: "Carsten Whimster" Date: Wed, 10 Jul 96 23:00:24 Subject: Re: compiling qbsp util On Wed, 10 Jul 1996 22:30:16 -0400, Dan Johnson wrote: >Greetings, > > I am attempting to compile the QBSP utility for Windows 95 using >Borland C++ 5.0. The files compile properly but when it attemps to link the >objects I recieve three errors: > > Unresolved External '_bitbytes' referenced from module soudpvs.c > Unresolved External '_uncompressed' referenced from module soudpvs.c > Unresolved External '_portalleafs' referenced from module soudpvs.c > >Does anyone know how to fix this error?? Even with these errors the linker >still creates an .exe file. Trying to QBSP the dm1.map will cause an error >in Windows although QBSPing lavapit.map (available from AfterShock) seems to >work. Unfortunatley if I load it in Quake is gives me a Bad Surface Extents >error. Now is this error realted to the QBSPing or the map file itself?? Somewhat related... I have been doing some work on NT with qbsp, light and vis, but when I try to use the resulting BSP file with Quake, it complains that it "can't spawn server DM1" and so on. Given that I am not willing to stealing a Quake beta before I can buy the game, how can I do this with SW until the full game is released? "Map DM1" doesn't work, and neither does "-game" on the commandline. Carsten Whimster EDM Associate Editor, Book Reviewer carsten_whimster@iqpac.com EDM Site: http://www.iqpac.com/ The OS/2 API Project http://www.iqpac.com/edm2/os2api/ My Webpage http://www.undergrad.math.uwaterloo.ca/~bcrwhims/ ------------------------------ From: jschuur@onlinemagic.com Date: Thu, 11 Jul 1996 13:41:35 +0100 (BST) Subject: Shareware Quake 1.00 out for those who don't poll ftp.id every hour: the 1.00 version of shareware quake has been released. it's a new release and there is no patch. - -= joost schuur tel - +44 171 820 7766 =- - -= software person email - jschuur@onlinemagic.com =- - -= online magic ltd, london www - http://www.nuqneH.org/~jschuur/ =- ------------------------------ From: Robert Dean Rudeseal Date: Thu, 11 Jul 1996 21:33:20 -0600 Subject: Re: quake-dev-digest V1 #23 This was posted on AfterShock. Now my question is, has anybody compiled the QuakeUtils to Win95/NT like the QBSP stuff was. The Quake Util's have been largly ignored by everybody in favor of the Qbsp/light/vis for Map Making/Editors out there. So if anyone is developing an Editor for the Objects/models in Quake please let us know! Quake Specs for Making Models There are a few files needed to take your alias (.tri) model into quake. I will explain each step for the process of bring your model to life. First of all you have to have a 3d model. Things to keep in mind tho is that the model can only have triangle polygons, Surface faces must be pointing the right way or u will not get a surface on your object. I would say stay within the range of 250-300 polygons for your character or you will probably see a massive slow down in the engine. Its best to start models from scratch. I have found that making characters with lots of polygons and then trying to rely on a polygon reduction method does not work at all. Keep in mind that your model scale should be in meters for best results. Here is what I do.. after I have the model saved I bring it into a program called Interchange y Senders which will convert about any object format to alias .tri format which is what you need in order to get them into quake currently. Once you have converted your object into alias .tri format you are ready to make the skin for the object. Here is where u use the first of the Quake utilities called texmake. Texmake takes your object and created a outline skin which you then bring into a paint package and create the texture for your object. Very simple and straight forward. If your skin isn't showing up make sure your scale of your object is in meters. That's one major problem that I ran into and took me a while to figure out. Texmake has very simple command parameters. E.g. to make our human.tri object skin simply do: texmake human.tri this will make a .lbm file called human.lbm for you to edit in a paint package. For best results use either pc version of deluxe paint or deluxe animation. A thing to keep note of when you run texmake is the scale size of the object that is recognizes. You will use this number later. Next step is to create a .qc (quake c) file for your model. Quake C has several uses. For this exercise we are just going to go over the simple version of it to bring in a character into quake. For all purposes we are going to replace the armor icon in the game. The reason I use the armor icon is it set up to rotate on its access which will give you a great spinning view of your object. QUAKE C EXAMPLE FOR ARMOR: $modelname armor $cd /evil/models/armor $flags 8 //client side rotate $origin 0 0 8 $scale 4 $base base $skin skin $frame armor This is a very simple quake c source file for your model. Let me explain a few of the lines of this file. $modelname The name you want your object to be called once you bring it though the modelgen code. $cd Directory where your model is located. $flags Rotation of the object. $orgin 0 0 8 Location of the object from the bounding box in the quake editor. $scale < # > This comes from the texmake number that is generated you can use different values if you want. $base Base object name kinda like a starting position of the object before animating it. $skin The output file that you touched up from texmake for your object. $frame here is where you load in several frames of the object for animation. example would be . $frame walk1 walk2 walk3 walk4 etc.. That is the basic for an object in order to have it animate you will need to add some c code after the $frames that tell your object how to act. I will get into that more on another file this is just to get your object into quake for the moment. You can take all these principles that I have explained to get your objects into quake. Once you have completed your quake c file its time to run it though model gen. Save the quake c file as armor.qc. Next step is to make 2 copies of your object. Name your object base.tri and armor.tri The reason for this is that when your run the model gen it will look for base from the $base base file and armor from the first frame of the armor in $frame armor. Once you have completed make sure that all these files are in one directory: base.tri armor.tri skin.lbm armor.qc Then simply run modelgen armor.qc which will then create a armor.mdl file which quake reads when running the game. If you have done everything right you should now see a armor.mdl file in the same directory. Now the fun part. Lets replace the your object with the armor icon in the game. There are a few things u need to know before you do this. In the quake dir create a dir structure like id1. Here is a break down of what you will need to make maps gfx and models. Create these directors: test gfx progs maps sound Now assuming you have the registered version and did not pirate this version you can go on then. damn you to hell if you didn't buy this. copy your armor.mdl file into test/progs dir. Then run quake with these command parameters. quake -game test This will bring you into quake and it should replace all the armor icons with your object icon. THINGS TO KEEP IN MIND: Objects HAVE to be triangles. When creating the skin keep in mind the game palette or things will look psychedelic :) TROUBLESHOOTING: If texmake or modelgen doesn't seem to work or hang then there is a problem with your object. There are several reasons for this: 1.You could have a non-triangle polygon in your object. 2.You could have repeated points that wernt deleted. 3.Scale of your object could be wrong. Meters has best output. That's it for now.. if you have any questions email gateway@rogue-ent.com. Steve Tietze Rogue Entertainment http://www.gamers.org/~rogue gateway@rogue-ent.com - --------------------------------------------------------------- Robert Dean Rudeseal Rudeseal@Seal-Industries.com HTTP://www.hemi.com/~rudeseal WebPage Development and Broadcast Services Quake has changed the Doom phrase of "If it moves Shoot it. If it doesn't move, Shoot it until it does" To: "This phrase will be released in 'Two Weeks'" ------------------------------ From: Ron Crisco Date: Fri, 12 Jul 1996 19:48:26 -0500 Subject: Re: Win95 Quake Utils Robert Dean Rudeseal wrote: > > This was posted on AfterShock. Now my question is, has anybody > compiled the QuakeUtils to Win95/NT like the QBSP stuff was. > The Quake Util's have been largly ignored by everybody in favor > of the Qbsp/light/vis for Map Making/Editors out there. So if anyone is > developing an Editor for the Objects/models in Quake please let us > know! > QuakeMe 2.2 is at ftp.stomped.com/pub/quake/texture_editors/quakeme22.zip It handles the .mdl files correctly for version 1.0, and is a nice Win95 app. I'm in the process of rewriting the Stomped files area, so any 1.0 compatible utilities would be welcomed in /incoming. Ron Crisco crisco@stomped.com ------------------------------ From: Jim Lowell Date: Sat, 13 Jul 1996 20:25:45 -0500 Subject: Quake Texture wads? Anyone know where I can get some Quake texture wads? I believe that Stephen Crowley's webpage has them but I can't find the URL for that page anywhere. Any help would be appreciated. - -= Jim Lowell =- ------------------------------ From: mustaine@usa.net (Tom Mustaine) Date: Sat, 13 Jul 1996 23:46:45 -0600 (MDT) Subject: Questions regarding Ambeince & More I have been working on a Map for a few days now, a rather large - extremly detailed map. Most of my editing is done with (Whoo) c:\EDIT, but with a good understanding of Quake, its very possible. Anyhow, My question is in reference to the ambient sounds given off by Water and Sky areas. Does anybody know what conditions need to be met for a area of sky to give off the ambient "wind" sound? Or similar with a body of Water? According to the latest entity definition lists, there are no ambient placeable entities for these perticular sounds. John Romero mentioned to me that Quake was smart with its ambience, large bodies of water would give off the water sound, being close to a sky-the wind sound, lava, etc.... Another question - How does quake define a Invisible brush? There are invisible brushes in quake, but the .map's that have been released don't give any insight on how to create them. Does the "clip" texture have something to do with this? And another - Defining path's for monsters? errr.. _____ _ _ [_. ._][ \ / ]-Tom Mustaine - Mustaine@usa.net - Aka: Paradox--- - | | | .V. | Design for Master Levels / Final Doom / & More | | | | | | "Genius...only a thought away..." [_] [_] [_]--[http://www.usa.net/~mustaine/quakerep.html]---- - - ------------------------------ From: larsen@sunset.cs.utah.edu (Steve Larsen) Date: Mon, 15 Jul 1996 08:43:54 -0600 Subject: Re: Questions regarding Ambeince & More > Anyhow, My question is in reference to the ambient sounds given off by >Water and Sky areas. Does anybody know what conditions need to be met for a >area of sky to give off the ambient "wind" sound? Or similar with a body of >Water? According to the latest entity definition lists, there are no >ambient placeable entities for these perticular sounds. John Romero >mentioned to me that Quake was smart with its ambience, large bodies of >water would give off the water sound, being close to a sky-the wind sound, >lava, etc.... For a surface to be an ambient sound emitter ;), it mearly needs to have the correct texture name. Here are the ones I could see looking at the soundpvs.c file: *water sky *slime *lava *04water > Another question - How does quake define a Invisible brush? There are >invisible brushes in quake, but the .map's that have been released don't >give any insight on how to create them. Does the "clip" texture have >something to do with this? yes, it is the texture. I have used clip, and trigger. Both appear to be invisible. Trigger at least can be crossed through. > And another - Defining path's for monsters? errr.. I believe there is a fairly elaborate explanation in the Quake Specs on this. I haven't personally had any experience. Now, I too have been working on a level (but not using Edit ;). I have posted about some of my experiences in r.c.g.q.e if anyone wants to see it, but allow me to summarize RE: id's tools: Light is currently the serious bottleneck, and that's without using the "-extra" parameter. Qbsp is pretty linear with regards to the level size and doesn't take too long. And the biggest surprise: Vis is not that bad at all. If I do the full blown version it takes 2-3 minutes. If I use the "-fast" parameter, it finishes in 20-30 seconds!! (Bernd, looks like Carmack may have beat us to the punch yet again about over-estimating the PVS. Damn him!! ;);) Another thing regarding the win32s ports of qbsp/light/vis in case anyone hasn't seen the thread. I have 96M of ram in my computer. I can build maps all day long under NeXTStep with no problems. This includes jrbase1 (which is of course e1m1 from the shareware). If I try to build jrbase1 under Windows 95, qbsp croaks after running a while. People have reported that by increasing their swap file size so they have a total of 160M of virtual memory, they have been able to build these maps. Obviously, something doesn't jive here. NS is way more memory hungry than 95, and it has never swapped once while running these tools. Even with QuakeEd, 3-4 shells, a web-browser, and lots other stuff open. This lack of consistency makes me wonder if these programs made the transition as seemlessly as we'd thought. Oh well. Steve ------------------------------ From: John Minadeo Date: Mon, 15 Jul 1996 11:07:59 -0400 (EDT) Subject: Re: Quake Texture wads? On Sat, 13 Jul 1996, Jim Lowell wrote: > Anyone know where I can get some Quake texture wads? I believe that Stephen > Crowley's webpage has them but I can't find the URL for that page anywhere. > > Any help would be appreciated. > > -= Jim Lowell =- Fuck. I was gonna tell ya I had them, but I deleted 'em without thinking a few days ago... If you come across them, lemme know will ya. / / jminadeo@nforce.com / "Committee - A cul-de-sac to which / __ /_ __ / ideas are lured and then quietly / / ) / ) / ) / strangled." - John A. Lincoln (__/__(__/__/ /__/ /__ Minadeo / http://www.nforce.com ------------------------------ From: Tom Mustaine Date: Mon, 15 Jul 1996 12:20:33 -0600 (MDT) Subject: Re: Questions regarding Ambeince & More > X-gamers.org: quake-dev@gamers.org > > > > Anyhow, My question is in reference to the ambient sounds given off by > >Water and Sky areas. Does anybody know what conditions need to be met for a > >area of sky to give off the ambient "wind" sound? Or similar with a body of > >Water? According to the latest entity definition lists, there are no > >ambient placeable entities for these perticular sounds. John Romero > >mentioned to me that Quake was smart with its ambience, large bodies of > >water would give off the water sound, being close to a sky-the wind sound, > >lava, etc.... > > For a surface to be an ambient sound emitter ;), it mearly needs to have > the correct texture name. Here are the ones I could see looking at > the soundpvs.c file: > > *water > sky > *slime > *lava > *04water Well, This is the problem I am running into. I have areas with the above mentioned textures, specifically Sky4 and *water0. When close to these areas in the game, I hear nothing - The ambient sounds don't emit from those areas for whatever reason?! Ideas anybody? BTW: What editor are you using? heheh...I want to beta a editor so badly its not even funny, using edit is great, but I have upwards of 3000+ lines in the .map file now (300+ brushes, Lotsa lights, a few trigges, etc..) and it gets a litle hard to manage with EDIT. _____ _ _ [_. ._][ \ / ]-Tom Mustaine - Mustaine@usa.net - Aka: Paradox--- - | | | .V. | Design for Master Levels / Final Doom / & More | | | | | | "Genius...only a thought away..." [_] [_] [_]--[http://www.usa.net/~mustaine/quakerep.html]---- - - ------------------------------ From: Jim Lowell Date: Mon, 15 Jul 1996 14:37:59 -0500 Subject: Re: Questions regarding Ambeince & More At 12:20 PM 7/15/96 -0600, you wrote: > >Well, This is the problem I am running into. I have areas with the above >mentioned textures, specifically Sky4 and *water0. When close to these >areas in the game, I hear nothing - The ambient sounds don't emit from >those areas for whatever reason?! Ideas anybody? Don't know if you did this, but you have to run the level through VIS to get the ambient sounds. - -= Jim Lowell =- ------------------------------ From: Tom Mustaine Date: Mon, 15 Jul 1996 14:55:04 -0600 (MDT) Subject: Re: Questions regarding Ambeince & More > > X-gamers.org: quake-dev@gamers.org > > At 12:20 PM 7/15/96 -0600, you wrote: > > > >Well, This is the problem I am running into. I have areas with the above > >mentioned textures, specifically Sky4 and *water0. When close to these > >areas in the game, I hear nothing - The ambient sounds don't emit from > >those areas for whatever reason?! Ideas anybody? > > Don't know if you did this, but you have to run the level through VIS to get > the ambient sounds. > > -= Jim Lowell = Did that too, does it matter what order you run qbsp/vis/light in? I usually run Qbsp 1st, then Vis, then light. I'll try qbsp, then light, then vis. Mabye that might work. ------------------------------ From: Bret Stastny Date: Mon, 15 Jul 1996 14:37:33 -0700 Subject: Optimized Vis missing call to CalcAmbientSounds (); Jim Lowell wrote: > > At 12:20 PM 7/15/96 -0600, you wrote: > > > >Well, This is the problem I am running into. I have areas with the above > >mentioned textures, specifically Sky4 and *water0. When close to these > >areas in the game, I hear nothing - The ambient sounds don't emit from > >those areas for whatever reason?! Ideas anybody? > > Don't know if you did this, but you have to run the level through VIS to get > the ambient sounds. > > -= Jim Lowell =- Ahh, This just snapped in my head, those compiler optimized version of Vis, I uploaded, I removed the line CalcAmbientSounds (); line from it to check if it compiled and forgot to add it back in... A BIG BIG sorry to all, I will get a fixed version up today at ftp.best.com/j/jbcal/Qexes/Pro I will call it fixedvis.exe Sorry again to all. Bret ------------------------------ From: Bret Stastny Date: Mon, 15 Jul 1996 15:16:36 -0700 Subject: Uploaded new Vis Well they are there, I left the names the same ftp.best.com/j/jcbal/qexes/ vis.exe ftp.best.com/j/jcbal/qexes/pro vis.exe Sorry again if anyone wast