From quake-editing-owner@nvg.unit.no Wed Apr 3 23:45 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id XAA29578 for ; Wed, 3 Apr 1996 23:45:47 +0200 (MET DST) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id XAA15583 for quake-editing-outgoing; Wed, 3 Apr 1996 23:34:29 +0200 Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id XAA15578 for ; Wed, 3 Apr 1996 23:34:24 +0200 Received: from sunset.cs.utah.edu by cs.utah.edu (8.6.12/utah-2.21-cs) id OAA25438; Wed, 3 Apr 1996 14:34:21 -0700 Received: from peruvian.cs.utah.edu by sunset.cs.utah.edu (8.6.12/utah-2.15sun-leaf) id OAA02649; Wed, 3 Apr 1996 14:34:46 -0700 Received: from localhost by peruvian.cs.utah.edu (8.6.10/utah-2.15-leaf) id OAA26333; Wed, 3 Apr 1996 14:34:14 -0700 Message-Id: <199604032134.OAA26333@peruvian.cs.utah.edu> To: quake-editing@nvg.unit.no From: larsen@sunset.cs.utah.edu (Steve Larsen) Subject: coordinate system Date: Wed, 03 Apr 96 14:33:58 MST Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 149 X-Lines: 9 Status: RO Hi all, Can someone verify for me which coordinate system Quake uses? I assume it is left-handed, but I'd just like to make sure. Thanks, Steve From quake-editing-owner@nvg.unit.no Wed Apr 3 23:54 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id XAA29592 for ; Wed, 3 Apr 1996 23:54:30 +0200 (MET DST) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id XAA15721 for quake-editing-outgoing; Wed, 3 Apr 1996 23:47:54 +0200 Received: from marvin.nero.uni-bonn.de (marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id XAA15716 for ; Wed, 3 Apr 1996 23:47:51 +0200 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id XAA29584 for ; Wed, 3 Apr 1996 23:47:47 +0200 (MET DST) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.1-NeRo-SW/8.7.1) id XAA02801 for quake-editing@nvg.unit.no; Wed, 3 Apr 1996 23:47:38 +0200 (MET DST) From: Bernd Kreimeier Date: Wed, 3 Apr 1996 23:47:38 +0200 (MET DST) Message-Id: <199604032147.XAA02801@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no Subject: Unofficial Quake Specs 3.1 X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 887 X-Lines: 24 Status: RO Forwarded from rec.games.computer.quake.editing. --------------------------------------------------------------------------- From: Raphael.Quinet@eed.ericsson.se (Raphael Quinet) The latest version (3.1) is currently available at the following URL: http://www.stud.montefiore.ulg.ac.be/ftp-mirror/quake/docs/qkspecs31.html I uploaded it to ftp.cdrom.com too, so it should be available soon in: http://www.cdrom.com/pub/idgames2/docs/qkspecs31.zip Version 3.1 is bigger than 3.0: 120K for the new HTML file instead of 74K for the previous version. It takes 42 pages when printed with Netscape! This very useful document was written by Olivier Montanuy, with contributions from Brian Martin, John Wakelin, David Etherton and others (including myself). It is an important source of information for anyone who wants to develop a Quake editor or build Quake levels. -Raphael From quake-editing-owner@nvg.unit.no Thu Apr 4 08:17 MET 1996 From: Derek Nickel To: "'quake-editing@nvg.unit.no'" Subject: Visible-Surface Determination Date: Wed, 3 Apr 1996 22:00:34 -0800 MIME-Version: 1.0 Sender: owner-quake-editing@nvg.unit.no Reply-To: quake-editing@nvg.unit.no X-Lines: 14 Status: RO Content-Length: 624 I came across an article that I thought might be of interest: "Inside Quake: Visible-Surface Determination" by Michael Abrash Dr. Dobb's Sourcebook, January/February 1996, #255 Ramblings In Real Time, pp. 41-45 This article talks about pushing past the unconscious limits that are often= set in a project. It then goes on to describe the various techniques that= John Carmack tried out while developing his visible-surface determination = and culling algorithms (VSD) in Quake. This includes a description of the = potentially visible set (PVS) , a.k.a. visibility lists, on page 45. Derek Nickel From quake-editing-owner@nvg.unit.no Thu Apr 4 08:51 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id IAA00879 for ; Thu, 4 Apr 1996 08:51:06 +0200 (MET DST) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id IAA21827 for quake-editing-outgoing; Thu, 4 Apr 1996 08:40:46 +0200 Received: from kuoi.asui.uidaho.edu (kamikaze@kuoi.asui.uidaho.edu [129.101.126.10]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id IAA21822 for ; Thu, 4 Apr 1996 08:40:43 +0200 Received: (from kamikaze@localhost) by kuoi.asui.uidaho.edu (8.6.12/8.6.9) id WAA08838 for quake-editing@nvg.unit.no; Wed, 3 Apr 1996 22:37:42 -0800 Date: Wed, 3 Apr 1996 22:37:42 -0800 From: Mark Hughes Message-Id: <199604040637.WAA08838@kuoi.asui.uidaho.edu> To: quake-editing@nvg.unit.no Subject: Re: coordinate system Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 269 X-Lines: 7 Status: RO larsen@sunset.cs.utah.edu (Steve Larsen) spake: >Can someone verify for me which coordinate system Quake uses? I assume >it is left-handed, but I'd just like to make sure. Right-handed. +Z is up, +X is east, +Y is north, 0' is east, 90' north, etc. -Mark Hughes From quake-editing-owner@nvg.unit.no Thu Apr 4 22:14 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id WAA04751 for ; Thu, 4 Apr 1996 22:14:08 +0200 (MET DST) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id WAA31470 for quake-editing-outgoing; Thu, 4 Apr 1996 22:06:51 +0200 Received: from marvin.nero.uni-bonn.de (marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id WAA31465 for ; Thu, 4 Apr 1996 22:06:49 +0200 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id WAA04738 for quake-editing@nvg.unit.no; Thu, 4 Apr 1996 22:06:48 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199604042006.WAA04738@marvin.nero.uni-bonn.de> Subject: Re: Visible-Surface Determination To: quake-editing@nvg.unit.no Date: Thu, 4 Apr 1996 22:06:48 +0200 (MET DST) In-Reply-To: <01BB21A9.53C79900@h96-209.ccnet.com> from "Derek Nickel" at Apr 3, 96 10:00:34 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Status: RO X-Lines: 33 Content-Type: text/plain; charset="US-ASCII" Content-Length: 969 > > I came across an article that I thought might be of interest: > > "Inside Quake: Visible-Surface Determination" > by Michael Abrash > Dr. Dobb's Sourcebook, January/February 1996, #255 > Ramblings In Real Time, pp. 41-45 > > > Derek Nickel Thanks for reminding me - I had completely forgotten. IIRC, sources are at ftp://ftp.idsoftware.com/MikeAB/ddjclip.zip. DDJ can be found at : http://www.ddj.com and, again from memory, they have the source available, too, but not the article. There are other BSP related articles from 1995, including one by Mike Abrash (ddjbsp2.zip, and May/June, again from memory). I will have to add the pointers to the Quake Developers pages. However, the article itself is copyrighted, and not one of those available at the DDJ site. If somebody does have a copy, perhaps we could get a summary of some kind. There is a README in the source archive. b. From quake-editing-owner@nvg.unit.no Tue Mar 19 03:29 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id DAA12514 for ; Tue, 19 Mar 1996 03:29:41 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id DAA29860 for quake-editing-outgoing; Tue, 19 Mar 1996 03:22:19 +0100 Received: from absolut-zero.winternet.com (root@absolut-zero.winternet.com [198.174.169.4]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id DAA29845 for ; Tue, 19 Mar 1996 03:22:14 +0100 Received: from parka (root@parka.winternet.com [198.174.169.9]) by absolut-zero.winternet.com (8.7.4/8.6.12) with ESMTP id UAA08541 for ; Mon, 18 Mar 1996 20:22:10 -0600 (CST) Received: from banquo.velocity.com (ppp-66-23.dialup.winternet.com [204.246.66.23]) by parka (8.7.4/8.6.12) with SMTP id UAA01389 for ; Mon, 18 Mar 1996 20:22:08 -0600 (CST) Posted-Date: Mon, 18 Mar 1996 20:22:08 -0600 (CST) Message-Id: <1.5.4b12.32.19960319022015.0068902c@winternet.com> X-Sender: jlowell@winternet.com X-Mailer: Windows Eudora Light Version 1.5.4b12 (32) Mime-Version: 1.0 Date: Mon, 18 Mar 1996 20:20:15 -0600 To: quake-editing@nvg.unit.no From: Jim Lowell Subject: One EXE for all? (was Re: Legal stuff) Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 37 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 1419 At 03:32 PM 3/18/96 +0100, you wrote: (snip) > >I'm not sure if it is a bad thing. Maintaining two different EXE's >would mean more work for id Software (creating the two versions, >supporting them, etc.). They cannot simply create a shareware EXE >which differs only by a few bytes (i.e. a hard-coded flag), because >some cracker would certainly post a patch to enable all the disabled >features. Also, it is easier to pirate and distribute a single EXE >file than to copy the whole CD-ROM, so a different EXE wouldn't >protect id Software for a long time. > (snip) Is there some reason that something couldn't be buried in the shareware WAD that isn't in the registered WAD that the EXE could look for? Then the EXE could look for it and refuse to load levels if it finds it. It could be made sufficently hard to remove if it was a key that was spread throughout the WAD and was used to construct some weird checkdigit at the end. It could remain undocumented, so nobody could remove it and the EXE would be the only thing that had to know how to look for it. That way everyone could make whatever editor they wanted, and if you didn't have the registered WAD, then you would not be able to play the add-on levels. In fact, the editor-designers wouldn't have to worry about checking for registered versions of the game at all, because the EXE would handle it. Any reason this won't work? -= Jim Lowell =- From quake-editing-owner@nvg.unit.no Mon Apr 15 17:43 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.163.74]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id RAA04106 for ; Mon, 15 Apr 1996 17:43:24 +0200 (MET DST) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id JAA10664 for quake-editing-outgoing; Sun, 14 Apr 1996 09:14:14 +0200 Received: from runix.runit.sintef.no (runix.runit.sintef.no [129.241.1.5]) by linpro.no (8.6.12/linpro1.13) id for ; Wed, 10 Apr 1996 16:29:01 +0200 Received: from marvin.nero.uni-bonn.de by runix.runit.sintef.no with SMTP (PP); Sun, 7 Apr 1996 20:20:51 +0200 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id UAA10869 for ; Sun, 7 Apr 1996 20:20:46 +0200 (MET DST) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.1-NeRo-SW/8.7.1) id UAA07228 for quake-editing@nvg.unit.no; Sun, 7 Apr 1996 20:20:34 +0200 (MET DST) From: Bernd Kreimeier Date: Sun, 7 Apr 1996 20:20:34 +0200 (MET DST) Message-Id: <199604071820.UAA07228@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no Subject: QuakeDev pages updated X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 560 X-Lines: 18 Status: RO I will forward parts of a mail reply by John Carmack on the issue of editing tools targetting the qtest1 release. Within the same mail, he provided some informaton on how QuakeEd works, and what the MAP file structure looks like. This information is available at http://www.nero.uni-bonn.de/~dn/q-sup/info/ with comments and additional material. b. ----------------------------------------------------------- "Thou shall live in exciting times." ----------------------------------------------------------- From quake-editing-owner@nvg.unit.no Mon Apr 15 17:53 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.163.74]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id RAA04317 for ; Mon, 15 Apr 1996 17:53:53 +0200 (MET DST) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id JAA11634 for quake-editing-outgoing; Sun, 14 Apr 1996 09:52:20 +0200 Received: from runix.runit.sintef.no (runix.runit.sintef.no [129.241.1.5]) by linpro.no (8.6.12/linpro1.13) id for ; Wed, 10 Apr 1996 16:29:20 +0200 Received: from marvin.nero.uni-bonn.de by runix.runit.sintef.no with SMTP (PP); Sun, 7 Apr 1996 20:31:25 +0200 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id UAA10887; Sun, 7 Apr 1996 20:31:22 +0200 (MET DST) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.1-NeRo-SW/8.7.1) id UAA07235; Sun, 7 Apr 1996 20:31:10 +0200 (MET DST) From: Bernd Kreimeier Date: Sun, 7 Apr 1996 20:31:10 +0200 (MET DST) Message-Id: <199604071831.UAA07235@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no Subject: Forward: qtest1 editing X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 2322 X-Lines: 58 Status: RO ----------------------------------------------------------------- Forwarded to quake-editing, from e-mail reply, with permission ----------------------------------------------------------------- From: John Carmack Date: Sat, 6 Apr 96 You wrote: > From: larsen@sal.cs.utah.edu (Steve Larsen) > Newsgroups: rec.games.computer.quake.editing > > I just asked John Carmack if I could release a Quake level > > editor, and he said yes. > > Would you mind to confirm this? > I would like to post the confirmation to the Quake Developers > mailing list. I am looking forward to the user communities activities with Quake. Certainly there will be some wasted effort in targeting the test release instead of the final version, but it will build usefull skills relevant to the final product. I plan on releasing a lot of source code after we ship, but please don't press me for it sooner. > However, consesus was that, taking the accidental release of the > models into account, All I can ask is that you please not place monsters, because I really didn't mean to have that half-ass code visible to the public. > no such tool should be released to the public. > > Next: while the BSP might still change, is the same true for your > CSG representation used for editing, and with qbsp, vis, light? It > will be next to impossible to have anybody agree on a file format > for distribution and editing - if those file formats are stable > already, is there any chance of you releasing info now? > Our .map format that QuakeEd generates hasn't changed in over six months, which is the real strength of non-game-related editors. The BSP format has changed (literally) over a dozen times since. The world will be a better place if everyone just uses our source format... Once again, I plan to release lots of related source when we ship. John Carmack --------------------------------------------------------------------- Within the same mail, he provided some additional informaton, which is available at http://www.nero.uni-bonn.de/~dn/q-sup/id_info/ b. --------------------------------------------------------------------- From Bernd.Kreimeier@nero.uni-bonn.de Mon Apr 15 17:42 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.163.74]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id RAA04097 for ; Mon, 15 Apr 1996 17:42:26 +0200 (MET DST) Received: from lubricant.free.org (lubricant.free.org [199.3.242.5]) by linpro.no (8.6.12/linpro1.13) id for ; Tue, 9 Apr 1996 23:14:45 +0200 Received: (from smap@localhost) by lubricant.free.org (8.7.3/8.6.9) id QAA24207 for ; Tue, 9 Apr 1996 16:14:08 -0500 (CDT) Received: from ppp059.free.org(199.3.242.90) by lubricant.free.org via smap (V1.3) id sma024201; Tue Apr 9 16:14:06 1996 Received: by ppp019.free.org with Microsoft Mail id <01BB262F.75CCE020@ppp019.free.org>; Tue, 9 Apr 1996 16:13:16 -0500 X-Authentication-Warning: lubricant.free.org: smap set sender to using -f Message-ID: <01BB262F.75CCE020@ppp019.free.org> From: Stephen Crowley To: "'Quake Developers'" Subject: MAP File Format Date: Tue, 9 Apr 1996 16:13:09 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Lines: 11 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 359 Has anyone figured out Id's map file format yet? I have been looking at johnc99.map quoted on one of the pages here. And was wondering, how are leaf codes implemented in .map files? Also, I don't really understand why you need six planes just for one side of the cube. Does anyone know of any other map files? Please forgive me if I'm way off. Stephen From quake-editing-owner@nvg.unit.no Mon Apr 15 17:52 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.163.74]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id RAA04295 for ; Mon, 15 Apr 1996 17:52:30 +0200 (MET DST) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id RAA14229 for quake-editing-outgoing; Mon, 15 Apr 1996 17:36:22 +0200 Received: from vidar.diku.dk (root@vidar.diku.dk [130.225.96.249]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id RAA14220 for ; Mon, 15 Apr 1996 17:36:12 +0200 Received: from berling.diku.dk (uffefl@berling.diku.dk [130.225.96.235]) by vidar.diku.dk (8.6.12/8.6.12) with ESMTP id RAA03927 for ; Mon, 15 Apr 1996 17:36:10 +0200 Received: (uffefl@localhost) by berling.diku.dk (8.6.12/8.6.12) id RAA29996; Mon, 15 Apr 1996 17:36:09 +0200 Date: Mon, 15 Apr 1996 17:36:08 +0200 (METDST) From: Uffe Friis Lichtenberg To: Quake Editing Mailing List Subject: No texture patches Message-ID: MIME-Version: 1.0 Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 65 Status: RO Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 2519 Hej all, and especially Bernd, Just read a bit on Bernds QTEST1 RFC at http://www.nero.uni-bonn.de/~dn/q-sup/info/q_rfc.html I have some comments on the "No texture patches" limitation. It is clear to us by now that Quake does not support Doom-like texture patches, so that we could create a multitude of textures using only a small set of building-block-textures. The question is: is it a problem that we somehow can circumvent? We can, at least for static textures, somehow simulate the existance of texture-patches for signs using an approach like this: Say we got a wall, and want some sort of sign, or message, shown on this wall. It could be accomplished, with relatively little memory overhead, by making a sign-sized polygon in the wall we want the sign on, and assigning a sign texture to it. Something like +-------------+ +-------------+ | | | wall | | | +---+-----+---+ | original | becomes | w | sign| w | | wall | +---+-----+---+ | | | wall | +-------------+ +-------------+ Unfortunately this surely adds some overhead to the renderer, and isn't completely flexible. (Unless we are using signs that fit a polygon perfectly we need to provide one sign texture for each kind of surface we want to assign it to.) And I'm unsure whether qbsp wouldn't just merge the two brushes sides. But perhaps it will only do so when the brushes has the same texture parameters (texture mipmap and NAT-coordinates). But is there a better way? The best I can come up with is implementing signs using billboard objects. (http://www.nero.uni-bonn.de/~dn/q-sup/info/qedit_info.html) And, as ids name suggests, this is probably the main purpose of having billboard objects. If a billboard object exists that "stay-in-place" all of the time we could layer any number of textures, thus getting the desired sign effect. The question is: is this flexible enough? I can't really think of a situation where I would wan't the texture patches from Doom available, but then I didn't ever do much creative work with textures in Doom. Anyway, I think that the problems of integrating texture patches in the Quake engine now would surely exceed the gained flexibility (unless ofcourse they already are supported, and nobody found out yet :). Zonk, Uffe. [uphfe] uffefl@diku.dk -- "This .signature hasn't been left unintentionally void of blankness" From quake-editing-owner@nvg.unit.no Mon Apr 15 18:43 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.163.74]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id SAA05474 for ; Mon, 15 Apr 1996 18:43:36 +0200 (MET DST) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id SAA15232 for quake-editing-outgoing; Mon, 15 Apr 1996 18:28:17 +0200 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id SAA15221 for ; Mon, 15 Apr 1996 18:28:03 +0200 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id SAA05227; Mon, 15 Apr 1996 18:27:56 +0200 (MET DST) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.4/8.7.1) id SAA00711; Mon, 15 Apr 1996 18:27:54 +0200 (MET DST) From: Bernd Kreimeier Date: Mon, 15 Apr 1996 18:27:54 +0200 (MET DST) Message-Id: <199604151627.SAA00711@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no, bernd@marvin.nero.uni-bonn.de Subject: ADMIN: Quake Developers list X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 995 X-Lines: 32 Status: RO You should by now have received the backlog of messages that made it into the backup prior to the hardware failure at nvg.unit.no, or got into the queue after the site was up again. For those that haven't received the mail notifications I submitted based on a not too recent list of subscribers, and have missed the USENET postings: The nvg.unit.no site suffered a hard disk failure on friday, april 5th. The majordomo files were badly hurt, and Arnt Gulbrandsen, Stig Venaas and possibly others have spent a significant amount of time on recovering as much as could be done. I am currently preparing to move the list to another site. I will thus switch the list to closed mode again, preventing further subscriptions until the transfer is done. b. P.S.: the Quake Developers pages might be down later this week, as we are replacing the WWW server we are currently using. From quake-editing-owner@nvg.unit.no Wed Apr 17 13:32 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.163.74]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id NAA02392 for ; Wed, 17 Apr 1996 13:32:54 +0200 (MET DST) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id CAA22057 for quake-editing-outgoing; Tue, 16 Apr 1996 02:24:22 +0200 Received: from lubricant.free.org (smap@lubricant.free.org [199.3.242.5]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id CAA22051 for ; Tue, 16 Apr 1996 02:24:18 +0200 Received: (from smap@localhost) by lubricant.free.org (8.7.3/8.6.9) id TAA15671 for ; Mon, 15 Apr 1996 19:20:27 -0500 (CDT) Received: from ppp032.free.org(199.3.242.63) by lubricant.free.org via smap (V1.3) id sma015664; Mon Apr 15 19:20:22 1996 Received: by ppp032.free.org with Microsoft Mail id <01BB2B01.004B09E0@ppp032.free.org>; Mon, 15 Apr 1996 19:23:18 -0500 X-Authentication-Warning: lubricant.free.org: smap set sender to using -f Message-ID: <01BB2B01.004B09E0@ppp032.free.org> From: Stephen Crowley To: "'Quake Developers'" Subject: MAP Format Date: Mon, 15 Apr 1996 19:22:20 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 36 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 1265 Hello everyone, Please ignore my last post, I realised how it works now. Sorry about that. Now on to the question. Has anyone successfully taken a .map file and compiled it to a .bsp yet? I started work on a program to do this a few days ago, but I need a little help. I can read all the sets of points from the maps and create a bunch of planes. Here is the first brush from johnc99.map: A B C D 1.000000 0.000000 0.000000 0.000000 0.000000 -1.000000 0.000000 -720.000000 -1.000000 0.000000 0.000000 -208.000000 0.000000 1.000000 0.000000 496.000000 0.000000 0.000000 -1.000000 0.000000 0.000000 0.000000 1.000000 -16.000000 Can anyone verify if this is correct or not? Do I need to make all the distances positive? Now that I have the planes, how would I go about creating a complex polyhedron? (private e-mail please) I have a 3d node builder w/ source that will take a list of convex polygons in text format and build the node tree. But I need it to take polyhedrons instead. It would be a lot easier, I think, to use a modified version of it instead of trying to write my own. It's is very efficient, if anyone wants it just mail me. I guess I just can't wait until Id release theirs. :-) Thanks, Stephen From quake-editing-owner@nvg.unit.no Wed Apr 17 14:33 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.163.74]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id OAA03453 for ; Wed, 17 Apr 1996 14:33:01 +0200 (MET DST) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id OAA09008 for quake-editing-outgoing; Wed, 17 Apr 1996 14:20:00 +0200 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id OAA08875 for ; Wed, 17 Apr 1996 14:15:01 +0200 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id OAA03129; Wed, 17 Apr 1996 14:14:57 +0200 (MET DST) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.4/8.7.1) id OAA07341; Wed, 17 Apr 1996 14:14:53 +0200 (MET DST) From: Bernd Kreimeier Date: Wed, 17 Apr 1996 14:14:53 +0200 (MET DST) Message-Id: <199604171214.OAA07341@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no, bernd@marvin.nero.uni-bonn.de Subject: ADMIN: final (hopefully) message X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 847 X-Lines: 26 Status: RO You will have received some more backlog mails from the quake-editing@nvg.unit.no list, as majordomo is up again. I am currently locking the list, and removing all subscriptions. You will not have to unsubscribe yourself. My apologies those who have accidentally been moved/ resubscribed by recovering the files from not to recent backups. There will (hopefully) no more postings from nvg.unit.no now, and I will sort out the subscribers list at the new site, gamers.org, ASAP. A final thanks to Arnt Gulbrandsen and Stig Venaas from nvg.unit.no for recovering the list one last time, and for supporting it (and doom-editing). signing off b. From quake-dev-owner@gamers.org Wed Apr 17 19:25 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 TAA08627 for ; Wed, 17 Apr 1996 19:24:59 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id NAA23758 for quake-dev-outgoing; Wed, 17 Apr 1996 13:20:03 -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 NAA23752 for ; Wed, 17 Apr 1996 13:19:56 -0400 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id TAA08581; Wed, 17 Apr 1996 19:19:50 +0200 (MET DST) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.4/8.7.1) id TAA10222; Wed, 17 Apr 1996 19:19:43 +0200 (MET DST) From: Bernd Kreimeier Date: Wed, 17 Apr 1996 19:19:43 +0200 (MET DST) Message-Id: <199604171719.TAA10222@colossus.nero.uni-bonn.de> To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de Subject: Total Recall X-Sun-Charset: US-ASCII Sender: owner-$LIST@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 886 X-Lines: 29 Status: RO Done. Back to business. You will find in the Hypermail archive all messages that reached me, at http://www.nero.uni-bonn.de/~dn/qd/archive/ The following events might have been missed by some of you during the blackout since that disk failure: - tools for editing qtest1 are okay - MAP file info by John Carmack released - CGDC talk by Michael Abrash on Quake rendering details on which can be found in said archive, and the support pages at http://www.nero.uni-bonn.de/~dn/q-sup/. Thanks to Piotr Kapiszweski for providing a new home for this list, and for making the move as painless as possible. b. ----------------------------------------------------------- "Having you here has me kept busier than a one-armed paperhanger." ----------------------------------------------------------- From quake-dev-owner@gamers.org Wed Apr 17 21:25 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 VAA09793; Wed, 17 Apr 1996 21:25:36 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id PAA24210 for quake-dev-outgoing; Wed, 17 Apr 1996 15:24:23 -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 PAA24206 for ; Wed, 17 Apr 1996 15:24:19 -0400 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id VAA09781; Wed, 17 Apr 1996 21:24:16 +0200 (MET DST) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.4/8.7.1) id VAA10400; Wed, 17 Apr 1996 21:24:11 +0200 (MET DST) From: Bernd Kreimeier Date: Wed, 17 Apr 1996 21:24:11 +0200 (MET DST) Message-Id: <199604171924.VAA10400@colossus.nero.uni-bonn.de> To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de Subject: FYI: info from John Carmack X-Sun-Charset: US-ASCII Sender: owner-$LIST@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 1685 X-Lines: 46 Status: RO The following are recent updates on the MAP and BSP details. Note that the second one is intended to solve the problem of distributing BSP files w/o including the Mipmaps. The basic idea is to have a modified "qbsp", or a separate tool, parsing a MAP file, and emitting lines like "_texture" "1 WALL14_5" in the worldspawn entity. Reference WAD files might be provided using "_wad" ".../base.wad" lines, or parameters to whatever tool is used for BSP extension. That tool will have to use the "_texture" key/value lines to determine which Mipmaps to add. I would still prefer a unified handling of PACK, WAD, WAD2, and BSP, but that's a different issue. After all, physicists always prefered GUTs. b. >From: John Carmack, Thu, 11 Apr 96 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. >From: John Carmack, Tue, 16 Apr 96 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. From quake-dev-owner@gamers.org Wed Apr 17 21:38 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 VAA09921; Wed, 17 Apr 1996 21:38:11 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id PAA24302 for quake-dev-outgoing; Wed, 17 Apr 1996 15:37:11 -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 PAA24297 for ; Wed, 17 Apr 1996 15:37:07 -0400 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id VAA09903; Wed, 17 Apr 1996 21:36:55 +0200 (MET DST) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.4/8.7.1) id VAA10417; Wed, 17 Apr 1996 21:36:47 +0200 (MET DST) From: Bernd Kreimeier Date: Wed, 17 Apr 1996 21:36:47 +0200 (MET DST) Message-Id: <199604171936.VAA10417@colossus.nero.uni-bonn.de> To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de Subject: ADMIN: Quake Developers fixes 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: 648 X-Lines: 15 Status: RO The QDev list's digest is working now. I had to fix a reply/sender problem with both the list and the digest. The QDev pages might be unreacheable at times; today we replaced the CERN server with Apache. It seems the protection is not yet configured right. Should be fixed now. The list is open for postings, and will be openend for new subscriptions again on monday. I honestly hope this is the last ADMIN posting for some weeks. b. From quake-dev-owner@gamers.org Thu Apr 18 18: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 SAA02008; Thu, 18 Apr 1996 18:41:46 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id MAA28647 for quake-dev-outgoing; Thu, 18 Apr 1996 12:40:29 -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 MAA28643 for ; Thu, 18 Apr 1996 12:40:23 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id SAA01981; Thu, 18 Apr 1996 18:40:20 +0200 (MET DST) Date: Thu, 18 Apr 1996 18:40:20 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199604181640.SAA01981@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de Subject: Re: No texture patches 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: 2668 X-Lines: 61 Status: RO A posting back from the quake-editing era.... >From: Uffe Friis Lichtenberg >It is clear to us by now that Quake does not support Doom-like >texture patches, so that we could create a multitude of textures using >only a small set of building-block-textures. The question is: is it a >problem that we somehow can circumvent? >The best I can come up with is implementing signs using billboard >objects. Having an object (entity) aligned with a wall will work, as long as you do not forget that the light maps will not be used on the object, only on the surfaces behind. Btw., a better (OpenGL-ish) name for such objects pasted to walls would be "decals" >I can't really think of a situation where I would wan't the >texture patches from Doom available, If I understood correctly: textures are references by MAP files by name. The "qbsp" utility creates surfaces from brushes, and keeps track of which textures have been used. Then it will look up the textures in a (might even by DOOM-style) WAD ("wad" ".../gfx/base.wad"), and create the mipmaps. I wonder if the anti-aliased scaling is done every time, and if TEXTURE1/2 are still (perhaps modified) in use. Any such processing of multi-patch textures (from DOOM or whatever) to mipmaps could be done seperately. >Anyway, I think that the problems of integrating texture patches in the >Quake engine now would surely exceed the gained flexibility (unless >ofcourse they already are supported, and nobody found out yet :). Perhaps my page has been inconclusive: a) using patches saves some texture memory, but not surface cache. It would ease adding small variations and navigational aids to basic (flat) textures b) all available descriptions of the renderer state that the suitable mipmap from a texture and the light map for (potentially) visible surfaces are combined once. The result is stored in the surface cache, as long as memory is available, and the surface remains in sight. Adding some simplified patch mechanism (e.g. one flat texture, opaque, and an optional list of partly transparent patches/decals) to this preprocessing "mipamp+lightmap -> texture in surface cache" would surely be feasible. In this case, the decals would be subject to the same lighting. They might even be flagged for "bright", in that case the patches would be added after lighting the appropriate mipmap. Hope that made more sense, this time. b. From quake-dev-owner@gamers.org Fri Apr 19 04:47 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 EAA07134; Fri, 19 Apr 1996 04:47:46 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id WAA00851 for quake-dev-outgoing; Thu, 18 Apr 1996 22:47:05 -0400 Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by gamers.org (thegate/gamers) with SMTP id WAA00846 for ; Thu, 18 Apr 1996 22:47:02 -0400 Received: from sunset.cs.utah.edu by cs.utah.edu (8.6.12/utah-2.21-cs) id UAA15436; Thu, 18 Apr 1996 20:46:51 -0600 Received: from peruvian.cs.utah.edu by sunset.cs.utah.edu (8.6.12/utah-2.15sun-leaf) id UAA27560; Thu, 18 Apr 1996 20:47:27 -0600 Received: from localhost by peruvian.cs.utah.edu (8.6.10/utah-2.15-leaf) id UAA05669; Thu, 18 Apr 1996 20:46:49 -0600 Message-Id: <199604190246.UAA05669@peruvian.cs.utah.edu> To: quake-dev@gamers.org From: larsen@sunset.cs.utah.edu (Steve Larsen) Subject: new level Date: Thu, 18 Apr 96 20:46:33 MDT 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: 1441 X-Lines: 49 Status: RO Hi all, I just finished hacking together a REAL small quake level (just two rooms connected by a couple of hallways). In the meantime, I learned a couple of things of interest that I thought I might share: 1. The UQS says that the edges for a surface must be constructed such that the vertices would be traversed in a counter-clockwise manner. I think this must be wrong. I could only get it to work in clockwise order. 2. As you may know, there is a limit to the maximum extent that a surface can displace (based on texture size, I'm guessing??). There doesn't seem to be such a limit on that animated worms texture (the one with the periodic noise-filter). 3. I had trouble using a single plane to describe the position of multiple surfaces when these surfaces where not on the same side of a BSP node. So, for the following: ^ | ------------------------|--------------------- a | b | | | | | BSP partition surface a and b are co-planar. However, if I used the same plane for them I would get unpredictable results (mostly, they would just not show up). I am sure I was doing something wrong, but I don't know what. Anyone have any experience with this? Anyway, now that I have the basics down, I can work on getting my editor up to speed. laters, Steve P.S. If you want to see this little level, visit: http://www.cs.utah.edu/~larsen. It is called "tworooms.zip". From quake-dev-owner@gamers.org Fri Apr 19 06:06 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 GAA07704; Fri, 19 Apr 1996 06:06:18 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id AAA04249 for quake-dev-outgoing; Fri, 19 Apr 1996 00:05:47 -0400 Received: from postbox.acs.ohio-state.edu (postbox.acs.ohio-state.edu [128.146.214.20]) by gamers.org (thegate/gamers) with SMTP id AAA04245 for ; Fri, 19 Apr 1996 00:05:45 -0400 Received: from carollo.acs.ohio-state.edu by postbox.acs.ohio-state.edu (8.6.9/5.901231) id AAA25135; Fri, 19 Apr 1996 00:05:43 -0400 Message-ID: <31766876.7E6C@osu.edu> Date: Thu, 18 Apr 1996 12:06:14 -0400 From: Chris Carollo Organization: The Ohio State University X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: quake-dev@gamers.org Subject: line intersecting plane... References: <199604190246.UAA05669@peruvian.cs.utah.edu> 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: 15 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 508 I have a geometric question... What is the easiest way to calculate where a line intersects a plane (given by two non-colinear vectors)? I started to work out the math (three equations, three unknowns), but it got REAL ugly REAL quick. I'm trying to convert my two-vector plane representation to the normal- distance representation...calculating the normal is simple (cross product), the distance from the normal to (0,0,0) is screwing with me. Does anyone have a simple way to calculate this? -Chris From quake-dev-owner@gamers.org Fri Apr 19 14:27 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 OAA12126; Fri, 19 Apr 1996 14:27:35 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id IAA06366 for quake-dev-outgoing; Fri, 19 Apr 1996 08:22:03 -0400 Received: from xr3.atlas.fr (xr3.atlas.fr [194.51.9.5]) by gamers.org (thegate/gamers) with ESMTP id IAA06362 for ; Fri, 19 Apr 1996 08:22:00 -0400 Fri, 19 Apr 1996 14:21:31 +0200 Fri, 19 Apr 1996 14:21:31 +0200 Fri, 19 Apr 1996 14:21:25 +0200 X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Fri, 19 Apr 1996 14:21:31 +0200 X400-Received: by mta xr3.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Fri, 19 Apr 1996 14:21:31 +0200 X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Fri, 19 Apr 1996 14:21:26 +0200 X400-Received: by /PRMD=cnet/ADMD=atlas/C=fr/; Relayed; Fri, 19 Apr 1996 14:21:25 +0200 Date: Fri, 19 Apr 1996 14:21:25 +0200 X400-Originator: montanuy@lsun80.lannion.cnet.fr X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=cnet/ADMD=atlas/C=fr/;829916485@x400.lannion.cnet.fr] X400-Content-Type: P2-1984 (2) Content-Identifier: New version of s Alternate-Recipient: Allowed From: Olivier Montanuy Message-ID: <9604191220.2C5504@lat1192.lannion.cnet.fr> To: quake-dev@gamers.org Subject: New version of specs 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: 1200 X-Lines: 33 Status: RO Dear Quake hackers, I haven't updated the specs in 3 weeks, despite all the new info, because I lack time for serious work on them. Very sorry for this, but work becomes quite involving (at times). Maybe it's time for someone else to maintain those specs. As some of you might have noticed, a few areas in the Quake specs are real unclear: I list some here: - Could someone confirm the surface edges are in clockwise order, not anticlockwise as stated? I admit I said anticlockwise at random (I knew it was one or the other. 1 chance out of 2, no?) but later forgot to update. - anyone could confirm the BSP split notes split or don't split the surface edges? - Could someone give a working formula or code for the layout of lightmaps and textures? I roughly know, but don't have time to check. - Some of you are working on the .MAP format. Your input is welcome in the specs (I don't have any time for them). Also, my BSP viewer WinTex 4.3 didn't make any progress in one month. It's too rudimentary to be worth publishing (only wireframe). If some of you know where I can get a second life for free, let me know. With regards, Olivier Montanuy From quake-dev-owner@gamers.org Fri Apr 19 14: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 OAA12428; Fri, 19 Apr 1996 14:53:24 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id IAA06519 for quake-dev-outgoing; Fri, 19 Apr 1996 08:52: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 IAA06515 for ; Fri, 19 Apr 1996 08:52:46 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id OAA12424 for quake-dev@gamers.org; Fri, 19 Apr 1996 14:52:33 +0200 (MET DST) Date: Fri, 19 Apr 1996 14:52:33 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199604191252.OAA12424@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org Subject: Re: line intersecting plane... 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: 1802 X-Lines: 41 Status: RO >From: Olivier Montanuy > multiply by the exponent of your personal level in maths. Well, this is not much of a useful answer, in any sense :-(. > From: Chris Carollo > What is the easiest way to calculate where a line intersects a plane > (given by two non-colinear vectors)? You will find a Dr. Dobb's Sourcebook article in the March/April 1996 issue by Michael Abrash (thanks to Derek Nickel for providing the pointer in first place): "3-D Clipping and Other Thoughts". I will simply quote: "If we take any point and dot with the plane normal, we'll find out how far from the origin the point is, as measured along the plane normal. [..] a simple comparison of the two values [the distance of the plane to the origin, the projection of the point's vector on the plane's normal] suffices to tell us which side of the plane the point is on." Hence the normal + distance representation. > I'm trying to convert my two-vector plane representation to the normal- > distance representation...calculating the normal is simple (cross > product), the distance from the normal to (0,0,0) is screwing with > me. You have the vector from the origin to the 1st of your three points defining the plane. You know that this point is on the plane. A dot product with your normal will give you the distance from origin to plane (again: projection of the vector on the normal). b. ------------------------------------------------------------------------- "Sharing knowledge makes the world a better place." ------------------------------------------------------------------------- From quake-dev-owner@gamers.org Fri Apr 19 00:51 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 AAA05414; Fri, 19 Apr 1996 00:51:19 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id SAA29412 for quake-dev-outgoing; Thu, 18 Apr 1996 18:48:45 -0400 Received: from vidar.diku.dk (root@vidar.diku.dk [130.225.96.249]) by gamers.org (thegate/gamers) with SMTP id SAA29408 for ; Thu, 18 Apr 1996 18:48:42 -0400 Received: from fjalar.diku.dk (uffefl@fjalar.diku.dk [130.225.96.232]) by vidar.diku.dk (8.6.12/8.6.12) with ESMTP id AAA19848 for ; Fri, 19 Apr 1996 00:48:39 +0200 Received: (uffefl@localhost) by fjalar.diku.dk (8.6.12/8.6.12) id AAA03757; Fri, 19 Apr 1996 00:48:38 +0200 Date: Fri, 19 Apr 1996 00:48:38 +0200 (METDST) From: Uffe Friis Lichtenberg To: quake-dev@gamers.org Subject: Re: No texture patches In-Reply-To: <199604181640.SAA01981@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: 124 Status: RO Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 5638 On Thu, 18 Apr 1996, Bernd Kreimeier wrote: > A posting back from the quake-editing era.... :) (BTW: Thanks for all the hard work!) > >From: Uffe Friis Lichtenberg > > >The best I can come up with is implementing signs using billboard > >objects. > > Having an object (entity) aligned with a wall will work, as long as > you do not forget that the light maps will not be used on the object, > only on the surfaces behind. This is a problem! Billboard objects would probably always be flat- or perhaps gouraud-shaded, and not with light maps, so they would always stand out in some way. This would have to be taken into account when designing the level, and thus put a constraint on the level designer. This is a Bad Thing. > Btw., a better (OpenGL-ish) name for > such objects pasted to walls would be "decals" Quite. But having another term for billboard objects used only in this context would only lead to confusion. Anyway they aren't (as far as I can see) in any way usable as decals: they are individual objects that can be placed anywere in the world; they are not bound to a wall! > >I can't really think of a situation where I would wan't the > >texture patches from Doom available, > > If I understood correctly: textures are references by MAP files by name. > The "qbsp" utility creates surfaces from brushes, and keeps track of > which textures have been used. Then it will look up the textures in > a (might even by DOOM-style) WAD ("wad" ".../gfx/base.wad"), and create > the mipmaps. I wonder if the anti-aliased scaling is done every time, > and if TEXTURE1/2 are still (perhaps modified) in use. Well that depends on qbsp of course. Though the anti-aliased scaling isn't a very computationally expensive process, it would be a rather silly waste of CPU resources to do it everytime the textures were needed. My guess is that the wad files with textures contain all the four resolutions needed. Hopefully it is so: this opens up for some interesting special effects, like secret messages only visible when very close to the texture (or possibly very far away :). Try fooling round with MipDip and edit the different mipmaps without resampling them, and you'll see what I mean. > Any such processing of multi-patch textures (from DOOM or whatever) to > mipmaps could be done seperately. Yes. Even if Quake doesn't support patches it would be rather easy to implement a small utility that could build the relevant textures using some sort of patch description. This would of course not bring down the runtime overhead induced by having many textures in memory at one time, but would allow level-designers to easily create textures using the many existion Doom texture packages. Besides if the target machine has enough RAM it would clearly be more speed-efficient to disable patch building in real-time! > Perhaps my page has been inconclusive: > > a) using patches saves some texture memory, but not surface cache. > It would ease adding small variations and navigational aids to > basic (flat) textures Well... Using billboard objects could probably make adding navigational aids equally easy, but the small variations is still something that Quake seemingly doesn't support well. This might need a separate utility depending on how qbsp handles it. Alternatively my previously shown method of splitting up a surface in several sub-surfaces could solve some of these problems. > b) all available descriptions of the renderer state that the suitable > mipmap from a texture and the light map for (potentially) visible > surfaces are combined once. The result is stored in the surface > cache, as long as memory is available, and the surface remains in > sight. > > Adding some simplified patch mechanism (e.g. one flat texture, opaque, > and an optional list of partly transparent patches/decals) to this > preprocessing "mipamp+lightmap -> texture in surface cache" would surely > be feasible. In this case, the decals would be subject to the same > lighting. They might even be flagged for "bright", in that case the > patches would be added after lighting the appropriate mipmap. Though the combination of mipmap and lightmap is a trivial process (using colour mixing LUTs, or in Quakes case, colour lighting LUTs) it is not computationally cheap. It does involve at least one table-lookup per texel. Adding a patched texture building before (or after) this would add to the total overhead each time a texture had to be fetched into the surface cache. I'm not sure of how much overhead this would amount to, but it is still something that would slow down Quake. By this reason alone I would say that the patch building of textures should be done as a preprocessing step, even though it would make distribution files larger (unless we can agree on a distribution format that supports patches) and memory requirements larger. It is though a serious problem that Quake only supports 256 textures total on a level: lets hope that id fixes this ASAP. (BTW: files with many areas of great similarity --- as those build using a patch texture building approach --- would compress very well with Lempel-Ziv based compression algorithms. This of course includes most of the compression utilities today. So the net.bandwith load wouldn't necessarily get excessive.) > Hope that made more sense, this time. Quite. I guess the motto of todays lesson would be: buy more RAM :) And harddisk too... Zonk, Uffe. [uphfe] uffefl@diku.dk -- "This .signature hasn't been left unintentionally void of blankness" From quake-dev-owner@gamers.org Sat Apr 20 00:48 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 AAA08175 for ; Sat, 20 Apr 1996 00:48:33 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id SAA08777 for quake-dev-outgoing; Fri, 19 Apr 1996 18:47:27 -0400 Received: from relay.bt.net (relay.bt.net [194.72.6.52]) by gamers.org (thegate/gamers) with SMTP id SAA08773 for ; Fri, 19 Apr 1996 18:47:24 -0400 Received: from flash.globalnews.com by relay.bt.net with SMTP (PP); Fri, 19 Apr 1996 23:35:43 +0100 Received: by flash.globalnews.com (SMI-8.6/SMI-SVR4) id XAA17246; Fri, 19 Apr 1996 23:32:33 GMT From: jschuur@flash.globalnews.com Date: Fri, 19 Apr 1996 23:32:33 +0000 (GMT) To: quake-dev@gamers.org Subject: Quake map distribution: speed vs. legality 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: 23 Status: RO Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 1018 if i understand correctly, it is being proposed new quake levels should only be redistributed in a .map format, since each level contains the textures it uses. reditributing quake levels in a .bsp format would be a violation of id's copyright. calculating the nodes to a quake level however can take up to an hour even on a 4 processor alpha (according to information from id). surely no average home user is going to wait for hours before his level is converted from .map to .bsp. or am i misunderstanding something here? is there an intermittent format with calcutated nodes (and lighting and whatever else qbsp, light and vis do) that merely needs to be assembled to the finished product quickly? -- joost schuur, Online Magic Ltd. ------------ Tel: +44 171 820 7766 -- ------------------------------------------------------------------------ ------------------------------------------------------------------------ --- http://jalad.globalnews.com/~jschuur/ - jschuur@onlinemagic.co.uk -- From quake-dev-owner@gamers.org Sat Apr 20 01:30 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 BAA08481 for ; Sat, 20 Apr 1996 01:30:54 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id TAA08980 for quake-dev-outgoing; Fri, 19 Apr 1996 19:28:14 -0400 Received: from vidar.diku.dk (root@vidar.diku.dk [130.225.96.249]) by gamers.org (thegate/gamers) with SMTP id TAA08976 for ; Fri, 19 Apr 1996 19:28:10 -0400 Received: from fjalar.diku.dk (uffefl@fjalar.diku.dk [130.225.96.232]) by vidar.diku.dk (8.6.12/8.6.12) with ESMTP id BAA01934 for ; Sat, 20 Apr 1996 01:28:08 +0200 Received: (uffefl@localhost) by fjalar.diku.dk (8.6.12/8.6.12) id BAA24670; Sat, 20 Apr 1996 01:28:07 +0200 Date: Sat, 20 Apr 1996 01:28:07 +0200 (METDST) From: Uffe Friis Lichtenberg To: quake-dev@gamers.org Subject: Re: Quake map distribution: speed vs. legality In-Reply-To: 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: 43 Status: RO Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 1897 On Fri, 19 Apr 1996 jschuur@flash.globalnews.com wrote: > if i understand correctly, it is being proposed new quake levels should > only be redistributed in a .map format, since each level contains the > textures it uses. reditributing quake levels in a .bsp format would be a > violation of id's copyright. > > calculating the nodes to a quake level however can take up to an hour > even on a 4 processor alpha (according to information from id). surely no > average home user is going to wait for hours before his level is > converted from .map to .bsp. > > or am i misunderstanding something here? is there an intermittent format > with calcutated nodes (and lighting and whatever else qbsp, light and > vis do) that merely needs to be assembled to the finished product quickly? As I see it destributing a .bsp file does not necessarily infringe ids copyright, unless you include some of their textures. So what we need is to destribute a .bsp file without ids textures, that only needs to be preprocessed before use (ie. copy missing textures from id1.pak). I remember Carmack stating that all entries beginning with "_" (underscore) will be ignored by the quake engine. Therefore we could transport the texture information in such entries (or am I wrong?). Something _really_ smart would be to have the distributed .bsp file be a valid .bsp file, ready for play. Only before being preprocessed all surfaces would have the same texture! And this texture could simply be black with the inscription: "Don't play this level before running smartutil.exe on it..." or something similar! This way newbies could download their Quake levels, play them, and _not_ have to ask in newsgroups or on IRC why the levels never work! (Cool: self-documenting and all ;) Zonk, Uffe. [uphfe] uffefl@diku.dk -- "This .signature hasn't been left unintentionally void of blankness" From quake-dev-owner@gamers.org Sat Apr 20 08:25 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 IAA11522 for ; Sat, 20 Apr 1996 08:25:19 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id CAA10861 for quake-dev-outgoing; Sat, 20 Apr 1996 02:24:49 -0400 Received: from odin.mdn.com (root@odin.mdn.com [199.89.235.91]) by gamers.org (thegate/gamers) with SMTP id CAA10857 for ; Sat, 20 Apr 1996 02:24:45 -0400 Received: by odin.mdn.com id (Debian /\oo/\ Smail3.1.29.1 #29.33); Sat, 20 Apr 96 01:26 EST Message-Id: From: amoon@odin.mdn.com (Alex R. Moon) Subject: Re: Quake map distribution: speed vs. legality To: quake-dev@gamers.org Date: Sat, 20 Apr 1996 01:26:00 -0500 (EST) In-Reply-To: from "Uffe Friis Lichtenberg" at Apr 20, 96 01:28:07 am X-Mailer: ELM [version 2.4 PL24 PGP2] 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: 1999 X-Lines: 37 Status: RO Uffe Friis Lichtenberg wrote: > As I see it destributing a .bsp file does not necessarily infringe ids > copyright, unless you include some of their textures. So what we need is > to destribute a .bsp file without ids textures, that only needs to be > preprocessed before use (ie. copy missing textures from id1.pak). > > I remember Carmack stating that all entries beginning with "_" > (underscore) will be ignored by the quake engine. Therefore we could > transport the texture information in such entries (or am I wrong?). That was in reference to the .MAP files. I presume he meant that all entries beginning with '_' would be filtered out by the qbsp/light/vis tools and not show up in the .BSP file at all. > Something _really_ smart would be to have the distributed .bsp file be a > valid .bsp file, ready for play. Only before being preprocessed all > surfaces would have the same texture! And this texture could simply be > black with the inscription: "Don't play this level before running > smartutil.exe on it..." or something similar! > > This way newbies could download their Quake levels, play them, and _not_ > have to ask in newsgroups or on IRC why the levels never work! > > (Cool: self-documenting and all ;) I think the most compatible/efficient way to do this would be to fully compile the BSP tree, but instead of having the full MIP texture data for copyrighted textures, it would just have the texture name and either a 0x0 texture (no texture data) or a dummy self-documenting texture like you describe above. Then the end-user compiling utility would just go searching through that user's other BSP files (or a WAD or whatever) for a texture with the same name as a dummy texture in the target BSP. Viola, a complete level. -- Alex R. Moon | "A university is what a college become when the amoon@odin.mdn.com | faculty loses interest in students." 71513.1453@compuserve.com | -- John Cardi From quake-dev-owner@gamers.org Sat Apr 20 19:55 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 TAA17282 for ; Sat, 20 Apr 1996 19:55:57 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id NAA12661 for quake-dev-outgoing; Sat, 20 Apr 1996 13:55: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 NAA12656 for ; Sat, 20 Apr 1996 13:55:10 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id TAA17252; Sat, 20 Apr 1996 19:55:09 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199604201755.TAA17252@marvin.nero.uni-bonn.de> Subject: Re: Quake map distribution: speed vs. legality To: quake-dev@gamers.org Date: Sat, 20 Apr 1996 19:55:09 +0200 (MET DST) Cc: bernd@marvin.nero.uni-bonn.de (Bernd Kreimeier) In-Reply-To: from "Alex R. Moon" at Apr 20, 96 01:26:00 am X-Mailer: ELM [version 2.4 PL25] 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 Status: RO X-Lines: 51 Content-Type: text/plain; charset="US-ASCII" Content-Length: 2030 >>Uffe Friis Lichtenberg wrote: >> I remember Carmack stating that all entries beginning with "_" >> (underscore) will be ignored by the quake engine. Therefore we could >> transport the texture information in such entries (or am I wrong?). You are right. That is the idea. >That was in reference to the .MAP files. I presume he meant that >all entries beginning with '_' would be filtered out by the >qbsp/light/vis tools and not show up in the .BSP file at all. This is not correct. Please re-read my comments along with the mail forwarded last week. If I understood correctly, the bottom line is: - the "wad" and "light" entries are used by qbsp and light, but not by qtest1 (not sure about this) - there are currently QuakeC dummies (entities) for these to keep Quake qtest1 from complaining (anybody put a undefined key into the entities file already?) - John Carmack changed Quakes handling of the entities lump, all "_*" keys will be ignored now - he intends to change said entries to "_wad" and "_light", to get rid of the dummies - he proposes using "_*" key/value lines in the MAP files for tasks like a BSP completion Distribution of MAP files is useful if one wants the level to be modified and edited by others. Automatic generation of MAP from BSP is a nice task we could tackle along with generating MAP from DOOM level descriptions. Distribution of BSP files w/o mipmaps lump requires a lookup assigning indices (as used in surfaces, generated by qbsp) to textures (as defined in the MAP file). It is no good idea to distribute this lookup separately. The current proposal is to add "_texture" " 1 WALL54_0" lines to the entities lump in the BSP. These will not be deleted by qbsp, and will be ignored by Quake. To use this approach with qtest1, these lines would have to be deleted after adding the mipmaps, to prevent warnings or errors. However, we are far from generating BSP files for qtest1 :-). b. From quake-dev-owner@gamers.org Sat Apr 20 20:19 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 UAA17476 for ; Sat, 20 Apr 1996 20:19:50 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id OAA12773 for quake-dev-outgoing; Sat, 20 Apr 1996 14:19:34 -0400 Received: from odin.mdn.com (root@odin.mdn.com [199.89.235.91]) by gamers.org (thegate/gamers) with SMTP id OAA12769 for ; Sat, 20 Apr 1996 14:19:29 -0400 Received: by odin.mdn.com id (Debian /\oo/\ Smail3.1.29.1 #29.33); Sat, 20 Apr 96 13:20 EST Message-Id: From: amoon@odin.mdn.com (Alex R. Moon) Subject: Re: Quake map distribution: speed vs. legality To: quake-dev@gamers.org Date: Sat, 20 Apr 1996 13:20:42 -0500 (EST) In-Reply-To: <199604201755.TAA17252@marvin.nero.uni-bonn.de> from "Bernd Kreimeier" at Apr 20, 96 07:55:09 pm X-Mailer: ELM [version 2.4 PL24 PGP2] 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: 1513 Status: RO X-Lines: 31 Bernd Kreimeier wrote: > Distribution of MAP files is useful if one wants the level to > be modified and edited by others. Automatic generation of > MAP from BSP is a nice task we could tackle along with > generating MAP from DOOM level descriptions. > > Distribution of BSP files w/o mipmaps lump requires a lookup > assigning indices (as used in surfaces, generated by qbsp) to > textures (as defined in the MAP file). It is no good idea > to distribute this lookup separately. The current proposal is > to add > > "_texture" " 1 WALL54_0" > > lines to the entities lump in the BSP. These will not be > deleted by qbsp, and will be ignored by Quake. To use this > approach with qtest1, these lines would have to be deleted > after adding the mipmaps, to prevent warnings or errors. But a lookup table mechanism for textures already exists in the BSP format. If you just use the mipmaps lump with dummy textures (textures with a name like WALL54_0 and an implied index by their position in the lump, but a size of 0x0 and no actual texture data) then a utility program can go through and replace all dummy textures with real textures from the quake BSP files based on the names of the dummy textures. There is no need to clutter up the entities lump with redundant data. -- Alex R. Moon | "A university is what a college become when the amoon@odin.mdn.com | faculty loses interest in students." 71513.1453@compuserve.com | -- John Cardi From quake-dev-owner@gamers.org Sat Apr 20 20: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 UAA17616 for ; Sat, 20 Apr 1996 20:36:59 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id OAA12859 for quake-dev-outgoing; Sat, 20 Apr 1996 14:36:43 -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 OAA12855 for ; Sat, 20 Apr 1996 14:36:39 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id UAA17609; Sat, 20 Apr 1996 20:36:35 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199604201836.UAA17609@marvin.nero.uni-bonn.de> Subject: Re: Quake map distribution: speed vs. legality To: quake-dev@gamers.org Date: Sat, 20 Apr 1996 20:36:35 +0200 (MET DST) Cc: bernd@marvin.nero.uni-bonn.de (Bernd Kreimeier) In-Reply-To: from "Alex R. Moon" at Apr 20, 96 01:20:42 pm X-Mailer: ELM [version 2.4 PL25] 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 Status: RO X-Lines: 23 Content-Type: text/plain; charset="US-ASCII" Content-Length: 1015 > If you just use the mipmaps lump with dummy textures (textures > with a name like WALL54_0 and an implied index by their position in the > lump, but a size of 0x0 and no actual texture data) then a utility program > can go through and replace all dummy textures with real textures from the > quake BSP files based on the names of the dummy textures. You are perfectly right. Somehow I entirely forgot about the "name" entry in the mipmaps lump. Too much sysad work last week, I guess. It might be a good idea to set the version index in the BSP header to some value unused and unknown to Quake, to keep it from loading a distribution BSP (let's call it dBSP for convenience sake). We could write a tool to "strip" a BSP file, creating a dBSP, and test it with the qtest1 BSP files (no practical use, as we should not distribute, but nice to test it already). Same for the "add_mip". Neat. Now I wonder wether those "_entries" are good for anything... b. From quake-dev-owner@gamers.org Sat Apr 20 21: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 VAA17916 for ; Sat, 20 Apr 1996 21:16:50 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id PAA13090 for quake-dev-outgoing; Sat, 20 Apr 1996 15:16:28 -0400 Received: from vidar.diku.dk (root@vidar.diku.dk [130.225.96.249]) by gamers.org (thegate/gamers) with SMTP id PAA13086 for ; Sat, 20 Apr 1996 15:16:25 -0400 Received: from jarnsaxa.diku.dk (uffefl@jarnsaxa.diku.dk [130.225.96.244]) by vidar.diku.dk (8.6.12/8.6.12) with ESMTP id VAA27190 for ; Sat, 20 Apr 1996 21:16:23 +0200 Received: (uffefl@localhost) by jarnsaxa.diku.dk (8.6.12/8.6.12) id VAA28478; Sat, 20 Apr 1996 21:16:22 +0200 Date: Sat, 20 Apr 1996 21:16:22 +0200 (METDST) From: Uffe Friis Lichtenberg To: quake-dev@gamers.org Subject: Re: Quake map distribution: speed vs. legality In-Reply-To: <199604201755.TAA17252@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 Status: RO X-Lines: 88 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 3725 On Sat, 20 Apr 1996, Bernd Kreimeier wrote: > Distribution of MAP files is useful if one wants the level to > be modified and edited by others. Automatic generation of > MAP from BSP is a nice task we could tackle along with > generating MAP from DOOM level descriptions. Having the .map follow the .bsp file all the way would be optimal. This way both level-editing and level-playing would be supported. I propose to designate an entry "_mapfile.zip" were a zip-compressed .map representation of the .bsp file could be kept. This way an editor would only have to deal with .bsp files (and thus avoid confusion for users). If the user wants to play the level he starts it up using the console command "map whatever", and if he wants to edit it he loads up an editor with whatever.bsp. This I propose because I find the idea of a completely self-contained (immidiately 'playable') .bsp-file very attractive. Instead of the typical Doom-multifile-zip-distribution each level would have one, and only one, file associated with it. The typical readme.txt could also easily be added to the .bsp-file as "_readme". Now, as earlier stated, a user might have to run an external utility on the .bsp-file (to get all textures right) to get the full experience, but basically it is playable right-away. Hmmm... I'm rambling, let me summarize: * A distributable .bsp-file contains none of ids textures, but "_texture" entries that tell a preprocessing utility how to build the right .bsp-file from the distributable .bsp-file. All the surfaces that should have had one of ids textures, are assigned a dummy texture in the distributable .bsp-file. This assignment is changed by a preprocessing utility according to the "_texture" entries. The preprocessing utility should also be able to reverse this process, so you don't have to keep the distributable file as well as the playable one. * To help map-editing a .bsp-file builder should, as a post-processing step, zip the .map-source-file and include it into the .bsp-file in the "_mapfile.zip" entry. This way an editor could work on .bsp-files only (and even save editor project information in the .bsp file as "_MYQED:varname=value" or similar; as long as we keep the MYQED string unique for each editor and editor version) and rebuilding .map-files from .bsp-files wouldn't be necessary. Also, a level author who doesn't wish other people to use his levels as a base, could easily mark this be _not_ including the "_mapfile.zip" entry. * The level-information, copyright and so on, could be placed in a "_readme" entry, which the previously mentioned preprocessing utility could show to the user while processing the .bsp-file. It would be especially nice if we could agree this early on, on a general layout of the "_*" entries. Even though we aren't even (thinking of :) building .bsp-files from .map-files yet, it would be nice to agree on a standard of sorts. > Distribution of BSP files w/o mipmaps lump requires a lookup > assigning indices (as used in surfaces, generated by qbsp) to > textures (as defined in the MAP file). It is no good idea > to distribute this lookup separately. The current proposal is > to add > > "_texture" " 1 WALL54_0" > > lines to the entities lump in the BSP. These will not be > deleted by qbsp, and will be ignored by Quake. To use this > approach with qtest1, these lines would have to be deleted > after adding the mipmaps, to prevent warnings or errors. I haven't tried it, but does qtest1 complain when encountering "_*" entries? Zonk, Uffe. [uphfe] uffefl@diku.dk -- "This .signature hasn't been left unintentionally void of blankness" From quake-dev-owner@gamers.org Sat Apr 20 21:19 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 VAA17962 for ; Sat, 20 Apr 1996 21:19:47 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id PAA13251 for quake-dev-outgoing; Sat, 20 Apr 1996 15:19:30 -0400 Received: from vidar.diku.dk (root@vidar.diku.dk [130.225.96.249]) by gamers.org (thegate/gamers) with SMTP id PAA13247 for ; Sat, 20 Apr 1996 15:19:28 -0400 Received: from jarnsaxa.diku.dk (uffefl@jarnsaxa.diku.dk [130.225.96.244]) by vidar.diku.dk (8.6.12/8.6.12) with ESMTP id VAA27334 for ; Sat, 20 Apr 1996 21:19:27 +0200 Received: (uffefl@localhost) by jarnsaxa.diku.dk (8.6.12/8.6.12) id VAA28494; Sat, 20 Apr 1996 21:19:25 +0200 Date: Sat, 20 Apr 1996 21:19:25 +0200 (METDST) From: Uffe Friis Lichtenberg To: quake-dev@gamers.org Subject: Re: Quake map distribution: speed vs. legality In-Reply-To: <199604201836.UAA17609@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 Status: RO X-Lines: 39 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 1552 On Sat, 20 Apr 1996, Bernd Kreimeier wrote: > > If you just use the mipmaps lump with dummy textures (textures > > with a name like WALL54_0 and an implied index by their position in the > > lump, but a size of 0x0 and no actual texture data) then a utility program > > can go through and replace all dummy textures with real textures from the > > quake BSP files based on the names of the dummy textures. > > You are perfectly right. Somehow I entirely forgot about the "name" > entry in the mipmaps lump. Too much sysad work last week, I guess. > > It might be a good idea to set the version index in the BSP header to > some value unused and unknown to Quake, to keep it from loading a > distribution BSP (let's call it dBSP for convenience sake). I still think that having a format for the dBSP files that would allow them to be playable (though ugly to look at) would be the best solution. > We could write a tool to "strip" a BSP file, creating a dBSP, and test > it with the qtest1 BSP files (no practical use, as we should not > distribute, but nice to test it already). Same for the "add_mip". Neat. Shouldn't be so difficult really. As long as people who add textures assign them new names... But isn't this (almost) exactly what Thingy does? > Now I wonder wether those "_entries" are good for anything... ? See previous posting... They sure could be used for a lot of creative things. Just put your mind to it :) Zonk, Uffe. [uphfe] uffefl@diku.dk -- "This .signature hasn't been left unintentionally void of blankness" From quake-dev-owner@gamers.org Sat Apr 20 11:47 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 LAA13016 for ; Sat, 20 Apr 1996 11:47:19 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id FAA11662 for quake-dev-outgoing; Sat, 20 Apr 1996 05:46:28 -0400 Received: from uucp.polbox.com.pl (root@uucp.polbox.com.pl [194.92.236.3]) by gamers.org (thegate/gamers) with SMTP id FAA11658 for ; Sat, 20 Apr 1996 05:46:17 -0400 Received: from mpolis.polbox.com.pl (dialup-b8.polbox.com.pl [194.181.68.161]) by uucp.polbox.com.pl (8.6.12/8.6.6) with SMTP id KAA29829 for ; Sat, 20 Apr 1996 10:41:52 +0200 From: mpolis@polbox.com.pl Date: Sat, 20 Apr 1996 10:41:52 +0200 Message-Id: <199604200841.KAA29829@uucp.polbox.com.pl> X-Sender: mpolis@polbox.com.pl X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 To: quake-dev@gamers.org Subject: To seam or not to seam... Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Status: RO X-Lines: 39 Content-Type: text/plain; charset="us-ascii" Content-Length: 1449 Hi. Two of my friends and myself are learning 3D through making Quake .MDL viewer :). Of course we know a bit about 3D (all sorting algorithms, free-dir.text.mapping, env.mapping, Lamert/Gouraud/Phong, etc.), but yet we have a little trouble with .MDL files... 1. On-seam, off-seam. We get the idea. To make textures linked seamless. Okay. There is a boolean. Okay. So we know which vertexes are on-seam, and which are not. But how to use this information in practice? I guess it has something to do with the fact that back texture is put on width/2... 2. Hmmm... A bit strange that noone made his own .MDL file yet. Of course there are a lot of home-made .MDLs (even the one with player as Duke Nukem...), but noone did it from scratch. Some people made whole new levels, but noone did monsters... Any ideas where lies the most difficult part of making 3D sprites (so to speak :)? 3. Now something for fun: it is suspected, that monsters gfx data will contain much more info that now. But now I can't think of anything else we would want! We have textures (and we're not restricted to one per monster), we have 'removable', independent body parts, we have information about the light, we have animations (in which we can even morph our monsters)... What more can one do with it?! Any hints, especially for 1st questions, will be very appreciated. Thanks... Adrian Chmielarz Metropolis From quake-dev-owner@gamers.org Sun Apr 21 08: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 IAA22769 for ; Sun, 21 Apr 1996 08:16:58 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id CAA15814 for quake-dev-outgoing; Sun, 21 Apr 1996 02:15:44 -0400 Received: from mail.phoenix.net (mail.phoenix.net [199.3.232.20]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id EAA21210 for ; Sun, 21 Apr 1996 04:03:06 +0200 Received: from jim ([204.120.250.19]) by mail.phoenix.net (8.6.12/8.6.12) with SMTP id VAA26895 for ; Sat, 20 Apr 1996 21:02:13 -0500 Message-ID: <317996A9.751E@gcchem.com> Date: Sat, 20 Apr 1996 21:00:09 -0500 From: Jim Bucher X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: quake-editing@nvg.unit.no Subject: rendering question 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: 8 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 473 I currently have a program that will display a wire frame of the quake levels. Now I want to use the visibility list to do some culling. To do this I need to know which leaf the camera is in. I am currently just searching through the array of leaves and checking if the camera is in the bounding box for each leaf. However, I have found that the camera can be in several of the bounding boxes. In other words, how do I find which leaf is the actual leaf the camera is in? From quake-dev-owner@gamers.org Sun Apr 21 08: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 IAA22829 for ; Sun, 21 Apr 1996 08:22:57 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id CAA15844 for quake-dev-outgoing; Sun, 21 Apr 1996 02:22: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 CAA15840 for ; Sun, 21 Apr 1996 02:22:47 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id IAA22825 for quake-dev@gamers.org; Sun, 21 Apr 1996 08:22:47 +0200 (MET DST) Date: Sun, 21 Apr 1996 08:22:47 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199604210622.IAA22825@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org Subject: Re: rendering question 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: 569 X-Lines: 19 Status: RO > In other words, how > do I find which leaf is the actual leaf the camera is in? Use the BSP. Start at the root, do a dot product of camera position vector and plane normal, compare with distance to origin. This gives you wether you are in the left or right subtree/halfspace. Repeat with the appropriate child node, until you reach a leaf. Done. I keep wondering wether Quake does this for any moving object for each frame... does anybody have any insights on how actual "EntityInLeaf" information is maintained? b. From quake-dev-owner@gamers.org Sun Apr 21 15:29 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 PAA26046 for ; Sun, 21 Apr 1996 15:29:04 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id JAA16651 for quake-dev-outgoing; Sun, 21 Apr 1996 09:28:42 -0400 Received: from minerva.phyast.pitt.edu (minerva.phyast.pitt.edu [136.142.111.2]) by gamers.org (thegate/gamers) with SMTP id JAA16647 for ; Sun, 21 Apr 1996 09:28:41 -0400 Received: (brian@localhost) by minerva.phyast.pitt.edu (8.6.10/8.6.5) id JAA08780 for quake-dev@gamers.org; Sun, 21 Apr 1996 09:28:36 -0400 From: "Brian K. Martin" Message-Id: <199604211328.JAA08780@minerva.phyast.pitt.edu> Subject: Re: To seam or not to seam... To: quake-dev@gamers.org Date: Sun, 21 Apr 1996 09:28:35 -0400 (EDT) In-Reply-To: <199604200841.KAA29829@uucp.polbox.com.pl> from "mpolis@polbox.com.pl" at Apr 20, 96 10:41:52 am X-Mailer: ELM [version 2.4 PL24] 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 Status: RO X-Lines: 33 Content-Type: text/plain; charset="US-ASCII" Content-Length: 1205 > > 1. On-seam, off-seam. We get the idea. To make textures > linked seamless. Okay. There is a boolean. Okay. So > we know which vertexes are on-seam, and which are not. > But how to use this information in practice? I guess > it has something to do with the fact that back texture > is put on width/2... yes i thought this was in the quake specs... if a polygon is on the back, then add w/2 to the points that are on seem (texture coords that is). > 2. Hmmm... A bit strange that noone made his own .MDL file > yet. Of course there are a lot of home-made .MDLs (even > the one with player as Duke Nukem...), but noone did > it from scratch. Some people made whole new levels, but > noone did monsters... Any ideas where lies the most > difficult part of making 3D sprites (so to speak :)? I have orginal mdl files. The only difficult part (not really difficult but time consuming) is placing the texture on the object. I'm thinking of making a web page for model making. I'll post if i do. > we have 'removable', independent body parts, we have > information about the light, we have animations (in which > there is no light info in the model files. brian From quake-dev-owner@gamers.org Sun Apr 21 22:44 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 WAA29224 for ; Sun, 21 Apr 1996 22:44:44 +0200 (MET DST) Received: from gamers.org (majordomo@[128.205.37.150]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with ESMTP id WAA17061 for ; Sun, 21 Apr 1996 22:45:57 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id QAA18355 for quake-dev-outgoing; Sun, 21 Apr 1996 16:43:03 -0400 Received: from netcom.netcom.com (root@netcom.netcom.com [192.100.81.100]) by gamers.org (thegate/gamers) with SMTP id QAA18351 for ; Sun, 21 Apr 1996 16:43:01 -0400 Received: (from darkelf@localhost) by netcom.netcom.com (8.6.13/Netcom) id NAA26210; Sun, 21 Apr 1996 13:34:49 -0700 Date: Sun, 21 Apr 1996 13:34:48 -0700 (PDT) From: "Drizzt Do'Urden" Subject: Visibility lists To: quake-dev@gamers.org 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: 848 I've recently been messing with creating a homemade level from scratch, but have run into some trouble. My test level is a simple 128x128x256 room, with 2 leaves. The level runs okay, but I get some strange problems during play. It seems that only the first leaf renders properly. (i.e. draws all the walls, etc..) While in the second leaf, none of the walls are drawn unless the back wall of the first leaf in in your line of sight. I am guessing this has something to do with the visibility lists. I have written what seems to be a working lmp to txt and txt to lmp converter for the visibility lists (entry04.lmp using unbsp). Assuming that is working corectly, I have no idea where to go from here. Any information on how the visibility lists work would be greatly appreciated. (Yes, i've read the Quake Specs) Brent From quake-dev-owner@gamers.org Mon Apr 22 03:08 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 DAA01187 for ; Mon, 22 Apr 1996 03:08:17 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id VAA19132 for quake-dev-outgoing; Sun, 21 Apr 1996 21:07:54 -0400 Received: from lubricant.free.org (smap@lubricant.free.org [199.3.242.5]) by gamers.org (thegate/gamers) with ESMTP id VAA19128 for ; Sun, 21 Apr 1996 21:07:51 -0400 Received: (from smap@localhost) by lubricant.free.org (8.7.3/8.6.9) id UAA10007 for ; Sun, 21 Apr 1996 20:04:40 -0500 (CDT) Received: from ppp034.free.org(199.3.242.65) by lubricant.free.org via smap (V1.3) id sma010002; Sun Apr 21 20:04:17 1996 Received: by ppp034.free.org with Microsoft Mail id <01BB2FBE.054329C0@ppp034.free.org>; Sun, 21 Apr 1996 20:06:26 -0500 X-Authentication-Warning: lubricant.free.org: smap set sender to using -f Message-ID: <01BB2FBE.054329C0@ppp034.free.org> From: Stephen Crowley To: "'Quake Developers'" Subject: Map Info from Carmack Date: Sun, 21 Apr 1996 20:05:30 -0500 Encoding: 20 TEXT 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: 604 X-Lines: 21 Status: RO Here is the info I got when I asked him about implementing seperate hulls in .map files. *** E-Mail from John Carmack - 4/21/96 The seperate clipping hulls (there was one in qtest, but there are more now) are automatically generated in the bsp utilities by doing a beveled hull expansion on the brushes. You don't need to do anything in the map editor. You can add brushes that only show up in the clipping hulls (invisible blocking brushes) by giving them the texture name "clip". John Carmack **** If anyone knows what "beveled hull expansion" is then please feel free to share. Stephen From quake-dev-owner@gamers.org Mon Apr 22 04:49 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 EAA01926 for ; Mon, 22 Apr 1996 04:49:02 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id WAA19527 for quake-dev-outgoing; Sun, 21 Apr 1996 22:48:34 -0400 Received: from postbox.acs.ohio-state.edu (postbox.acs.ohio-state.edu [128.146.214.20]) by gamers.org (thegate/gamers) with SMTP id WAA19523 for ; Sun, 21 Apr 1996 22:48:32 -0400 Received: from carollo.acs.ohio-state.edu by postbox.acs.ohio-state.edu (8.6.9/5.901231) id WAA22220; Sun, 21 Apr 1996 22:48:31 -0400 Message-ID: <317A4ADC.75D9@osu.edu> Date: Sun, 21 Apr 1996 10:49:00 -0400 From: Chris Carollo Organization: The Ohio State University X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: quake-dev@gamers.org Subject: Re: Map Info from Carmack References: <01BB2FBE.054329C0@ppp034.free.org> 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: 22 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 805 > > *** E-Mail from John Carmack - 4/21/96 > > The seperate clipping hulls (there was one in qtest, but there are more > > now) are automatically generated in the bsp utilities by doing a beveled > > hull expansion on the brushes. You don't need to do anything in the map > > editor. What does he mean by "clipping hulls"? And there was only *one* of them in qtest? It doesn't sound like he just mean hulls separate from the main level hull... > > You can add brushes that only show up in the clipping hulls (invisible > > blocking brushes) by giving them the texture name "clip". So we can define invisible volumes? Or does he mean that we can define a brush that does a boolean subtract? > If anyone knows what "beveled hull expansion" is then please feel free to > share. Seconded. :) -Chris From quake-dev-owner@gamers.org Mon Apr 22 17:23 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 RAA17737 for ; Mon, 22 Apr 1996 17:23:45 +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 RAA00412 for ; Mon, 22 Apr 1996 17:25:00 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id LAA22389 for quake-dev-outgoing; Mon, 22 Apr 1996 11:21:59 -0400 Received: from xr3.atlas.fr (xr3.atlas.fr [194.51.9.5]) by gamers.org (thegate/gamers) with ESMTP id LAA22385 for ; Mon, 22 Apr 1996 11:21:51 -0400 Mon, 22 Apr 1996 17:19:49 +0200 Mon, 22 Apr 1996 17:19:49 +0200 Mon, 22 Apr 1996 17:03:22 +0200 X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Mon, 22 Apr 1996 17:19:49 +0200 X400-Received: by mta xr3.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Mon, 22 Apr 1996 17:19:49 +0200 X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Mon, 22 Apr 1996 17:19:27 +0200 X400-Received: by /PRMD=cnet/ADMD=atlas/C=fr/; Relayed; Mon, 22 Apr 1996 17:03:22 +0200 Date: Mon, 22 Apr 1996 17:03:22 +0200 X400-Originator: montanuy@lsun80.lannion.cnet.fr X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=cnet/ADMD=atlas/C=fr/;830185402@x400.lannion.cnet.fr] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: To seam or n Alternate-Recipient: Allowed From: Olivier Montanuy Message-ID: <9604221502.2D2EE0@lat1192.lannion.cnet.fr> To: quake-dev@gamers.org Subject: Re: To seam or not to seam... 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: 564 X-Lines: 17 Status: RO >yes i thought this was in the quake specs... This is in the spec, indded. But that doesn't mean it's understandable for everyone :-) (like 50% of the .BSP description). Can someone take a look and propose a simpler explanation? > The only difficult part is placing the texture on the object. And maybe generating the animation frames themselves... >there is no light info in the model files. I confirm. Once again, the wording of the specs (lightnormalindex) probably is just confusing. Someone has a better wording? Olivier (building spec 3.2) From quake-dev-owner@gamers.org Mon Apr 22 17: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 RAA22939 for ; Mon, 22 Apr 1996 17:56:38 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id LAA22504 for quake-dev-outgoing; Mon, 22 Apr 1996 11:55:15 -0400 Received: from xr3.atlas.fr (xr3.atlas.fr [194.51.9.5]) by gamers.org (thegate/gamers) with ESMTP id LAA22500 for ; Mon, 22 Apr 1996 11:55:12 -0400 Mon, 22 Apr 1996 17:54:42 +0200 Mon, 22 Apr 1996 17:54:42 +0200 Mon, 22 Apr 1996 17:50:54 +0200 X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Mon, 22 Apr 1996 17:54:42 +0200 X400-Received: by mta xr3.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Mon, 22 Apr 1996 17:54:42 +0200 X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Mon, 22 Apr 1996 17:54:34 +0200 X400-Received: by /PRMD=cnet/ADMD=atlas/C=fr/; Relayed; Mon, 22 Apr 1996 17:50:54 +0200 Date: Mon, 22 Apr 1996 17:50:54 +0200 X400-Originator: montanuy@lsun80.lannion.cnet.fr X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=cnet/ADMD=atlas/C=fr/;830188254@x400.lannion.cnet.fr] X400-Content-Type: P2-1984 (2) Content-Identifier: RE: Map Files Alternate-Recipient: Allowed From: Olivier Montanuy Message-ID: <9604221550.0D29F0@lat1192.lannion.cnet.fr> To: quake-dev@gamers.org Subject: RE: Map Files 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: 615 X-Lines: 15 Status: RO >What I need to know is how would you take a list of planes and turn that >into a list of vertices and lines (a convex polyhedron)? sounds like the kind of stuff that happens in the simplex's algorithm (a classic stuff used in optimisation). No idea how id does this, but the result isn't perfect (many duplicated segment references). I assume most vertex will appear naturally when doing the BSP splitting. >// The sign of R is chosen opposite to the sign of D when D!=0, the same I wonder why the heck you would want to change the sign of r. It's positive. Else your normal vector will be inverted. From quake-dev-owner@gamers.org Mon Apr 22 18: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 SAA28308 for ; Mon, 22 Apr 1996 18:16:13 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id MAA22621 for quake-dev-outgoing; Mon, 22 Apr 1996 12:15:15 -0400 Received: from marvin.nero.uni-bonn.de (marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id MAA22617 for ; Mon, 22 Apr 1996 12:15:09 -0400 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id SAA28081 for ; Mon, 22 Apr 1996 18:14:32 +0200 (MET DST) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.4/8.7.1) id SAA06067 for quake-dev@gamers.org; Mon, 22 Apr 1996 18:14:25 +0200 (MET DST) From: Bernd Kreimeier Date: Mon, 22 Apr 1996 18:14:25 +0200 (MET DST) Message-Id: <199604221614.SAA06067@colossus.nero.uni-bonn.de> To: quake-dev@gamers.org Subject: RE: Map Files 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: 2957 X-Lines: 72 Status: RO >>What I need to know is how would you take a list of planes and turn that >>into a list of vertices and lines (a convex polyhedron)? > sounds like the kind of stuff that happens in the simplex's algorithm > (a classic stuff used in optimisation). I do not think so, frankly. > No idea how id does this, but the result isn't perfect (many duplicated > segment references). I assume most vertex will appear naturally when doing > the BSP splitting. Again: beg to differ. It seems that our current understanding of the MAP format is incomplete. In my opinion, there are the following processing steps that have to be done *within QuakeEd*: define/modify planes of a single brush calculate a boundary representation of the brush. based on plane-plane-intersections add brush to the map as already done Note that the boundary representation is necesary, as human beings are not likely to think in infinite planes. We need the building blocks to be convex polyhedra, solid bricks of material. See QuakeEd screenshots, the top-down view. Note that all planes of one brush do intersect, but that planes of different brushes do not intersect. Brush-brush intersection is calculated using CSG with the polygons, not the planes. I refer to the "recommended readings" page, the book by Martti Mantyla (and his Geometric Workbench source), and the Ian Ashdown code in the HELIOS radiosity package - both use half-edge representations, IIRC, that allow for boolean operations with boundary representations: solid modeling, that is. There is a reprint of the CSG book by Mantyla scheduled for May, it is currently out of print. The "qbsp", as much as my two cents are worth, calculates brush-brush intersection - the QuakeEd screenshot does not demonstrate the 3D camera view. A z-buffer for slow preview will work nicely with intersecting polyhedras, so there it might be better to keep that calculations out of the editor. To understand the MAP files, we should ask ourselves: What does a MAP with only one brush looks like, i.e. one solid that is surrounded by nothing. What does a MAP look like with only non-intersecting and non-touching brushes? What does "sealing the world" mean (mentioned by Abrash and Carmack), but removal of all outside surfaces that cannot be seen from the interior? Will there be anything left in the two MAPs described above, once "qbsp" is done? Note that John Carmack mentions "convex polyhedra operations" in both "qbsp" and QuakeEd. Again, anybody who is working on a MAP editor should be aware of the processing of planes and brushes necessary for any previewing during editing. Vertices and edges are only implicit in the MAP files, but they have to be made explicit to the user. b. From quake-dev-owner@gamers.org Mon Apr 22 20:02 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 UAA01827 for ; Mon, 22 Apr 1996 20:02:45 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id OAA23035 for quake-dev-outgoing; Mon, 22 Apr 1996 14:00:39 -0400 Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by gamers.org (thegate/gamers) with SMTP id OAA23031 for ; Mon, 22 Apr 1996 14:00:37 -0400 Received: from sunset.cs.utah.edu by cs.utah.edu (8.6.12/utah-2.21-cs) id MAA05787; Mon, 22 Apr 1996 12:00:30 -0600 Received: from peruvian.cs.utah.edu by sunset.cs.utah.edu (8.6.12/utah-2.15sun-leaf) id MAA06279; Mon, 22 Apr 1996 12:01:07 -0600 Received: from localhost by peruvian.cs.utah.edu (8.6.10/utah-2.15-leaf) id MAA23663; Mon, 22 Apr 1996 12:00:29 -0600 Message-Id: <199604221800.MAA23663@peruvian.cs.utah.edu> From: larsen@sunset.cs.utah.edu (Steve Larsen) To: quake-dev@gamers.org Subject: Re: Visibility lists In-reply-to: Your message of "Sun, 21 Apr 96 13:34:48 PDT." Date: Mon, 22 Apr 96 12:00:17 MDT 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: 864 X-Lines: 18 Status: RO > I've recently been messing with creating a homemade level from scratch, >but have run into some trouble. My test level is a simple 128x128x256 >room, with 2 leaves. The level runs okay, but I get some strange problems >during play. It seems that only the first leaf renders properly. (i.e. >draws all the walls, etc..) While in the second leaf, none of the walls >are drawn unless the back wall of the first leaf in in your line of sight. Is this room non-convex, or is there some other reason you have two leaves for one room? One thing you might check tho. I had a similar problem if I used the same plane for more than one surface. I am not sure why. I thought any surfaces that were co-planar would use the same plane for caching efficiency. This might still be the case, but I had a lot of problems whenever I tried it. Steve From quake-dev-owner@gamers.org Mon Apr 22 20:21 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 UAA05314 for ; Mon, 22 Apr 1996 20:21:39 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id OAA23159 for quake-dev-outgoing; Mon, 22 Apr 1996 14:20:13 -0400 Received: from relay-2.mail.demon.net (disperse.demon.co.uk [158.152.1.77]) by gamers.org (thegate/gamers) with SMTP id OAA23154 for ; Mon, 22 Apr 1996 14:20:05 -0400 Received: from post.demon.co.uk ([158.152.1.72]) by relay-2.mail.demon.net id ae19587; 22 Apr 96 18:51 +0100 Received: from tsys.demon.co.uk ([158.152.159.87]) by relay-3.mail.demon.net id aa27458; 22 Apr 96 18:51 +0100 Date: Mon, 22 Apr 96 00:36:59 GMT Message-ID: <13285@tsys.demon.co.uk> From: Tom Wheeley Organization: City Zen FM To: quake-dev@gamers.org Subject: Quake map distribution: speed vs. legality X-Mailer: Demon Internet Simple News v1.30 Lines: 30 X-Sig-By: Tomsystems Quote v1.2. (c)1996 Tom Wheeley, tomw@tsys.demon.co.uk 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: 1440 X-Lines: 32 Status: RO In article you write: > * A distributable .bsp-file contains none of ids textures, but > "_texture" entries that tell a preprocessing utility how to > build the right .bsp-file from the distributable .bsp-file. > > All the surfaces that should have had one of ids textures, are assigned > a dummy texture in the distributable .bsp-file. This assignment is > changed by a preprocessing utility according to the > "_texture" entries. > > The preprocessing utility should also be able to reverse this process, > so you don't have to keep the distributable file as well as the > playable one. I wrote a similar utility to this ages ago, but you can only use id's textures :-) Maybe texture names in the texture list beginning with `_' would be picked up by the pre-pro as `filenames' (perhaps in a PAK file?) of mip textures, whereas standard names would be taken to be standard id tex. Remember that the mip header only gives 16 chars for the name (IIRC). People could be encouraged to keep a local .PAK file (or similar) of all their custom textures -- an interface for this would have to be rigidly adhered to, but may prove too difficult to manage. :( The BSP file as it stands is a very limited structure, expansion wise. .splitbung -- * TQ 1.0 * The 'Just So Quotes'. C++ -- The language in which only friends can access your private members. From quake-dev-owner@gamers.org Mon Apr 22 20:36 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 UAA05537 for ; Mon, 22 Apr 1996 20:36:44 +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 UAA00810 for ; Mon, 22 Apr 1996 20:38:01 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id OAA23305 for quake-dev-outgoing; Mon, 22 Apr 1996 14:36:09 -0400 Received: from uucp.polbox.com.pl (root@uucp.polbox.com.pl [194.92.236.3]) by gamers.org (thegate/gamers) with SMTP id OAA23299 for ; Mon, 22 Apr 1996 14:36:03 -0400 Received: from mpolis.polbox.com.pl (dialup219.polbox.com.pl [194.181.68.219]) by uucp.polbox.com.pl (8.6.12/8.6.11) with SMTP id UAA17070 for ; Mon, 22 Apr 1996 20:35:55 +0200 From: mpolis@polbox.com.pl Date: Mon, 22 Apr 1996 20:35:55 +0200 Message-Id: <199604221835.UAA17070@ uucp.polbox.com.pl> X-Sender: mpolis@polbox.com.pl X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 To: quake-dev@gamers.org Subject: Re: To seam or not to seam... Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 59 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 2224 >>yes i thought this was in the quake specs... > This is in the spec, indded. But that doesn't mean it's understandable for > everyone :-) (like 50% of the .BSP description). > Can someone take a look and propose a simpler explanation? Well, as usually in such situations we figured it out ourselves :) Here is a part of the source of our viewer: if(texture[face->v1].onseam && !face->facefront) { tp[0].x = texture[face->v1].tx + txcor; tp[0].y = texture[face->v1].ty; } else { tp[0].x = texture[face->v1].tx; tp[0].y = texture[face->v1].ty; } -------------------------------------------------------------------- >> The only difficult part is placing the texture on the object. > And maybe generating the animation frames themselves... Second thought is obvious, and first one is right. Working on 2D picture to wrap it around 3D object in the way Quake does it is very difficult... -------------------------------------------------------------------- >>there is no light info in the model files. > I confirm. Once again, the wording of the specs (lightnormalindex) > probably is just confusing. Someone has a better wording? Hmmm... We are thinking if id isn't just going to fake lightining on monsters. Using this normal we could make them Gouraud shaded, but with so many restrictions, that we can for a sure forget dynamic/various lights on the monsters... Guess we will have to wait till another test release :)... Well, it's just 3 weeks till E3. -------------------------------------------------------------------- I new thing started to bug me. Michael Abrash said (on CGDC) that they use z-buffer for monsters. In no way I can believe it. We used quick-sort and there is almost no polygons glitching when displaying monsters. They are very cleverly modelled, probably not from scratch (we suspect they were build from thousands of polygons then some kind of polygon-reduction process was run; all SGI programs have such things and - otherwise than in 3D-Studio - they work fine). So why taking so much memory and processing power for z-buffer, when quick-sort or radix will be much better and have quality enough?... Adrian Chmielarz Metropolis From quake-dev-owner@gamers.org Mon Apr 22 21:08 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 VAA05779 for ; Mon, 22 Apr 1996 21:08:44 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id PAA23523 for quake-dev-outgoing; Mon, 22 Apr 1996 15:08:18 -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 PAA23519 for ; Mon, 22 Apr 1996 15:08:13 -0400 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id VAA05773 for ; Mon, 22 Apr 1996 21:08:09 +0200 (MET DST) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.4/8.7.1) id VAA06180 for quake-dev@gamers.org; Mon, 22 Apr 1996 21:08:07 +0200 (MET DST) From: Bernd Kreimeier Date: Mon, 22 Apr 1996 21:08:07 +0200 (MET DST) Message-Id: <199604221908.VAA06180@colossus.nero.uni-bonn.de> To: quake-dev@gamers.org Subject: Re: To seam or not to seam... 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: 2648 X-Lines: 60 Status: RO >> I confirm. Once again, the wording of the specs (lightnormalindex) >> probably is just confusing. Someone has a better wording? Index refering to a predefined vertex normal sounds about right. I second that. Btw., the UQS should clearly state what is found in the MDL, and what is found in the EXE. >I new thing started to bug me. Michael Abrash said (on CGDC) that > they use z-buffer for monsters. You will have in the order of 10e1 polygons within view from the static environment. There are some 10e2 triangles in an MDL object. Each single object is more complex than an entire DOOM level. A wall polygon occupies up to 10e3 average (up to full view). Any triangle is likely to occupy a dozen pixels. Quoting from the CGDC transparencies: "Polygon models are meshes of 100-400 polygons, with a single front/back skin stretched over them. We couldn't clip them to the world BSP, because it would be too expensive, so we just drew each triangle in the nearest leaf it had a vertex in, which caused occasional errors. Errors sorting polygons within models. Errors sorting between models in same leaf (and also with other BSP models and sprites)." Conclusion: trying several alternatives, they settled for a z-buffer. Thus the rendering should look like this: They use the BSP front-to-back order for all environment polygons. Abrash says that, using an edge-sorted rasterizer, overdraw is zero. Thus a simple z-fill (write-only during BSP traversal) is not too expensive. Note that you calculate z for perspective correct texture mapping anyway for each pixel. I read a claim of 15% costs over the drawing. In a second pass, all possibly visible objects are rendered using the z-buffer (read-than-write), which is supposed to be less costly than sorting. I do not know wether BSP objects are treated the same like the MDL. I guess billboards (sprites) should better be. Actually, it surprised me a lot the first time I heard about it. Talk about preconceptions. The more you think about it, the more advantages you see. The z-buffered stuff could be anything: separate polygons, intersecting, even a depth map could be used. Triangles could intersect the walls (remember the lava/water). It will be interesting to see how this benefits from upcoming hardware z-buffering, too. In any case, I believe that Mike Abrash is right: it is the mixture of sophisticated spatial subdivision (BSP) and simple, straight processing of the visible triangles that works best. b. From quake-dev-owner@gamers.org Mon Apr 22 21: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 VAA06132 for ; Mon, 22 Apr 1996 21:53:07 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id PAA23914 for quake-dev-outgoing; Mon, 22 Apr 1996 15:52:27 -0400 Received: from mail.phoenix.net (mail.phoenix.net [199.3.232.20]) by gamers.org (thegate/gamers) with SMTP id PAA23910 for ; Mon, 22 Apr 1996 15:52:25 -0400 Received: from jim ([204.120.250.19]) by mail.phoenix.net (8.6.12/8.6.12) with SMTP id OAA26582 for ; Mon, 22 Apr 1996 14:52:03 -0500 Message-ID: <317BE2C9.32D1@gcchem.com> Date: Mon, 22 Apr 1996 14:49:29 -0500 From: Jim Bucher X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: quake-dev@gamers.org Subject: Re: To seam or not to seam... References: <199604221649.MAA12654@minerva.phyast.pitt.edu> 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: 8 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 243 > Can someone take a look and propose a simpler explanation if (!poly.onFront) for (i = 0; i < poly.numVerts; i++) if (poly.vert[i].onSeem) poly.vert[i].u += poly.textureWidth / 2; > I stand by vertex normals. anyone? I agree. From quake-dev-owner@gamers.org Mon Apr 22 22:15 MET 1996 From: Randy Linden To: "'quake-dev@gamers.org'" Subject: RE: To seam or not to seam... Date: Mon, 22 Apr 1996 12:42:31 -0700 MIME-Version: 1.0 Sender: owner-quake-dev@gamers.org Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Length: 711 X-Lines: 17 Status: RO > I new thing started to bug me. Michael Abrash said (on CGDC) that >they use z-buffer for monsters. In no way I can believe it. Believe it, it's true -- they use a Z-Buffer for the Alias Models. There are a *multitude* of sorting problems that cannot be solved with Z-based sorting. In *very* simple cases, you could take the "average" Z of a given polygon and sort based on that, however with the models that they have, many polygons interesect and overlap many other polygons (both within the same model, and otherwise). BTW, If you're not having these problems with your displayer, try looking at a different model...Many of them will exhibit the sorting errors. Rand. ShockWave Studios, Inc. From quake-dev-owner@gamers.org Mon Apr 22 22:39 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 WAA06491 for ; Mon, 22 Apr 1996 22:39:34 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id QAA24381 for quake-dev-outgoing; Mon, 22 Apr 1996 16:39:11 -0400 Received: from minerva.phyast.pitt.edu (minerva.phyast.pitt.edu [136.142.111.2]) by gamers.org (thegate/gamers) with SMTP id QAA24377 for ; Mon, 22 Apr 1996 16:39:08 -0400 Received: (brian@localhost) by minerva.phyast.pitt.edu (8.6.10/8.6.5) id QAA14180 for quake-dev@gamers.org; Mon, 22 Apr 1996 16:37:33 -0400 From: "Brian K. Martin" Message-Id: <199604222037.QAA14180@minerva.phyast.pitt.edu> Subject: Re: To seam or not to seam... To: quake-dev@gamers.org Date: Mon, 22 Apr 1996 16:37:32 -0400 (EDT) In-Reply-To: <199604221835.UAA17070@ uucp.polbox.com.pl> from "mpolis@polbox.com.pl" at Apr 22, 96 08:35:55 pm X-Mailer: ELM [version 2.4 PL24] 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: 42 Status: RO Content-Type: text/plain; charset="US-ASCII" Content-Length: 1863 > > > >>there is no light info in the model files. > > Hmmm... We are thinking if id isn't just going to fake lightining > on monsters. Using this normal we could make them Gouraud shaded, > but with so many restrictions, that we can for a sure forget > dynamic/various lights on the monsters... Guess we will have to > wait till another test release :)... Well, it's just 3 weeks till > E3. > ?? id Doesn't fake light. I am sure. these are the vertex normals and they are used for gouraud shading. The lighting on the monsters is indeed dynamic. That's why it says that in the quake specs. Believe me, I tested it and even implemented it in the newest version of meddle. (see that appendix in the specs for the normal table) I doubt id will change much about the MDL files (execpt maybe that bug of having invalid vertex normals in the MDL file). > -------------------------------------------------------------------- > > I new thing started to bug me. Michael Abrash said (on CGDC) that > they use z-buffer for monsters. In no way I can believe it. We used Carmack had told me that they do use a z-buffer. Look how nice the clipping is on the models when they stick in a wall. Also try to load up you memory with tons of things and then run quake in a hi res mode. You can get an error saying there isn't enough memory for the z-buffer. well that doesn't mean diddly crap but it is some evidence. Also notice that in some angles where you get an error in sorting, you don't see that in quake. (but you may have a better sorting algo than me..) He also said the reason for the z buffer was that in most cases the monsters are only a few pixels in size so the z-buffer wasn't used heavily, so it's not too time consuming. But I have to agree with you that it is hard to believe because I can never fill the z-buffer that fast. brian brian From quake-dev-owner@gamers.org Tue Apr 23 00:52 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 AAA07614 for ; Tue, 23 Apr 1996 00:52:05 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id SAA25188 for quake-dev-outgoing; Mon, 22 Apr 1996 18:51:27 -0400 Received: from postbox.acs.ohio-state.edu (postbox.acs.ohio-state.edu [128.146.214.20]) by gamers.org (thegate/gamers) with SMTP id SAA25184 for ; Mon, 22 Apr 1996 18:51:25 -0400 Received: from carollo.acs.ohio-state.edu by postbox.acs.ohio-state.edu (8.6.9/5.901231) id SAA06992; Mon, 22 Apr 1996 18:51:23 -0400 Message-ID: <317B64CB.3CEF@osu.edu> Date: Mon, 22 Apr 1996 06:51:55 -0400 From: Chris Carollo Organization: The Ohio State University X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: quake-dev@gamers.org Subject: Re: Map Files References: <199604221614.SAA06067@colossus.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: 49 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 2217 Bernd Kreimeier wrote: > In my opinion, there are the following processing steps that have to > be done *within QuakeEd*: > > define/modify planes of a single brush > calculate a boundary representation of the brush. > based on plane-plane-intersections > add brush to the map as already done > > Note that the boundary representation is necesary, as human beings are > not likely to think in infinite planes. We need the building blocks to > be convex polyhedra, solid bricks of material. See QuakeEd screenshots, > the top-down view. I concur. IMO, the following steps are necessary: 1. Load MAP file and convert brushes from list-of-planes to vertex-edge representation. 2. Allow users to move vertices, add/move brushes, and move/add edges. Possible checks here that the sides of the brush remain coplanar. Or, the editor could restrict the user to only moving vertices in such a way as to preserve coplanarity...but this seems like it would be overly complex and not really needed. Comments? 3. Convert brushes from vertex-edge list-of-planes representation. If coplanarity wasn't checked before, definitely do it here. As I see it, the only operation that is really compl