From owner-quake-editing@nvg.unit.no Wed Mar 6 17:40 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 RAA02164 for ; Wed, 6 Mar 1996 17:40:16 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id RAA09220 for quake-editing-digest-outgoing; Wed, 6 Mar 1996 17:39:27 +0100 Date: Wed, 6 Mar 1996 17:39:27 +0100 Message-Id: <199603061639.RAA09220@sabre-wulf.nvg.unit.no> From: owner-quake-editing-digest@nvg.unit.no To: quake-editing-digest@nvg.unit.no Subject: quake-editing-digest V1 #453 Reply-To: quake-editing@nvg.unit.no Errors-To: owner-quake-editing-digest@nvg.unit.no Precedence: bulk Content-Type: text Content-Length: 7272 X-Lines: 251 Status: RO quake-editing-digest Wednesday, 6 March 1996 Volume 01 : Number 453 Re: Quake data structures Re: Quake data structures Re: Textures. Quake BSP info from Carmack ---------------------------------------------------------------------- From: "Brian K. Martin" Date: Wed, 6 Mar 1996 02:09:55 -0500 (EST) Subject: Re: Quake data structures I forgot if I sent these to you. Some things are wrong. The 4'th byte in the vframe.v is the index to the precalculated vertex normals. So you can convert from mdl to whatever, but not back yet because I didn't figure out the normal data structure. Later. MDL file format (this is what I know so far) These are the structs I use to read in file info: struct vframe{ unsigned char head[12]; unsigned char *v; }; struct MDL_FILE{ char filetype[4]; int version; float xscale,yscale,zscale; float xoffset,yoffset,zoffset; float radius; float f1,f2,f3; unsigned num_items; unsigned bitmapw; unsigned bitmaph; unsigned num_vertices; unsigned num_triangles; unsigned num_frames; unsigned blank; unsigned char *bitmap; unsigned int *vertex; unsigned int *triangle; struct vframe *frame; }; void read_mdl(FILE *in) { int i,j,k; fread(&mdl.filetype,4,1,in); fread(&mdl.version,4,1,in); fread(&mdl.xscale,4,1,in); fread(&mdl.yscale,4,1,in); fread(&mdl.zscale,4,1,in); fread(&mdl.xoffset,4,1,in); fread(&mdl.yoffset,4,1,in); fread(&mdl.zoffset,4,1,in); fread(&mdl.radius,4,1,in); fread(&mdl.f1,4,1,in); fread(&mdl.f2,4,1,in); fread(&mdl.f3,4,1,in); fread(&mdl.num_items,4,1,in); fread(&mdl.bitmapw,4,1,in); fread(&mdl.bitmaph,4,1,in); fread(&mdl.num_vertices,4,1,in); fread(&mdl.num_triangles,4,1,in); fread(&mdl.num_frames,1,4,in); fread(&mdl.blank,1,4,in); mdl.bitmap = new (unsigned char)[mdl.bitmapw*mdl.bitmaph*mdl.num_items]; for(k=0;k > It would be quite interesting to know, what we will need for Quake > > at the end - id 'said' that they will release their map-editor, for > > Win95 and Linux - so, there's actually no need for others. Are they > > going to release File-Tools and stuff too? > > I would be interested to know if they are planning to release the source > for their editor too: I think they also 'said' that they would release i seem to recall dave taylor or someone else from id saying they wouldn't release their editor after all since they didn't want to get tech support mails for it. they might change their opinion again, but things don't seem to be as certain as they were (or were they ever? ;) ------------------------------ From: Antony Suter Date: Thu, 07 Mar 1996 00:01:44 +1000 Subject: Re: Textures. At 12:06 PM 5/3/1996 +1000, you wrote: >I have noticed that the textures seem to have 3 states, depending on how >far you are from the texture. At a certain distance the texture is >anti-aliased, which reduces graphical artifacts resulting from spotty >textures seen from a distance. > >Does anyone know if the engine itself does the anti-aliasing, or if there >are actually three versions of each texture in the pak? I would say that you are looking at the MIP maps. Are they like this:- First full size, next is a quarter the area, last is 1/16th the area? - -- - - Antony Suter (Rohan, of Middle Earth) - - "Pick a signature, any signature. As long as it's this one". ------------------------------ From: Antony Suter Date: Thu, 07 Mar 1996 00:01:45 +1000 Subject: Quake BSP info from Carmack The all algorithmical Carmack has been kind enough to grace me with some correspondance. The points are below. note: as Magnus and Raphael have pointed out, expect the Quake file formats to change! - - not going to release BSP code till game is final. - - changes are still happening. - - will need optimization to run well on most machines:- - - they run it on a 4 CPU alpha box with 128 MB RAM. (my other car is a Mercedes!) - - The full map processing is actually three seperate programs: qbsp: which builds minimized drawing and clipping hulls from a solid geometry description of the world. This is the memory pig that can chew up 50+ resident megs on big levels. Single threaded, but most levels only take a minute or so to run. light: builds the surface lighting maps. Fully parallelel, generally taking a few minutes to make a high quality run, or less for a non-filtered version. vis: builds the potentially visible set. Fully parallel. This is the CPU pig. It is wildly content dependant (combinatorially sensitve), so some levels may only take a minute or so, but there is one level we have that takes nearly an hour even on 4 cpus. During development, subsets of the suite are run, and only for full testing is the vis program run. And to go with your lemon scented paper napkins, he said:- "I suspect a lot of university computers are going to find new tasks at night :-)" - -- - - Antony Suter (Rohan, of Middle Earth) - - "Pick a signature, any signature. As long as it's this one". ------------------------------ End of quake-editing-digest V1 #453 *********************************** From owner-quake-editing@nvg.unit.no Wed Mar 6 17:48 MET 1996 Received: from sabre-wulf.nvg.unit.no (bin@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id RAA02229 for ; Wed, 6 Mar 1996 17:48:27 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id RAA09514 for quake-editing-digest-outgoing; Wed, 6 Mar 1996 17:48:15 +0100 Date: Wed, 6 Mar 1996 17:48:15 +0100 Message-Id: <199603061648.RAA09514@sabre-wulf.nvg.unit.no> From: owner-quake-editing-digest@nvg.unit.no To: quake-editing-digest@nvg.unit.no Subject: quake-editing-digest V1 #1 Reply-To: quake-editing@nvg.unit.no Errors-To: owner-quake-editing-digest@nvg.unit.no Precedence: bulk Content-Type: text Content-Length: 4430 X-Lines: 109 Status: RO quake-editing-digest Wednesday, 6 March 1996 Volume 01 : Number 001 Re: reference library design/mdl file formats Re: release of id tools/was: Quake data structures ---------------------------------------------------------------------- From: Bernd Kreimeier Date: Wed, 6 Mar 1996 13:55:32 +0100 (MET) Subject: Re: reference library design/mdl file formats >> warning on still changing file formats > This is the reason why I write QEU as a library of generic routines > for loading and saving files. If anyone uses this library for a > program, it will be easy to upgrade to any new format, because only a > few things will have to be changed in the library and most of the There are two important aspects to remember in designing a portable reference library for QUE and other tools: a) keep in mind the interactive editing specific needs for Constructive Solid Geometry-compliant data structures. This too will be worth the additional work in the end. I recommend looking at the references given on the "recommended readings" page (see below): the books by Martti Mantyla and Ian Ashdown, in particular, featuring half edge representations. b) keep in mind the specific needs involved with near-realtime rendering. We might or might not succeed in writing some (even non-texturing) 3D preview this time, but you definitely won't be able to integrate any such beast with a modeller/editor as long as your data structures are focused on being dynamically only (adding/removing vertices etc.), without taking efficiency into account. Two additional remarks: for radiosity-style calculation of lighting/shadow maps, I definitely recommend taking a close look at the HELIOS sources that are now publically available, written by Ian Ashdown. As for slow but doable 3D preview, I recommend looking at the Mesa library. Both referenced on the "overview of resources" page, which, like "recommended readings", is cross-referenced now at http://www.nero.uni-bonn.de/~dn/q-sup/ the Quake Developers Support pages. b. ------------------------------ From: Bernd Kreimeier Date: Wed, 6 Mar 1996 13:39:17 +0100 (MET) Subject: Re: release of id tools/was: Quake data structures > On Mon, 4 Mar 1996, Tom Lees wrote: > > > > id 'said' that they will release their map-editor, for > > I would be interested to know if they are planning to release the source > > for their editor too: I think they also 'said' that they would release > From: jschuur@flash.globalnews.com > > i seem to recall dave taylor or someone else from id saying they > wouldn't release their editor after all since they didn't want to get > tech support mails for it. they might change their opinion again, but > things don't seem to be as certain as they were (or were they ever? ;) That about sums it up :-). Let me try to end this discussion: id will do as they choose. They might or might not promise, write, release "Official Specs", they might or might not release editor sources, they might put them under one License or another, might even sell them to other companies, might put them under NDA. If you want to know for sure, ask id or wait. Period. I remember very well the same questions on "Official DOOM Specs". There is no reliable flow of information, and no consistent support, and we cannot not depend on either. Just as id cannot depend on us. If you are going to write an editor or utility, that is *your* choice. You are not working for id. Do not expect any favors, nor offer them. Do what you want to do, for your own reasons. Protect your property or don't, and let id protect theirs. Take your own risks, waste your own time. You could either do business or have fun, but not both. You want a deal? Sign a contract. This discussion is idle speculation, and will *not* make a difference. b. - ------------------------------------------------------------------------- "Being paranoid does not mean They aren't out to get you." - ------------------------------------------------------------------------- ------------------------------ End of quake-editing-digest V1 #1 ********************************* From owner-quake-editing@nvg.unit.no Thu Mar 7 02:29 MET 1996 Received: from sabre-wulf.nvg.unit.no (bin@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id CAA04003 for ; Thu, 7 Mar 1996 02:29:08 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id CAA05682 for quake-editing-digest-outgoing; Thu, 7 Mar 1996 02:22:42 +0100 Date: Thu, 7 Mar 1996 02:22:42 +0100 Message-Id: <199603070122.CAA05682@sabre-wulf.nvg.unit.no> From: owner-quake-editing-digest@nvg.unit.no To: quake-editing-digest@nvg.unit.no Subject: quake-editing-digest V1 #2 Reply-To: quake-editing@nvg.unit.no Errors-To: owner-quake-editing-digest@nvg.unit.no Precedence: bulk Content-Type: text Content-Length: 2631 X-Lines: 72 Status: RO quake-editing-digest Thursday, 7 March 1996 Volume 01 : Number 002 Quake data structures Re: reference library design/mdl file formats ---------------------------------------------------------------------- From: Tom Wheeley Date: Wed, 06 Mar 96 01:02:37 GMT Subject: Quake data structures In article you write: > On Mon, 4 Mar 1996, Denis wrote: > > > It would be quite interesting to know, what we will need for Quake > > at the end - id 'said' that they will release their map-editor, for > > Win95 and Linux - so, there's actually no need for others. Are they > > going to release File-Tools and stuff too? > > I would be interested to know if they are planning to release the source > for their editor too: I think they also 'said' that they would release > the source code for the quake server, but with the current implementation > of it (part of quake itself), this does not look possible unless the > quake server is re-written to be external to quake itself (as well as > internal). Are id still thinking of releasing Quake as .o files as mentioned by in comp..djgpp in quaketalk? I think the idea was that you would thyen get 'server.c' (gross simplification, I'm sure) and manufacturers could then easily write their own 'device drivers', and then release them to be linked in when Quake is played. Even if id do release an editor, it will be a while before they do, and it may even be limited (even if not intentially). - -- * TQ 1.0 * The 'Just So Quotes'. "They're filming Rocky V now. This one's being billed as `Rocky's Greatest Challenge', so I guess there's an IQ test involved." -- Jay Leno ------------------------------ From: "Brian K. Martin" Date: Wed, 6 Mar 1996 13:08:07 -0500 (EST) Subject: Re: reference library design/mdl file formats > > > Two additional remarks: for radiosity-style calculation of lighting/shadow > maps, I definitely recommend taking a close look at the HELIOS sources that > are now publically available, written by Ian Ashdown. As for slow but > doable 3D preview, I recommend looking at the Mesa library. Both referenced > on the "overview of resources" page, which, like "recommended readings", is > cross-referenced now at > If anyone want's to learn 3d texture mapping techinques, I strongly recommend 3DGPL.ZIP at x2ftp.oulu.fi You will learn enough there to make a portable and solid 3d rendering engine. brian ------------------------------ End of quake-editing-digest V1 #2 ********************************* From owner-quake-editing@nvg.unit.no Sat Mar 9 02:31 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 CAA15241 for ; Sat, 9 Mar 1996 02:31:38 +0100 (MET) Received: from sabre-wulf.nvg.unit.no (bin@sabre-wulf.nvg.unit.no [129.241.161.9]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with SMTP id CAA22730; Sat, 9 Mar 1996 02:32:29 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id CAA05192 for quake-editing-digest-outgoing; Sat, 9 Mar 1996 02:24:46 +0100 Date: Sat, 9 Mar 1996 02:24:46 +0100 Message-Id: <199603090124.CAA05192@sabre-wulf.nvg.unit.no> From: owner-quake-editing-digest@nvg.unit.no To: quake-editing-digest@nvg.unit.no Subject: quake-editing-digest V1 #3 Reply-To: quake-editing@nvg.unit.no Errors-To: owner-quake-editing-digest@nvg.unit.no Precedence: bulk Content-Type: text Content-Length: 13049 X-Lines: 365 Status: RO quake-editing-digest Saturday, 9 March 1996 Volume 01 : Number 003 ADMIN: digest operational Re: reference library design/mdl file formats Question Re: Question Unofficial Quake Specs 3.0 released! Re: Question Re: Question Re: Question Quake Palette ---------------------------------------------------------------------- From: Bernd Kreimeier Date: Thu, 7 Mar 1996 11:00:39 +0100 (MET) Subject: ADMIN: digest operational It looks like the digest has been fixed, and even the volumes do have the right number now :-). Please feel free to change your subscription if you prefer the digest mode. Those who have missed earlier postings might want to look at the Hypermail archive at http://www.nero.uni-bonn,de/~dn/q-sup/, the page that hosts the Quake Developers support pages. My apologies for any inconvenience. b. ------------------------------ From: Bernd Kreimeier Date: Thu, 7 Mar 1996 14:38:47 +0100 (MET) Subject: Re: reference library design/mdl file formats >From: "Brian K. Martin" >If anyone want's to learn 3d texture mapping techinques, I strongly >recommend 3DGPL.ZIP at x2ftp.oulu.fi >You will learn enough there to make a portable and solid 3d rendering >engine. I second that. It includes tutorials and source. The "x2ftp" site is a very good repository anyway, as well as the 3D engines page at http://www.cs.tu-berlin.de/~ki/engines.html Also, do not underestimate Mesa. A decent library with a fast separate data path e.g. for span blitting is a good ground to stand on. See the wadtoiv home page on how DOOM levels might look once they are converted for Quake :-). For now, it is just OpenInventor. b. ------------------------------ From: Olivier Date: 07 Mar 96 17:12:17+0100 Subject: Question Hello Bernd, Well, the stuff is finished, Ralph has it. Whatever he intends to do with it. Now, a Question: any idea whereI could get a decent free/shareware modeler? I used POV and MORAY, but maybe you know of something better? for windoze? I need to display everything in 3D, to check, and don't want to add my own 3D bugs to the stuff already there. Well, if there isn't anything suitable I'll have to hack in my own stuff. whatever. Will take me days... Olivier ------------------------------ From: Bernd Kreimeier Date: Thu, 7 Mar 1996 17:45:46 +0100 (MET) Subject: Re: Question > Now, a Question: any idea where I could get a decent free/shareware modeler? > I used POV and MORAY, but maybe you know of something better? for windoze? I know that there's Midnight modeler for linux, but nothing else. Chris? > I need to display everything in 3D, to check, and don't want to add my own > 3D bugs to the stuff already there. Well, if there isn't anything suitable > I'll have to hack in my own stuff. whatever. Will take me days... Considering conversion issues, I think it will be worse. Of course, this will be a problem for all of us planning on tools for 3D. I see not too many alternatives. My suggestion for now: - use Mesa (OpenGL API) to display. This will work on all UNIX, and is supposed to work with Windows, too (haven't tried). It will render slow texture mapping, but will be written fast and portable. And it works really fast on my linux box. Depending on your experience with OpenGL, you will get preliminary results within hours - but the rendering will be slow. In the long run, especially with complicated (and still changing data structures) I'd suggest the following: - get VRweb, the source of the VRML browser based on Mesa, written by the Hyper-G team. Out of the box, it is for UNIX, dunno if there is a windows version already. - get the qvlib parser and I/O libraries at the VRML software repository, and do conversion from your own PAK/BSP/WAD utilities to VRML, using those C++ libraries. This seems a very good idea in the long run anyway. Will guarantee lots of publicity, too. Anybody to suggest a decent solution that will work tomorrow? b. P.S.: VRweb, the VRML repository, and Mesa referenced on the "overview of resources", on the QuakeDev support pages at http://www.nero.uni-bonn.de/~dn/q-sup - ----------------------------------------------------------------------------- "Between you and us, conformity of purpose will be achieved through the mutual satisfaction of requirements." - ----------------------------------------------------------------------------- ------------------------------ From: Raphael.Quinet@eed.ericsson.se Date: Thu, 7 Mar 1996 17:51:03 +0100 (MET) Subject: Unofficial Quake Specs 3.0 released! Greetings, fellow Quake hackers! I am pleased to announce the release of the "Unofficial Quake Specs", version 3.0. This document, written by Olivier Montanuy with the help of Brian Martin and yours truly, contains all the technical information that has been discovered so far about the test release of Quake (QTEST1). This document can be distributed freely and is intended to be a reference for all authors of Quake editors and utilities, as well as a source of information for the curious. It is the result of several days (and nights) of hacking and is certainly not complete, but it will be updated as new information is discovered. Here is the table of contents: 0. Introduction 1. The PACK files 1.1 The PACK file format 1.2 The Resources files 1.3 The Sound files 1.4 The Code lump 2. The Level Map Models 2.1 General description of levels Maps 2.2 The Contents of .BSP files 2.3 The Format of .BSP files 2.4 The Format of the level entries 2.5 Additional informations 3. The Entity Alias Models 3.1 Explanations of Alias Models 3.2 Animating Alias Models 3.3 The Alias Model .MDL file format 4. The sprite models 4.1 General description of Sprites 4.2 The Format of the .SPR files 5. New WAD file 5.1 WAD2 File format 5.2 Format of status bar pictures 5.3 Format of console lumps 5.4 Format of palettes 6. Final word The Unofficial Quake Specs are available at the following WWW sites: http://www.nero.uni-bonn.de/~dn/q-sup/spec/qspec-current.html http://www.stud.montefiore.ulg.ac.be/ftp-mirror/quake/docs/ http://ftp.cdrom.com/pub/idgames2/docs/ (in ZIP format only) Discussion of these specs should take place in the newsgroup rec.games.computer.quake.editing or on the quake-editing mailing list (please use these fora for technical discussion only - gameplay issues should be discussed in rec.games.computer.quake.misc only). Exchanges in a public forum are better than private e-mail, so that others can be informed before a new edition of the specs is released. Also, the authors don't want hundreds of messages in their mailboxes. Hmmm... someone told me to add this: DO NOT BOTHER THE AUTHORS BY E-MAIL OR THEY WILL MAKE .MDL VOODOO PUMPKINS OUT OF YOU AND WILL FILL YOU FULL OF NINE INCH NAILS. So there! :-) Enjoy! - -Raphael ------------------------------ From: Mark Hughes Date: Thu, 7 Mar 1996 16:55:43 -0800 Subject: Re: Question Bernd Kreimeier spake: >Anybody to suggest a decent solution that will work tomorrow? Rayshade is a great raytracer, and there's an X-based 3-D semi-interactive modeler called "raypaint" based on it (rayshade is as much a software library for raytracing as it is a standalone program). I highly recommend it. While it's not a 3-D motion engine, it works well for producing snapshots of a scene. Rayshade Netshade - the latest version of Rayshade. -Mark Hughes ------------------------------ From: Bernd Kreimeier Date: Fri, 8 Mar 1996 13:09:56 +0100 (MET) Subject: Re: Question > misc. stuff on Mesa, VRML etc. deleted Bogus. Looks like I haven't really been awake yesterday. The main advantage of using VRML is that there are already VRML browser/viewer. Convert whatever you want to see to VRML scene descriptions, and load the file with one of them. Dead slow on a PC for now, but workable and portable. I digged up the mail on GLView at home: forwarded with next posting. For all you Windrowsers out there :-). There is an overview at http://www.sdsc.edu/SDSC/Partners/vrml/software/browsers.html Modelers are available there at ../modelers.html. VRweb (recommended for linux) is at http://www.iicm.tu-graz.ac.at/Cvrweb (possibly slow connection). Now what you need is to get a version of qvlib running with your program, and dump your data to a VRML file. Depending on your browser's caps, you're done. b. ------------------------------ From: Bernd Kreimeier Date: Fri, 8 Mar 1996 13:10:40 +0100 (MET) Subject: Re: Question Forwarded: a shareware OpenGL based Windows VRML browser. b. >From www-vrml-owner@wired.com Fri Nov 24 23:22 MET 1995 From: "Holger Grahn" To: www-vrml@wired.com Subject: ANNOUNCE: GLView 2.02 a new WIN VRML OpenGL Browser Announcing GLView 2.0, the worlds first Shareware VRML Browser for Windows 95 and Windows NT. GLView uses Microsoft OpenGL for rendering, meaning support for *all* display modes from 16 and 256 to True-Color and support for 3D engine boards (e.g. Glint or others). Available at: http://www.snafu.de/~hg GLView provides more features than any other VRML browser (at least currently): - import of RAW, GEO, Wavefront OBJ (f) and AutoCad DXF files. - export of RAW, GEO, STL, VRML (single object) files - support for SFImage, SGI RGB, DIB/BMP, Targa, Jpeg and GIF texture image formats. - simple VRML object/material/texture animations using experimental VRML extensions nodes Rotor, Shuttle, Blinker, TextureRotor - supports 3D extruded VRML text - 3D morphing of arbitrary VRML indexFaceSets (e.g. a cow becomes a sphere). - detailed camera control including near and far clipping planes and view angle - many viewstyles from shaded, bounding-boxes to lighted/textured/antialiased wireframe - for portability from Inventor, most Inventor Geometry nodes are supported. - - support for all special things like multiple emissive indexed face/vertex materials, LOD, WWWAnchor and camera switching, viewpoints, texture transforms ... automatic triangulation of indexed faces sets .... For VRML Authors there are other features of interest like - collapsing an entire VRML Scene-Tree to a single (triangulated) IndexedFaceSet - Material-Editor - special TextureCoordinate generation functions (e.g. sphere/cylinder projection) - creation of 3D Text logos from arbitrary True-Type fonts - 3D-file conversion For a GL techie GLView allows access to low-level OpenGL options like - Texture filtering rules (e.g. mip-mapping, bilinear) - Fog - OpenGL pixelformats, triangle strip construction - OpenGL extension functions - frame rate display .... The next versions will probably bring : a Python script language VRML extension, 3D Particle Systems, some VRML scene editing, a VRML NodeInterpolator for camera animations and texture/material blending. e.g. to animate Material over time using some keyframes: NodeInterpolator { # interpolate all child nodes and traverses the resulting in-between node speed 5.0 # once cyle in 5 seconds Material{} Material{} Material{} ... } I hope you will have fun with GLView, thanks for the help with Netscape DDE to the VRML mailing list. HG ################################################### Holger Grahn hg@berlin.snafu.de http://www.snafu.de/~hg ------------------------------ From: Jim Bucher Date: Fri, 08 Mar 1996 18:49:12 -0600 Subject: Quake Palette I am working on a .mdl viewer and I need to know the internal format of the quake palette. I imagine it uses a look up table, but I don't know the format of the table. BTW, does anyone else think it is strange that the .mdl textures are variable width? This makes the inner loop a lot slower than using a 256 or power of 2 width. ------------------------------ End of quake-editing-digest V1 #3 ********************************* From owner-quake-editing@nvg.unit.no Sun Mar 10 02:28 MET 1996 Received: from sabre-wulf.nvg.unit.no (bin@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id CAA16352 for ; Sun, 10 Mar 1996 02:28:48 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id CAA24907 for quake-editing-digest-outgoing; Sun, 10 Mar 1996 02:22:21 +0100 Date: Sun, 10 Mar 1996 02:22:21 +0100 Message-Id: <199603100122.CAA24907@sabre-wulf.nvg.unit.no> From: owner-quake-editing-digest@nvg.unit.no To: quake-editing-digest@nvg.unit.no Subject: quake-editing-digest V1 #4 Reply-To: quake-editing@nvg.unit.no Errors-To: owner-quake-editing-digest@nvg.unit.no Precedence: bulk Content-Type: text Content-Length: 3123 X-Lines: 86 Status: RO quake-editing-digest Sunday, 10 March 1996 Volume 01 : Number 004 Quake tools in C++ Re: Quake Palette Re: Quake Palette Re: Quake Palette ---------------------------------------------------------------------- From: Steve Simpson Date: Sat, 09 Mar 1996 10:23:15 -0500 Subject: Quake tools in C++ I'm interested in writing some Quake tools in C++, preferably using the C++ Standard Template Library (STL). I'll be developing using Win95 with memory mapped files. Are there others out there with similar interests (i.e. using C++ rather than C)? ------------------------------ From: Raphael.Quinet@eed.ericsson.se Date: Sat, 9 Mar 1996 16:36:33 +0100 (MET) Subject: Re: Quake Palette On Fri, 08 Mar 1996, Jim Bucher wrote: > I am working on a .mdl viewer and I need to know the internal format of > the quake palette. I imagine it uses a look up table, but I don't know > the format of the table. BTW, does anyone else think it is strange that > the .mdl textures are variable width? This makes the inner loop a lot > slower than using a 256 or power of 2 width. The Quake palette is a simple array of 256 * 3 bytes (RGB). The palette is stored in gfx.wad. Take a look at "LoadPalette()" in QEU 0.3 (in the file f_bitmap.c). This should show you how to use it. You can also compile "unwad2" and see how it saves the palette in BMP files. - -Raphael ------------------------------ From: Jim Bucher Date: Sat, 09 Mar 1996 13:26:21 -0600 Subject: Re: Quake Palette Raphael.Quinet@eed.ericsson.se wrote: > > The Quake palette is a simple array of 256 * 3 bytes (RGB). The palette > is stored in gfx.wad. Take a look at "LoadPalette()" in QEU 0.3 (in the > file f_bitmap.c). This should show you how to use it. You can also > compile "unwad2" and see how it saves the palette in BMP files. > > -Raphael I know how the palette is set up, but when I use the palette from the gfx.wad the textures do not look right. This leads me to believe that they are using a color look up table for the texture. So, do you know if the textures reference the palette directly, or is there is an intermediate color quantization table? It could be that I have just set the palette wrong. ------------------------------ From: Jim Bucher Date: Sat, 09 Mar 1996 14:05:23 -0600 Subject: Re: Quake Palette Jim Bucher wrote: > > I know how the palette is set up, but when I use the palette from the > gfx.wad the textures do not look right. This leads me to believe that they > are using a color look up table for the texture. So, do you know if the > textures reference the palette directly, or is there is an intermediate > color quantization table? It could be that I have just set the palette > wrong. I just fixed the problem. I was setting the palette wrong. The palette entries are in the range of 0-255. The VGA DAC only accepts 6-bit entries so I had to right shift all values by 2 before setting the palette. ------------------------------ End of quake-editing-digest V1 #4 ********************************* From owner-quake-editing@nvg.unit.no Mon Mar 11 02:30 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 CAA18334 for ; Mon, 11 Mar 1996 02:30:25 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id CAA06400 for quake-editing-digest-outgoing; Mon, 11 Mar 1996 02:23:07 +0100 Date: Mon, 11 Mar 1996 02:23:07 +0100 Message-Id: <199603110123.CAA06400@sabre-wulf.nvg.unit.no> From: owner-quake-editing-digest@nvg.unit.no To: quake-editing-digest@nvg.unit.no Subject: quake-editing-digest V1 #5 Reply-To: quake-editing@nvg.unit.no Errors-To: owner-quake-editing-digest@nvg.unit.no Precedence: bulk Content-Type: text Content-Length: 26960 X-Lines: 577 Status: RO quake-editing-digest Monday, 11 March 1996 Volume 01 : Number 005 Distributing Quake maps (long-ish, wordy and rambling :) Re: Distributing Quake maps (long-ish, wordy and rambling :) Re: Quake tools in C++ Re: Distributing Quake maps (long-ish, wordy and rambling :) Distributing Quake maps (long-ish, wordy and rambling :) Distributing Quake maps (long-ish, wordy and rambling :) Re: Distributing Quake maps ---------------------------------------------------------------------- From: Tom Wheeley Date: Sun, 10 Mar 96 01:40:28 GMT Subject: Distributing Quake maps (long-ish, wordy and rambling :) Reading both Raphael's recent article in rgcqe and the Quake specs, it seems to me like we do not want hundreds of textures cluttering peoples maps. Now, I don't know: a) How close people are to anything resembling level editors. (Not close, I should think, seeing how many `lookups' there are to be calculated in the maps/*.bsp files. b) How much Quakes handling of textures (`surfaces') will change between this test version (qkspec30) and the wondrous mythical `Final Version'. However, my thoughts on these are: a) If we agree on something now, perhaps with a bit of source, then a standard for distributing levels can be set before we get rogue levels making the rounds of the ftp/www sites... b) I am assuming that having the textures in each map will not change to references. There is also the issue of including id's textures in distributed levels. At the minimum I am proposing is a tool not dis-similar to DeuSF or DeuTex which is run locally by the end user. This will process a list of textures which the program `statically links' into a final BSP file. This control file could be designed in 3 ways. . structure based, and thus virtually unmaintainable by humans, but easy for programs to fiddle with. . text file, for the most part using the `texture numbers' (for more info on how the textures are referenced, see Quake Specs). This would be created by the map editor, which would interface with the user with the texture names . text file, but uses the texture names when specifying sources. This would be the slowest (but not that slow) to process. It would be easily maintainable by humans though :) Using the 3rd format, it would look something like this: (The names are complete fabrications!). # Quake `MakeTex.cfg' file. #StoredName Source file Entry name RedBrickWall maps/test1.bsp IDREDWALL # Search a BSP file Stuccoish maps/test1.dir/entry02.lmp IDSTUCCOISH # Search multi MIP lump SecretSrc maps/test3.bsp =12 # Entry 12 in a BSP # End sample MakeTex.cfg file Unfortunately, the only magic which can be tested for is for the BSP files and so no-way could be established for checking that a miptex lump _is_ a miptex lump (without checking the size difference of the offsets, possibly). Thus raw .MIP (or whatever) files would have to be outlawed, they would have to start with the very simple multiple MIP header (as per the beginning of the miptex lump) of size 1. This idea of processing at the users locale could possibly be extended to the creation of the various abstract stuctures which comprise most of the rest of the .BSP file. Finally, I think the _easiest_ way to distribute the rest of the data would be within a PAK file, possibly renamed LEV or QL (or .TOM ;-)). Then each BSP lump would have an entry in the .PAK file, along with new mip textures (referenced in the MakeTex file as ``NewName PAKentryname'' -- 2 tokens). The reason each mip texture would have its own PAK entry, rather than a simgle MultiMIP entry is that it would make processing simpler (extracting and searching one archive rather than 2) The MakeTex itself would be in the PAK as Entry 'MakeTex'. Other (possibly standardized) entries could be made such as `Author', 'Description', 'Licence' etc. These could be displayed by the MakeTex program. There is then the small dilemma of whether to have MakeTex work on the distribution file directly (save disk space) or create a new file completely. If there is sufficient reason for the first option, then perhaps the distributable file would need to be structured almost exactly like a BSP file, and the new textures simply appended. This, imho, is not as neat. I would like to thank both of you for reading this far ;-) I would like other's opinions on this. (I can tell I've missed something obvious... :) I have done a bit of preliminary coding for MakeTex, but there's no point going to far with it if the idea is flawed. I am using, abusing and extending the QEU files to do this. (mainly q_*, f_bsp, f_pack and my own skeletal f_miptex) - -- * TQ 1.0 * The 'Just So Quotes'. I know you're supposed to take life one day at a time -- but lately several days have attacked me at once. ------------------------------ From: Tom Lees Date: Sun, 10 Mar 1996 08:06:26 +0000 (GMT) Subject: Re: Distributing Quake maps (long-ish, wordy and rambling :) On Sun, 10 Mar 1996, Tom Wheeley wrote: > At the minimum I am proposing is a tool not dis-similar to DeuSF or DeuTex > which is run locally by the end user. This will process a list of textures > which the program `statically links' into a final BSP file. This is a good idea, but it shouldn't be too slow, otherwise we will get 'binaries' distributed versions of levels as well as 'source' versions. > > This control file could be designed in 3 ways. > > . structure based, and thus virtually unmaintainable by humans, but easy > for programs to fiddle with. > . text file, for the most part using the `texture numbers' (for more info > on how the textures are referenced, see Quake Specs). This would be > created by the map editor, which would interface with the user with > the texture names > . text file, but uses the texture names when specifying sources. This > would be the slowest (but not that slow) to process. It would be easily > maintainable by humans though :) > Or, it could be structure based, but created from a file using the 3rd format, for the best of both worlds. > Unfortunately, the only magic which can be tested for is for the BSP files and > so no-way could be established for checking that a miptex lump _is_ a miptex > lump (without checking the size difference of the offsets, possibly). Thus > raw .MIP (or whatever) files would have to be outlawed, they would have to > start with the very simple multiple MIP header (as per the beginning of the > miptex lump) of size 1. Why not use a different format completely (like BMP or GIF or something)? This would probably result in minimal work for level designers and level editor programmers, and make the distributed level format more portable in the case of the Quake structures changing format. > This idea of processing at the users locale could possibly be extended to the > creation of the various abstract stuctures which comprise most of the rest of > the .BSP file. However, I think that this would slow down the local processing time too much, leading to separate binary and source distributions. > The MakeTex itself would be in the PAK as Entry 'MakeTex'. Other (possibly > standardized) entries could be made such as `Author', 'Description', 'Licence' > etc. These could be displayed by the MakeTex program. I'm not sure if this is completely necessary. If the format of the levels within the distributed PAK file is going to be different than in standard Quake BSP files, why not simply put the data as part of the new distribution level format? > There is then the small dilemma of whether to have MakeTex work on the > distribution file directly (save disk space) or create a new file completely. > If there is sufficient reason for the first option, then perhaps the > distributable file would need to be structured almost exactly like a BSP file, > and the new textures simply appended. This, imho, is not as neat. If the full version of Quake supports more than a single PAK file, a nice option would be for the user to be all his or her favourite levels in one PAK file, which could then be loaded every time Quake starts, then access to all the user-created levels would be simple. However, I don't think there is any call to directly modify the distribution files, other than that it keeps the directory structure and files in the Quake directory cleaner. - -- Tom Lees (tom@lpsg.demon.co.uk) ------------------------------ From: Bernd Kreimeier Date: Sun, 10 Mar 1996 10:15:51 +0100 (MET) Subject: Re: Quake tools in C++ > From: Steve Simpson > I'm interested in writing some Quake tools in C++, preferably using > the C++ Standard Template Library (STL). I'll be developing using > Win95 with memory mapped files. Are there others out there with > similar interests (i.e. using C++ rather than C)? All my tools (which are not primarily intended for Quake) are/will be written in C++. I do not think, however, that I will use the STL. >From what I have seen, gcc-2.7.2 still has problems with STL, and I consider UNIX (read: linux) and GCC (hopefully including DJGPP) my base plattform. Is there any particular reason for your suggesting STL? Haven b. ------------------------------ From: Bernd Kreimeier Date: Sun, 10 Mar 1996 10:32:33 +0100 (MET) Subject: Re: Distributing Quake maps (long-ish, wordy and rambling :) > misc. discussion and proposals about distribution files deleted One remark: as long as we do not know the final PAK/WAD2/whatever format, it makes no sense to invent another file format with a huge bias towards Quake. In 1995, I wrote a proposal for a generalized WAD file structure. I remember a WAD API proposal by somebody from the DEU team. In addition, there are descriptions of Dark Forces and Descent files. Now take therse and PAK and WAD2, and look for what all these have in common. Here is how I handled WAD files: I wrote a separate conversion function that, reading the raw data lump of the directory, assigned lump Type information based on some heuristics. In addition, I treated the magic "IWAD" or "PWAD" as a Type indicator, too. This means that my own DWAD files could as well include PWAD or IWAD files as lumps, because I had no difference between File header and Directory entry: both had type, offset, length, and name (and checksum...), the data was just interpreted differently. The main advantage is that this is a) recursive, b) allows for including differently written files as lumps, and therefore c) allowed for using GIF, WAV etc. raw data lumps as well. If you want me to elaborate, I will dig up the specs. A good idea used by the PAK is combining tar-like structures with direct/seek access capability: the subdirectory handling. But this simply means changing the way "/" is treated in the names of generalized WAD files. Finally: think in terms of checksums, copyright information, identifiers, and resource (textures, sounds) repositories. It might be a good idea to use PNG for pictures (see Quake Developers support pages, overview of resources). GIF is not a good idea. In principle, each lump that might be used and re-distributed in different ways should provide all info about how it should be named in the directory, the checksum to verify the data is not corrupted, and the copyright/version/revision information, and the Type of lump. b. ------------------------------ From: Tom Wheeley Date: Sun, 10 Mar 96 13:16:25 GMT Subject: Distributing Quake maps (long-ish, wordy and rambling :) In article you write: > On Sun, 10 Mar 1996, Tom Wheeley wrote: > > > At the minimum I am proposing is a tool not dis-similar to DeuSF or DeuTex > > which is run locally by the end user. This will process a list of textures > > which the program `statically links' into a final BSP file. > > This is a good idea, but it shouldn't be too slow, otherwise we will get > 'binaries' distributed versions of levels as well as 'source' versions. The test maps are only a meg, so my guess is a max of about 10s on my 386sx (I'm in a similar position to Raphael -- can't play the damn game ! :) This time would be larger for more textures. There is (currently) a max of 256 textures now. I don't think it is a significant step, timewise. Slower than PKUNZIPping the file, probably, but not meaningfully so. > > > > > This control file could be designed in 3 ways. > > > > . structure based, and thus virtually unmaintainable by humans, but easy > > for programs to fiddle with. > > . text file, for the most part using the `texture numbers' (for more info > > on how the textures are referenced, see Quake Specs). This would be > > created by the map editor, which would interface with the user with > > the texture names > > . text file, but uses the texture names when specifying sources. This > > would be the slowest (but not that slow) to process. It would be easily > > maintainable by humans though :) > > > Or, it could be structure based, but created from a file using the 3rd > format, for the best of both worlds. > > > Unfortunately, the only magic which can be tested for is for the BSP files and> > so no-way could be established for checking that a miptex lump _is_ a miptex > > lump (without checking the size difference of the offsets, possibly). Thus > > raw .MIP (or whatever) files would have to be outlawed, they would have to > > start with the very simple multiple MIP header (as per the beginning of the > > miptex lump) of size 1. > > Why not use a different format completely (like BMP or GIF or something)? > This would probably result in minimal work for level designers and level > editor programmers, and make the distributed level format more portable > in the case of the Quake structures changing format. Well, the texture designers have to create the MIP textures, which are scaled by 1/2/4/8 respectively. It is up to the texture editors to convert from BMP or GIF. I don't want to have to use multi-image GIFs here. > > This idea of processing at the users locale could possibly be extended to the > > creation of the various abstract stuctures which comprise most of the rest of > > the .BSP file. > > However, I think that this would slow down the local processing time too > much, leading to separate binary and source distributions. It depends on the how fast it is to create some of them. f.e. if a particularly large lump was quick to process, it would be prefereable to process this at the end, rather than distribute a large lump. Remember that `binary' distributions are illegal, and are currently blocked from ftp.cdrom.com This is just a _possible_ extension, anyway. > > The MakeTex itself would be in the PAK as Entry 'MakeTex'. Other (possibly > > standardized) entries could be made such as `Author', 'Description', 'Licence'> > etc. These could be displayed by the MakeTex program. > > I'm not sure if this is completely necessary. If the format of the levels > within the distributed PAK file is going to be different than in standard > Quake BSP files, why not simply put the data as part of the new > distribution level format? Umm, I'm not entirely sure what you mean. The MakeTex will build a `standard' BSP file from the more general information in the PAK file. There is no good place to put `unneccesary' information in the BSP file, as there is in the PAK files, which have a more complicated directory. You can only put things in gaps, (like QEU does with version info) > > > There is then the small dilemma of whether to have MakeTex work on the > > distribution file directly (save disk space) or create a new file completely. > > If there is sufficient reason for the first option, then perhaps the > > distributable file would need to be structured almost exactly like a BSP file,> > and the new textures simply appended. This, imho, is not as neat. > > If the full version of Quake supports more than a single PAK file, a nice > option would be for the user to be all his or her favourite levels in one > PAK file, which could then be loaded every time Quake starts, then access > to all the user-created levels would be simple. However, I don't think > there is any call to directly modify the distribution files, other than > that it keeps the directory structure and files in the Quake directory > cleaner. Yes, I think I would prefer the separate file method. I must say, being able to specify PPACKs ;) would be very nice. At the moment, you can just put things in the directory tree, although it doesn't quite have the desired `priority'. .splitbung - -- * TQ 1.0 * 101 Slogans for Quake 57. alt.sex.Quake: Please hit me again.... ------------------------------ From: Tom Wheeley Date: Sun, 10 Mar 96 13:31:01 GMT Subject: Distributing Quake maps (long-ish, wordy and rambling :) In article <199603100932.KAA08721@colossus.nero.uni-bonn.de> you write: > > > misc. discussion and proposals about distribution files deleted > > One remark: as long as we do not know the final PAK/WAD2/whatever > format, it makes no sense to invent another file format with a > huge bias towards Quake. > > In 1995, I wrote a proposal for a generalized WAD file structure. > I remember a WAD API proposal by somebody from the DEU team. In > addition, there are descriptions of Dark Forces and Descent > files. Now take therse and PAK and WAD2, and look for what all > these have in common. > > Here is how I handled WAD files: I wrote a separate conversion > function that, reading the raw data lump of the directory, > assigned lump Type information based on some heuristics. In addition, This is very interesting. I definitely think that this format would be more appropriate for the distribution file than the PAK. I was not really proposing a new format, other than the `MakeTex.cfg' file. Could you send to me (or post to the list if appropriate) the format of this DWAD? Also, where are the quake-development pages? Apologies if they were in the info file on the list, but I must have missed it. .splitbung - -- * TQ 1.0 * The 'Just So Quotes'. Recursive, adj.; see Recursive ------------------------------ From: amoon@odin.mdn.com (Alex R. Moon) Date: Sun, 10 Mar 1996 13:07:44 -0500 (EST) Subject: Re: Distributing Quake maps Tom Wheeley wrote: > > In article you write: > > > On Sun, 10 Mar 1996, Tom Wheeley wrote: > > > > > At the minimum I am proposing is a tool not dis-similar to DeuSF or DeuTex > > > which is run locally by the end user. This will process a list of textures > > > which the program `statically links' into a final BSP file. > > > > This is a good idea, but it shouldn't be too slow, otherwise we will get > > 'binaries' distributed versions of levels as well as 'source' versions. > > The test maps are only a meg, so my guess is a max of about 10s on my 386sx > (I'm in a similar position to Raphael -- can't play the damn game ! :) > This time would be larger for more textures. There is (currently) a max of > 256 textures now. I don't think it is a significant step, timewise. Slower > than PKUNZIPping the file, probably, but not meaningfully so. This depends on how compiled you expect this format to be. Do you expect it to contain only geometry data, or do you expect it to contain all the bsp trees and visilists as well? If the former, be aware that id has said that visilist calculation can take over an hour on a 4 processor 200MHz Alpha machine. If the latter, why not just use a .BSP format with the textures replaced with placeholders (null textures with just a texture name). Then some tool could go through and rifle the id .BSP files (or any other .BSP files) looking for the appropriate textures and chuck them in. Personally I'd like to see both, a textureless .BSP file AND a human-friendly, BSPless and visilistless geometry format. > > > This idea of processing at the users locale could possibly be extended to the > > > creation of the various abstract stuctures which comprise most of the rest of > > > the .BSP file. > > > > However, I think that this would slow down the local processing time too > > much, leading to separate binary and source distributions. > > It depends on the how fast it is to create some of them. f.e. if a > particularly large lump was quick to process, it would be prefereable to > process this at the end, rather than distribute a large lump. Remember that > `binary' distributions are illegal, and are currently blocked from ftp.cdrom.com > This is just a _possible_ extension, anyway. Compiling the BSP trees, light maps, and visilists sounds like it'll take forever. Definitely not something an end user is going to want to mess with. On the other hand, Doom showed us that dedicated BSP builders can get better results than many editors' built-in BSP builders. I hate to think how much more that will be true with visilist builders. So, how about a generic text format which all editors and compilers can use which simply gives the geometry for the level which can then be compiled into a .BSP file (with or without actual textures, see above)? > > > The MakeTex itself would be in the PAK as Entry 'MakeTex'. Other (possibly > > > standardized) entries could be made such as `Author', 'Description', 'Licence'> > etc. These could be displayed by the MakeTex program. > > > > I'm not sure if this is completely necessary. If the format of the levels > > within the distributed PAK file is going to be different than in standard > > Quake BSP files, why not simply put the data as part of the new > > distribution level format? > > Umm, I'm not entirely sure what you mean. The MakeTex will build a `standard' > BSP file from the more general information in the PAK file. There is no > good place to put `unneccesary' information in the BSP file, as there is in > the PAK files, which have a more complicated directory. You can only put > things in gaps, (like QEU does with version info) If this is all you want it to do, just use a .BSP format with a wierd version and placeholders for the texture data. Searching other .BSP files or .TEX files for the appropriate textures should be simple. Here are my thoughts on how an uncompiled level format should be constructed. There are essentially three elements which make up a quake map: 1) It's geometry (the surfaces), 2) It's inhabitants (the entities), and 3) It's textures. Everything else can be calculated given those three. Therefore, the obvious solution (to me) is to have three file types, one for each element of a level. Each level would have three files (optionally PACKed) which could be compiled into one .BSP file. The only question is what format each file should adhere to. The entities are stored in the .BSP file in a nice simple text format, so why not use that for the .ENT file? We could make it conform to DOS CR-LF format instead of its UNIX-style LFs and just strip the CRs when it's compiled into a BSP file. The textures also have their own format in the .BSP file which we can use for the .TEX (or .MIP, or whatever) files, perhaps with an additional header giving a magic and any other info we want to add. The only question then is what format we should use for storing the geometry data. In my opinion, there's no question that we should use as human-readable a text format as possible. The files probably won't be huge in the first place and compression will seriously shrink the text files such that file size shouldn't be a deciding factor in favoring a binary format. Other than size, text files have all the advantages; they're easy to read, they're easy to manipulate, they're easy to understand, etc, etc. Some time ago, iD was using a format like the following format for this purpose (snarfed from an old ddt irc log, everything has, no doubt, changed): : 4 WALL14_5 0 0 0 0 0 0 (0,912,176,144) (0,928,176,144) (16,928,176,144) (16,912,176,144) 4 WALL14_5 0 0 0 0 0 0 (192,928,144,0) (192,1040,144,0) (208,1040,144,0) (208,928,144,0) : In the generic case (using the variables from qkspec30), this format is: numedge texname sofs(?) tofs(?) flips(?) light(?) unknown0(?) unknown1(?) (v1_x,v1_y,v1_z1,v1_z2) (v2_x,v2_y,v2_z1,v2_z2) ... (vn_x,vn_y,vn_z1,vn_z2) Note that they're using a simple solid geometry approach instead of giving a separate entry for each surface. Each entry instead represents a sort of extruded polygon which includes numedge+2 surfaces. This has advantages for editors in that they can use the solid geometry information in their user interface and for CSM instead of forcing the user to deal with each surface separately. And for editors or files which have no solid information, you can simply set vn_z1 = vn_z2 for every vertex. Basically, if we want a text and human-readable geometry format, we need to decide whether that format should contain only surface information, or if it should contain some sort of additional solid geometry information. If the former, a format such as: numedge texname sofs tofs flips light unknow0 unknown1 (v1_x,v1_y,v1_z) (v2_x,v2_y,v2_z) ... (vn_x,vn_y,vn_z) should be sufficient. In the latter case we need something more complex, either id's format above (which is awfully limited), or perhaps something like this: # Surfaces # -------- numsurfaces : numedge texname sofs tofs flips light unknow0 unknown1 (v1_x,v1_y,v1_z) (v2_x,v2_y,v2_z) ... (vn_x,vn_y,vn_z) : # Solid Objects # ------------- numobjects : numsurfaces surface1 surface2 ... surfacen : This format is just the surfaces format from above plus a number of surface lists (similar to the surface lists used for BSP leaves) which represent solid objects, for use by editors in CSM and user-level manipulation. In summary, we've got an entities format. We've got a texture format (though we may wish to add a header). The only decision we've left to make is for a geometry format, and deciding on that should be relatively simple. - -- 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 ------------------------------ End of quake-editing-digest V1 #5 ********************************* From owner-quake-editing@nvg.unit.no Tue Mar 12 02:29 MET 1996 Received: from sabre-wulf.nvg.unit.no (bin@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id CAA06873 for ; Tue, 12 Mar 1996 02:29:06 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id CAA30454 for quake-editing-digest-outgoing; Tue, 12 Mar 1996 02:22:44 +0100 Date: Tue, 12 Mar 1996 02:22:44 +0100 Message-Id: <199603120122.CAA30454@sabre-wulf.nvg.unit.no> From: owner-quake-editing-digest@nvg.unit.no To: quake-editing-digest@nvg.unit.no Subject: quake-editing-digest V1 #6 Reply-To: quake-editing@nvg.unit.no Errors-To: owner-quake-editing-digest@nvg.unit.no Precedence: bulk Content-Type: text Content-Length: 794 X-Lines: 23 Status: RO quake-editing-digest Tuesday, 12 March 1996 Volume 01 : Number 006 .MDL animations ---------------------------------------------------------------------- From: Jim Bucher Date: Mon, 11 Mar 1996 16:10:32 -0600 Subject: .MDL animations There can be several 'animations' in each model. I am wondering if there is any information in the model file that tell which frame an animation starts and stops on. I looked at the data in the frame header, but it does not look like it contains any info on how the frames form an animated sequence. Does anyone know where the data for the animation sequences is stored? It has to be somewhere unless it is hard coded. ------------------------------ End of quake-editing-digest V1 #6 ********************************* From owner-quake-editing@nvg.unit.no Wed Mar 13 02:31 MET 1996 Received: from sabre-wulf.nvg.unit.no (bin@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id CAA14676 for ; Wed, 13 Mar 1996 02:31:17 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id CAA25266 for quake-editing-digest-outgoing; Wed, 13 Mar 1996 02:24:31 +0100 Date: Wed, 13 Mar 1996 02:24:31 +0100 Message-Id: <199603130124.CAA25266@sabre-wulf.nvg.unit.no> From: owner-quake-editing-digest@nvg.unit.no To: quake-editing-digest@nvg.unit.no Subject: quake-editing-digest V1 #7 Reply-To: quake-editing@nvg.unit.no Errors-To: owner-quake-editing-digest@nvg.unit.no Precedence: bulk Content-Type: text Content-Length: 2384 X-Lines: 62 Status: RO quake-editing-digest Wednesday, 13 March 1996 Volume 01 : Number 007 Re: .MDL animations Re: .MDL animations ---------------------------------------------------------------------- From: stw113@psu.edu (Sean Werkema) Date: Mon, 11 Mar 1996 22:05:32 -0500 Subject: Re: .MDL animations >There can be several 'animations' in each model. I am wondering if there >is any information in the model file that tell which frame an animation >starts and stops on. I looked at the data in the frame header, but it >does not look like it contains any info on how the frames form an >animated sequence. Does anyone know where the data for the animation >sequences is stored? It has to be somewhere unless it is hard coded. According to id, the selection of the appropriate frame is done by the QuakeC code. So in a way, yes, it's hard coded, and in a way, no, it's not. But it's not suprising that there is no animation information in the .MDL files. +-----------------------------------------------------------------+ | "There is no partial credit. If we cannot put a man on the | | moon we do not get any credit for putting him up into a tree." | | Email: stw113@psu.edu (Sean Werkema) | | Web: http://www.crayola.cse.psu.edu/~werkema BCNU :) | +-----------------------------------------------------------------+ ------------------------------ From: "Brian K. Martin" Date: Tue, 12 Mar 1996 08:11:05 -0500 (EST) Subject: Re: .MDL animations > > > > There can be several 'animations' in each model. I am wondering if there > is any information in the model file that tell which frame an animation > starts and stops on. I looked at the data in the frame header, but it > does not look like it contains any info on how the frames form an > animated sequence. Does anyone know where the data for the animation > sequences is stored? It has to be somewhere unless it is hard coded. > The data in the frame header defines the bounding block around the object. My guess is that the animation frame sequence is stored in the progs.dat file somewhere. brian p.s. MDL (MedDLe) is up to version 1.0 and now has 3d texture mapped graphics and stuff.. http://www.phyast.pitt.edu/~brian/mdlv10.zip ------------------------------ End of quake-editing-digest V1 #7 ********************************* From owner-quake-editing@nvg.unit.no Thu Mar 14 02:33 MET 1996 Received: from sabre-wulf.nvg.unit.no (bin@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id CAA21711 for ; Thu, 14 Mar 1996 02:33:00 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id CAA14508 for quake-editing-digest-outgoing; Thu, 14 Mar 1996 02:26:25 +0100 Date: Thu, 14 Mar 1996 02:26:25 +0100 Message-Id: <199603140126.CAA14508@sabre-wulf.nvg.unit.no> From: owner-quake-editing-digest@nvg.unit.no To: quake-editing-digest@nvg.unit.no Subject: quake-editing-digest V1 #8 Reply-To: quake-editing@nvg.unit.no Errors-To: owner-quake-editing-digest@nvg.unit.no Precedence: bulk Content-Type: text Content-Length: 18981 X-Lines: 445 Status: RO quake-editing-digest Thursday, 14 March 1996 Volume 01 : Number 008 Re: Quake tools in C++ Re: Quake tools in C++ Re: .MDL animations Map Conversion Utility, Anyone? Re: Map Conversion Utility, Anyone? Re: Map Conversion Utility, Anyone? Re: .MDL animations Re: .MDL animations Forward: Intermediate file format Re: Forward: Intermediate file format ---------------------------------------------------------------------- From: Bernd Kreimeier Date: Sun, 10 Mar 1996 10:15:51 +0100 (MET) Subject: Re: Quake tools in C++ > From: Steve Simpson > I'm interested in writing some Quake tools in C++, preferably using > the C++ Standard Template Library (STL). I'll be developing using > Win95 with memory mapped files. Are there others out there with > similar interests (i.e. using C++ rather than C)? All my tools (which are not primarily intended for Quake) are/will be written in C++. I do not think, however, that I will use the STL. >From what I have seen, gcc-2.7.2 still has problems with STL, and I consider UNIX (read: linux) and GCC (hopefully including DJGPP) my base plattform. Is there any particular reason for your suggesting STL? Haven b. ------------------------------ From: Steve Simpson Date: Wed, 13 Mar 1996 08:18:35 -0500 Subject: Re: Quake tools in C++ Bernd Kreimeier wrote: > > > From: Steve Simpson > > > I'm interested in writing some Quake tools in C++, preferably using > > the C++ Standard Template Library (STL). I'll be developing using > > Win95 with memory mapped files. Are there others out there with > > similar interests (i.e. using C++ rather than C)? > > All my tools (which are not primarily intended for Quake) are/will be > written in C++. I do not think, however, that I will use the STL. > >From what I have seen, gcc-2.7.2 still has problems with STL, and > I consider UNIX (read: linux) and GCC (hopefully including DJGPP) my > base plattform. Is there any particular reason for your suggesting > STL? Haven > > b.I'm learning STL and looking for a project to try to put it to practical use. It certainly doesn't have to be used on this project. I'd simply be looking for ways where it could be used. The important thing is doing it in C++. STL is secondary but may be useful. Steve Simpson ------------------------------ From: "John B. Williston" Date: Wed, 13 Mar 1996 11:09:43 -0500 Subject: Re: .MDL animations Brian K. Martin wrote: > p.s. MDL (MedDLe) is up to version 1.0 and now has 3d texture mapped > graphics and stuff.. http://www.phyast.pitt.edu/~brian/mdlv10.zip I really like the job you've done on MedDLe. I'm trying to learn 3D graphics right now myself -- are you still willing to share the code? I suspect it would be helpful as a learning excercise. Thanks in advance! John - -- http://ourworld.compuserve.com:80/homepages/williston_consulting/ ___ ___ \ \ ____ / / Williston Consulting \ \/ \/ / _____________ "Software worth buying" \ /\ / / _________/ \_/ \_/ / / 70541.1335@compuserve.com / /_________ us018032@interramp.com /_____________/ ------------------------------ From: Scott Coleman Date: Wed, 13 Mar 1996 10:11:09 -0800 Subject: Map Conversion Utility, Anyone? In perusing the postings here, I've seen some discussions of homebrew Quake editors. If it hasn't been already, I'd like to suggest that a map conversion utility, which would convert existing DOOM maps to work with the Quake Deathmatch Test engine, might be a good first project rather than a full blown editor. My reasoning is as follows: We all know that the Quake data file formats are in a state of flux, so a full-blown editor would likely represent at least a not insignificant amount of wasted effort because the end result would not work with the next release of Quake. True, much of the investment in coding will be reusable with little or no changes in the "Quake Final" editors. However, the same is true for the routines developed for the conversion utility. Among the advantages of making this map converter "detour" on the route to a editor is that it would require less development time: a script driven command line interface would suffice for the converter, as opposed to the full blown 3D rendering and point-and-click interface which the editor would require. With the thousands of existing DOOM levels as source material, we'd have plenty to tide us over until the real Quake game and levels arrive. Quake Ledges, anyone? How about Quake Danzig15? ;-) At the rate you guys are hacking out the details, it shouldn't take more than 2-3 weeks for a workable converter to come out - IF someone could be persuaded to start working on one. Anyone up for it? BTW, once the converter was finished, the code would of course serve as an excellent foundation for the eventual editor. One other wild idea: make the level compilers parallelizable over the Internet. With a few cooperating net.folks, a group of hosts could be organized to donate their spare CPU cycles to make the conversion process move along more quickly. I confess I'm not an expert in the theory behind the parallelization of algorithms such as BSP tree generation, so I don't know how practical this is - either from a technical standpoint or from a "political" standpoint - so feel free to slice it to ribbons. ;-) Reaction? Comments? begin 600 WINMAIL.DAT M>)\^(@H2`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$-@ 0` M`@````(``@`!!) &`#@!```!````# ````,``# #````"P`/#@`````"`?\/ M`0```%$`````````@2L?I+ZC$!F=;@#=`0]4`@````!Q=6%K92UE9&ET:6YG M0&YV9RYU;FET+FYO`%--5% `<75A:V4M961I=&EN9T!N=F``(P`0````4```!33510`````!X``S !````&@```'%U86ME+65D:71I M;F= ;G9G+G5N:70N;F\````#`!4,`0````,`_@\&````'@`!, $````<```` M)W%U86ME+65D:71I;F= ;G9G+G5N:70N;F\G``(!"S !````'P```%--5% Z M455!2T4M141)5$E.1T!.5D2P@06YY;VYE M/P!M"P$%@ ,`#@```,P'`P`-``H`"P`)``,`! $!(( #``X```#,!P,`#0`) M``@`)0`#`!P!`0F `0`A````,C0V0S(X031!13=#0T8Q,4%$1C$P,#(P048T M,#!!,3(`)@`' ``0```" ```!-87 @0V]N=F5RP8``+P)``!,6D9U'T+Z2O\`"@$/`A4"J 7K M`H,`4 +R"0(`8V@*P'-E=#(W!@`&PP*#,@/%`@!P)S=&5M`H,S=P+D M!Q,"@S0$UA,U"%!MW&EC!@0%X * ?0J ",_%"=D[&"\R-34"@ J!@PVQ"V!N M9S$P,Q10KPL*%%$+\A-0;Q/08P5 2PJ/'#AC`$ @20.@< T$D'4`D!LP('1H M97T?8&\3P!_!!" @$!@P+/D?,"=V(" 1L GP(7 #%B&# 'X%&8=6%K(" )@&ET!; \2$29"!L:2/1XR0P(7!U9V<'D 5 ( "2805 82 `P' @!:#. M;B%0$: BD2!U(' F@-)T)A%W:!:0:"E@"&#.;"9@*#0%0&5X! `@ @``# ="FA5"="G0GP9PN (0$6 M@&=H)4*))\%G;P1P(&9I$:#K!4 @(" BX1L`=7@A M$"'0W3%E+3'J*<4F@FPRTA-0_P>0"? GL05 -W E`">R-="W!4 +@ "09P,` M+]!C`'#[)[$$8'4\42+A*6 \T0F _R/P#= 7T251/@`?H":Q(!'_"? F8#P1 M*? %0"G4/3(L'/TND'@PD3N@,P$X\R.C)'#V5!^0+J)U*:$BX2 ""X#_(5 3 MP > /%$X806@(B ?T?\#\#&R(" 8,!^@`: W<2QC_2D1=#=Q!;$UT"@@,3$G M,6LX4B "(B.D1@N !T B]2/X2#(`92AA(1 @`D=@^R'Q,Y%T1%$WDA_S`V H MX?\ND 0@#; A4!? 'W OL4SUZ2@_>2XT?$$$8!_5)?"Z=CX184DB(N$`P&L? MQ.\SD2?X$] %P"(-L"0P"'#_2I HL4TF)K,GT#JE3&(GDN .CB"!03N9 40(5!&(FT#@29B+I#[.%%4`68`T$>A M*>,G``W0_Q:03,A3IR$0,\%.0"!!/T'G)M$@`C&9,T0RX4"P!G$O']%:HB! M6S$M6J$M8_TF@&,L0%LY*8- 8SJZ5W7])'!7+'8@``A@1V! L"+#_RJ\-W!. M$3.C(= (<%NA+:'W!G$'0"E19291$8 A40M0]SQ!,M!>DFD-L"C0(L$H87\H MT (P`Q%-(R7@`R CI&=W3"):HV:U>$1H2%Q_G(A43/!`Y$JL%N@,; \0O\"$#Z -P$HHDSF M2W$",".P]P,@,D8T?$];`1SP,.)&L?LF8&FA85E 4J% 1&:C6E)^<#=A$: ? M8 K -8$[H&E^>D=S:A,@`A] 5 $ND'3_9$4Q<0?1!:!.03"Q'\**XO\S\7:0 M7<$O<$UA*! BXQ/ 7P0@>><%L&NP`P!Z7F1D?P(@.-(@`2_@(7 =@2 @0_10 M54\`>6%@!Y$FT8>'_T\9'-%;H 01!&"!XA? ']'_=8-7D6&0.[ D<4\"BZ $ M$?TA,&T](X)#'W%%\V2T>9#^1#?D% PTP-2)\$=`6@#`)W"WSBQ0+!@PTARGQ4B($ I$?^=LDJ0 MH"EY$#FABZ"(00-0?YLQ)M)A<3A!)V$FX 408N\&X " )'!P/U(EX)V1`B!G M;G 6847"0 `(,&#^5[C_$+L!'@`]``$````!`````````(V1 ` end ------------------------------ From: "Brian K. Martin" Date: Wed, 13 Mar 1996 13:38:57 -0500 (EST) Subject: Re: Map Conversion Utility, Anyone? I think a doom map converter will be out as soon as some one releases a utility which calculates the BSP tree for quake. Isn't that what most of you are waiting for? brian ------------------------------ From: Bernd Kreimeier Date: Wed, 13 Mar 1996 19:43:40 +0100 (MET) Subject: Re: Map Conversion Utility, Anyone? >I confess I'm not an expert in the theory behind >the parallelization of algorithms such as BSP tree generation, so I don't >know how practical this is Creation of a BSP is a problem of making decisions (read: selecting the right toplevel splits). This allows for brute force parallelization. Heuristics or branch'n'bound are still exploring search trees - you might try out alternatives in parallel. I do not know about any BSP specific parallelization. Anybody? Remebering the quoted John Carmack explanations, "qbsp" will not be the problem anyway, nor will the radiosity-style "light". According to this posting, the "vis"ibility list calculation is CPU intensive despite being fully parallel. Without looking into the details my guess is that parallelization of this is not difficult (more or less optimal distribution of source nodes on target processors), as long as each CPU gets a full copy of the map data - any other node might be a possible destination for LineOfSight and visibility checks. On the other suggestions: - - to my experience, a decent editor is 90% GUI in terms of development effort. The WAD/PACK details do not matter in this regard. Come to think of it, it is simply the same problem any decent 3D modeler faces. Start thinking "plug-ins" instead of node builder etc. :-). - - conversion of DOOM levels requires tools that depend on WAD/PACK details - as those, in turn, depend on the algorithms used. Read: id stating the files will change means the algorithms will change. Thus the "qbsp"/"light"/"vis" tools will change. While conversion is surely a step to go, I doubt it is a good intermediate. You will probably neither see those in 2-3 weeks, nor is the code likely be more reusable than any editor's. Of course, simplified conversion (no lighting, dummy visibility lists) are entirely possible. - - a much more valuable intermediate might be working on VRML, DXF or 3DS conversion, which would allow for both display (utilizing VRML browsers, POVRAY) and map editing (commercial modeling software). - - note that we do NOT have any map representation in the PACK/WAD/BSP. It includes pre-processed lookups, but not the Constructive Solid Geometry scene description. DOOM-speak: SSEGS, but no LINEDEFS. We have to make up this up (e.g. by taking the Geometric Workbench from Mantyla). Of course, converting DOOM files has the advantage that there is a generally accepted (albeit restricted) map representation, and working editors. Thus you have a point. >From: "Brian K. Martin" >I think a doom map converter will be out as soon as some one >releases a utility which calculates the BSP tree for quake. >Isn't that what most of you are waiting for? Indeed :-). b. ------------------------------ From: Jim Bucher Date: Wed, 13 Mar 1996 13:17:25 -0600 Subject: Re: .MDL animations Brian K. Martin wrote: > The data in the frame header defines the bounding block around > the object. My guess is that the animation frame sequence is stored > in the progs.dat file somewhere. Could you post the format of the header? > p.s. MDL (MedDLe) is up to version 1.0 and now has 3d texture mapped > graphics and stuff.. http://www.phyast.pitt.edu/~brian/mdlv10.zip I just checked it out. Pretty cool. My viewer also does 3D texture mapping, and can cycle through the frames. I'll probably upload it to ftp.cdrom.com in a couple of days. It will be called QMV05.ZIP. First I am going to have some friends test it out. ------------------------------ From: "Brian K. Martin" Date: Wed, 13 Mar 1996 16:32:13 -0500 (EST) Subject: Re: .MDL animations > > > > Brian K. Martin wrote: > > > The data in the frame header defines the bounding block around > > the object. My guess is that the animation frame sequence is stored > > in the progs.dat file somewhere. > Could you post the format of the header? > first 4 bytes are 0. The next three are the lower limits, then a mystery byte, the next three are the upper limits, then a mystery byte. The x, y, z floats for each limit is found in the same way you find the vertices (see quake specs). In MedDLe, in 3d mode, hit 'h' and you will see the bounding box, then cycle through the frames. ------------------------------ From: Bernd Kreimeier Date: Wed, 13 Mar 1996 23:01:50 +0100 (MET) Subject: Forward: Intermediate file format Forwarded to this mailing list..... From: madsdyd@jarnsaxa.diku.dk (Mads Dydensborg) Newsgroups: rec.games.computer.quake.editing Subject: Intermidiate File format nessecary?? Date: 11 Mar 1996 17:49:16 GMT HI all. After reading the Unofficial Quake Specs, (Thanks to Olivier Montanuy and cowriters), I'm left with the impression, that a BSP file, may not be the best format to work with, during the *design* of a new level : When creating the BSP file, surfaces may be split, new vertices and edges created, etc. Oppisite to DOOM, where the SSEGS etc, where additional information. Is this a correct understanding? If yes, would it serve all purposes to agree on a format for exchanging files under development? In this way, (if possible), a format for editing could include ways to name mip-textures, etc. etc., and thereby maybe even reduce the size of Quake add on levels : Collections of textures could be distributed, and semicompiled levels could be distributed and compiled by each user into BSP maps, from a tool designed for this. Am I completly off track here? Probably.. :-) Mads - -- +---------------------------------------------------------------------+ | Mads Bondo Dydensborg. Student at DIKU, Copenhagen - Denmark. | | Email: madsdyd@diku.dk www: http://www.diku.dk/students/madsdyd | +---------------------------------------------------------------------+ ------------------------------ From: Bernd Kreimeier Date: Wed, 13 Mar 1996 23:11:43 +0100 (MET) Subject: Re: Forward: Intermediate file format Forward of my reply.... From: bernd@NeRo.Uni-Bonn.DE (Bernd Kreimeier) Newsgroups: rec.games.computer.quake.editing Subject: Re: Intermidiate File format nessecary?? Date: 13 Mar 1996 12:45:14 GMT In article madsdyd@jarnsaxa.diku.dk (Mads Dydensborg) writes: > From: madsdyd@jarnsaxa.diku.dk (Mads Dydensborg) > > After reading the Unofficial Quake Specs, (Thanks to Olivier Montanuy and > cowriters), I'm left with the impression, that a BSP file, may not be the > best format to work with, during the *design* of a new level : When > creating the BSP file, surfaces may be split, new vertices and edges created, > etc. Oppisite to DOOM, where the SSEGS etc, where additional information. > > Is this a correct understanding? Yep. While the details of the BSP lookups will probably change significantly until the final release of the shareware version, this particular detail might not. It comes to my mind that distributing the preprocessed lookup information (equivalent to SSEGS) while not using an level editing information (equivalent to LINEDEFS) will make creating derivative works and modification of both proprietary and free maps more difficult. Which might or might not be done intentionally. > If yes, would it serve all purposes to agree on a format for exchanging > files under development? In this way, (if possible), a format for > editing could include ways to name mip-textures, etc. etc., and thereby maybe > even reduce the size of Quake add on levels : Collections of textures > could be distributed, and semicompiled levels could be distributed and > compiled by each user into BSP maps, from a tool designed for this. Indeed. There are a lot of related issues (reference resource databases and management of contribution repositories, the need of a CSG description of a level for editing purposes, conversion issues of old resource files aka WADs), and the fact that it will be futile to develop anything sophisticated with only qtest1 in mind. Still any good proposal is virtually worthless without a portable and commonly accepted reference library supporting I/O based on any such non-id file format. It will take some time. And most people will ignore even a decently supported solution, solely because it is not used by id. > Am I completly off track here? Probably.. :-) I don't think so. Good point indeed. You might find some further discussion of this on the Quake Developers mailing list (majordomo@nvg.unit.no, send mail w/o Subject:, body: info quake-editing) soon. b. - --------------------------------------------------------------------------- "Problem solving is hunting. It is savage pleasure, and we are born to it." - --------------------------------------------------------------------------- ------------------------------ End of quake-editing-digest V1 #8 ********************************* From owner-quake-editing@nvg.unit.no Fri Mar 15 02:31 MET 1996 Received: from sabre-wulf.nvg.unit.no (bin@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id CAA29059 for ; Fri, 15 Mar 1996 02:31:49 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id CAA04042 for quake-editing-digest-outgoing; Fri, 15 Mar 1996 02:25:10 +0100 Date: Fri, 15 Mar 1996 02:25:10 +0100 Message-Id: <199603150125.CAA04042@sabre-wulf.nvg.unit.no> From: owner-quake-editing-digest@nvg.unit.no To: quake-editing-digest@nvg.unit.no Subject: quake-editing-digest V1 #9 Reply-To: quake-editing@nvg.unit.no Errors-To: owner-quake-editing-digest@nvg.unit.no Precedence: bulk Content-Type: text Content-Length: 8521 X-Lines: 217 Status: RO quake-editing-digest Friday, 15 March 1996 Volume 01 : Number 009 The Gimp! Map Conversion Utility, Anyone? One more file format suggestion Re: One more file format suggestion ---------------------------------------------------------------------- From: Bernd Kreimeier Date: Thu, 14 Mar 1996 10:54:14 +0100 (MET) Subject: The Gimp! In a flash of shallow inspiration, I wrote > Start thinking "plug-ins" instead of node builder etc. :-). Now here's your daily pointer: http://www.xcf.berkeley.edu/~gimp/gimp.html or use the image-intensive index page of this image conversion, manipulation, and paint tool. I recommend this to anybody who is thinking of some kinf of Quake Construction/Developers Kit for Linux, be it for free distribution or private use. >From a programmer's point of view, I am particularly interested in the external module (plug-in) interface. If you think of creating an editor or a frontend for tools, you should take a close look at this. I will! b. P.S.: Peter Mattis, one of the authors, wrote one of the DOOM-style rendering engines out there. See http://www.csua.berkeley.edu/~petm/final.html - ------------------------------------------------------------------- "Bring out the Gimp." "The Gimp's sleepin'!" "Guess you just have to go wake 'im up now won't you?" - ------------------------------------------------------------------- ------------------------------ From: Tom Wheeley Date: Wed, 13 Mar 96 19:14:16 GMT Subject: Map Conversion Utility, Anyone? In article <01BB10C5.66E97C00@descent.interplay.com> you write: > In perusing the postings here, I've seen some discussions of homebrew Quake > editors. If it hasn't been already, I'd like to suggest that a map > conversion utility, which would convert existing DOOM maps to work with the > Quake Deathmatch Test engine, might be a good first project rather than a > full blown editor. My reasoning is as follows: > > We all know that the Quake data file formats are in a state of flux, so a > full-blown editor would likely represent at least a not insignificant > amount of wasted effort because the end result would not work with the > next release of Quake. True, much of the investment in coding will be > reusable with little or no changes in the "Quake Final" editors. However, > the same is true for the routines developed for the conversion utility. Not really. The only bits which are likely to change are 90% of the conv. utility -- as it is the file formats and BSP generation which are most likely to change. Quake will still be a 3D game, needing a 3D editor. BTW, from the Quake specs it seems that the nodes etc of the BSP file are reasonably well understood (well, documented, anyway..) So, how far has anyone got with writing a `node builder'? > Reaction? Comments? I think that such a tool, although encouraging levels which do not make use of the Quake engine, would be very popular and useful. (You could do a template in a Doom editor, then change it later in a beta Quake editor) > begin 600 WINMAIL.DAT > M>)\^(@H2`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$-@ 0` wtf?! .splitbung - -- * TQ 1.0 * 101 Slogans for Quake 61. Quake: To Boldly Go Where No Hammer Has Gone Before ------------------------------ From: Lauri Alanko Date: Thu, 14 Mar 1996 17:23:03 +0200 (EET) Subject: One more file format suggestion Hello! As there has been talk about a file format suitable for distributing levels etc., here are some of my thoughts about this. The general problem seems to be that there are many different pieces of data that can be modified, but there are only a few forms in which Quake will read this data. Therefore a system is needed which converts editable and distributable pieces of data into Quake-readable pieces of data. It is my thought that there is no reason to limit this system merely to maps and textures. Couldn't there be a general resource location system which allows the "statical linking" of almost anything that people are likely to modify? So, basically, when someone distributes an add-on, be it a level, a model texture or whatever, it should contain information about: 1. What should be created from these add-ons (eg. a .bsp level file) 2. What else is required to create them (eg. textures, entities) In addition, the end-user should supply information about: 3. Where the required "libraries" are located (eg. a .pak file) 4. How all the things are joined to create the final product (eg. qube 2.0) The end-user should have a reference table where the "linker" can find the locations of the pieces of data needed to create the final product. This would be a text file, easily editable. Something along these lines... texture water { //Grab the texture straight from the .pak file pak id1.pak bspfile maps/test2.bsp //This is looked up in the packfile now. bspentry 02 //This would probably be the default anyway... mipname *04mwat2 } texture water { //The mipmap is composed from bitmaps mip1 maps/textures/_04mwat2.bmp //in the linking process. Slow but mip2 maps/textures/_04mwat2.bm2 //handy if one is editing the texture mip4 maps/textures/_04mwat2.bm4 //all the time. mip8 maps/textures/_04mwat2.bm8 } texture water { //This would maybe be the most common way bspfile maps/test2.bsp //to do it, grab the texture from a level. mipname *04mwat2 } Then when the new level is distributed (probably in some format that includes all the visilist calculations), there is a header or something which tells to use the symbolic texture name "water" in certain areas. When the final map is "linked", the end result will be a level where water looks like whatever the _end user_ has customized it to look like. This kind of "resource locating" could be used for anything else. A level could contain a symbolic entity "ogre", which defaults to progs/ogre.mdl, but could be redefined by the end user to contrib/progs/bgates.mdl. Or someone might just distribute an entity list and tell in the header which map it is for. A system this flexible would have advantages. Given proper configuration, it should be possible to create a new 2 meg level from a 50k distribution file with a single command. Also, the end user could (but wouldn't have to) change the outlook of the distributed level by simply changing some definitions and relinking. No need for Qeutex. Okay, there are disadvantages, too. The linking process could take a lot of time. If all the end user's textures are in .bmp files it may take a while to create proper .bsp entries from them. But the end user _could_ have everything neatly "precompiled" in a .pak file, in which case it shouldn't take too long just to copy the necessary entries and add a few from the distribution. In any case the end user could have his files in whatever format he prefers. This would require a very sophisticated "linker" program, which would read the end user's reference table and invoke the proper tools to change pieces of data from one format to another (eg. a model texture and a full model into another model where the texture has been replaced). And finally, any of this will be damn near useless until the file formats that Quake will support have been confirmed. So my idea is a system where every conceivable piece of data could be identified and automatically put in the right place to compose the final product. Silly me. Comments? How much of this would be conceivable? Lauri Alanko ------------------------------ From: "Brian K. Martin" Date: Thu, 14 Mar 1996 13:01:12 -0500 (EST) Subject: Re: One more file format suggestion I think this talk may not be very useful at this exact moment. I'm not trying to sound like a smart ass, but I would guess that id will prolly have some type of load commands on the consol which allow one to add different maps while still using the standard textures. I hope they don't continue to have the maps and textures together. If they do, then we will surely need to think of something. (several good ideas so far though). brian ------------------------------ End of quake-editing-digest V1 #9 ********************************* From owner-quake-editing@nvg.unit.no Sat Mar 16 02:35 MET 1996 Received: from sabre-wulf.nvg.unit.no (bin@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id CAA01600 for ; Sat, 16 Mar 1996 02:35:07 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id CAA10689 for quake-editing-digest-outgoing; Sat, 16 Mar 1996 02:28:32 +0100 Date: Sat, 16 Mar 1996 02:28:32 +0100 Message-Id: <199603160128.CAA10689@sabre-wulf.nvg.unit.no> From: owner-quake-editing-digest@nvg.unit.no To: quake-editing-digest@nvg.unit.no Subject: quake-editing-digest V1 #10 Reply-To: quake-editing@nvg.unit.no Errors-To: owner-quake-editing-digest@nvg.unit.no Precedence: bulk Content-Type: text Content-Length: 2409 X-Lines: 71 Status: RO quake-editing-digest Saturday, 16 March 1996 Volume 01 : Number 010 Re: Map Conversion Utility, Anyone? One more file format suggestion ---------------------------------------------------------------------- From: Scott Coleman Date: Fri, 15 Mar 1996 09:52:37 -0800 Subject: Re: Map Conversion Utility, Anyone? At 07:14 PM 3/13/96 GMT, you wrote: >> begin 600 WINMAIL.DAT >> M>)\^(@H2`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$-@ 0` > >wtf?! WTF, indeed. Off-topic, I know, but I beg your indulgence since the question was asked: Microsoft Exchange, the POP mail client which comes bundled with Windows 95, has an extremely annoying habit of attaching UUEncoded files to outgoing email WITHOUT TELLING THE USER THAT IT IS DOING SO. I only mention it here because you all saw it and might be curious. You'll notice I'm now using Eudora Light. ;-) My apologies for the inadvertent addition and this off-topic explanation. - --- Scott Coleman, President American Society of Reverse Engineers asre@ni.net ------------------------------ From: Tom Wheeley Date: Fri, 15 Mar 96 23:23:45 GMT Subject: One more file format suggestion In article <199603141801.NAA04253@minerva.phyast.pitt.edu> you write: > > I think this talk may not be very useful at this exact moment. > I'm not trying to sound like a smart ass, but I would guess > that id will prolly have some type of load commands on the consol > which allow one to add different maps while still using the standard > textures. I hope they don't continue to have the maps and textures > together. If they do, then we will surely need to think of something. > (several good ideas so far though). Well, I don't know if anyone has tried my TLM hack (beta, only available in a.b.g.q), but it runs so fast as to be transparent to the user, and reduces the distributable by a factor of approx 2. This will be greatly improved in the next version (still a hack, until we agree on a nice file format), as I think every map so far is just a modified thing list. BTW, does anyone else think that PHIL.BSP has a strange filesize, being an odd number and all? .splitbung - -- * TQ 1.0 * 101 uses for dead bodies in Quake 84) Throw their Heads into other players faces to temporarily blind them. ------------------------------ End of quake-editing-digest V1 #10 ********************************** From owner-quake-editing@nvg.unit.no Sun Mar 17 02:29 MET 1996 Received: from sabre-wulf.nvg.unit.no (bin@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id CAA02316 for ; Sun, 17 Mar 1996 02:29:04 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id CAA00933 for quake-editing-digest-outgoing; Sun, 17 Mar 1996 02:22:40 +0100 Date: Sun, 17 Mar 1996 02:22:40 +0100 Message-Id: <199603170122.CAA00933@sabre-wulf.nvg.unit.no> From: owner-quake-editing-digest@nvg.unit.no To: quake-editing-digest@nvg.unit.no Subject: quake-editing-digest V1 #11 Reply-To: quake-editing@nvg.unit.no Errors-To: owner-quake-editing-digest@nvg.unit.no Precedence: bulk Content-Type: text Content-Length: 1328 X-Lines: 45 Status: RO quake-editing-digest Sunday, 17 March 1996 Volume 01 : Number 011 WAD Conversion sketch ---------------------------------------------------------------------- From: Bernd Kreimeier Date: Sat, 16 Mar 1996 21:59:26 +0100 (MET) Subject: WAD Conversion sketch I thought again about the recent discussion of the possibility of a WAD conversion, and I recognized that I forgot one important detail. IMO the 2D BSP and a REJECT lump w/o special effects contains all information necessary to create a valid Quake BSP. We do not need a new BSP/REJECT builder for conversion. Any such converted map will still have only one floor and ceiling per z coordinate, or BSP and REJECT would not be sufficient for conversion. Nonetheless, the advantages seem to be worth the effort. I refrained from posting a lengthy but still sketchy proposal to the list. If you are interested, you will find a pointer on the Quake Developers Support page, at http://www.nero.uni-bonn.de/~dn/q-sup/ I have a deadline on easter weekend, and will probably not do much on this until then. If somebody is already working on this, please let me know. b. ------------------------------ End of quake-editing-digest V1 #11 ********************************** From owner-quake-editing@nvg.unit.no Tue Mar 19 02:29 MET 1996 Received: from sabre-wulf.nvg.unit.no (bin@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id CAA12444 for ; Tue, 19 Mar 1996 02:29:35 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id CAA28879 for quake-editing-digest-outgoing; Tue, 19 Mar 1996 02:23:11 +0100 Date: Tue, 19 Mar 1996 02:23:11 +0100 Message-Id: <199603190123.CAA28879@sabre-wulf.nvg.unit.no> From: owner-quake-editing-digest@nvg.unit.no To: quake-editing-digest@nvg.unit.no Subject: quake-editing-digest V1 #12 Reply-To: quake-editing@nvg.unit.no Errors-To: owner-quake-editing-digest@nvg.unit.no Precedence: bulk Content-Type: text Content-Length: 26709 X-Lines: 677 Status: RO quake-editing-digest Tuesday, 19 March 1996 Volume 01 : Number 012 Rendering Quake surfaces Re: WAD Conversion sketch Re: WAD Conversion sketch Re: WAD conversion sketch Re: WAD Conversion sketch Re: WAD conversion sketch Legal stuff (was Re: WAD conversion sketch) Visibility Lists Re: Visibility Lists Legal issues (was: WAD conversion sketch) Re: Legal stuff (was Re: WAD conversion sketch) Re: Legal stuff (was Re: WAD conversion sketch) Re: WAD Conversion sketch ---------------------------------------------------------------------- From: etherton@netcom.com (David Etherton) Date: Sun, 17 Mar 1996 20:47:17 -0800 Subject: Rendering Quake surfaces [Please forgive me if this is asked a lot, I can't get through to the mail archives on http://www.nero.uni-bonn.de/~dn/qd/qd_welcome.html right now] Like just about everybody else around here, I've been playing around with trying to render the Quake levels. The Quake specs (3.0) have proved invaluable. First, in the List of Edges, if the sign bit of the edge is set, are we supposed to look at edge ~i or -i? (Nodes use ~i to mark leaves according to both the spec and my own experience). For the List of Edges, though, neither ~i nor -i seem to work particularly well, although -i seems to work slightly better. I can traverse the BSP tree and find the leaf containing my camera position correctly, so I know I've got the basics right. However, when I try to render, I find that the list of surfaces often tells me to (say) render surface 7 three times in a row, and that it's got 30 edges in the surface. Surfaces with small numbers of edges seem to "connect" together well (ie the end vertex of one edge is the start vertex of the next, and it forms a closed figure). Some surfaces with larger numbers of edges seem to form closed figures if you sort the edges after reading them in, but surfaces with 16 or more edges seem to not form closed figures. I can't imagine a fast renderer wanting to deal with anything larger than a tri or a quad, so I'm suspicious of anything with more than four edges. Combined with my experience with surfaces with large numbers of edges having nonsensical edge lists, I wonder if we're supposed to interpret the edge count differently if it's above a certain value. Also, why would the list of surfaces explicitly tell me to render the same surface two or three times in a row? I haven't done an exhaustive check, but it appears that every time a surface is supposed to render several times in a row, it usually also has a large number of edges. Am I totally off in the weeds here or is anybody else fighting the same things I am? - -David Etherton ps. For what it's worth, I have been able to parse and render the models perfectly; either a Z-buffer or a bucket Z-sort seems to produce good results; the latter has some slight defects (ever seen a PlayStation?) but is *much* faster on both my PC and my SparcStation ------------------------------ From: Uffe Friis Lichtenberg Date: Mon, 18 Mar 1996 11:47:35 +0100 (MET) Subject: Re: WAD Conversion sketch On Sat, 16 Mar 1996, Bernd Kreimeier wrote: > I thought again about the recent discussion of the > possibility of a WAD conversion, and I recognized that > I forgot one important detail. IMO the 2D BSP and a > REJECT lump w/o special effects contains all information > necessary to create a valid Quake BSP. > > We do not need a new BSP/REJECT builder for conversion. Well, I tend to disagree. You do need additional information, as you say in your 'WAD conversions sketch', like plane-bundling (trivial), vertices (trivial), hull generation (not so trivial?), etc. But firstly you do need a 3D BSP tree: remember all the floors and ceilings are planes in Quake, and must thus partition the rest of the polygons in some way. This could lead to a number of problems if not handled right. My guess is that wad conversion would be easiest to implement if you had two utilities: one to convert a wad to an intermediate file format (perhaps the same used to distribute Quake levels) specifying polygons (with textures) and entities, and another tool to build a valid .BSP from this file format (ie. a 3D BSP generator, as well as texture reference resolving and so on.) Having it split up into two utilities would also make .DXF -> intermediate file format, .3DS -> intermediate file format, etc. a lot easier to manage, as we would be able to use all sorts of excellent 3D editors already available to edit Quake levels, and let the second utility to all the hard work afterwards. But of course, it wouldn't be trivial to create a utility that builds an efficient BSP tree. But it wouldn't be any more difficult than doing it in 2D was. > Any such converted map will still have only one floor > and ceiling per z coordinate, or BSP and REJECT would not > be sufficient for conversion. Nonetheless, the advantages > seem to be worth the effort. But where do you find wads that fulfil this requirement? I can't think of a single one. (If I understand you right.) > I refrained from posting a lengthy but still sketchy > proposal to the list. If you are interested, you will > find a pointer on the Quake Developers Support page, > at > > http://www.nero.uni-bonn.de/~dn/q-sup/ Regarding the legal issues: Maybe iD's licence doesn't explicitly forbid the creation/distribution of add-on levels for Quake, but personally I feel that we should respect iD's work and not bring out any fully-fledged editor before the registered version becomes available. But perhaps I'm alone in this? Zonk, Uffe. [uphfe] uffefl@diku.dk ------------------------------ From: "Brian K. Martin" Date: Mon, 18 Mar 1996 07:53:25 -0500 (EST) Subject: Re: WAD Conversion sketch > > On Sat, 16 Mar 1996, Bernd Kreimeier wrote: > > Regarding the legal issues: > > Maybe iD's licence doesn't explicitly forbid the creation/distribution of > add-on levels for Quake, but personally I feel that we should respect > iD's work and not bring out any fully-fledged editor before the > registered version becomes available. But perhaps I'm alone in this? > I agree. I was upset to see complete levels and mdl files uploaded to ftp and net sites. I think the level/model editors should not work with the shareware release, unless id gives an ok. I will most likely hold back the next version of meddle because of this. brian ------------------------------ From: Bernd Kreimeier Date: Mon, 18 Mar 1996 14:23:42 +0100 (MET) Subject: Re: WAD conversion sketch I try to separate the legal issues thread from the more technical aspects. It is a futile discussion anyway. There is only one way to resolve this, namely a request from id Software. You might want to ask them. > Legal issues: not bring out any useful tools prior to > registered release. This is a slightly difficult issue. I have no intention to end discussion of such topics, which is a far cry from a public production release of anything. After all, we might as well shutdown this list for a few months if we all agree to wait for registered Quake. > tools should not work with shareware release In this case we could as well abandon any discussion of distribution file formats, and DMADDS/DeuSF-style or pack/unpack tools source distribution. It has always been possible to create a replacement IWAD because id decided to distribute the same EXE as shareware, registered, and commercial. The qtest1 seems to indicate that this will not change, which is a bad thing. b. ------------------------------ From: Bernd Kreimeier Date: Mon, 18 Mar 1996 14:35:18 +0100 (MET) Subject: Re: WAD Conversion sketch >From: Uffe Friis Lichtenberg >additional info need, namely convex hulls Has anybody verified that a Slab BSP tree is needed, or might it be easily omitted with a zero length entry? If there is only one Slab, does it have to be a convex hull, or is a bounding box sufficient? >we do need a 3D BSP tree If I am not mistaken, you could simply copy the 2D BSP into a matching 3D BSP, and convert the information from the old NODES and SSECTORS. Think about it. >the floors and ceilings are planes and have to be partitioned You are perfectly right. In fact, this might be the most difficult task to solve. It breaks down to creating closed polygons from SECTORS and LINEDEFS for each floor (ceilings will have the same partitions), and using the 2D BSP NODES info (namely the partition lines) to split the SECTORS' polygon into the Leaf2D surfaces. I already added this to the proposal. >misc. remarks on conversion, DXF, intermediate file formats All very true. However, I am skeptical that any file format not done by id will ever be agreed upon. Anybody remember the porposal by Tom Neff (WAD Interchange Format)? >>The WAD will have to have only one floor/ceiling per xy plane, >>i.e. the DOOM world geometry restrictions >But where do you find wads that fulfil this requirement? Hmmm? Any WAD that can be used with DOOM does :-). b. ------------------------------ From: Bernd Kreimeier Date: Mon, 18 Mar 1996 15:03:43 +0100 (MET) Subject: Re: WAD conversion sketch I updated the proposal at http://www.nero.uni-bonn.de/~dn/q-sup/ and added some details I omitted in the first draft. It is still sketchy. Here are some important aspects: A modified DOOM BSP Node builder might be a better solution, instead of a completely separate conversion tool. I would appreciate any comment from those on the list who have actually written such a tool. Automatic conversion and DOOM map recycling is no worthwhile reason to create such a tool. Texture, door, switch issues will make any such attempt futile. Any given WAD map will not be playable, and look worse. What's the point of DOOM restricted geometry in Quake anyway? The DOOM WAD file format provides a commonly accepted intermediate file format. We could start there, and might even agree on how it should be extended. Any DOOM map editor could be modified along with a qbsp/BSP_3D Node builder to take into account different texture handling, different entities. This is a migration path. Put quite simply: if there were a 3D editor, full specs, and a working node builder guaranteed, I wouldn't waste a single thought. Right now, this project is quite educational in several regards. b. ------------------------------ From: Raphael.Quinet@eed.ericsson.se Date: Mon, 18 Mar 1996 15:32:56 +0100 (MET) Subject: Legal stuff (was Re: WAD conversion sketch) On Mon, 18 Mar 1996, Bernd Kreimeier wrote: > I try to separate the legal issues thread from the more > technical aspects. [...] I changed the subject, so that it is more obvious... > > tools should not work with shareware release > > In this case we could as well abandon any discussion > of distribution file formats, and DMADDS/DeuSF-style > or pack/unpack tools source distribution. As long as the full-featured editors do not allow you to edit the shareware game, it should be OK. The current tools are far from being "full-featured". I don't think that small tools would really harm id Software, if they work with the shareware game. Besides, it would be too much trouble for some of these small tools to check if the user has the registered game. Here is what I am planning to do for QEU: I will probably split the code in three parts. There will be the GUI library (SWAPI), the routines for handling Quake files as well as the files for other games such as Doom (I will probably call this part "GEL", for "Game Editing Library") and the programs themselves: the editor and the tools that are currently in QEU 0.3. The first two parts (SWAPI and GEL) will work with the shareware version of the game. The GUI library is independent of the game and I am planning to use it for other programs, so it is normal that it doesn't check for a registered version of anything. The Game Editing Library (or whatever it is called - suggestions are welcome) will also work with the shareware game(s) because it contains mostly low-level functions for loading and saving file related to various games. These routines don't know much about the high-level structures or the contents of the PACK file and they should be independant of the version of the game being loaded or saved. The editor will check for the registered version, because this is the only part of the code which will know the meaning of the various parts of the PACK file (or BSP files). Thus it will be able to check if the PACK file contains some entries that are only available in the registered game. By the way, I intend to release the first two parts (SWAPI and GEL) under a non-restrictive license so that anyone can copy, modify or distribute this code. The editor and tools will also be free and the source code will be available, but I will restrict commercial distribution and encourage people to contribute to the main code instead of distributing modified versions. > It has always > been possible to create a replacement IWAD because id > decided to distribute the same EXE as shareware, > registered, and commercial. The qtest1 seems to indicate > that this will not change, which is a bad thing. 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. If all editors are fair (towards id Software) and refuse to work with the shareware version, I think this will be enough. Some of them will be distributed as source code (such as QEU for Quake or DEU for Doom), so it would theoretically be possible for someone to patch them so that they work with the shareware game. However, someone who takes the time to go through the whole source code and track the various tests that have been scattered in the code by the author of the program would probably find it easier to get a pirate copy of the game, so I don't think this is a real problem. Of course, I assume that the authors of the editors include more than one test which checks if the user has a registered version of the game. - -Raphael ------------------------------ From: etherton@megatek.com (David Etherton) Date: Mon, 18 Mar 1996 09:11:28 +0800 Subject: Visibility Lists When trying to determine which leaves are visible from a current leaf, one looks at the vislist memory of the leaf data structure. However, it's not clear to me which of the following two formulas is correct: int i; // leaf number to check u_char *vp = start_of_vislist + leaf->vislist if (vp[i>>3] & (1<<(i&7))) { puts("is visibile"); } - - or - if (vp[i>>3] & (128>>(i&7))) { puts("is visibile"); } My renderer isn't far enough along that I can readily tell; the obvious solution would be to play with the bits and run it through quake itself, but id didn't distribute a Sparc version of quake yet :(. My guess is that the first formula is correct, but I suspect there's something weird with the visibility lists because I had assumed (hoped) that for any leaf i, its own visibility bit is set in its visbility list. This would seem to make sense to me because (barring special effects), two adjacent leaves may very well have the exact same visibility lists, so they could share the list. Unfortunately, while test1.bsp and test2.bsp both have starting positions in leaves that can "see" themselves, test3.bsp does not. Any comments? Obviously my own implementation could be at fault and I'm wondering if anybody else is having similar problems. On another topic [as a bonus if you've actually read this far :)], I've found that augmenting the node structures with backpointers to their parents (after reading in the map) might prove useful for optimizing rendering. In order to render from a specific position, I'm doing the following: - Traverse the bsp tree to find which leaf the camera is in, caching the result so that I can do a quick bbox check the next time to see if I'm in the same leaf. - See if the current leaf has the same visibility list (ie offset) as our cached result. - If it does not, scan the visibility list, and for each leaf which is visible, mark the leaf as needing to be rendered, then mark its parent node as needing to be visited, and then mark *that* parent's node, and so on, until we either hit the root of the tree or hit a node that's already marked for visitation. - Start traversing the tree at the top. - If neither child node needs to be visited, stop. - If only one child node needs to be visited, only visit that child. - If both children need to be visited, then and only then test the camera position against the node's split plane to see which child needs to be visited first. We can also project the bounding box of a node or leaf into the view frustum to see if we can trivially reject the entire subtree (off the side, or behind the viewer) before visiting it as well. - -David Etherton ------------------------------ From: etherton@megatek.com (David Etherton) Date: Mon, 18 Mar 1996 09:46:28 -0800 (PST) Subject: Re: Visibility Lists Here's a data dump from test1.bsp: VISILIST SIZE 14039 494 total leaves, 1068 total nodes leaf 0: visoffs=0 {0 bits since last} leaf 1: visoffs=0 {0 bits since last} leaf 2: visoffs=29 {232 bits since last} leaf 3: visoffs=54 {200 bits since last} leaf 4: visoffs=76 {176 bits since last} leaf 5: visoffs=102 {208 bits since last} leaf 6: visoffs=125 {184 bits since last} leaf 7: visoffs=148 {184 bits since last} leaf 8: visoffs=171 {184 bits since last} leaf 9: visoffs=197 {208 bits since last} leaf 10: visoffs=223 {208 bits since last} leaf 11: visoffs=246 {184 bits since last} leaf 12: visoffs=272 {208 bits since last} leaf 13: visoffs=298 {208 bits since last} leaf 14: visoffs=321 {184 bits since last} leaf 15: visoffs=344 {184 bits since last} leaf 16: visoffs=370 {208 bits since last} leaf 17: visoffs=393 {184 bits since last} leaf 18: visoffs=416 {184 bits since last} leaf 19: visoffs=442 {208 bits since last} leaf 20: visoffs=468 {208 bits since last} leaf 21: visoffs=494 {208 bits since last} leaf 22: visoffs=520 {208 bits since last} .... I suspect there's something weird about the visibility lists. While all of the offsets are within the boundaries of the visibility list, and some of the lists do run off the end of the end of the lump, I find the fact that all of the visibility lists overlap is rather disturbing. I can't see how sharing the same bit pattern between multiple visibility lists could ever be useful. I suspect that there's an offset and length field that we don't know about yet which would allow us to say that all leaves not in a specified range are either visible or invisible; leaves within the specified range check the visibility bitmask. Also, several of the later leaves have a visibility offset of -1; does that mean no other leaves are visible from here or all other leaves are visible from here? - -David - -- David Etherton | Megatek Corporation | "Shop as usual, and avoid panic buying." ------------------------------ From: Uffe Friis Lichtenberg Date: Mon, 18 Mar 1996 19:17:14 +0100 (MET) Subject: Legal issues (was: WAD conversion sketch) On Mon, 18 Mar 1996, Bernd Kreimeier wrote: > You might want to ask them. I don't think there could be any other answer than 'no, please don't make editors available for anything other than the registered version', but of course I could be wrong. > > Legal issues: not bring out any useful tools prior to > > registered release. > > This is a slightly difficult issue. I have no intention > to end discussion of such topics, which is a far cry from a > public production release of anything. After all, we might > as well shutdown this list for a few months if we all > agree to wait for registered Quake. No no. There is IMO a BIG difference between discussing Quake hacking/editing and releasing small utils to demonstrate the concepts, and releasing fully-fledged software to modify Quake with (ie. hacking tools vs. end-user products.) I can't see any harm in the discussion or release of viewers/small editors/file format converters/etc. as long as they are not "marketed" as Quake-editors. BTW: until a Quake non-test version comes out this is all we have to play around with anyway, so there's no need trying to stop us now :) > > tools should not work with shareware release > > In this case we could as well abandon any discussion > of distribution file formats, and DMADDS/DeuSF-style > or pack/unpack tools source distribution. Well, it's a bit hard to speculate on that until the shareware finally hits the net. Zonk, Uffe. [uphfe] uffefl@diku.dk ------------------------------ From: Uffe Friis Lichtenberg Date: Mon, 18 Mar 1996 19:29:55 +0100 (MET) Subject: Re: Legal stuff (was Re: WAD conversion sketch) On Mon, 18 Mar 1996 Raphael.Quinet@eed.ericsson.se wrote: > As long as the full-featured editors do not allow you to edit the > shareware game, it should be OK. The current tools are far from being > "full-featured". Agreed. > I don't think that small tools would really harm id > Software, if they work with the shareware game. Dunno about that. Perhaps a message in these small tools that simply states "Will Not Work With The Shareware" (or something similar) would be sufficient, even though they might actually work? > The editor will check for the registered version, because this is the > only part of the code which will know the meaning of the various parts > of the PACK file (or BSP files). Thus it will be able to check if the > PACK file contains some entries that are only available in the > registered game. This is of course assuming that iD will choose a strategy similar to Doom with the registered contra shareware versions. > 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. I don't think it would be difficult for iD to do separate compiles (perhaps with a -DSHAREWARE for the shareware version) that actually makes two very different exes. But the discussion is futile anyway: pirates will circumvent anything iD can throw at them, so iD are probably better off directing their energy towards the game engine. > Of course, I assume > that the authors of the editors include more than one test which > checks if the user has a registered version of the game. Can't see the problem here. If there is just a single test the author of the editor can't take responsibility for modified versions of the editor. Again, pirates circumvent just about anything, and wasting time on copy-protection is useless. Just make the test so an ordinary user wouldn't be able to circumvent it. Zonk, Uffe. [uphfe] uffefl@diku.dk ------------------------------ From: "Michael G. Clawson" Date: Mon, 18 Mar 96 17:07:29 EST Subject: Re: Legal stuff (was Re: WAD conversion sketch) In reply to 18 Mar message from quake-editing@nvg.unit.no: >> It has always >> been possible to create a replacement IWAD because id >> decided to distribute the same EXE as shareware, >> registered, and commercial. The qtest1 seems to indicate >> that this will not change, which is a bad thing. >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.). Allow me to add to that: It may or may not be the best way of doing business, but I would hardly call giving people the benefit of the doubt by simply asking programmers to not make their tools work with the shareware version of doom a 'bad thing'. I rather admire that policy. It's refreshing. ------------------------------ From: Jimmy Sieben Date: Mon, 18 Mar 1996 16:31:07 -0600 (CST) Subject: Re: WAD Conversion sketch > On Sat, 16 Mar 1996, Bernd Kreimeier wrote: > > Regarding the legal issues: > > Maybe iD's licence doesn't explicitly forbid the creation/distribution of > add-on levels for Quake, but personally I feel that we should respect > iD's work and not bring out any fully-fledged editor before the > registered version becomes available. But perhaps I'm alone in this? I think editors should be released; the 3D design interface would need some extensive end-user testing. The file formats and graphics are changing, as stated by several id employees, so there is no risk of shareware compatibility there. I cannot see any reason not to release an editor, technical/programming issues aside. +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | _______ _ _ _____ IRC: EvlGenius | | |______ \ / | | Mail: l-sieben@memphis.edu | | |______ \/ __|__ |_____ | | ______ _______ __ _ _____ _ _ _______ DOOM Player, Programmer, | | | ____ |______ | \ | | | | |______ IRC hacker extraordinaire | | |_____| |______ | \_| __|__ |_____| ______| Bow down to The Genius | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ ------------------------------ End of quake-editing-digest V1 #12 ********************************** From owner-quake-editing@nvg.unit.no Wed Mar 20 02:29 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 CAA29350 for ; Wed, 20 Mar 1996 02:29:49 +0100 (MET) Received: from sabre-wulf.nvg.unit.no (bin@sabre-wulf.nvg.unit.no [129.241.161.9]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with SMTP id CAA19952; Wed, 20 Mar 1996 02:30:52 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id CAA17545 for quake-editing-digest-outgoing; Wed, 20 Mar 1996 02:22:15 +0100 Date: Wed, 20 Mar 1996 02:22:15 +0100 Message-Id: <199603200122.CAA17545@sabre-wulf.nvg.unit.no> From: owner-quake-editing-digest@nvg.unit.no To: quake-editing-digest@nvg.unit.no Subject: quake-editing-digest V1 #13 Reply-To: quake-editing@nvg.unit.no Errors-To: owner-quake-editing-digest@nvg.unit.no Precedence: bulk Content-Type: text Content-Length: 6205 X-Lines: 172 Status: RO quake-editing-digest Wednesday, 20 March 1996 Volume 01 : Number 013 One EXE for all? (was Re: Legal stuff) Howdy Dudey Time. [RANDOM TITLE] Re: Legal issues (was: WAD conversion sketch) WinTex 4.3 and Quake specs Re: Legal issues (was: WAD conversion sketch) ----