From quake-dev-owner@gamers.org Mon Jun 3 19:14 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 TAA05004 for ; Mon, 3 Jun 1996 19:14:17 +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 TAA24209 for ; Mon, 3 Jun 1996 19:15:37 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id NAA16177 for quake-dev-outgoing; Mon, 3 Jun 1996 13:06:27 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id NAA16150 for ; Mon, 3 Jun 1996 13:03:24 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id TAA04984; Mon, 3 Jun 1996 19:03:07 +0200 (MET DST) Date: Mon, 3 Jun 1996 19:03:07 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606031703.TAA04984@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de Subject: Info from John Carmack (1) X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 3473 X-Lines: 95 Status: RO I am going to forward a couple of mails to the list, with permission. This should have happened way earlier, btw., but work got the better of me the last weeks. b. This one immediately followed the mail about editing qtest1. ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Sun Apr 7 20:26 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Sun, 7 Apr 96 13:25:22 -0500 To: Bernd.Kreimeier@NeRo.Uni-Bonn.DE Subject: Re: qtest1 editors? >Problem: billboard object (sprite) support might be removed, or >incomplete. Billboards allow for good use of partly transparent >textures. They are going to stay in. All of the sprite types you mention are currently supported, and there is also a sprite type that always has the XY normal pointing towards the view, which is slightly different than parallel to the view plane. >1.1 The trailing zeros in a plane like > "( 0 816 0 ) ( 0 512 0 ) ( 16 512 0 ) TECH07_2 0 0 0" > >are s_ofs, t_ofs, and flags? I.e. a texture offset s_ofs=16, >t_ofs=-32, with negate_s, negate_t, and exch_st all set would read Exactly. In case you didn't figure it out already, the points that define the plane are not necessarlily points on the brush, but just three non colinear points on the plane. I chose this representation instead of a normal/distance form because it allows me to keep perfect precision with integral values. I fear floating point creep in many forms. >2.1 How does "qbsp" handle two brushes that do not intersect, but > merely "touch"? Contacting faces are merged out of existance. I'm pretty sure that a brush that has no thickness in a given dimension would clip itself out of existance and not show up at all in the bsp file, but I'm not positive. > >Levels carry their own textures with them. > > Would it be possible to include a dummy entry of two long int in > the BSP header? As a placeholder for an optional list of "15 > BIGDOOR" entries, to be ignored by the engine. I don't think any app specific data should be stored raw in bsp files. Store it in a key/value pair in the world entity. An unrecognized key name will get a warning from Quake, but you can either define a new variable in defs.qc (when I release the compiler), or just use a valid string variable key like "netname" or "weaponmodel". Or perhapse I should just ignore (or make notification a development option) unknown keys at load time? It is nice to know when you make a typo... > I wish you only had... I figured this out last week, and it will > hamper level design in the most subtle ways. I don't see any > convenient fix, though. It was originally a speed issue for building the surface caches, but a later insight rendered the problem moot. I would like to fix it, but it probably won't show until Quake 2. The current limitation that annoys the map guys most is that texture shifting is by multiples of 16. If I put in The Fix, the primary benefit would be pixel level shifting, but it would also allow arbitrary rotation and scaling. That is an easily abused feature, though... Overall, natural alignment makes creating good looking maps a lot easier, because you usually don't have to offset things at all to get them to line up. John Carmack ----- End Included Message ----- From quake-dev-owner@gamers.org Mon Jun 3 19:22 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 TAA05022 for ; Mon, 3 Jun 1996 19:20:45 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id NAA16209 for quake-dev-outgoing; Mon, 3 Jun 1996 13:12:15 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id NAA16205 for ; Mon, 3 Jun 1996 13:12:09 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id TAA04998; Mon, 3 Jun 1996 19:12:02 +0200 (MET DST) Date: Mon, 3 Jun 1996 19:12:02 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606031712.TAA04998@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de Subject: Info from John Carmack (2) X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 2523 X-Lines: 69 Status: RO ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Thu Apr 11 23:28 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Thu, 11 Apr 96 16:26:16 -0500 To: Bernd Kreimeier Subject: FYI Content-Type: text/plain; charset="us-ascii" Content-Length: 1199 For your information, prompted by the comment about the limit of 255 textures in a qtest1 level, the current format has expanded miptex, sofs, tofs, and flags to 16 bits. While we probably won't ship a level with more than about 64 textures in it, I agree, 256 is never really enough of anything. The limit on offsets also prevented us from using >256 size textures in some situations, which people will probably want to do even before hitting the 256 unique textures limit. All better now, in any case. On the NAT front, I am considering changing the .map definition to use arbitrary texture origin and S and T vectors on each plane, instead of the sofs / tofs / flags values that are currently there. That would enable any affine texture arrangement, including arbirary rotation and size changes. I still don't think that capability is going to make it into the .bsp format for quake1, but it seems very probably for quake2, and I might as well get the .map format ready for it. Its good to see some reasoned comments about my architecture. I will be trying to address as many things as I can while under the pressure of shipping the game... John Carmack ----- End Included Message ----- ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Tue Apr 16 21:07 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Tue, 16 Apr 96 14:07:50 -0500 To: Bernd.Kreimeier@NeRo.Uni-Bonn.DE Subject: another FYI Content-Type: text/plain; charset="us-ascii" Content-Length: 400 On the subject of storing additional info in .map and .bsp files, I decided that all key names that begin with an underscore will be dropped by quake, so you can store whatever you want in them for utility communication. I am probably going to change all of our map uses of "wad" and "light" to "_wad" and "_light" so I can remove the unused dummy variables from the progs. John Carmack ----- End Included Message ----- From quake-dev-owner@gamers.org Mon Jun 3 19:20 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 TAA05013 for ; Mon, 3 Jun 1996 19:19:02 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id NAA16227 for quake-dev-outgoing; Mon, 3 Jun 1996 13:15:59 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id NAA16223 for ; Mon, 3 Jun 1996 13:15:49 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id TAA05008; Mon, 3 Jun 1996 19:14:57 +0200 (MET DST) Date: Mon, 3 Jun 1996 19:14:57 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606031714.TAA05008@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de Subject: Info from John Carmack (3) X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 3417 X-Lines: 85 Status: RO ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Fri Apr 26 20:22 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Fri, 26 Apr 96 13:21:10 -0500 To: Bernd Kreimeier Subject: Re: q&a Content-Type: text/plain; charset="us-ascii" Content-Length: 2988 You wrote: > Q's: > > 1. I want to forward a posting of yours (to Brian Martin) > concerning z-fill/z-buffer usage to the QuakeDev list, to settle > the occasional "z-buffer?" threads. Do you have any objections > against making any of your mails to us public? I never say anything that can't be quoted. > 2. Will billboards (sprites, decals) be mipmapped in 1.0/2.0? Hadn't planned on it, because it would require alpha channel to properly mipmap a mixture of transparent and opaque pixels. > 3. Will the texture names in the BSP mipmaps lump stay? I want to > use them to store the info needed to add mipmaps to a BSP file w/o > mipmaps - use of "_wad" optional. Yes, they should still be there. Are you planning to use miptex without any pixels as placeholders for another utility to fill in? I don't really think that is a great idea. Yes, it takes a couple hundred K to cary the graphics with a level, but it is rarely more than 20% of a full sized map's disk footprint. We are going to give free license to redistribute our art in user maps for non-commercial purposes. Packaging it all into one file makes distribution so much easier -- people don't need to get both graphics and levels. > 4. qtest1 and your log seem to indicate that Quake will try to > preserve view_up as much as possible (except on being > dead/strifing). Does that mean that there will be no builtin > support for 360 degree rotations around LOS/no rotate_ccw/cw > commands to bind to a key? There is no direct way to do it, but you can set cl_rollangle to 45 or so to get a whole lot of roll... A linked in input driver can set the view angle to anything it wants, so HMD can roll arbitrarily. qc code can set any angle for other objects, but there are some restrictions on player views, due to the client side short-circuiting of view control (to reduce latency). > 5. I am looking at GNUstep, trying to guess the changes of a > QuakeEd Linux port using GNU gcc ObjectiveC support and the > (supposedly 85% done) GNUstep libraries. Have you ever considered > this option? What classes/libs does QuakeEd require? QuakeEd is written for NEXTSTEP 3.3, while GnuStep is an implementation of the OPENSTEP spec. I haven't had time to port it to openstep yet, but it looks like it will take a little effort. NeXT has tools in NS 4.0 to help, but it still isn't automatic. > 6. Is there any real gain in not doing the mipmapping down to 1x1? Yes, I need to keep a cache pointer for each surface and each mip level, so adding four more mip levels would eat 160k of ram on a 10,000 polygon level. > 7. Idle curiosity: what became of the spherically mapped sky? It is a very squashed sphere now. A true sphere looked like you were inside a beach ball. Currently on the hardware 3D boards, it is a flat mapping, but that looks pretty poor. We are probably going to subdivide on them to get the spherical projection. John Carmack ----- End Included Message ----- From quake-dev-owner@gamers.org Mon Jun 3 19:28 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 TAA05032 for ; Mon, 3 Jun 1996 19:28:39 +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 TAA24293 for ; Mon, 3 Jun 1996 19:26:01 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id NAA16256 for quake-dev-outgoing; Mon, 3 Jun 1996 13:19:40 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id NAA16251 for ; Mon, 3 Jun 1996 13:19:32 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id TAA05014; Mon, 3 Jun 1996 19:19:25 +0200 (MET DST) Date: Mon, 3 Jun 1996 19:19:25 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606031719.TAA05014@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de Subject: Info from John Carmack (3a) X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 3274 X-Lines: 74 Status: RO This is that earlier posting on z-buffer usage, as provided by Brian Martin. b. ------------------------------------------------------------------- >From johnc@idnewt.idsoftware.com Tue Mar 26 17:12:36 1996 Message-Id: <9603262211.AA22560@idnewt.idsoftware.com> Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Received: by NeXT.Mailer (1.118.3) From: John Carmack Date: Tue, 26 Mar 96 16:11:40 -0600 To: "Brian K. Martin" Subject: Re: quake models References: <199603261430.JAA27076@minerva.phyast.pitt.edu> Status: RO You wrote: > Yes, it would be a real pain in the ass to download a different mdl > file to the server for each player. That is out of the question. > But why don't you allow to add one more peice of info to be sent on > initialization besides the colors, that is a string for a name of > the mdl to use. like 'player2.mdl'. This would allow so many more > cool possibilities. You guys don't have to worry about supplying > the models, just make it possible to use them. My idea was to have > quake load up the default player.mdl, then if someone wanted to use > a different one, and the client had it on their disk, they could > use it. Of course the color values could still be used and maybe > even you could just overwrite existing mdl info so you don't need > to read in all the frames, maybe just the texture. I've been considering the options for a while, and an "optional model" field is probably pretty good. I wouldn't count on it for 1.0, but that is the type of thing that might make it in on a revision. > -- Also, would you be kind enough to give the relevance of the byte > in the frame data after the max bound values in the mdl files. It is unused. Three byte structures are non-portable, so it's just padded. > Also the precalculated indecies go up to 161, but there are some 255's > in the models that are set to dark with no gouraud shading. I found > that values like 162 could be used to make things like sparkles and > stuff. Is this planned of just on accident (i.e. should I pursue > this if I wanted to hack an mdl file? but I would never do that.) There shouldn't be any 255s. What model did you see them in? It may be a bug. > one other little thing. I was arguing to several people about quake > using a z-buffer to render models. I can find no proof, no one > believes me. Every one says it's too slow. (and it is, but it works > good). Any words? The alias models are z buffered. The world is rendered with Z fill, which costs about 15% over just the drawing. Yes, the z buffering hurts on really large models, but for the majority of them, it is a speed advantage. If the average polygon size is only a dozen pixels or so, doing a compare and store to the z buffer for each pixel is less work than sorting against the other polygons in the model (let alone properly sorting against the world). As for speed... We will ship about 20% faster than qtest1. The 486 performance will still be hopeless, but that is the price for going to a floating point intensive design. I still stand by it as the right decision for the lifespan of the product. John Carmack ----- End Included Message ----- From quake-dev-owner@gamers.org Mon Jun 3 19:31 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 TAA05037 for ; Mon, 3 Jun 1996 19:30:50 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id NAA16336 for quake-dev-outgoing; Mon, 3 Jun 1996 13:29:12 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id NAA16296 for ; Mon, 3 Jun 1996 13:24:55 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id TAA05026; Mon, 3 Jun 1996 19:24:50 +0200 (MET DST) Date: Mon, 3 Jun 1996 19:24:50 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606031724.TAA05026@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de Subject: Info from John Carmack (4) X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 2984 X-Lines: 87 Status: RO ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Sat May 11 05:46 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Fri, 10 May 96 22:46:23 -0500 To: Bernd Kreimeier Subject: Re: q&a (2) Content-Type: text/plain; charset="us-ascii" Content-Length: 2727 You wrote: > 1. The Quake registered (==shareware?) will still be released as > DJGPP-linkeable modules? The initial 0.9 will not, but some later version will. I'm not sure if the initial CD pressing will, because there won't be any external drivers yet. The will be net released at some point for sure. > Followup: Iff, will the linux version be on the same CDROM? As > modules (gcc-linkeable) as well? I would hate to see DOS get the > better of this. Or looseDOWS. I have intentions to do so, but since Dave Talor left id, there is nobody here actively running linux, so it can get pushed out of the way by other issues pretty easily. Dave is still going to support the unix ports for us, but it is less of a priority. Yes, unix versions are cool, but they don't rank that high on the priority list. > 2. The COLORMAP remapping of the WAD2 palette for lighting (32 > steps again?) is part of the EXE now? Its an external data lump now, so the palette and colormapping (including fullbrighting) can be completely changed. > Followup: like the normal vectors used with the MDL, wouldn't it be > a better idea to keep any lookups outside the EXE, to prevent EXE > hacking, and ease configuration? ;-) > 3. Is the design of QuakeC vs. physics of the game flexible enough > to separate "blast" (momentum transfer) from "damage", i.e. pushing > an armored target without hurting it (area effects, not direct > hits)? Absolutely. Romero has asked me to do this a number of times, but I haven't gotten around to it. A while ago, we had mosnter cannons that chucked bad guys out of a piston, but it went away with some redesign. > Followup: will involuntary movements (like being pushed by an > explosion) change the view_up (including roll)? Whatever > restrictions on GUI/net packet size, preserving the view_up during > involuntary movements (falling) seems to make things "stiff" by > design. I let the client short curcuit the view angle in most cases, so the server doesn't usually override it. It's possible, though. > 4. Just a confirmation: the z-fill is done as a separate pass, not > within the texture mapping loop, because of (lack of) registers on > i586? Exactly. > Better performance on other CPU's? Alpha? Unlikely, because we have a fair amount of hand coded intel ASM. A 21164 certainly won't be a slug, though. I still need to fix a little 64 bitism in my code before it is going to work on alphas, though. I will get that done for sure. John Carmack ----- End Included Message ----- From quake-dev-owner@gamers.org Mon Jun 3 19:42 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 TAA05056 for ; Mon, 3 Jun 1996 19:41:32 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id NAA16460 for quake-dev-outgoing; Mon, 3 Jun 1996 13:38:50 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id NAA16452 for ; Mon, 3 Jun 1996 13:38:35 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id TAA05046; Mon, 3 Jun 1996 19:38:32 +0200 (MET DST) Date: Mon, 3 Jun 1996 19:38:32 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606031738.TAA05046@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de Subject: Info from John Carmack (5) X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 7694 X-Lines: 172 Status: RO ----- Begin Included Message ----- >From johnc@idcanon1.idsoftware.com Sat May 18 04:38 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Fri, 17 May 96 21:38:15 -0500 To: Bernd Kreimeier Subject: Re: q&a (3) Content-Type: text/plain; charset="us-ascii" Content-Length: 7321 You wrote: > Two shorts, one int. Two longs you might want to ignore. > > Q: you are using the "portals" mentioned in the worklog during PVS > computation, as described in Seth Tellers PhD? Similar idea, different implementation. Someone refered me to Teller's papers after I had a non-robust version of Quake PVS running, and it clarified some things in my mind, but was definatly a different tack from what I would up doing. I certainly don't retain any of the portal chain information for run time culling -- the map files are too huge as it is. I use a gross leaf to leaf PVS bit table, then the hierarchal BSP bounding volumes for frustom culling. > Q: I understand the short circuiting of view control on the client. > Is it correct that only yaw/pitch (determining movement along > current LOS and aiming) are transfered to the server? Is this > "hardwired" in the net packet structure? The server only rarely sends view angle information to the clients (enteting level, teleporters, etc). The client has full control over the view angles (all of them) most of the time, and sends all three view angles to the server each frame. This can be removed for things like tracking the monster that killed you when you are on the ground. > > Q: if I understood correctly - mipmpas are created by qbsp each > time anew, using a WAD file (old style? TEXTURE1/2, PNAMES?). There > is no Mipmaps WAD lump. > > Suggestion: how about including the DOOM > shareware/registered/commercial patches, PNAMES and textures on the > Quake CD, too? Removing all the monster frame rotations will > protect DOOM sales (as far as this is possible anyway). Permitting > redistribution will ease conversions a lot. It increases the pool > to draw [sic!] from. It looks good in the shops (added value). The > artwork was a major part of DOOM's success, it deserves a mipmapped > afterlife ;-). The mipmaps are creaated by qlumpy into new format wad files (just about the only remaining use of them -- they were intended to be used heavily, but I wound up going with the much superior search path / directory hierarchy aproach), but those are only referenced by QuakeEd and qbsp, which copies the needed ones into the map .bsp file directly. We used some DOOM graphics early on, but the palettes are different enough that the artwork is damaged in the conversion. Artists tend to be picky about showing degraded versions of their work :-) Don't worry, there are lots of really good Quake graphics. > > > Q: have you at some point thought about entities that are not > occluded by surfaces, i.e. always rendered on top of everything > else if within the view frustrum (no PVS)? > > Purpose: there is no automap for good reasons. I have tried a > look-through 2D automap with a DOOM-style renderer and found it > confusing, a 3D one is prolly even more useless. > > However, the concept of an (annotated) marker entity seems worth > bothering: an object that can be dropped, or shot at/attached to > another entity, that is always visible even through walls (in a > certain view mode, at least). It gives the player a sense of > direction to move along, but he still has to remember the structure > of the map. The advantages for hunting games are obvious: a tagged > target will always be visible, but is still difficult to hunt down > and trap. > I don't think that is a good idea. When an object shows through it's natural occluders, it give a pretty serious optical illusion that the things it is showing through are translucent, damaging the rock-solid feel of the world. > > Q: this is a not too specific remark (thus lengthy). If I > understood correctly, RGBA support is supposed to be a major > benefit of upcoming hardware (i.e. might be available in 1997 :). > It seems to me that the current engine design is biased with > respect to index color mode. Examples: > > + WAD2 Palette now contains 256 RGB values, it might as well > contain a NoOfColors field (256, 4096), and RGBA entries (32bit or > 48bit) at virtually no costs (ignored in index color mode) > > + Mipmaps and billboards implicitely reference one Palette, they > might as well explicitely reference a Palette (ignored in index > color mode) > > + billboards do not have mipmapping (no blending in indexed color > mode), but they might as well have (if w/o blending, it is still > LOD, and sprites will show more variation) > > Low overhead suggestion: bright objects (light sources) might > (implicitely) use a second, different Palette in 24bit modes. > > Followup: How is the lightmap+mipmap -> surface cache processing > done in 24 bit mode? Same LUT with same 256 colors? Or > NoOfLightlevel*256 true color values? Some comments: originally, we maintained 8, 16, and 32 bit code for all of our drawing, and we worked in every conceivable video mode. This was a major pain in the ass to maintain. 16 bit color looked noticably WORSE than 8 bit color, because while we have smooth 16 color gradiants of some non primary colors that look fine in 256 color mode (18 bits of color precision), in 15 or 16 bit mode there is a noticable hue change every time you are forced to drift a bit off of your ideal color. 24 bit color looked better than 8 bit, but not a whole lot. This is mostly due to good source images. For an arbitrary image processing solution where you can chuck any old set of pixels at it, any direct color mode is going to be a ton better, but when you have control over your source data you can pick and choose to make 8 bit outperform 16 bit, and save all the extra space and processing time. We do occasionally take a lose in the mip map creation process for lack of good colors in the palette, but I do an error diffusion during the resampling, which helps a lot. Lighting direct color images hurts a fair amount, too. MMX is really nice for that, but without it you either need huge tables or lots of bit twiddling. All that said, Quake is still my last indexed color engine. I still think it is the right call for this moment in time, but the future is definatly direct color. > Followup: is the current 3D hardware worth to be taken into account > in renderer design? I.e. are there ways to use RGBA e.g. for > processing lightmaps (as Alpha-map implicitely blending with a > solid black)? How does the lightmap+mipmap processing fit with > on-board texture memory anyway? A max-throughput engine is still going to use small, tiled textures in hardware, just as in software. I think the image quality tradeofs of surface caches are worth the speed cost, though. 3DFX has done some light map building demos with the hardware, and rendition could certainly be programmed to do it. I suspect that all of the Quake drivers will still build the surface caches in software, because many of the current 3D boards have high setup overhead per primitive, and drawing tons of little boxes would suck. Rasterization hardware is definatly the future. Soon you will not be able to buy a computer without it, because it can be implemented in the same single chip video controllers currently used, and it will become a checkbox item. John Carmack ----- End Included Message ----- From quake-dev-owner@gamers.org Mon Jun 3 19:51 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 TAA05070 for ; Mon, 3 Jun 1996 19:51:20 +0200 (MET DST) Received: from gamers.org (thegate.gamers.org [128.205.37.150]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with ESMTP id TAA24441 for ; Mon, 3 Jun 1996 19:51:05 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id NAA16572 for quake-dev-outgoing; Mon, 3 Jun 1996 13:46:36 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id NAA16567 for ; Mon, 3 Jun 1996 13:46:23 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id TAA05060; Mon, 3 Jun 1996 19:45:57 +0200 (MET DST) Date: Mon, 3 Jun 1996 19:45:57 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606031745.TAA05060@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de Subject: Info from John Carmack (6) X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 4235 X-Lines: 118 Status: RO In march, following the CeBit fair, I asked about support of the S3 ViRGE and ViRGE/VX. I add that one short reply to the discussion of 3D hardware in the more recent posting. b. ----- Begin Included Message ----- From: John Carmack Date: Sat, 16 Mar 96 15:00:50 -0600 To: Bernd Kreimeier Subject: Re: Verite premier platform We are supporting both S3 and rendition for release. Rendition should be a bit faster. John Carmack ----- End Included Message ----- ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Fri May 24 22:32 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Fri, 24 May 96 15:32:46 -0500 To: Bernd Kreimeier Subject: Re: q&a (4) Content-Type: text/plain; charset="us-ascii" Content-Length: 3183 You wrote: > Q: Brush.h in the QuakeEd sources is obsolete, it refers to > EditWindow.h and is not imported at all. Is this part of something > new (Brush Editor) that is not released yet, or a leftover? > It was a leftover. Delete it. > > Q: qbsp, vis, light and qlumpy are written in C? ObjectiveC? If the > latter, using only common classes (in gcc libobjc.a), or anything > more NS specific? Pure C. ( Pure ANSI, in fact, except for cwd() ) They compile on practically anything. > > > Q: You wrote: > >I am eagerly looking forward to writing a brand new editor for > >windows NT + open GL as soon as Quake ships. > > Reminds me of two drawbacks I foresee with the Verite cards: > a) Rendition never indicated OpenGL support (but supports HEIDI) > b) judging from their zero-response, XFree86 support will suffer from > NDA and Matrox-style attitude. Am I wrong? I'd rather be wrong: the > Verite looks very interesting, esp. if programming the RISC would > be an option for pedestrians, too. The Technical Specs on the > Chromatic pages are much more promising in that regard, i.e. open > to the public. I doubt we will see a verite GL driver, but I did mention it to them. They are dram based, so it isn't a real workstation class card anyway. They are pretty decent folks, so I don't think XFree86 support is out of the question. I'll mention it next time I talk with them. I suspect they are just in crunch mode and don't have the time to devote to freeware projects. I think being open with the RISC programming would be to their best advantage, becaue demo-coder types would be able to do incredibly impressive stuff with it. > Q: In addition to S3 and Verite: have you had the time to evaluate > other cards/chips? Pyramid3D or Chromatic? Not the GLINT300SX for > obvious reasons. Too bad 3D Labs targets a different market, they > already support a Mesa driver project. GLINT300TX + GLINT delta will be a kick-ass workstation setup. 3DFX has the best fill rate around. ATI is no good, because it doesn't have a Z buffer at the moment. I haven't evaluated Pyramid3D or Chromatic. I have an intergraph GL workstation, which is a solid performer, and they have new technology coming out in a few months, but it isn't consumer level stuff. BTW, I just became aware of Mesa last week, and I am very impressed with it. I hope to contribute something to the project when I have more time. I may compatability check my new editor against it. > > Q: Idle curiosity: Michael Abrash mentioned a "Vertex-free > surfaces" approach to Visible Surface Determination that sounded > like using a MAP-like representation for rendering as well. Have > you looked at the NEC/VideoLogic PowerVR chip, which, to my > understanding, uses a similar representation? It was more like using an ultra simple bsp, like the clipping hull, to directly generate the scene. It was cool, and very very space efficient, but not fast enough. It would run great on the PowerVR chip, but because that is such a strange (not mainstream) paradigm, I don't predict great acceptance of PowerVR. John Carmack ----- End Included Message ----- From quake-dev-owner@gamers.org Mon Jun 3 20:18 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 UAA05103 for ; Mon, 3 Jun 1996 20:16:50 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id OAA16978 for quake-dev-outgoing; Mon, 3 Jun 1996 14:13:37 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id OAA16973 for ; Mon, 3 Jun 1996 14:13:29 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id UAA05097; Mon, 3 Jun 1996 20:13:28 +0200 (MET DST) Date: Mon, 3 Jun 1996 20:13:28 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606031813.UAA05097@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de Subject: Info from John Carmack (7) X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 3963 X-Lines: 98 Status: RO Last but one. Please note that this is the accumulated log since march, less than one q&q per week on average. Note the postscriptum. I will update the Hypermail archive ASAP, and encourage everybody to add other bits of information they got, to keep *me* from asking more stupid questions. Thanks. b. ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Mon Jun 3 18:08 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Mon, 3 Jun 96 11:07:47 -0500 To: Bernd Kreimeier Subject: Re: q&a (4a) ? Content-Type: text/plain; charset="us-ascii" Content-Length: 3389 You wrote: > Q: In the qtest1 palette, there are >= 16 colors all white. Has the > palette changed, i.e. has it been unfinished? Would it be possible > to release the current/final version? We added another range of fullbright explosion colors, I don't think anything else has changed. > Q: Would you mind providing a hint on the "sealing" of a map? Does > this include a processing step like mentioned by Seth Teller, > fixing small gaps and holes to reduce vis computation and PVS size, > or is it determining "sky" surfaces? I don't fix any small gaps, but removing all the crud on the outside of the level more than halves the data size. After building the BSP tree of the world, I build a graph of the portals between the leaf nodes, then do a simple graph flood fill from the outside of the world. If it ever reaches a leaf with an entity (light, player, etc) in it, it assumes that it leaked inside the level and writes a pointfile containing a trail of dots that can be loaded into quake to find the path that went through the hole. > Q: on NATs and the new MAP format. You wrote: > > >On the NAT front, I am considering changing the .map definition > >to use arbitrary texture origin and S and T vectors on each > >plane, instead of the sofs / tofs / flags values that are > >currently there. > > I expected something like ( x,y,z,s,t ). Instead, there are two > additional values in jrbase1.map that seem to be always 1.0000. > This is supposed to be scaling, in addition to sofs/tofs/flags? > There are "sizing" buttons in the early screenshots of QuakeEd. Or > am I missing something? The textures are arbitrary now, but the definition is a bit confusing. My first thought was "just include S and T vectors on each surface". That is the simple, straightforward representation, but it is bad for editing, because every deformation of a brush needs to modify the vectors. I wound up representing the textures as modifications off of natural texture alignment. shift and scale on each axis plus rotation. It feels clunky, and I doubt it is The Right Thing. > > >BTW, I just became aware of Mesa last week, and I am very > >impressed with it. I hope to contribute something to the > >project when I have more time. I may compatability check my new > >editor against it. > > Actually, texture mapping (esp. mipmapping) is not yet complete (as > of 1.2.8, which is supposed to be the last release for about 6 > months). How about a i586 optimized driver, btw :-)? Mipmapping isn't crucial. I saw the basic wrap/clamp test running, and I glanced at the code, so I don't think it is too horribly far off. I did notice that the parallel array structure of the texture mapping polygon rasterizer is going to guarantee cache associativity collisions on every single scan line. If I can find some time, I would like to donate some work, but my time is a pretty damn scarce commodity. John Carmack ps: I encourage you to share my comments with the rest of the community that might be interested, in the hope of preventing my answering the same questions multiple times... ----- End Included Message ----- From quake-dev-owner@gamers.org Mon Jun 3 20:45 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 UAA05132 for ; Mon, 3 Jun 1996 20:45:46 +0200 (MET DST) Received: from gamers.org (thegate.gamers.org [128.205.37.150]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with ESMTP id UAA25178 for ; Mon, 3 Jun 1996 20:46:23 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id OAA17220 for quake-dev-outgoing; Mon, 3 Jun 1996 14:40:11 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id OAA17213 for ; Mon, 3 Jun 1996 14:40:04 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id UAA05122; Mon, 3 Jun 1996 20:40:14 +0200 (MET DST) Date: Mon, 3 Jun 1996 20:40:14 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606031840.UAA05122@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de Subject: Info from John Carmack (8) X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 4421 X-Lines: 108 Status: RO Done. From now on, I will simply forward any other info to this list as soon as I get it, which will simplify things a lot. Take your time to digest... b. ----- Begin Included Message ----- >From johnc@idcanon1.idsoftware.com Sat Jun 1 20:00 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Sat, 1 Jun 96 13:00:27 -0500 To: Bernd Kreimeier Subject: Re: q&a (5) Content-Type: text/plain; charset="us-ascii" Content-Length: 3818 You wrote: > I stumbled across the following two quotes: > > "Carmack made mention of redoing Quake Ed file structure because of > this" (related to some intrusion attempt, I gather) > > Q: Is the MAP format going to change? Btw., sounds strange, what'd > be the advantage (in relation to some pirated pre-release engine)? If the registered pak file had been stolen, but a functional exe had been, then I would probably have made a change to make the final released exe not recognize all the .bsp files in the pirated registered pak file. In any case, they didn't get any data, so I'm not messing with it. > > "Carmack is about 1/3 finished with an NT version of our Map > editor" > > Q: The NT version is done using VC++? Are you going to release that > source? It'd be convenient to port a C++/OpenGL version to Linux. > And futile to reinvent the wheel after the fact. > 1/3 finished is a biiig overstatement. I have the editor view layout mostly functional on my intergraph GL accelerated NT system (its way cool to be running around the map with blended transparent walls in realtime), but it will take me at least a solid two weeks of work after quake's release before the editor is really ready for prime time. I don't know about "futile"... I was actually looking forward to seeing what other people come up with for editor interaction paradigms. If you mean a straight port of QuakeEd, yeah, it might be a waste of time. > You are moving way to fast for weekend code warriors. I managed to > built, change and toy around with QuakeEd (logged my first three > hours on a NeXT - too bad there is no IB and ObjectiveC for Linux). GCC does objective C right now, but it would still be a major porting effor to move it to objc-X or gnustep. > Q: are there any distribution restrictions you want me to put on > QuakeEd related stuff? That is: screenshosts, derivatives of > jrbase1.map, modified sources, NeXT binaries. There is no > qbsp&Cie., thus I cannot imagine any damage (besides spoiling > jrbase1 prior to SW release). However, please let me know. I put it up without consulting our lawyers :-) Consider it all available for any not-for-profit use. > > On the new editor: > > Q: are you going to include any DDE/IPC connection of Quake and > Quakeed? I.e. moving the camera in the editor moves the POV in > Quake, and switches start/stop monster animation etc. For entity > placement and even texture alignment (or lighting), no BSP built > should be necessary. OpenGL previewing might ease texture alignment > pains, but entity placement and fine-tuning the map needs test runs > using the AI. In principle, one needs a way to have server move one > client according to the commands of another client. > > Q: reminds me: still planning on releasing the server sources? All of the .qc code will be relased (QuakeEd parses it for entity names, anyway), but I have gotten a little more reticent about releasing object code and some C code just from a control point of view. Anyway, for large scale server issues it turns out that the best way to control quake is with a wrapper program, instead of modifying internal code. The qc compiler and source will come out withing a couple days of release. I could release the bsp tools around the same time, but I'm not sure if anyone can use them until a generally accessable editor is made. I will release the code for the NT editor when I get it nice and stable. In wireframe mode that should run acceptably even on an unaccelerated system, but it is being designed for hardware acceleration. When everything settles down (version 1.3 or so, probably) I may release the object code with some source files for serious internal tweaking. John Carmack ----- End Included Message ----- From quake-dev-owner@gamers.org Thu Jun 6 12:54 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 MAA13206 for ; Thu, 6 Jun 1996 12:54:38 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id GAA13461 for quake-dev-outgoing; Thu, 6 Jun 1996 06:52:21 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id GAA13454 for ; Thu, 6 Jun 1996 06:52:04 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id MAA13194; Thu, 6 Jun 1996 12:51:48 +0200 (MET DST) Date: Thu, 6 Jun 1996 12:51:48 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606061051.MAA13194@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de Subject: QuakeEd 1.2 upload/test1.map X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 1640 X-Lines: 41 Status: RO I have uploaded with permission on http://www.gamers.org/dEngine/archive/ the following files: QuakeEd-1.2.bin.next-m68k.tgz - a QuakeEd binary QuakeEd-1.2.src.tgz - the current source version QuakeEd-1.2.map.tgz - map files, including test1 test1.map.gz - the qtest1 test1.map file This is not a production release, but it should be useful to anybody having occasional access to a NeXT (like me) and trying to design a GUI for editing. You might even be able to do some map editing. There is no miptex support (yet). Later releases will find their way to ftp.cdrom.com, but I do not think 1.2 is ready for widespread use. Please let me know about any problems ASAP. In addition, John Carmack released the test1.map source as used in the Quake qtest1 release. This offers every BSP builder out there a chance to compare the results on test1.map against the BSP file in qtest1. To anybody working with/modifying QuakeEd: I am maintaing the current sources with CVS. Please send me any patches/diffs/ extensions you are doing, and I will incorporate them in the base. You NeXT guys currently have an advantage :-) but by the time NeXTQuake might be available, QuakeEd might still be the only working editor available to you, so it makes sense to take care of it. Thanks to Steve Larsen who provided his sources and patches for this release, and to Jean-Paul, Jan and Jelske for providing help and NeXT access. Thanks to Vareck Bostrom as well. b. From quake-dev-owner@gamers.org Thu Jun 6 13:37 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 NAA13276 for ; Thu, 6 Jun 1996 13:37:32 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id HAA13710 for quake-dev-outgoing; Thu, 6 Jun 1996 07:36:37 -0400 Received: from relay.bt.net (relay.bt.net [194.72.6.52]) by gamers.org (thegate/gamers) with SMTP id HAA13706 for ; Thu, 6 Jun 1996 07:36:34 -0400 Received: from onlinemagic.com (actually flash.onlinemagic.com) by relay.bt.net with SMTP (PP); Thu, 6 Jun 1996 12:36:13 +0100 Received: by onlinemagic.com (SMI-8.6/SMI-SVR4) id NAA26866; Thu, 6 Jun 1996 13:31:54 +0100 From: jschuur@onlinemagic.com Date: Thu, 6 Jun 1996 12:31:54 +0000 (GMT) To: quake-dev@gamers.org Subject: Re: QuakeEd 1.2 upload/test1.map In-Reply-To: <199606061051.MAA13194@marvin.nero.uni-bonn.de> Message-ID: MIME-Version: 1.0 Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 15 Status: RO Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 603 can you clarify this bern: this version include patches and improvements made to quakeed by people other than id? what about changed johnc has made to quakeed? (his work log indicates that some things were changed in the past week or two). good to see someone is working on the code already. -- joost schuur, Online Magic Ltd. ----------- Tel: +44 171 820 7766 -- ----------------------------------------------------------------------- ---------------------------------------------------------------------- --- http://www.nuqneH.org/~jschuur/ ---- jschuur@onlinemagic.co.uk --- From quake-dev-owner@gamers.org Thu Jun 6 14:02 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 OAA13325 for ; Thu, 6 Jun 1996 14:02:08 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id IAA13878 for quake-dev-outgoing; Thu, 6 Jun 1996 08:01:08 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id IAA13874 for ; Thu, 6 Jun 1996 08:01:02 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id OAA13321 for quake-dev@gamers.org; Thu, 6 Jun 1996 14:00:58 +0200 (MET DST) Date: Thu, 6 Jun 1996 14:00:58 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606061200.OAA13321@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org Subject: Re: QuakeEd 1.2 upload/test1.map X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 1799 X-Lines: 56 Status: RO > can you clarify this bern: this version include patches and > improvements made to quakeed by people other than id? A few patches, yep, improvements, nope. > what about changed johnc has made to quakeed? (his work log indicates > that some things were changed in the past week or two) Not included. Yes, there seem to be at least the following ones: * QuakeEd: fixed crash when misselecting an entity angle * QuakeEd: forbid dragging position / direction when textured and some intended: QuakeEd: goto point in command window QuakeEd: view pos button QuakeEd: don't explode if /qcache isn't present QuakeEd: top trace for shearing is at 2048, increase to 8192 This is a problem for several reasons: a) his worklog technique makes it tedious to track this, because you will have to look fot those retrospect "+" entries, too. b) it is not worth while to bother anybody :-) on each single change as long as QuakeEd is not in widespread use c) I did not bother to import QuakeEd in CVS for tracking third party sources (which would have been appropriate for frequent updates) - as I do not benefit that much from the NeXT version, I simply cannot afford the time. I intend to get back to this once they shipped, and he abandoned QuakeEd for his new NT/OpenGL editor. In the meantime, it is more important to 1) get a mipmap WAD2 file done (thus NeXT users might be able to create maps) 2) get a bsp builder running (thus NeXT users will be able to generate maps they can`t play :) and, most important IMO: 3) get a working editor done for Linux :-). Hope this clarifies the issue. b. From quake-dev-owner@gamers.org Thu Jun 6 14:41 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 OAA13593 for ; Thu, 6 Jun 1996 14:41:18 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id IAA14139 for quake-dev-outgoing; Thu, 6 Jun 1996 08:39:08 -0400 Received: from relay.bt.net (relay.bt.net [194.72.6.52]) by gamers.org (thegate/gamers) with SMTP id IAA14135 for ; Thu, 6 Jun 1996 08:39:03 -0400 Received: from onlinemagic.com (actually flash.onlinemagic.com) by relay.bt.net with SMTP (PP); Thu, 6 Jun 1996 13:38:22 +0100 Received: by onlinemagic.com (SMI-8.6/SMI-SVR4) id OAA28013; Thu, 6 Jun 1996 14:33:43 +0100 From: jschuur@onlinemagic.com Date: Thu, 6 Jun 1996 13:33:43 +0000 (GMT) To: quake-dev@gamers.org Subject: Re: QuakeEd 1.2 upload/test1.map In-Reply-To: <199606061200.OAA13321@marvin.nero.uni-bonn.de> Message-ID: MIME-Version: 1.0 Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 19 Status: RO Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 590 On Thu, 6 Jun 1996, Bernd Kreimeier wrote: > 3) get a working editor done for Linux :-). speaking of that, for those who haven't seen it: http://www.canweb.net/~fisty/shaker/ although it appears the author doesn't currently have as much time as he'd like for this project, -- joost schuur, Online Magic Ltd. ----------- Tel: +44 171 820 7766 -- ----------------------------------------------------------------------- ---------------------------------------------------------------------- --- http://www.nuqneH.org/~jschuur/ ---- jschuur@onlinemagic.co.uk --- From quake-dev-owner@gamers.org Thu Jun 6 17:15 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 RAA13908 for ; Thu, 6 Jun 1996 17:15:36 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id LAA15277 for quake-dev-outgoing; Thu, 6 Jun 1996 11:14:07 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id LAA15266 for ; Thu, 6 Jun 1996 11:14:02 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id RAA13896; Thu, 6 Jun 1996 17:13:44 +0200 (MET DST) Date: Thu, 6 Jun 1996 17:13:44 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606061513.RAA13896@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org Subject: Re: QuakeEd 1.2 upload/test1.map X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 1421 X-Lines: 36 Status: RO At least two people seemed to have problems downloading the test1.map.gz. I took the opportunity and cleaned it up (the original NeXT mail from John Carmack had lots of CR/LF inserts breaking up brushes - a brush apparently has to be defined in a single line/removed the "wad" key/ removed "angle"/added "message"/moved "classname" to top), and checked it with QuakeEd. The download problems might be NerdsCraps fault - use SaveLinkAs, beware that the friggin decompresses on the fly. Observations I made on the occasion: a) the POV can be moved with mouse drag&drop, in both XYView and ZScrollView b) no auto-center is performed in XY View c) no auto-detect of current height is done d) on a NeXT cube, PageUp/Down for "next floor up/down" is not available - use ZScroll drag as workaround e) besides being smaller than jrbase1, test1 seems to be slower (or I am getting impatient :) You might get loads of warnings "Entity with no brush and esize_model" on loading the map (it happend with the original one, haven`t checked again). b. P.S.: 'nother thing I learned about how to do an editor is that switching to wireframe/solid, or omitting faraway brushes should be done automatically during movement, with check on framerate. User sets preference, not mode. From quake-dev-owner@gamers.org Thu Jun 6 17:15 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 RAA13911 for ; Thu, 6 Jun 1996 17:15:43 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id LAA15265 for quake-dev-outgoing; Thu, 6 Jun 1996 11:14:01 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id LAA15261 for ; Thu, 6 Jun 1996 11:13:56 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id RAA13898; Thu, 6 Jun 1996 17:13:53 +0200 (MET DST) Date: Thu, 6 Jun 1996 17:13:53 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606061513.RAA13898@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de Subject: Editor GUI design X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 2026 X-Lines: 59 Status: RO Joost wrote: >> a working editor for Linux > speaking of that, for those who haven't seen it: > > http://www.canweb.net/~fisty/shaker/ Reminds me. The screenshots there and incompetently toying around with QuakeEd raised a few issues I would like get some opinions on - namely what an editor should/should not do. Just to get things started (gee, from the looks of it I am the only one using this mailing list), here`s one. More to come. 1) The Axial Bias I haven`t had the opportunity to do serious work with QuakeEd, however, one thing that caught my eye is a certain bias towards axial blocks. First, it is the thing the most easiest to create and manipulate with QuakeEd. You will apply CSG operations to those, mostly. In the end, the overwhelming majority of brushes/polygons is axial. Possible solutions: -Brush (Group) rotation operations -Brush Templates, (sets of) polyhedra approximating curved, non-axial surfaces, just a libary -a separate Brush Editor (Mode) -DXF/3DS Import Btw. it seems that in QuakeEd there is no way to load a MAP file into a MAP file - the help says "a selection is not cleared when loading a new map, so selections can be brought over from other files", which works, but looks a bit like putting the horse in the saddle... if you catch my drift. Secondly, the View Modes encourage use of axial brushes. The look/down XY View does not invite editing multi-storey editing (there might be a decent z-clipping available, haven`t checked). The Z ScrollView emphasizes this. The CameraView is controlled by DOOM-style cursor movement - there is no mlook, not even a limited look-up/down (not even a fly mode, but a floor up/down). The engine is capable of 3 DoF in both movement and orientation, thus an editor has to have this feature, too. Possible solutions: -mlook mode -4 Views, three of them axial, one free Comments anybody? b. From quake-dev-owner@gamers.org Thu Jun 6 18:32 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 SAA13947 for ; Thu, 6 Jun 1996 18:26:56 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id MAA15906 for quake-dev-outgoing; Thu, 6 Jun 1996 12:24:29 -0400 Received: from xr3.atlas.fr (xr3.atlas.fr [194.51.9.5]) by gamers.org (thegate/gamers) with ESMTP id MAA15902 for ; Thu, 6 Jun 1996 12:24:24 -0400 Thu, 6 Jun 1996 18:24:19 +0200 Thu, 6 Jun 1996 18:24:19 +0200 Thu, 6 Jun 1996 18:24:12 +0200 X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Thu, 6 Jun 1996 18:24:19 +0200 X400-Received: by mta xr3.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Thu, 6 Jun 1996 18:24:19 +0200 X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Thu, 6 Jun 1996 18:24:15 +0200 X400-Received: by /PRMD=cnet/ADMD=atlas/C=fr/; Relayed; Thu, 6 Jun 1996 18:24:12 +0200 Date: Thu, 6 Jun 1996 18:24:12 +0200 X400-Originator: montanuy@lsun80.lannion.cnet.fr X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=cnet/ADMD=atlas/C=fr/;834078252@x400.lannion.cnet.fr] X400-Content-Type: P2-1984 (2) Content-Identifier: RE: Editor GUI d Alternate-Recipient: Allowed From: Olivier Montanuy Message-ID: <9606061623.32444C@lat1192.l...> To: quake-dev@gamers.org Subject: RE: Editor GUI design X-Mailer: E-Mail 1.6 Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 1374 X-Lines: 39 Status: RO -----Warning: this message is diplomatically challenged----- [cut-off from Bernd's message...] >The engine is capable of 3 DoF in both movement and orientation, >thus an editor has to have this feature, too. >Comments anybody? Comment is simple: Quake levels are closed. just like Descent mines. how the heck do you think one creates a mine? You walk inside and you cut your way throught the walls, using a suitably shaped object. The .MAP format made of filled convex blocks isn't suitable, in my not possibly humble opinion. That's the way you build houses in the open, not the way you dig mines. What do we care about the exterior of the level? How come it's even calculated? It can even cause errors (leakage). If the map files were substractive (i.e.made of empty blocks, in a filled space, instead of filled block in empty space, it would be much easier to edit and generate. And of course, you should be able to edit the level while walking inside, not via some lame combination of 2D views or delayed camera view. That screams for a portal based scheme. Another company will do it, and will bite market shares off id. Guess who. Not everyone is lost in the Realms of 3D. I might calm down once I get my hands on a PPro 200, but I doubt many Quake players/editors can afford one. The Arrogant Frog (who else?) From quake-dev-owner@gamers.org Thu Jun 6 19:04 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 TAA13981 for ; Thu, 6 Jun 1996 19:04:03 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id NAA16293 for quake-dev-outgoing; Thu, 6 Jun 1996 13:02:35 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id NAA16288 for ; Thu, 6 Jun 1996 13:02:29 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id TAA13977 for quake-dev@gamers.org; Thu, 6 Jun 1996 19:03:17 +0200 (MET DST) Date: Thu, 6 Jun 1996 19:03:17 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606061703.TAA13977@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org Subject: RE: Editor GUI design X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 1733 X-Lines: 44 Status: RO >Comment is simple: Quake levels are closed. >a mine? You walk inside and you cut your >way throught the walls, using a suitably shaped object. Right. >If the map files were substractive (i.e.made of empty >blocks, in a filled space, instead of filled block in >empty space, it would be much easier to edit and generate. QuakeEd CSG supports this. I am currently working my way through the help.txt (RTFM, as always, my speciality), and naturally, it is possible to create a huge block and bite away. >The .MAP format made of filled convex blocks isn't suitable, I do not agree on this one. Your remark goes straight for the jugular, though - in "densely occluded environments" the empty space you walk in might be a convex or non-convex polyhedron - it cannot be described by a single Brush. Thus creating rooms always means creating a Group of Brushes. QuakeEd starts with empty space, and you start dropping Brushes. In a way, this seems counterintuitive, but the Sealing of the map takes care of the outside border. Not to difficult to get used to. I guess that most of us can handle those small plastic building bricks - not so sure about pickaxes. Surrounding yourself with six big solid brushes and start digging away might be more difficult - I usually loose sense of direction inside a building, not outside :-). Might be bad in terms of final brush count as well. Once you have created the rooms, you are placing furniture - as nobody digs a chair, so to speak. b. P.S.: new GUI checkbox: "Agoraphobia mode on/off". From quake-dev-owner@gamers.org Thu Jun 6 20:15 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 UAA14203 for ; Thu, 6 Jun 1996 20:15:32 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id OAA16893 for quake-dev-outgoing; Thu, 6 Jun 1996 14:13:14 -0400 Received: from postbox.acs.ohio-state.edu (postbox.acs.ohio-state.edu [128.146.214.20]) by gamers.org (thegate/gamers) with ESMTP id OAA16888 for ; Thu, 6 Jun 1996 14:13:10 -0400 Received: from carollo.acs.ohio-state.edu (S-98-240.resnet.ohio-state.edu [140.254.98.240]) by postbox.acs.ohio-state.edu (8.7.5/8.7.3) with SMTP id OAA25114 for ; Thu, 6 Jun 1996 14:11:19 -0400 (EDT) Message-ID: <31B669DC.19BB@osu.edu> Date: Thu, 06 Jun 1996 01:17:16 -0400 From: Chris Carollo Organization: The Ohio State University X-Mailer: Mozilla 3.0b3 (Win95; I) MIME-Version: 1.0 To: quake-dev@gamers.org Subject: Re: Editor GUI design References: <199606061513.RAA13898@marvin.nero.uni-bonn.de> Content-Transfer-Encoding: 7bit Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 69 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 2386 Bernd Kreimeier wrote: [snip] > 1) The Axial Bias > > Possible solutions: > > -Brush Templates, > (sets of) polyhedra approximating curved, non-axial surfaces, > just a libary This seems like a good idea. Obviously primitives like cubes or tetrahedra should be implemented, along with extruded regular polygons. > -a separate Brush Editor (Mode) For designing complex brushes it might be desirable to not display all other brushes. Though I question how often people will be designing complex convex polyhedra. Certainly editing at the level of edge/vertex/entire-brush is necessary in some fashon, but each introduces problems (convexity of brush, coplanarity of faces) > -DXF/3DS Import Importing from 3DS seems to be an everpresent request, but it never quite seems applicable. IMO, an editor needs to be specialized (especially when dealing with brushes) to be really useful. [big snip re: view modes] > Possible solutions: > > -mlook mode A mlook mode seems useful in examining the layout of maps, and not so useful in actually editing the map. When looking at a map at some cockeyed angle, it no longer becomes clear how to easily manipulate entities and brushes in three dimensions. > -4 Views, three of them axial, one free In Quest, I'm including four primary look directions (+X, +Y, -X, -Y), and also the ability to look in the +Z and -Z directions (in reference to primary look direction). All vertex/edge/brush editing is done perpenticularly to the camera direction. This way, the user cannot change the "depth" of any entity, which is fairly intuative. The downside is that designing very complex brushes (no faces pependicular to any of the view directions) can be a real pain. I'm thinking of adding a "edit-the-current-brush-only" mode where the camera can be rotated freely around the brush. My guess is that the vast majority of brushes will _not_ be complex, and this will not be a major problem, and I won't have to bother coding this. ;) I'm also considering letting the user allow intermediate look directions (i.e. at 45 degree increments instead of 90). Because I'm kind of coding blind (not having the ability to really edit a map yet), I'm not sure if this will be a problem or not. I guess time will tell... > Comments anybody? Likewise... -Chris Quest page at http://www.cis.ohio-state.edu/~carollo/quest.html From quake-dev-owner@gamers.org Thu Jun 6 20:53 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 UAA14215 for ; Thu, 6 Jun 1996 20:53:26 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id OAA17249 for quake-dev-outgoing; Thu, 6 Jun 1996 14:50:24 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id OAA17245 for ; Thu, 6 Jun 1996 14:50:19 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id UAA14211 for quake-dev@gamers.org; Thu, 6 Jun 1996 20:52:26 +0200 (MET DST) Date: Thu, 6 Jun 1996 20:52:26 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606061852.UAA14211@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org Subject: Re: Editor GUI design X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 2531 X-Lines: 67 Status: RO >editing at the level of edge/vertex/entire-brush is necessary >in some fashon, but each introduces problems (convexity of brush, >coplanarity of faces) Indeed. Add to the big ToDo list: - Brush convexity checking - Brush merge adjacent coplanar - Brush remove redundant planes (will not create facets) >Obviously primitives like cubes >or tetrahedra should be implemented, There are two approaches: a) Dialog Boxes and GUI interacts (mouse) to create one of a fixed set of primitives b) a generic Load/Save Template mechanisms, and scaling/translation/rotation manipulating a bounding box rep c) both I think (a) and (c) tend to clutter the GUI, but that is a matter of personal preferences. >For designing complex brushes it might be desirable to not display >all other brushes. Again two alternatives: a) a Selection/Filter aproach - you are still within MAP space b) a separate Brush Editor, in model space >When looking at a map at >some cockeyed angle, it no longer becomes clear how to easily >manipulate entities and brushes in three dimensions. Add the major axises to the preview. Define six keys to move along +/- X/Y/Z. One or more slanted views? >an "edit-the-current-brush-only" mode where >the camera can be rotated freely around the brush. In a predominantly XY-plane aligned world (direction of gravity is alsway along Z) it might be useful to have a rotate around the Z axis. There is the tall/short extrude feature in QuakeEd. Taking a XY convex polygon and extending it along Z (or some sloped axis) is a possible mode. Drawing the convex polygon in XY (2D view) in a separate window, for example. There are surely a lot of useful simplifications, and the use of Axial Blocks surely fits man-made environments. However I keep thinking that more or less 2D biased editing will be done anyway. Consider what I call a "Poseidon" level - e.g. a ship wreck on the beach, or even toppled, pockets of air, water surfaces, slippery decks, and no a single XY aligned plane in sight. QuakeEd might or might not be up to the task, but NAT's will be a major pain. You can't even take a given MAP and tilt and roll it a couple of degrees w/o screwing texture alignment (might be fixed if arbitrary texture coordinates are indeed possible now). You can't even do a yaw-rotation (around Z) with a given map or brush selection w/o taking care of the texture alignments, but that's a different issue. b. From quake-dev-owner@gamers.org Thu Jun 6 21:13 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 VAA14297 for ; Thu, 6 Jun 1996 21:13:26 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id PAA17413 for quake-dev-outgoing; Thu, 6 Jun 1996 15:10:13 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id PAA17408 for ; Thu, 6 Jun 1996 15:10:08 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id VAA14291; Thu, 6 Jun 1996 21:12:45 +0200 (MET DST) Date: Thu, 6 Jun 1996 21:12:45 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606061912.VAA14291@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de Subject: Palette Matching X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 816 X-Lines: 20 Status: RO Has anybody taken a look at the Doom PlayPal vs. the Quake palette? I did some matching runs with various metrics in RGB space, and there are very few exact matches, and a larger number of severe mismatches. I haven`t (yet) tried to convert an actual DOOM texture to the Quake Palette, but prospects do not look good. Dithering might help. Has anybody with some experience in handling limited palettes tried? Which, in turn, means that converted or re-done Doom maps should possibly stick to the PlayPal - meaning they cannot use the skin textures matching the Quake palette. In addition, a palette lump should accompany the mipmaps (in the BSP or elsewhere). It`s only 768 bytes, after all, and in perfect agreement with the thinking that puts the mipmaps in the BSP. b. From quake-dev-owner@gamers.org Fri Jun 7 00:18 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 AAA14456 for ; Fri, 7 Jun 1996 00:18:21 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id SAA20250 for quake-dev-outgoing; Thu, 6 Jun 1996 18:08:40 -0400 Received: from vidar.diku.dk (root@vidar.diku.dk [130.225.96.249]) by gamers.org (thegate/gamers) with SMTP id SAA20245 for ; Thu, 6 Jun 1996 18:08:36 -0400 Received: from grid.diku.dk (uffefl@grid.diku.dk [130.225.96.242]) by vidar.diku.dk (8.6.12/8.6.12) with ESMTP id AAA05731 for ; Fri, 7 Jun 1996 00:17:29 +0200 Received: (uffefl@localhost) by grid.diku.dk (8.6.12/8.6.12) id AAA25310; Fri, 7 Jun 1996 00:17:29 +0200 Date: Fri, 7 Jun 1996 00:17:29 +0200 (METDST) From: Uffe Friis Lichtenberg To: quake-dev@gamers.org Subject: Re: Palette Matching In-Reply-To: <199606061912.VAA14291@marvin.nero.uni-bonn.de> Message-ID: MIME-Version: 1.0 Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 49 Status: RO Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 1892 On Thu, 6 Jun 1996, Bernd Kreimeier wrote: > Has anybody taken a look at the Doom PlayPal vs. the > Quake palette? I did some matching runs with various > metrics in RGB space, and there are very few exact > matches, and a larger number of severe mismatches. I > haven`t (yet) tried to convert an actual DOOM texture > to the Quake Palette, but prospects do not look good. This corresponds exactly to some of ... (John Carmack?)'s comments. The palette chosen for Quake is far from the palette used in Doom. But I remember reading somewhere (in the log?) that palette now could be level based. Thus the problem seems easy to solve -- simply use the Doom palette. > Dithering might help. Has anybody with some experience > in handling limited palettes tried? In my experience dithering texture maps (at such a low resolution as those of Quake) never gives satisfactorily results. It can only get worse with the mipmapping applied. > Which, in turn, means that converted or re-done Doom > maps should possibly stick to the PlayPal - meaning > they cannot use the skin textures matching the Quake > palette. Any Doom conversion has to include converted sprites. (Just a new skin texture for the player and enemies to start with -- later on new models perhaps). Although low-res, the original sprites could probably be used more or less directly for this. > In addition, a palette lump should accompany > the mipmaps (in the BSP or elsewhere). It`s only 768 > bytes, after all, and in perfect agreement with the > thinking that puts the mipmaps in the BSP. I think (but am unsure) that this is already the case. (I hope.) Think of it: it bloody well *has* to. Otherwise creating Quake levels with completely different settings/themes will be nigh on impossible. Zonk, Uffe. [uphfe] uffefl@diku.dk -- "This .signature hasn't been left unintentionally void of blankness" From quake-dev-owner@gamers.org Fri Jun 7 00:49 MET 1996 Date: Thu, 06 Jun 1996 18:48:13 -0400 From: Rob Shields Organization: Eve Net X-Mailer: Mozilla 2.01Gold (Win95; I) MIME-Version: 1.0 To: quake-dev@gamers.org Subject: Re: Palette Matching Content-Transfer-Encoding: 7bit Sender: owner-quake-dev@gamers.org Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 29 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 547 Bernd Kreimeier wrote: > > Has anybody taken a look at the Doom PlayPal vs. the > Quake palette? [full quote deleted for sanity - b.] My last project before QMapHack was a set of utilities for personal use that would take a set of images and orient them to use the same palette. With some modifications, I could attempt to convert some DOOM2 textures to QUAKE textures. However, I have not had much experience a far as DOOM2 file formats, so I need to know how to extract the textures and palette from DOOM2 to try this. Rob Shields From quake-dev-owner@gamers.org Fri Jun 7 01:16 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 BAA14500 for ; Fri, 7 Jun 1996 01:16:31 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id TAA21130 for quake-dev-outgoing; Thu, 6 Jun 1996 19:00:55 -0400 Received: from vidar.diku.dk (root@vidar.diku.dk [130.225.96.249]) by gamers.org (thegate/gamers) with SMTP id TAA21125 for ; Thu, 6 Jun 1996 19:00:51 -0400 Received: from grid.diku.dk (uffefl@grid.diku.dk [130.225.96.242]) by vidar.diku.dk (8.6.12/8.6.12) with ESMTP id BAA06820 for ; Fri, 7 Jun 1996 01:13:47 +0200 Received: (uffefl@localhost) by grid.diku.dk (8.6.12/8.6.12) id BAA25350; Fri, 7 Jun 1996 01:13:46 +0200 Date: Fri, 7 Jun 1996 01:13:46 +0200 (METDST) From: Uffe Friis Lichtenberg To: quake-dev@gamers.org Subject: RE: Editor GUI design In-Reply-To: <9606061623.32444C@lat1192.l...> Message-ID: MIME-Version: 1.0 Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 167 Status: RO Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 7220 On Thu, 6 Jun 1996, Olivier Montanuy wrote: > Comment is simple: Quake levels are closed. just like Descent mines. > how the heck do you think one creates a mine? You walk inside and you > cut your way throught the walls, using a suitably shaped object. I don't think you're right. (Have you ever tried using Devil to create Descent levels? Tedious at best, undescribable at worst.) Construction of a level would probably be easier if you had only the `constructive' approach, not the `destructive'. There will of course always be situations where the destructive approach could be easier/more intuitive, but I think this is fewer times than the other way around. (Am I making any sense? Sorry, it's late.) Any editor worth it's salt will have both options of course. What we'll really need for Quake Editor Development is a set of CSG library functions. (Doing the union/intersection/negation calculations, converting to meshes for display, saving as .map primitives, and so on.) Once I get some time on my hands (yeah right) I'll probably start there and work my way up to the GUI later on. > The .MAP format made of filled convex blocks isn't suitable, in my not > possibly humble opinion. That's the way you build houses in the open, > not the way you dig mines. What do we care about the exterior of the level? > How come it's even calculated? It can even cause errors (leakage). Another facet of good editors -- scene validation. Leakage should be simple though. John Carmack even told us (somewhere) how he does. > And of course, you should be able to edit the level while walking > inside, not via some lame combination of 2D views or delayed camera view. I agree on you totally here. After trying out Build (although it is severely limited) I have become convinced that this is the only way really good levels can be built. (It makes it so easy to add that final touch, and placing the really cool details.) > That screams for a portal based scheme. ? The Way My Ideal Editor Would Work ---------------------------------- (And no I am not implying that I will ever try to implement this. It could be fun, but I could never find the time for it.) * Basically there should be three modes for editing level layout: 1) Brush editing A library of `building blocks' will be necessary to create levels in a reasonable amount of time. Also this is handy to create a consistent look throughout the levels. (Placing similar looking columns, furniture and so on helps maintain a theme.) These brushes has to be creatable and editable. Also CSG must be present to combine brushes. Basically union, intersection and negation is necessary. In my experience CSG eases editing very much. It allows you to create simple to semi-complex stuff in no time and has a very nice learning curve for beginners (or non-techies). 2) Map editing Using the brushes to add to the scene (place stuff) or subtract from the scene (drill holes). Also some operations to translate or rotate large parts of (or perhaps the entire) scene must be present. Moving and deleting individual brushes after they are placed must also be possible. This is used to build architecture, place furniture and other such stuff. Also textures and lights can placed at appropriate places. Lights are of course only used in pre-processing. I am guessing dynamic lights will be entities. 3) Entity placement Placing monsters, health, dynamic lights, switches, doors, bridges and what not. All the rest, so to speak. All these three modes should ideally be accessable at the same time so you don't have to spend time switching screens or even programs. All modes must also be able to work on subsets of the level so the user can concentrate on the task at hand. All editing should be possible using the following views (now this is where I get out of hand): a) Isometric Generic isometric with a view-vector and view-window defined. Hot keys or menu items for `snapping' the view to +X, -X, +Y, -Y, +Z and -Z must be available. Also you must be able to snap to the nearest 45 degree vector so you can get that typical isometric top-down view. b) Perspective The well known view-point and view-direction scheme. As used in Quake. Also hot keys for `snapping' the view should be available. If possible a `Quake Simulation' would be ideal. It doesn't have to simulate AI or any such stuff. But trying the level out (even just in wire-frame) with scene-gravity, and other such server parameters set, could be very useful. (For instance: checking to see whether the player can reach a ledge by jumping or getting a feel for the size of the level.) Both views should be available in wire-frame and textured modes. Texture mapping does not have to be very accurate (ie. perspective correct in perspective mode is not necessary). Just enough to enable proper texture alignment. Both modes should be able to use colour to enhance depth perception and minize drawing overheads. Anyway, this is probably best doable in an environment where 3D API's are available that will allow hardware accelleration and so forth. Wire-frame (with hidden surface removal) should be possible anywhere though. ("Put away that Speccy, Kiddo" :) All editing must be done with an editing plane defined (moving vertices and so forth parallel to it). And for rotation, arbitrary axises (sp?) must be placable. Note: I think a properly done isometric view-scheme is more important than the perspective ``walking in the level'' view-scheme. Also texture mapping, z-buffering and even projection is a lot easier in this. * For the CSG routines it is of prime concern to: 1) Keep precision high, so brushes don't become more and more complicated because of repeated intersections and unions. 3D Studio has this problem to a high degree. Math should probably be integer were possible. (Isn't this why John Carmack chose to have plane definition vectors integer in the .map file?) 2) Fast. We do not wish to wait all day just because we tried to cut a cube out of a wall. Internal map representations should probably maintain a strong position coherence between brushes, so we don't have to check every brush against each other everytime we move something. 3) Perform closures correctly. (Is this the wrong term? I'm rephrasing from memory.) [Foley, et al, Principles and Practice...] has some nice comments on this. Don't know how implementation friendly all of the algorithms are though. * This is of course without considering .mdl editing, .qc editing (seems like a lot of the switch logic and similar stuff has to be placed here), texture-editing, sprite-editing, sound-editing, etc. Any comments? Bye, Uffe. [uphfe] uffefl@diku.dk -- "Doom was fun, Quake was fun. Now for a *real* challenge... REAL LIFE!" - Anonymous moron "That sucks, let's burn it!" - Beavis (Non-Anonymous moron) From quake-dev-owner@gamers.org Wed Jun 5 17:18 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 RAA11968 for ; Wed, 5 Jun 1996 17:18:29 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id LAA04471 for quake-dev-outgoing; Wed, 5 Jun 1996 11:10:40 -0400 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id LAA04467 for ; Wed, 5 Jun 1996 11:10:34 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id QAA11850; Wed, 5 Jun 1996 16:35:23 +0200 (MET DST) Date: Wed, 5 Jun 1996 16:35:23 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606051435.QAA11850@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de Subject: QuakeDev pages update X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 297 X-Lines: 15 Status: RO Minor update: + May and June mails + DOOM and Quake color palette page + a couple of NeXT QuakeEd GUI screenshots + draft of Quake Editing primer + removed some (not all) obsoletes See ChangeLog. b. From quake-dev-owner@gamers.org Fri Jun 7 14:57 MET 1996 X-Sender: rclemmer@minn.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Date: Fri, 07 Jun 1996 07:50:19 -0500 To: quake-dev@gamers.org From: Rick Clemmer Subject: Re: Palette Matching Sender: owner-quake-dev@gamers.org Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 39 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 597 At 06:48 PM 6/6/96 -0400, you wrote: >X-gamers.org: quake-dev@gamers.org > >Bernd Kreimeier wrote: >> >> Has anybody taken a look at the Doom PlayPal vs. the >> Quake palette? I did some matching runs with various >> [again, deleted full quotation - b. ] >> b. > [and again - get a grip on your mailers - b.] >so I need to know how >to extract the textures and palette from DOOM2 to try this. > Rob Shields Get WinTex 4.2 it can read the DOOM/DOOM2 pallettes and textures. After it reads them just save them to a file. Rick Clemmer From quake-dev-owner@gamers.org Fri Jun 7 15:28 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 PAA15985 for ; Fri, 7 Jun 1996 15:27:41 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id JAA27769 for quake-dev-outgoing; Fri, 7 Jun 1996 09:25:18 -0400 Received: from xr3.atlas.fr (xr3.atlas.fr [194.51.9.5]) by gamers.org (thegate/gamers) with ESMTP id JAA27763 for ; Fri, 7 Jun 1996 09:25:14 -0400 Fri, 7 Jun 1996 15:12:33 +0200 Fri, 7 Jun 1996 15:12:33 +0200 Fri, 7 Jun 1996 15:10:29 +0200 X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Fri, 7 Jun 1996 15:12:33 +0200 X400-Received: by mta xr3.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Fri, 7 Jun 1996 15:12:33 +0200 X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Fri, 7 Jun 1996 15:12:29 +0200 X400-Received: by /PRMD=cnet/ADMD=atlas/C=fr/; Relayed; Fri, 7 Jun 1996 15:10:29 +0200 Date: Fri, 7 Jun 1996 15:10:29 +0200 X400-Originator: montanuy@lsun80.lannion.cnet.fr X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=cnet/ADMD=atlas/C=fr/;834153029@x400.lannion.cnet.fr] X400-Content-Type: P2-1984 (2) Content-Identifier: RE: Editor GUI d Alternate-Recipient: Allowed From: Olivier Montanuy Message-ID: <9606071219.104978@lat1192.l...> To: quake-dev@gamers.org Subject: RE: Editor GUI design X-Mailer: E-Mail 1.6 Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 1444 X-Lines: 39 Status: RO >Construction of a level would probably be easier if you had only the >`constructive' approach, not the `destructive'. The "mine" image wasn't correct in fact Building a Quake levels should be more like building a space station (well, if you already practiced this as a hobby...). You start from a room, and add more room elements. Convex, like the brushes, but instead of being filled, their are empty. The calculation cannot be more complex than with current brushes. Of course, we could also use normal filled brushes (for some internal furniture) but mainly it has to be done with empty ones. It's as constructive as your approach, but with different stuff. and at least you don't have to wonder about the "exterior", and possible leakage (which are going to be a bore). >Any editor worth it's salt will have both options of course. What we'll >really need for Quake Editor Development is a set of CSG library functions. Ok for the functions. But I think it's the current .MAP format that causes troubles. Whatever CSG you use, you'll have to convert the result into a set of filled brushes, which will make a lot of data. > Note: I think a properly done isometric view-scheme is more important > than the perspective ``walking in the level'' view-scheme. I agree with this... as long as the level is some kind of building with layers. With caves, it's useless. How about VR helmets, now. Olivier From quake-dev-owner@gamers.org Fri Jun 7 16:35 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 QAA16373 for ; Fri, 7 Jun 1996 16:35:17 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id KAA28331 for quake-dev-outgoing; Fri, 7 Jun 1996 10:33:42 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id KAA28326 for ; Fri, 7 Jun 1996 10:33:37 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id QAA16363 for quake-dev@gamers.org; Fri, 7 Jun 1996 16:33:36 +0200 (MET DST) Date: Fri, 7 Jun 1996 16:33:36 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606071433.QAA16363@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org Subject: ADMIN reminder X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 208 X-Lines: 6 Status: RO About each recent posting in the "Palette Matching thread" used full quotation. Please remove all obsolete lines and restrict to the necessary parts. Thank you. b. From quake-dev-owner@gamers.org Fri Jun 7 16:43 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 QAA16389 for ; Fri, 7 Jun 1996 16:43:42 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id KAA28386 for quake-dev-outgoing; Fri, 7 Jun 1996 10:41:50 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id KAA28381 for ; Fri, 7 Jun 1996 10:41:43 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id QAA16385 for quake-dev@gamers.org; Fri, 7 Jun 1996 16:41:33 +0200 (MET DST) Date: Fri, 7 Jun 1996 16:41:33 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606071441.QAA16385@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org Subject: RE: Palette Matching X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 797 X-Lines: 24 Status: RO > From: "Dark Shadow" > > From: Bernd Kreimeier > > Has anybody taken a look at the Doom PlayPal vs. the > > Quake palette? I did some matching runs with various > Question: Can't you just completely replace the Quake palette with the > DOOM palettes? Sure. You will not be able to combine Quake and DOOM textures. To be able to mix needs a good palette matching. > Since the textures are > included in each map file, from what I've read, Nope. The mipmaps are in the BSP file. > you could totally replace > the palette lump in the BSP I checked the worklog, and did not find the note the Uffe Friis mentioned. For all I know, it is still in the WAD2. b. From quake-dev-owner@gamers.org Fri Jun 7 16:56 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 QAA16405 for ; Fri, 7 Jun 1996 16:55:48 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id KAA28538 for quake-dev-outgoing; Fri, 7 Jun 1996 10:53:57 -0400 Received: from lafvax (lafvax.lafayette.edu [139.147.8.2]) by gamers.org (thegate/gamers) with ESMTP id KAA28532 for ; Fri, 7 Jun 1996 10:53:53 -0400 Received: from lafvax.lafayette.edu by lafvax.lafayette.edu (PMDF V5.0-4 #6834) id <01I5MI50NRO0000ENX@lafvax.lafayette.edu> for quake-dev@gamers.org; Fri, 07 Jun 1996 10:57:21 -0500 (EST) Date: Fri, 07 Jun 1996 10:57:21 -0500 (EST) From: Mike Ruete Subject: Re: Editor GUI design In-reply-to: <31B669DC.19BB@osu.edu> To: quake-dev@gamers.org Message-id: MIME-version: 1.0 Content-transfer-encoding: 7BIT Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 49 Status: RO Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 2381 On Thu, 6 Jun 1996, Chris Carollo wrote: > > -4 Views, three of them axial, one free > > In Quest, I'm including four primary look directions (+X, +Y, -X, > -Y), and also the ability to look in the +Z and -Z directions (in > reference to primary look direction). All vertex/edge/brush editing > is done perpenticularly to the camera direction. This way, the > user cannot change the "depth" of any entity, which is fairly > intuative. Perhaps you should consider the ability to change the camera direction to be perpendicular to, or coplanar with any surface of the level. In most cad programs, this is a very useful ability. I'd also suggest adding the ability to "grab" a face of a brush and move it "in and out" along it's normal. This would be most useful for six-sided polyhedra, but could have it's uses elsewhere. I've done a reasonable amount of CAD work, and I find multiple views to be extremely helpful. When I edit, I usually have an isometric view, a left side view, a front view, and a top view. I edit in the left, front, and top, but I often use the isometric for getting a feel for what I'm building, and also for selecting edges and faces that would otherwise be overlapped and hard to select in axial views. If I were making an editor, I'd code my wire-frame renderer to work in its own separate window. This way spawning another view and switching the "primary" one would be a lot easier. > The downside is that designing very complex brushes (no faces > pependicular to any of the view directions) can be a real pain. > I'm thinking of adding a "edit-the-current-brush-only" mode where > the camera can be rotated freely around the brush. My guess is that > the vast majority of brushes will _not_ be complex, and this will > not be a major problem, and I won't have to bother coding this. ;) That's not really a valid assumption, though. Speaking as a member of TeamTNT (creators of TNT: Evilution and ICARUS: Alien Vangaurd), I can assure you that what people, especially talented level authors, look forward to most about Quake level editing is the ability to make wacky, non-orthogonal walls/cielings/whatever. If we wanted to do more mostly orthogonal stuff, we'd just keep editing DOOM. I think non-axial views and the ability to (relatively) easily create *very* complex brushes is vital. -Mike Ruete From quake-dev-owner@gamers.org Fri Jun 7 17:40 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 RAA16856 for ; Fri, 7 Jun 1996 17:40:05 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id LAA29039 for quake-dev-outgoing; Fri, 7 Jun 1996 11:37:35 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id LAA29035 for ; Fri, 7 Jun 1996 11:37:31 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id RAA16849 for quake-dev@gamers.org; Fri, 7 Jun 1996 17:37:29 +0200 (MET DST) Date: Fri, 7 Jun 1996 17:37:29 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606071537.RAA16849@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org Subject: Re: Editor GUI design X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 1614 X-Lines: 34 Status: RO >From: Mike Ruete > Perhaps you should consider the ability to change the camera >direction to be perpendicular to Second that. I think texture alignment should work like this: click on the facet in any view, one view shows the facet with textures, perpendicular, and the adjacent facets with perspective correct texture mapping. This is for manually fixing NAT screwups. >I'd also suggest adding the ability to "grab" a face of a brush >and move it "in and out" along it's normal. Agreed. Add to this: create facet from vertex (triangle on a cube, as many vertices as incoming edges in general), and collapse facet to vertex. In both cases, you might click on a facet (i.e. the new one), and again a view perpendicular is spawned. Moving the vertices in 2D will tilt the plane in 3D. >I'd code my wire-frame renderer to work in its own >separate window. This way spawning another view and switching the >"primary" one would be a lot easier. This should work within one window as well, with 1 and 4 overlayed Drawing Panes, or am I mistaken. Anyway, the basic idea is sound: each renderer is one object with one (part of) the window. I loathe the windowitis that drowns my desktop in a dozen separate ones, though. >I think non-axial views and the ability to (relatively) easily >create *very* complex brushes is vital. I agree. Think of (approximations) of pipes/spheres/tanks. It does not look like creating a six- or many-sided pillar is a on-stop-shop task in QuakeEd. b. From quake-dev-owner@gamers.org Sat Jun 8 17:26 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 RAA18529 for ; Sat, 8 Jun 1996 17:26:33 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id LAA04915 for quake-dev-outgoing; Sat, 8 Jun 1996 11:25:40 -0400 Received: from lafvax (lafvax.lafayette.edu [139.147.8.2]) by gamers.org (thegate/gamers) with ESMTP id LAA04910 for ; Sat, 8 Jun 1996 11:25:37 -0400 Received: from lafvax.lafayette.edu by lafvax.lafayette.edu (PMDF V5.0-4 #6834) id <01I5NX4F1OOM0022Y7@lafvax.lafayette.edu> for quake-dev@gamers.org; Sat, 08 Jun 1996 11:17:33 -0500 (EST) Date: Sat, 08 Jun 1996 11:17:33 -0500 (EST) From: Mike Ruete Subject: Re: Editor GUI design In-reply-to: <199606071537.RAA16849@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org Message-id: MIME-version: 1.0 Content-transfer-encoding: 7BIT Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 30 Status: RO Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 1257 On Fri, 7 Jun 1996, Bernd Kreimeier wrote: > This should work within one window as well, with 1 and 4 overlayed > Drawing Panes, or am I mistaken. Anyway, the basic idea is sound: > each renderer is one object with one (part of) the window. I loathe > the windowitis that drowns my desktop in a dozen separate ones, > though. If you mean like what WinTex does, I hate that two. What I had in mind was something where you have a main view window, and that window is subdivided into smaller windows. Also, I'm not too familiar with XWindow, so I may have no clue what you're talking about. :) > I agree. Think of (approximations) of pipes/spheres/tanks. It > does not look like creating a six- or many-sided pillar is a > on-stop-shop task in QuakeEd. Speaking of which... Back to the idea of primitives. All primitives should have a "root" point/axis, and there should be plenty of options for aligning that within your level. A couple methods that spring to mind are setting the root point of the primitive on the endpoint/intersection of an edge, and aligning the axis parallel/perpendicular to an existing edge. Also, rotating a primitve about its root axis should probably be the final step in primitive insertion. -Mike Ruete From quake-dev-owner@gamers.org Sat Jun 8 19:13 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 TAA18572 for ; Sat, 8 Jun 1996 19:13:50 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id NAA05649 for quake-dev-outgoing; Sat, 8 Jun 1996 13:13:12 -0400 Received: from audumla.students.wisc.edu (students.wisc.edu [144.92.104.66]) by gamers.org (thegate/gamers) with SMTP id NAA05644 for ; Sat, 8 Jun 1996 13:13:07 -0400 Received: from darkstar by audumla.students.wisc.edu; id MAA21186; 8.6.9W/42; Sat, 8 Jun 1996 12:13:05 -0500 Message-Id: <2.2.32.19960608170818.0069cf74@students.wisc.edu> X-Sender: ngrasmus@students.wisc.edu X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Date: Sat, 08 Jun 1996 12:08:18 -0500 To: quake-dev@gamers.org From: Nick Rasmussen Subject: Too tied to brushes? Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 15 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 613 Are brushes really the way to go with a new editor? Obviously, if you want to use id's qbsp et al you have to have brushes in the .map file, but I think that the task of creating the brushes is one that could be handled by the editor as the map is saved. A much more intuiative interface (for me at least) is one where you control texture on a per-polygon (and perhaps a per-group of polygons) level. This, along with a perpendicular-to-polygon viewpoint would lend itself easily to alinging textures. Also, not having to bother with the brushes would probably allow faster level design. -Nick Rasmussen From quake-dev-owner@gamers.org Sat Jun 8 22:22 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 WAA18661 for ; Sat, 8 Jun 1996 22:22:17 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id QAA06958 for quake-dev-outgoing; Sat, 8 Jun 1996 16:21:46 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id QAA06954 for ; Sat, 8 Jun 1996 16:21:42 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id WAA18652 for quake-dev@gamers.org; Sat, 8 Jun 1996 22:21:40 +0200 (MET DST) Date: Sat, 8 Jun 1996 22:21:40 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606082021.WAA18652@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org Subject: Re: Editor GUI design X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 1053 X-Lines: 32 Status: RO From: Mike Ruete >All primitives should have a "root" point/axis, and >there should be plenty of options for aligning that >within your level. You've lost me. Could you explain? Is this selecting an edge, and/or a vertex, as a frame of reference for moving/rotating the brush? As for aligning two brushes, this reminds me of some related questions: a) is an editing mode with polyhedra-polyhedra 3D collision detection worth the hassle? b) here is a next interaction: pick two facets of two brushes. Now press "glue". One brush will be rotated and translated to stick to the other, selected facet on selected facet. Now there are only 3 degrees of freedom left: in the plane defined by the two parallel facets, move in x,y, or rotate by some angle. >>windowitis >If you mean like what WinTex does, I hate that too. I was actually thinking Sun Mailtool... dunno about WinTex, unfortunately it does not run with Linux :-(. b. From quake-dev-owner@gamers.org Sat Jun 8 22:33 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 WAA18670 for ; Sat, 8 Jun 1996 22:33:15 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id QAA07123 for quake-dev-outgoing; Sat, 8 Jun 1996 16:32:51 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id QAA07119 for ; Sat, 8 Jun 1996 16:32:45 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id WAA18664; Sat, 8 Jun 1996 22:32:50 +0200 (MET DST) Date: Sat, 8 Jun 1996 22:32:50 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606082032.WAA18664@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de Subject: Info from John Carmack (9) X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 4361 X-Lines: 131 Status: RO Here's another one. Btw., the flip/mirror question was indeed a stupid one - recognized this too late. And it must be s_ofs t_ofs rot_angle s_scale t_scale obviously, as most Plane lines read "...0 0 0 1 1" now. b. ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Fri Jun 7 20:29 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Fri, 7 Jun 96 13:26:18 -0500 To: Bernd Kreimeier Subject: Re: q&a (6) Content-Type: text/plain; charset="us-ascii" Content-Length: 3559 You wrote: > > Q: gravity is fixed along Z. Would there be unreasonable overhead > assigning a gravity/current/force vector to a volume (like the > water/lava attribute is maintained)? We have "push triggers" that assign a velocity when you are inside them. We use them for flinging players through gerbil tubes. They aren't exactly what you want (you have no control when in them), but it is just qc code and could be changed easily. There are efficiency issues with using them all over the place, but they aren't too bad. > Q: besides lava-style texture animation, is there a simple s/t > scroll animation? Different speeds? Not for normal textures, because the light map samples are tied to a block structure. I could slide the turbulent textures, because they don't have lightmaps, but I haven't put any interface in for it. It will probably show up in Quake 2. > Q: wouldn`t it be better to include the palette (768 bytes) along > with the mipmap lumps in the BSP? Solely for using DOOM playpal, or > other full palette replacements. MDL skins etc. will be a problem, > but entities are external references anyway. The palette is included along with the misc graphics, like the console and status bar. If you want to use a different palette, you are going to have to create all new graphics for everything else. I really doubt it is worth it. > > Q: am I mistaken that, with "s/t_ofs s/t_scale rot", it is not > possible anymore to flip/mirror a texture, because of using NAT's? A negative scale is a flip. > > This is confusing :-(. Ceterum censeo: shouldn't NAT's be assigned > within QuakeEd/any editor, and the result be saved as (s,t). > Semi-auto texture alignment is an editor feature. The brushes > aren`t human readable anyway. Ah well, I will shut up on this one. > The .map file is the editor file format, so it has representations convenient for the editor. The .bsp file has representations convenient for rendering. I tried just putting in s/t vectors for the planes, but it makes many editor operations cumbersome. I know, I know. It doesn't feel right to me either. > Q: the MAP format does not allow for persistent hierarchy/grouping > (which is useless for qbsp, but useful for editing). Care to > comment on: > > --------------------------------- >{ > "classname" "worldspawn" > "message" "The House" > { > "_label" "The Bathroom" > { > ( .., .., .. ) WALLTILE .... > ( .., .., .. ) WALLTILE .... > ... > } > { > // more brushes > } > // end bathroom > } > { > "_label" "The Living Room" > { > ( .., .., .. ) CARPET .... > // more brushes > } > } > // more rooms >} > ------------------------------- This is changing with my NT editor. The entity grouping groups brushes very nicely allready. I am just going to add a little change to qbsp so that an entity with a classname of "submodel" or something will just be merged into the world entity for bsp generation. > The MAP files will have a life expectancy exceeding Quake's by far. > As far as 3D map editing is concerend, it is time to think > "progressive refinement" - or "kaizen". Btw., the more I think my > way through brush based editing, the more I like it - this has been > a damn good idea. Yes, I still think I made the right decision for solid based editing, and I think it will be adopted widely. I was charmed to see Epic using my "brush" terminology in describing their unreal editor :-). John Carmack ----- End Included Message ----- From quake-dev-owner@gamers.org Sat Jun 8 22:41 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 WAA18681 for ; Sat, 8 Jun 1996 22:41:43 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id QAA07214 for quake-dev-outgoing; Sat, 8 Jun 1996 16:41:30 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id QAA07207 for ; Sat, 8 Jun 1996 16:41:24 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id WAA18677 for quake-dev@gamers.org; Sat, 8 Jun 1996 22:41:27 +0200 (MET DST) Date: Sat, 8 Jun 1996 22:41:27 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199606082041.WAA18677@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org Subject: Re: Info from John Carmack (4) X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 926 X-Lines: 37 Status: RO John Carmack wrote: >> will the linux version be ... as modules (gcc-linkeable) >I have intentions to do so, but since Dave Talor left id This is a comment from Dave Taylor. ----- Begin Included Message ----- >From ddt@crack.com Mon Jun 3 20:25 MET 1996 From: Dave Taylor To: Bernd.Kreimeier@NeRo.Uni-Bonn.DE Subject: Re: Linux Quake port > a) Thanks heaps welcome > b) If you get around to release a LinuxQuake, would it be possible > to release it as linkable modules like the intended DJGPP release > (see mail quoted below)? Should be. > c) ... > Would it be possible to run LinuxQuake with DDE/IPC > to control player position and LOS from the editor, i.e. to > use LinuxQuake as an interactive preview (including monster > animation)? It would of course be possible to write this. However, it won't be written. Sorry. =-ddt-> ----- End Included Message ----- From quake-dev-owner@gamers.org Sun Jun 9 01:44 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 BAA18780 for ; Sun, 9 Jun 1996 01:44:54 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id TAA08739 for quake-dev-outgoing; Sat, 8 Jun 1996 19:44:11 -0400 Received: from relay.bt.net (relay.bt.net [194.72.6.52]) by gamers.org (thegate/gamers) with SMTP id TAA08735 for ; Sat, 8 Jun 1996 19:44:08 -0400 Received: from onlinemagic.com (actually flash.onlinemagic.com) by relay.bt.net with SMTP (PP); Sun, 9 Jun 1996 00:44:04 +0100 Received: by onlinemagic.com (SMI-8.6/SMI-SVR4) id BAA29462; Sun, 9 Jun 1996 01:39:40 +0100 From: jschuur@onlinemagic.com Date: Sun, 9 Jun 1996 00:39:40 +0000 (GMT) To: quake-dev@gamers.org Subject: list your quake editing project Message-ID: MIME-Version: 1.0 Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 16 Status: RO Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 574 i'd like to list all the quake editors currently under developement on aftershock, in it's diy section. have a look at http://www.nuqneH.org/aftershock/diy/editorsmake.html and drop me a line if you're working on an editor you'd like to have mentioned there. -- joost schuur, Online Magic Ltd. ----------- Tel: +44 171 820 7766 -- ----------------------------------------------------------------------- ---------------------------------------------------------------------- --- http://www.nuqneH.org/~jschuur/ ---- jschuur@onlinemagic.co.uk --- From quake-dev-owner@gamers.org Sun Jun 9 05:23 MET 1996 Date: Sat, 08 Jun 1996 23:29:07 -0500 From: Andrew Gilpin Organization: Eve Net X-Mailer: Mozilla 2.02Gold (Win95; I) MIME-Version: 1.0 To: quake-dev@gamers.org Subject: Re: list your quake editing project Content-Transfer-Encoding: 7bit Sender: owner-quake-dev@gamers.org Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 29 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 403 jschuur@onlinemagic.com wrote: > [ full quote deleted. Sigh - b. ] > and drop me a line if you're working on an editor you'd like to have > mentioned there. I am one of the programmers working on QMapHack, but I think it is already listed on the DIY page. Anyways the homepage for QMapHack is http://www.eve.net/~rshields/ -- Andrew Gilpin mailto:agilpin@eve.net http://www.eve.net/~agilpin/ From quake-dev-owner@gamers.org Sun Jun 9 21:01 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 VAA20826 for ; Sun, 9 Jun 1996 21:01:22 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id OAA18712 for quake-dev-outgoing; Sun, 9 Jun 1996 14:58:42 -0400 Received: from vidar.diku.dk (root@vidar.diku.dk [130.225.96.249]) by gamers.org (thegate/gamers) with SMTP id OAA18708 for ; Sun, 9 Jun 1996 14:58:38 -0400 Received: from grid.diku.dk (uffefl@grid.diku.dk [130.225.96.242]) by vidar.diku.dk (8.6.12/8.6.12) with ESMTP id UAA02258 for ; Sun, 9 Jun 1996 20:58:35 +0200 Received: (uffefl@localhost) by grid.diku.dk (8.6.12/8.6.12) id UAA16900; Sun, 9 Jun 1996 20:58:34 +0200 Date: Sun, 9 Jun 1996 20:58:34 +0200 (METDST) From: Uffe Friis Lichtenberg To: quake-dev@gamers.org Subject: RE: Editor GUI design In-Reply-To: <9606071219.104978@lat1192.l...> Message-ID: MIME-Version: 1.0 Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 157 Status: RO Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 6604 On Fri, 7 Jun 1996, Olivier Montanuy wrote: > Building a Quake levels should be more like building a space station > (well, if you already practiced this as a hobby...). ;) > You start from a > room, and add more room elements. Convex, like the brushes, but instead > of being filled, their are empty. > The calculation cannot be more complex than with current brushes. Well, that's OK if you want to build a space station/mine/and so on, but for other architectural ideas it might not be ideal. I agree the _calculations_ can't be more complex than the other way round, but converting them back to .map is surely gonna be more complex when you do subtractive CSG operations rather than additive. Still, a good editor should support both ways... > It's as constructive as your approach, but with different stuff. > and at least you don't have to wonder about the "exterior", and possible > leakage (which are going to be a bore). Well sure, leakage is gonna suck, but with proper .map validation routines it should be possible to detect automatically and perhaps even fix semi-automatically. > Ok for the functions. But I think it's the current .MAP format that causes > troubles. Whatever CSG you use, you'll have to convert the result into a set of > filled brushes, which will make a lot of data. Exactly. It the to .map function that will be the hard one to code. I have been thinking somewhat like this: BTW: This is C++ which makes me think: what would be of most interest to the rest of the Quake editing community, C or C++? (Mads: I'm not going to use Delphi, no I'm not! ;) class CSGtree { public: CSGtree(Brush b); // Instantiate leaf // + other constructors and the usual stuff CSGtree operator+(const CSGtree other) const; // return union of *this and other CSGtree operator*(const CSGtree other) const; // return intersection of *this and other CSGtree operator-(void) const; // (unary minus... is this the correct syntax? can't really remember) // return negation of *this PolygonMesh toPolygonMesh(void) const; // return polygon mesh representing CSGtree CSGtree normalize(void) const; // return `normalized' CSG representation (self-made terminology) // (ie. one using only unions; an any-order traversal of the // tree would produce output suitable for a .map file) Brush toBrush(void) const); // return a single brush representing *this (if possible) CSGtree transform(Matrix4x4 m) const; // transform node and leaves using the given matrix CSGtree translate(Vector3 v) const; // translate node and leaves using the given vector // (ie. setup matrix and use transform() for naive implementation CSGtree rotateX(float a) const; // rotate... // + all the other handy editing functions you could think of... } (Of course this interface is very `top-level' and should be optimized with references or pointers where appropriate. Also non-const (but state-changing) functions should be available to offer efficiency where you know you won't be needing the `old' instance. This should give the general idea... Otherwise tell me I'm rambling :) (I'm assuming proper classes for PolygonMesh and Brush, but this should be somewhat more trivial. PolygonMesh would probably just be a list of polygons, but rendering could possibly benefit from using BSP or other pre-sorting, as they shouldn't be recalculated constantly. A Brush would probably just be a list of planes. Here BSP might be useful too, who knows.) All operations should then be performed upon CSG representations with operators at the nodes and brushes at the leaves. The tricky functions will be toPolygonMesh(), normalize() and toBrush(). toPolygonMesh() should be managable. The trick will be to keep the polygon count relatively low (ideally as low as possible). If the given CSGtree is a leaf (ie. a brush) it should be (relatively) trivial to perform all intersections between the planes to get list of polygons. Otherwise you would just apply the funcion recursively and then unite/intersect/negate polygon meshes. `Dead' polygons (ie. polygons inside the object, never visible) should of course be culled. Real problem: speed and accuracy. Check out 3D Studios boolean operations on their triangle-meshes. Verry buggy/slow/inadequate. Speed will probably never reach real-time rates, so an editor will need to remember the PolygonMesh returned by toPolygonMesh() and only force a recalculation when necessary. normalize() should identify the smallest amount of brushes necessary for the conversion. Unions are easy: they convert one-to-one, but if the union can be represented as one brush (ie. it is still convex) it should be reduced to that (using toBrush()). Intersections are easy too: just collapsing the two brush representations (list of planes) produces correct output, but redundant planes (ie. planes that have no