From owner-quake-dev-digest@gamers.org Mon Jun 3 20:08 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 UAA05084 for ; Mon, 3 Jun 1996 20:08:07 +0200 (MET DST) Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with ESMTP id TAA24439; Mon, 3 Jun 1996 19:49:55 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id NAA16581 for quake-dev-digest-outgoing; Mon, 3 Jun 1996 13:46:41 -0400 From: owner-quake-dev-digest@gamers.org Date: Mon, 3 Jun 1996 13:46:41 -0400 Message-Id: <199606031746.NAA16581@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #8 Reply-To: quake-dev@gamers.org Errors-To: owner-quake-dev-digest@gamers.org Precedence: bulk X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 34124 X-Lines: 882 Status: RO quake-dev-digest Monday, 3 June 1996 Volume 01 : Number 008 ---------------------------------------------------------------------- From: Bernd Kreimeier Date: Mon, 20 May 1996 18:43:31 +0200 (MET DST) Subject: Re: The GUI of Choice? Concluding summary (as far as I am concerned):

          | XToolkit |_Lang. | Builder | Mesa/GLUT | ---------------------------------------------------
Amulet    | own      | C++   | not yet |     ?     |
Fresco    | Xt, own  | C++   | ?       | possible  |
V         | Athena   | C++   | no      | possible  |
wxWindows | XView    | C++   | yes     | supported |

wxWindwos supports Mesa/OpenGl since mid of 1995, with GLX (Linux/SGI), and with NT. The author of V indicated he had not tried nor heard of any attempts, but it should work: "The vCanvas class provides methods to retrieve both Widget and Drawable handles for X, and HWNDs for Windows, which is what I understand is required by OpenGL." The same is likely to be true for Fresco. I have received no response whatsoever from the authors of Amulet. ... and the winner is ... In case anybody could care less: I will try wxWindows with Linux, as the GLX-based Mesa support is the most decisive issue. See QED :-). b. ------------------------------ From: Raphael.Quinet@eed.ericsson.se Date: Mon, 20 May 1996 19:07:41 +0200 (MET DST) Subject: Anybody still using Turbo C 3.0? Hi there! Here is an article that I just posted in the Doom/Quake editing newsgroups. It is barely on-topic for these lists, that's why I encourage you to post your replies to the newsgroups or to send them to me directly instead of sending them to the lists. If necessary, I will post a summary of the replies here. Here is my question: I made some progress on GAEL, my portable Doom/Quake editing library (which will be released as part of QEU 0.4), but some parts of the code get a bit messy if I still support Turbo C 3.0. Following the good tradition of DEU, I try to support as many operating systems and compilers as possible (DJGPP, Borland, Watcom under DOS and many other compilers under UNIX), but some workarounds for the bugs in the old Turbo C 3.0 make the code less readable and I would like to get rid of these kludges. Description of the most annoying bug: TC 3.0 cannot increment huge pointers with the "++" operator. Try writing a short program which declares a pointer as "char huge *p" and then print the value of p before and after "p++" and "p = p + 1" and you will see the difference! That was one of the most frustrating problems that I had when debugging some early versions of DEU two years ago. Because of that, I have to put some #ifdef's in my code, and this is not very pretty. For example: #ifdef __TURBOC__ *p = x; p = p + 1; #else *p++ = x; #endif When this is a single statement, that solution is still bearable, but it gets really annoying when the "++" is embedded in another statement or when there are several huge pointers involved in a loop. I would like to know if there are some people out there who are still using TC 3.0 for compiling C programs, or if I can assume that everybody has switched to a newer version of Borland C++ or to another compiler, such as DGJPP (which is very good, and free). If I don't have to support TC 3.0 anymore, I would be glad to get rid of these #ifdef's in the code. Note that I will still be supporting 16-bits DOS compilers as well as 32-bits compilers; it's only TC 3.0 which is a problem. - -Raphael - -- +---------------------------------------------------------------------------+ | WWW: http://www.montefiore.ulg.ac.be/~quinet | | E-mail: Raphael.Quinet@eed.ericsson.se or quinet@montefiore.ulg.ac.be | | S-mail: Raphael Quinet, 9 rue des Martyrs, 4550 Nandrin (Belgium) | +---------------------------------------------------------------------------+ ------------------------------ From: Bernd Kreimeier Date: Tue, 21 May 1996 12:42:48 +0200 (MET DST) Subject: Re: QuakeEd source released I updated the QuakeDev pages at http://www.gamers.org/dEngine/quake/. There is a (preliminary) Source Overview page, the screenshots page has been updated (the GIF files are a lot smaller), and the links I posted earlier this month have been added. If anybody is going to work on porting QuakeEd, I would appreciate reports. I am considering a port using C++, wxWindows and Mesa just as a feasibility study, and will put whatever insights on the pages. b. P.S.: there is one file in DOS format, cmdlib.h - perhaps a really ancient one :-). Besides the two screenshots itself, the other TIFF files (icons) are in a 12bit format inaccesible to most tools available to me, but the Gimp loads it - and vx grabs it. Whatever it's worth. Anyone happen to know a UNIX/C-equivalent of the UserPath lib? ------------------------------ From: Bernd Kreimeier Date: Mon, 3 Jun 1996 19:03:07 +0200 (MET DST) Subject: Info from John Carmack (1) I am going to forward a couple of mails to the list, with permission. This should have happened way earlier, btw., but work got the better of me the last weeks. b. This one immediately followed the mail about editing qtest1. - ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Sun Apr 7 20:26 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Sun, 7 Apr 96 13:25:22 -0500 To: Bernd.Kreimeier@NeRo.Uni-Bonn.DE Subject: Re: qtest1 editors? >Problem: billboard object (sprite) support might be removed, or >incomplete. Billboards allow for good use of partly transparent >textures. They are going to stay in. All of the sprite types you mention are currently supported, and there is also a sprite type that always has the XY normal pointing towards the view, which is slightly different than parallel to the view plane. >1.1 The trailing zeros in a plane like > "( 0 816 0 ) ( 0 512 0 ) ( 16 512 0 ) TECH07_2 0 0 0" > >are s_ofs, t_ofs, and flags? I.e. a texture offset s_ofs=16, >t_ofs=-32, with negate_s, negate_t, and exch_st all set would read Exactly. In case you didn't figure it out already, the points that define the plane are not necessarlily points on the brush, but just three non colinear points on the plane. I chose this representation instead of a normal/distance form because it allows me to keep perfect precision with integral values. I fear floating point creep in many forms. >2.1 How does "qbsp" handle two brushes that do not intersect, but > merely "touch"? Contacting faces are merged out of existance. I'm pretty sure that a brush that has no thickness in a given dimension would clip itself out of existance and not show up at all in the bsp file, but I'm not positive. > >Levels carry their own textures with them. > > Would it be possible to include a dummy entry of two long int in > the BSP header? As a placeholder for an optional list of "15 > BIGDOOR" entries, to be ignored by the engine. I don't think any app specific data should be stored raw in bsp files. Store it in a key/value pair in the world entity. An unrecognized key name will get a warning from Quake, but you can either define a new variable in defs.qc (when I release the compiler), or just use a valid string variable key like "netname" or "weaponmodel". Or perhapse I should just ignore (or make notification a development option) unknown keys at load time? It is nice to know when you make a typo... > I wish you only had... I figured this out last week, and it will > hamper level design in the most subtle ways. I don't see any > convenient fix, though. It was originally a speed issue for building the surface caches, but a later insight rendered the problem moot. I would like to fix it, but it probably won't show until Quake 2. The current limitation that annoys the map guys most is that texture shifting is by multiples of 16. If I put in The Fix, the primary benefit would be pixel level shifting, but it would also allow arbitrary rotation and scaling. That is an easily abused feature, though... Overall, natural alignment makes creating good looking maps a lot easier, because you usually don't have to offset things at all to get them to line up. John Carmack - ----- End Included Message ----- ------------------------------ From: Bernd Kreimeier Date: Mon, 3 Jun 1996 19:12:02 +0200 (MET DST) Subject: Info from John Carmack (2) - ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Thu Apr 11 23:28 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Thu, 11 Apr 96 16:26:16 -0500 To: Bernd Kreimeier Subject: FYI Content-Type: text/plain; charset="us-ascii" Content-Length: 1199 For your information, prompted by the comment about the limit of 255 textures in a qtest1 level, the current format has expanded miptex, sofs, tofs, and flags to 16 bits. While we probably won't ship a level with more than about 64 textures in it, I agree, 256 is never really enough of anything. The limit on offsets also prevented us from using >256 size textures in some situations, which people will probably want to do even before hitting the 256 unique textures limit. All better now, in any case. On the NAT front, I am considering changing the .map definition to use arbitrary texture origin and S and T vectors on each plane, instead of the sofs / tofs / flags values that are currently there. That would enable any affine texture arrangement, including arbirary rotation and size changes. I still don't think that capability is going to make it into the .bsp format for quake1, but it seems very probably for quake2, and I might as well get the .map format ready for it. Its good to see some reasoned comments about my architecture. I will be trying to address as many things as I can while under the pressure of shipping the game... John Carmack - ----- End Included Message ----- - ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Tue Apr 16 21:07 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Tue, 16 Apr 96 14:07:50 -0500 To: Bernd.Kreimeier@NeRo.Uni-Bonn.DE Subject: another FYI Content-Type: text/plain; charset="us-ascii" Content-Length: 400 On the subject of storing additional info in .map and .bsp files, I decided that all key names that begin with an underscore will be dropped by quake, so you can store whatever you want in them for utility communication. I am probably going to change all of our map uses of "wad" and "light" to "_wad" and "_light" so I can remove the unused dummy variables from the progs. John Carmack - ----- End Included Message ----- ------------------------------ From: Bernd Kreimeier Date: Mon, 3 Jun 1996 19:14:57 +0200 (MET DST) Subject: Info from John Carmack (3) - ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Fri Apr 26 20:22 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Fri, 26 Apr 96 13:21:10 -0500 To: Bernd Kreimeier Subject: Re: q&a Content-Type: text/plain; charset="us-ascii" Content-Length: 2988 You wrote: > Q's: > > 1. I want to forward a posting of yours (to Brian Martin) > concerning z-fill/z-buffer usage to the QuakeDev list, to settle > the occasional "z-buffer?" threads. Do you have any objections > against making any of your mails to us public? I never say anything that can't be quoted. > 2. Will billboards (sprites, decals) be mipmapped in 1.0/2.0? Hadn't planned on it, because it would require alpha channel to properly mipmap a mixture of transparent and opaque pixels. > 3. Will the texture names in the BSP mipmaps lump stay? I want to > use them to store the info needed to add mipmaps to a BSP file w/o > mipmaps - use of "_wad" optional. Yes, they should still be there. Are you planning to use miptex without any pixels as placeholders for another utility to fill in? I don't really think that is a great idea. Yes, it takes a couple hundred K to cary the graphics with a level, but it is rarely more than 20% of a full sized map's disk footprint. We are going to give free license to redistribute our art in user maps for non-commercial purposes. Packaging it all into one file makes distribution so much easier -- people don't need to get both graphics and levels. > 4. qtest1 and your log seem to indicate that Quake will try to > preserve view_up as much as possible (except on being > dead/strifing). Does that mean that there will be no builtin > support for 360 degree rotations around LOS/no rotate_ccw/cw > commands to bind to a key? There is no direct way to do it, but you can set cl_rollangle to 45 or so to get a whole lot of roll... A linked in input driver can set the view angle to anything it wants, so HMD can roll arbitrarily. qc code can set any angle for other objects, but there are some restrictions on player views, due to the client side short-circuiting of view control (to reduce latency). > 5. I am looking at GNUstep, trying to guess the changes of a > QuakeEd Linux port using GNU gcc ObjectiveC support and the > (supposedly 85% done) GNUstep libraries. Have you ever considered > this option? What classes/libs does QuakeEd require? QuakeEd is written for NEXTSTEP 3.3, while GnuStep is an implementation of the OPENSTEP spec. I haven't had time to port it to openstep yet, but it looks like it will take a little effort. NeXT has tools in NS 4.0 to help, but it still isn't automatic. > 6. Is there any real gain in not doing the mipmapping down to 1x1? Yes, I need to keep a cache pointer for each surface and each mip level, so adding four more mip levels would eat 160k of ram on a 10,000 polygon level. > 7. Idle curiosity: what became of the spherically mapped sky? It is a very squashed sphere now. A true sphere looked like you were inside a beach ball. Currently on the hardware 3D boards, it is a flat mapping, but that looks pretty poor. We are probably going to subdivide on them to get the spherical projection. John Carmack - ----- End Included Message ----- ------------------------------ From: Bernd Kreimeier Date: Mon, 3 Jun 1996 19:19:25 +0200 (MET DST) Subject: Info from John Carmack (3a) This is that earlier posting on z-buffer usage, as provided by Brian Martin. b. - ------------------------------------------------------------------- >From johnc@idnewt.idsoftware.com Tue Mar 26 17:12:36 1996 Message-Id: <9603262211.AA22560@idnewt.idsoftware.com> Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Received: by NeXT.Mailer (1.118.3) From: John Carmack Date: Tue, 26 Mar 96 16:11:40 -0600 To: "Brian K. Martin" Subject: Re: quake models References: <199603261430.JAA27076@minerva.phyast.pitt.edu> Status: RO You wrote: > Yes, it would be a real pain in the ass to download a different mdl > file to the server for each player. That is out of the question. > But why don't you allow to add one more peice of info to be sent on > initialization besides the colors, that is a string for a name of > the mdl to use. like 'player2.mdl'. This would allow so many more > cool possibilities. You guys don't have to worry about supplying > the models, just make it possible to use them. My idea was to have > quake load up the default player.mdl, then if someone wanted to use > a different one, and the client had it on their disk, they could > use it. Of course the color values could still be used and maybe > even you could just overwrite existing mdl info so you don't need > to read in all the frames, maybe just the texture. I've been considering the options for a while, and an "optional model" field is probably pretty good. I wouldn't count on it for 1.0, but that is the type of thing that might make it in on a revision. > -- Also, would you be kind enough to give the relevance of the byte > in the frame data after the max bound values in the mdl files. It is unused. Three byte structures are non-portable, so it's just padded. > Also the precalculated indecies go up to 161, but there are some 255's > in the models that are set to dark with no gouraud shading. I found > that values like 162 could be used to make things like sparkles and > stuff. Is this planned of just on accident (i.e. should I pursue > this if I wanted to hack an mdl file? but I would never do that.) There shouldn't be any 255s. What model did you see them in? It may be a bug. > one other little thing. I was arguing to several people about quake > using a z-buffer to render models. I can find no proof, no one > believes me. Every one says it's too slow. (and it is, but it works > good). Any words? The alias models are z buffered. The world is rendered with Z fill, which costs about 15% over just the drawing. Yes, the z buffering hurts on really large models, but for the majority of them, it is a speed advantage. If the average polygon size is only a dozen pixels or so, doing a compare and store to the z buffer for each pixel is less work than sorting against the other polygons in the model (let alone properly sorting against the world). As for speed... We will ship about 20% faster than qtest1. The 486 performance will still be hopeless, but that is the price for going to a floating point intensive design. I still stand by it as the right decision for the lifespan of the product. John Carmack - ----- End Included Message ----- ------------------------------ From: Bernd Kreimeier Date: Mon, 3 Jun 1996 19:24:50 +0200 (MET DST) Subject: Info from John Carmack (4) - ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Sat May 11 05:46 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Fri, 10 May 96 22:46:23 -0500 To: Bernd Kreimeier Subject: Re: q&a (2) Content-Type: text/plain; charset="us-ascii" Content-Length: 2727 You wrote: > 1. The Quake registered (==shareware?) will still be released as > DJGPP-linkeable modules? The initial 0.9 will not, but some later version will. I'm not sure if the initial CD pressing will, because there won't be any external drivers yet. The will be net released at some point for sure. > Followup: Iff, will the linux version be on the same CDROM? As > modules (gcc-linkeable) as well? I would hate to see DOS get the > better of this. Or looseDOWS. I have intentions to do so, but since Dave Talor left id, there is nobody here actively running linux, so it can get pushed out of the way by other issues pretty easily. Dave is still going to support the unix ports for us, but it is less of a priority. Yes, unix versions are cool, but they don't rank that high on the priority list. > 2. The COLORMAP remapping of the WAD2 palette for lighting (32 > steps again?) is part of the EXE now? Its an external data lump now, so the palette and colormapping (including fullbrighting) can be completely changed. > Followup: like the normal vectors used with the MDL, wouldn't it be > a better idea to keep any lookups outside the EXE, to prevent EXE > hacking, and ease configuration? ;-) > 3. Is the design of QuakeC vs. physics of the game flexible enough > to separate "blast" (momentum transfer) from "damage", i.e. pushing > an armored target without hurting it (area effects, not direct > hits)? Absolutely. Romero has asked me to do this a number of times, but I haven't gotten around to it. A while ago, we had mosnter cannons that chucked bad guys out of a piston, but it went away with some redesign. > Followup: will involuntary movements (like being pushed by an > explosion) change the view_up (including roll)? Whatever > restrictions on GUI/net packet size, preserving the view_up during > involuntary movements (falling) seems to make things "stiff" by > design. I let the client short curcuit the view angle in most cases, so the server doesn't usually override it. It's possible, though. > 4. Just a confirmation: the z-fill is done as a separate pass, not > within the texture mapping loop, because of (lack of) registers on > i586? Exactly. > Better performance on other CPU's? Alpha? Unlikely, because we have a fair amount of hand coded intel ASM. A 21164 certainly won't be a slug, though. I still need to fix a little 64 bitism in my code before it is going to work on alphas, though. I will get that done for sure. John Carmack - ----- End Included Message ----- ------------------------------ From: Bernd Kreimeier Date: Mon, 3 Jun 1996 19:38:32 +0200 (MET DST) Subject: Info from John Carmack (5) - ----- Begin Included Message ----- >From johnc@idcanon1.idsoftware.com Sat May 18 04:38 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Fri, 17 May 96 21:38:15 -0500 To: Bernd Kreimeier Subject: Re: q&a (3) Content-Type: text/plain; charset="us-ascii" Content-Length: 7321 You wrote: > Two shorts, one int. Two longs you might want to ignore. > > Q: you are using the "portals" mentioned in the worklog during PVS > computation, as described in Seth Tellers PhD? Similar idea, different implementation. Someone refered me to Teller's papers after I had a non-robust version of Quake PVS running, and it clarified some things in my mind, but was definatly a different tack from what I would up doing. I certainly don't retain any of the portal chain information for run time culling -- the map files are too huge as it is. I use a gross leaf to leaf PVS bit table, then the hierarchal BSP bounding volumes for frustom culling. > Q: I understand the short circuiting of view control on the client. > Is it correct that only yaw/pitch (determining movement along > current LOS and aiming) are transfered to the server? Is this > "hardwired" in the net packet structure? The server only rarely sends view angle information to the clients (enteting level, teleporters, etc). The client has full control over the view angles (all of them) most of the time, and sends all three view angles to the server each frame. This can be removed for things like tracking the monster that killed you when you are on the ground. > > Q: if I understood correctly - mipmpas are created by qbsp each > time anew, using a WAD file (old style? TEXTURE1/2, PNAMES?). There > is no Mipmaps WAD lump. > > Suggestion: how about including the DOOM > shareware/registered/commercial patches, PNAMES and textures on the > Quake CD, too? Removing all the monster frame rotations will > protect DOOM sales (as far as this is possible anyway). Permitting > redistribution will ease conversions a lot. It increases the pool > to draw [sic!] from. It looks good in the shops (added value). The > artwork was a major part of DOOM's success, it deserves a mipmapped > afterlife ;-). The mipmaps are creaated by qlumpy into new format wad files (just about the only remaining use of them -- they were intended to be used heavily, but I wound up going with the much superior search path / directory hierarchy aproach), but those are only referenced by QuakeEd and qbsp, which copies the needed ones into the map .bsp file directly. We used some DOOM graphics early on, but the palettes are different enough that the artwork is damaged in the conversion. Artists tend to be picky about showing degraded versions of their work :-) Don't worry, there are lots of really good Quake graphics. > > > Q: have you at some point thought about entities that are not > occluded by surfaces, i.e. always rendered on top of everything > else if within the view frustrum (no PVS)? > > Purpose: there is no automap for good reasons. I have tried a > look-through 2D automap with a DOOM-style renderer and found it > confusing, a 3D one is prolly even more useless. > > However, the concept of an (annotated) marker entity seems worth > bothering: an object that can be dropped, or shot at/attached to > another entity, that is always visible even through walls (in a > certain view mode, at least). It gives the player a sense of > direction to move along, but he still has to remember the structure > of the map. The advantages for hunting games are obvious: a tagged > target will always be visible, but is still difficult to hunt down > and trap. > I don't think that is a good idea. When an object shows through it's natural occluders, it give a pretty serious optical illusion that the things it is showing through are translucent, damaging the rock-solid feel of the world. > > Q: this is a not too specific remark (thus lengthy). If I > understood correctly, RGBA support is supposed to be a major > benefit of upcoming hardware (i.e. might be available in 1997 :). > It seems to me that the current engine design is biased with > respect to index color mode. Examples: > > + WAD2 Palette now contains 256 RGB values, it might as well > contain a NoOfColors field (256, 4096), and RGBA entries (32bit or > 48bit) at virtually no costs (ignored in index color mode) > > + Mipmaps and billboards implicitely reference one Palette, they > might as well explicitely reference a Palette (ignored in index > color mode) > > + billboards do not have mipmapping (no blending in indexed color > mode), but they might as well have (if w/o blending, it is still > LOD, and sprites will show more variation) > > Low overhead suggestion: bright objects (light sources) might > (implicitely) use a second, different Palette in 24bit modes. > > Followup: How is the lightmap+mipmap -> surface cache processing > done in 24 bit mode? Same LUT with same 256 colors? Or > NoOfLightlevel*256 true color values? Some comments: originally, we maintained 8, 16, and 32 bit code for all of our drawing, and we worked in every conceivable video mode. This was a major pain in the ass to maintain. 16 bit color looked noticably WORSE than 8 bit color, because while we have smooth 16 color gradiants of some non primary colors that look fine in 256 color mode (18 bits of color precision), in 15 or 16 bit mode there is a noticable hue change every time you are forced to drift a bit off of your ideal color. 24 bit color looked better than 8 bit, but not a whole lot. This is mostly due to good source images. For an arbitrary image processing solution where you can chuck any old set of pixels at it, any direct color mode is going to be a ton better, but when you have control over your source data you can pick and choose to make 8 bit outperform 16 bit, and save all the extra space and processing time. We do occasionally take a lose in the mip map creation process for lack of good colors in the palette, but I do an error diffusion during the resampling, which helps a lot. Lighting direct color images hurts a fair amount, too. MMX is really nice for that, but without it you either need huge tables or lots of bit twiddling. All that said, Quake is still my last indexed color engine. I still think it is the right call for this moment in time, but the future is definatly direct color. > Followup: is the current 3D hardware worth to be taken into account > in renderer design? I.e. are there ways to use RGBA e.g. for > processing lightmaps (as Alpha-map implicitely blending with a > solid black)? How does the lightmap+mipmap processing fit with > on-board texture memory anyway? A max-throughput engine is still going to use small, tiled textures in hardware, just as in software. I think the image quality tradeofs of surface caches are worth the speed cost, though. 3DFX has done some light map building demos with the hardware, and rendition could certainly be programmed to do it. I suspect that all of the Quake drivers will still build the surface caches in software, because many of the current 3D boards have high setup overhead per primitive, and drawing tons of little boxes would suck. Rasterization hardware is definatly the future. Soon you will not be able to buy a computer without it, because it can be implemented in the same single chip video controllers currently used, and it will become a checkbox item. John Carmack - ----- End Included Message ----- ------------------------------ From: Bernd Kreimeier Date: Mon, 3 Jun 1996 19:45:57 +0200 (MET DST) Subject: Info from John Carmack (6) In march, following the CeBit fair, I asked about support of the S3 ViRGE and ViRGE/VX. I add that one short reply to the discussion of 3D hardware in the more recent posting. b. - ----- Begin Included Message ----- From: John Carmack Date: Sat, 16 Mar 96 15:00:50 -0600 To: Bernd Kreimeier Subject: Re: Verite premier platform We are supporting both S3 and rendition for release. Rendition should be a bit faster. John Carmack - ----- End Included Message ----- - ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Fri May 24 22:32 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Fri, 24 May 96 15:32:46 -0500 To: Bernd Kreimeier Subject: Re: q&a (4) Content-Type: text/plain; charset="us-ascii" Content-Length: 3183 You wrote: > Q: Brush.h in the QuakeEd sources is obsolete, it refers to > EditWindow.h and is not imported at all. Is this part of something > new (Brush Editor) that is not released yet, or a leftover? > It was a leftover. Delete it. > > Q: qbsp, vis, light and qlumpy are written in C? ObjectiveC? If the > latter, using only common classes (in gcc libobjc.a), or anything > more NS specific? Pure C. ( Pure ANSI, in fact, except for cwd() ) They compile on practically anything. > > > Q: You wrote: > >I am eagerly looking forward to writing a brand new editor for > >windows NT + open GL as soon as Quake ships. > > Reminds me of two drawbacks I foresee with the Verite cards: > a) Rendition never indicated OpenGL support (but supports HEIDI) > b) judging from their zero-response, XFree86 support will suffer from > NDA and Matrox-style attitude. Am I wrong? I'd rather be wrong: the > Verite looks very interesting, esp. if programming the RISC would > be an option for pedestrians, too. The Technical Specs on the > Chromatic pages are much more promising in that regard, i.e. open > to the public. I doubt we will see a verite GL driver, but I did mention it to them. They are dram based, so it isn't a real workstation class card anyway. They are pretty decent folks, so I don't think XFree86 support is out of the question. I'll mention it next time I talk with them. I suspect they are just in crunch mode and don't have the time to devote to freeware projects. I think being open with the RISC programming would be to their best advantage, becaue demo-coder types would be able to do incredibly impressive stuff with it. > Q: In addition to S3 and Verite: have you had the time to evaluate > other cards/chips? Pyramid3D or Chromatic? Not the GLINT300SX for > obvious reasons. Too bad 3D Labs targets a different market, they > already support a Mesa driver project. GLINT300TX + GLINT delta will be a kick-ass workstation setup. 3DFX has the best fill rate around. ATI is no good, because it doesn't have a Z buffer at the moment. I haven't evaluated Pyramid3D or Chromatic. I have an intergraph GL workstation, which is a solid performer, and they have new technology coming out in a few months, but it isn't consumer level stuff. BTW, I just became aware of Mesa last week, and I am very impressed with it. I hope to contribute something to the project when I have more time. I may compatability check my new editor against it. > > Q: Idle curiosity: Michael Abrash mentioned a "Vertex-free > surfaces" approach to Visible Surface Determination that sounded > like using a MAP-like representation for rendering as well. Have > you looked at the NEC/VideoLogic PowerVR chip, which, to my > understanding, uses a similar representation? It was more like using an ultra simple bsp, like the clipping hull, to directly generate the scene. It was cool, and very very space efficient, but not fast enough. It would run great on the PowerVR chip, but because that is such a strange (not mainstream) paradigm, I don't predict great acceptance of PowerVR. John Carmack - ----- End Included Message ----- ------------------------------ End of quake-dev-digest V1 #8 ***************************** From owner-quake-dev-digest@gamers.org Thu Jun 6 23:01 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id XAA14332 for ; Thu, 6 Jun 1996 23:00:18 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id QAA19016 for quake-dev-digest-outgoing; Thu, 6 Jun 1996 16:54:35 -0400 From: owner-quake-dev-digest@gamers.org Date: Thu, 6 Jun 1996 16:54:35 -0400 Message-Id: <199606062054.QAA19016@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #9 Reply-To: quake-dev@gamers.org Errors-To: owner-quake-dev-digest@gamers.org Precedence: bulk X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 29546 X-Lines: 816 Status: RO quake-dev-digest Thursday, 6 June 1996 Volume 01 : Number 009 ---------------------------------------------------------------------- From: Bernd Kreimeier Date: Mon, 3 Jun 1996 20:13:28 +0200 (MET DST) Subject: Info from John Carmack (7) Last but one. Please note that this is the accumulated log since march, less than one q&q per week on average. Note the postscriptum. I will update the Hypermail archive ASAP, and encourage everybody to add other bits of information they got, to keep *me* from asking more stupid questions. Thanks. b. - ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Mon Jun 3 18:08 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Mon, 3 Jun 96 11:07:47 -0500 To: Bernd Kreimeier Subject: Re: q&a (4a) ? Content-Type: text/plain; charset="us-ascii" Content-Length: 3389 You wrote: > Q: In the qtest1 palette, there are >= 16 colors all white. Has the > palette changed, i.e. has it been unfinished? Would it be possible > to release the current/final version? We added another range of fullbright explosion colors, I don't think anything else has changed. > Q: Would you mind providing a hint on the "sealing" of a map? Does > this include a processing step like mentioned by Seth Teller, > fixing small gaps and holes to reduce vis computation and PVS size, > or is it determining "sky" surfaces? I don't fix any small gaps, but removing all the crud on the outside of the level more than halves the data size. After building the BSP tree of the world, I build a graph of the portals between the leaf nodes, then do a simple graph flood fill from the outside of the world. If it ever reaches a leaf with an entity (light, player, etc) in it, it assumes that it leaked inside the level and writes a pointfile containing a trail of dots that can be loaded into quake to find the path that went through the hole. > Q: on NATs and the new MAP format. You wrote: > > >On the NAT front, I am considering changing the .map definition > >to use arbitrary texture origin and S and T vectors on each > >plane, instead of the sofs / tofs / flags values that are > >currently there. > > I expected something like ( x,y,z,s,t ). Instead, there are two > additional values in jrbase1.map that seem to be always 1.0000. > This is supposed to be scaling, in addition to sofs/tofs/flags? > There are "sizing" buttons in the early screenshots of QuakeEd. Or > am I missing something? The textures are arbitrary now, but the definition is a bit confusing. My first thought was "just include S and T vectors on each surface". That is the simple, straightforward representation, but it is bad for editing, because every deformation of a brush needs to modify the vectors. I wound up representing the textures as modifications off of natural texture alignment. shift and scale on each axis plus rotation. It feels clunky, and I doubt it is The Right Thing. > > >BTW, I just became aware of Mesa last week, and I am very > >impressed with it. I hope to contribute something to the > >project when I have more time. I may compatability check my new > >editor against it. > > Actually, texture mapping (esp. mipmapping) is not yet complete (as > of 1.2.8, which is supposed to be the last release for about 6 > months). How about a i586 optimized driver, btw :-)? Mipmapping isn't crucial. I saw the basic wrap/clamp test running, and I glanced at the code, so I don't think it is too horribly far off. I did notice that the parallel array structure of the texture mapping polygon rasterizer is going to guarantee cache associativity collisions on every single scan line. If I can find some time, I would like to donate some work, but my time is a pretty damn scarce commodity. John Carmack ps: I encourage you to share my comments with the rest of the community that might be interested, in the hope of preventing my answering the same questions multiple times... - ----- End Included Message ----- ------------------------------ From: Bernd Kreimeier Date: Mon, 3 Jun 1996 20:40:14 +0200 (MET DST) Subject: Info from John Carmack (8) Done. From now on, I will simply forward any other info to this list as soon as I get it, which will simplify things a lot. Take your time to digest... b. - ----- Begin Included Message ----- >From johnc@idcanon1.idsoftware.com Sat Jun 1 20:00 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Sat, 1 Jun 96 13:00:27 -0500 To: Bernd Kreimeier Subject: Re: q&a (5) Content-Type: text/plain; charset="us-ascii" Content-Length: 3818 You wrote: > I stumbled across the following two quotes: > > "Carmack made mention of redoing Quake Ed file structure because of > this" (related to some intrusion attempt, I gather) > > Q: Is the MAP format going to change? Btw., sounds strange, what'd > be the advantage (in relation to some pirated pre-release engine)? If the registered pak file had been stolen, but a functional exe had been, then I would probably have made a change to make the final released exe not recognize all the .bsp files in the pirated registered pak file. In any case, they didn't get any data, so I'm not messing with it. > > "Carmack is about 1/3 finished with an NT version of our Map > editor" > > Q: The NT version is done using VC++? Are you going to release that > source? It'd be convenient to port a C++/OpenGL version to Linux. > And futile to reinvent the wheel after the fact. > 1/3 finished is a biiig overstatement. I have the editor view layout mostly functional on my intergraph GL accelerated NT system (its way cool to be running around the map with blended transparent walls in realtime), but it will take me at least a solid two weeks of work after quake's release before the editor is really ready for prime time. I don't know about "futile"... I was actually looking forward to seeing what other people come up with for editor interaction paradigms. If you mean a straight port of QuakeEd, yeah, it might be a waste of time. > You are moving way to fast for weekend code warriors. I managed to > built, change and toy around with QuakeEd (logged my first three > hours on a NeXT - too bad there is no IB and ObjectiveC for Linux). GCC does objective C right now, but it would still be a major porting effor to move it to objc-X or gnustep. > Q: are there any distribution restrictions you want me to put on > QuakeEd related stuff? That is: screenshosts, derivatives of > jrbase1.map, modified sources, NeXT binaries. There is no > qbsp&Cie., thus I cannot imagine any damage (besides spoiling > jrbase1 prior to SW release). However, please let me know. I put it up without consulting our lawyers :-) Consider it all available for any not-for-profit use. > > On the new editor: > > Q: are you going to include any DDE/IPC connection of Quake and > Quakeed? I.e. moving the camera in the editor moves the POV in > Quake, and switches start/stop monster animation etc. For entity > placement and even texture alignment (or lighting), no BSP built > should be necessary. OpenGL previewing might ease texture alignment > pains, but entity placement and fine-tuning the map needs test runs > using the AI. In principle, one needs a way to have server move one > client according to the commands of another client. > > Q: reminds me: still planning on releasing the server sources? All of the .qc code will be relased (QuakeEd parses it for entity names, anyway), but I have gotten a little more reticent about releasing object code and some C code just from a control point of view. Anyway, for large scale server issues it turns out that the best way to control quake is with a wrapper program, instead of modifying internal code. The qc compiler and source will come out withing a couple days of release. I could release the bsp tools around the same time, but I'm not sure if anyone can use them until a generally accessable editor is made. I will release the code for the NT editor when I get it nice and stable. In wireframe mode that should run acceptably even on an unaccelerated system, but it is being designed for hardware acceleration. When everything settles down (version 1.3 or so, probably) I may release the object code with some source files for serious internal tweaking. John Carmack - ----- End Included Message ----- ------------------------------ From: Bernd Kreimeier Date: Wed, 5 Jun 1996 16:35:23 +0200 (MET DST) Subject: QuakeDev pages update Minor update: + May and June mails + DOOM and Quake color palette page + a couple of NeXT QuakeEd GUI screenshots + draft of Quake Editing primer + removed some (not all) obsoletes See ChangeLog. b. ------------------------------ From: Bernd Kreimeier Date: Thu, 6 Jun 1996 12:51:48 +0200 (MET DST) Subject: QuakeEd 1.2 upload/test1.map I have uploaded with permission on http://www.gamers.org/dEngine/archive/ the following files: QuakeEd-1.2.bin.next-m68k.tgz - a QuakeEd binary QuakeEd-1.2.src.tgz - the current source version QuakeEd-1.2.map.tgz - map files, including test1 test1.map.gz - the qtest1 test1.map file This is not a production release, but it should be useful to anybody having occasional access to a NeXT (like me) and trying to design a GUI for editing. You might even be able to do some map editing. There is no miptex support (yet). Later releases will find their way to ftp.cdrom.com, but I do not think 1.2 is ready for widespread use. Please let me know about any problems ASAP. In addition, John Carmack released the test1.map source as used in the Quake qtest1 release. This offers every BSP builder out there a chance to compare the results on test1.map against the BSP file in qtest1. To anybody working with/modifying QuakeEd: I am maintaing the current sources with CVS. Please send me any patches/diffs/ extensions you are doing, and I will incorporate them in the base. You NeXT guys currently have an advantage :-) but by the time NeXTQuake might be available, QuakeEd might still be the only working editor available to you, so it makes sense to take care of it. Thanks to Steve Larsen who provided his sources and patches for this release, and to Jean-Paul, Jan and Jelske for providing help and NeXT access. Thanks to Vareck Bostrom as well. b. ------------------------------ From: jschuur@onlinemagic.com Date: Thu, 6 Jun 1996 12:31:54 +0000 (GMT) Subject: Re: QuakeEd 1.2 upload/test1.map can you clarify this bern: this version include patches and improvements made to quakeed by people other than id? what about changed johnc has made to quakeed? (his work log indicates that some things were changed in the past week or two). good to see someone is working on the code already. -- joost schuur, Online Magic Ltd. ----------- Tel: +44 171 820 7766 -- ----------------------------------------------------------------------- ---------------------------------------------------------------------- - --- http://www.nuqneH.org/~jschuur/ ---- jschuur@onlinemagic.co.uk --- ------------------------------ From: Bernd Kreimeier Date: Thu, 6 Jun 1996 14:00:58 +0200 (MET DST) Subject: Re: QuakeEd 1.2 upload/test1.map > can you clarify this bern: this version include patches and > improvements made to quakeed by people other than id? A few patches, yep, improvements, nope. > what about changed johnc has made to quakeed? (his work log indicates > that some things were changed in the past week or two) Not included. Yes, there seem to be at least the following ones: * QuakeEd: fixed crash when misselecting an entity angle * QuakeEd: forbid dragging position / direction when textured and some intended: QuakeEd: goto point in command window QuakeEd: view pos button QuakeEd: don't explode if /qcache isn't present QuakeEd: top trace for shearing is at 2048, increase to 8192 This is a problem for several reasons: a) his worklog technique makes it tedious to track this, because you will have to look fot those retrospect "+" entries, too. b) it is not worth while to bother anybody :-) on each single change as long as QuakeEd is not in widespread use c) I did not bother to import QuakeEd in CVS for tracking third party sources (which would have been appropriate for frequent updates) - as I do not benefit that much from the NeXT version, I simply cannot afford the time. I intend to get back to this once they shipped, and he abandoned QuakeEd for his new NT/OpenGL editor. In the meantime, it is more important to 1) get a mipmap WAD2 file done (thus NeXT users might be able to create maps) 2) get a bsp builder running (thus NeXT users will be able to generate maps they can`t play :) and, most important IMO: 3) get a working editor done for Linux :-). Hope this clarifies the issue. b. ------------------------------ From: jschuur@onlinemagic.com Date: Thu, 6 Jun 1996 13:33:43 +0000 (GMT) Subject: Re: QuakeEd 1.2 upload/test1.map On Thu, 6 Jun 1996, Bernd Kreimeier wrote: > 3) get a working editor done for Linux :-). speaking of that, for those who haven't seen it: http://www.canweb.net/~fisty/shaker/ although it appears the author doesn't currently have as much time as he'd like for this project, -- joost schuur, Online Magic Ltd. ----------- Tel: +44 171 820 7766 -- ----------------------------------------------------------------------- ---------------------------------------------------------------------- - --- http://www.nuqneH.org/~jschuur/ ---- jschuur@onlinemagic.co.uk --- ------------------------------ From: Bernd Kreimeier Date: Thu, 6 Jun 1996 17:13:53 +0200 (MET DST) Subject: Editor GUI design Joost wrote: >> a working editor for Linux > speaking of that, for those who haven't seen it: > > http://www.canweb.net/~fisty/shaker/ Reminds me. The screenshots there and incompetently toying around with QuakeEd raised a few issues I would like get some opinions on - namely what an editor should/should not do. Just to get things started (gee, from the looks of it I am the only one using this mailing list), here`s one. More to come. 1) The Axial Bias I haven`t had the opportunity to do serious work with QuakeEd, however, one thing that caught my eye is a certain bias towards axial blocks. First, it is the thing the most easiest to create and manipulate with QuakeEd. You will apply CSG operations to those, mostly. In the end, the overwhelming majority of brushes/polygons is axial. Possible solutions: - -Brush (Group) rotation operations - -Brush Templates, (sets of) polyhedra approximating curved, non-axial surfaces, just a libary - -a separate Brush Editor (Mode) - -DXF/3DS Import Btw. it seems that in QuakeEd there is no way to load a MAP file into a MAP file - the help says "a selection is not cleared when loading a new map, so selections can be brought over from other files", which works, but looks a bit like putting the horse in the saddle... if you catch my drift. Secondly, the View Modes encourage use of axial brushes. The look/down XY View does not invite editing multi-storey editing (there might be a decent z-clipping available, haven`t checked). The Z ScrollView emphasizes this. The CameraView is controlled by DOOM-style cursor movement - there is no mlook, not even a limited look-up/down (not even a fly mode, but a floor up/down). The engine is capable of 3 DoF in both movement and orientation, thus an editor has to have this feature, too. Possible solutions: - -mlook mode - -4 Views, three of them axial, one free Comments anybody? b. ------------------------------ From: Bernd Kreimeier Date: Thu, 6 Jun 1996 17:13:44 +0200 (MET DST) Subject: Re: QuakeEd 1.2 upload/test1.map At least two people seemed to have problems downloading the test1.map.gz. I took the opportunity and cleaned it up (the original NeXT mail from John Carmack had lots of CR/LF inserts breaking up brushes - a brush apparently has to be defined in a single line/removed the "wad" key/ removed "angle"/added "message"/moved "classname" to top), and checked it with QuakeEd. The download problems might be NerdsCraps fault - use SaveLinkAs, beware that the friggin decompresses on the fly. Observations I made on the occasion: a) the POV can be moved with mouse drag&drop, in both XYView and ZScrollView b) no auto-center is performed in XY View c) no auto-detect of current height is done d) on a NeXT cube, PageUp/Down for "next floor up/down" is not available - use ZScroll drag as workaround e) besides being smaller than jrbase1, test1 seems to be slower (or I am getting impatient :) You might get loads of warnings "Entity with no brush and esize_model" on loading the map (it happend with the original one, haven`t checked again). b. P.S.: 'nother thing I learned about how to do an editor is that switching to wireframe/solid, or omitting faraway brushes should be done automatically during movement, with check on framerate. User sets preference, not mode. ------------------------------ From: Olivier Montanuy Date: Thu, 6 Jun 1996 18:24:12 +0200 Subject: RE: Editor GUI design - -----Warning: this message is diplomatically challenged----- [cut-off from Bernd's message...] >The engine is capable of 3 DoF in both movement and orientation, >thus an editor has to have this feature, too. >Comments anybody? Comment is simple: Quake levels are closed. just like Descent mines. how the heck do you think one creates a mine? You walk inside and you cut your way throught the walls, using a suitably shaped object. The .MAP format made of filled convex blocks isn't suitable, in my not possibly humble opinion. That's the way you build houses in the open, not the way you dig mines. What do we care about the exterior of the level? How come it's even calculated? It can even cause errors (leakage). If the map files were substractive (i.e.made of empty blocks, in a filled space, instead of filled block in empty space, it would be much easier to edit and generate. And of course, you should be able to edit the level while walking inside, not via some lame combination of 2D views or delayed camera view. That screams for a portal based scheme. Another company will do it, and will bite market shares off id. Guess who. Not everyone is lost in the Realms of 3D. I might calm down once I get my hands on a PPro 200, but I doubt many Quake players/editors can afford one. The Arrogant Frog (who else?) ------------------------------ From: Bernd Kreimeier Date: Thu, 6 Jun 1996 19:03:17 +0200 (MET DST) Subject: RE: Editor GUI design >Comment is simple: Quake levels are closed. >a mine? You walk inside and you cut your >way throught the walls, using a suitably shaped object. Right. >If the map files were substractive (i.e.made of empty >blocks, in a filled space, instead of filled block in >empty space, it would be much easier to edit and generate. QuakeEd CSG supports this. I am currently working my way through the help.txt (RTFM, as always, my speciality), and naturally, it is possible to create a huge block and bite away. >The .MAP format made of filled convex blocks isn't suitable, I do not agree on this one. Your remark goes straight for the jugular, though - in "densely occluded environments" the empty space you walk in might be a convex or non-convex polyhedron - it cannot be described by a single Brush. Thus creating rooms always means creating a Group of Brushes. QuakeEd starts with empty space, and you start dropping Brushes. In a way, this seems counterintuitive, but the Sealing of the map takes care of the outside border. Not to difficult to get used to. I guess that most of us can handle those small plastic building bricks - not so sure about pickaxes. Surrounding yourself with six big solid brushes and start digging away might be more difficult - I usually loose sense of direction inside a building, not outside :-). Might be bad in terms of final brush count as well. Once you have created the rooms, you are placing furniture - as nobody digs a chair, so to speak. b. P.S.: new GUI checkbox: "Agoraphobia mode on/off". ------------------------------ From: Chris Carollo Date: Thu, 06 Jun 1996 01:17:16 -0400 Subject: Re: Editor GUI design Bernd Kreimeier wrote: [snip] > 1) The Axial Bias > > Possible solutions: > > -Brush Templates, > (sets of) polyhedra approximating curved, non-axial surfaces, > just a libary This seems like a good idea. Obviously primitives like cubes or tetrahedra should be implemented, along with extruded regular polygons. > -a separate Brush Editor (Mode) For designing complex brushes it might be desirable to not display all other brushes. Though I question how often people will be designing complex convex polyhedra. Certainly editing at the level of edge/vertex/entire-brush is necessary in some fashon, but each introduces problems (convexity of brush, coplanarity of faces) > -DXF/3DS Import Importing from 3DS seems to be an everpresent request, but it never quite seems applicable. IMO, an editor needs to be specialized (especially when dealing with brushes) to be really useful. [big snip re: view modes] > Possible solutions: > > -mlook mode A mlook mode seems useful in examining the layout of maps, and not so useful in actually editing the map. When looking at a map at some cockeyed angle, it no longer becomes clear how to easily manipulate entities and brushes in three dimensions. > -4 Views, three of them axial, one free In Quest, I'm including four primary look directions (+X, +Y, -X, - -Y), and also the ability to look in the +Z and -Z directions (in reference to primary look direction). All vertex/edge/brush editing is done perpenticularly to the camera direction. This way, the user cannot change the "depth" of any entity, which is fairly intuative. The downside is that designing very complex brushes (no faces pependicular to any of the view directions) can be a real pain. I'm thinking of adding a "edit-the-current-brush-only" mode where the camera can be rotated freely around the brush. My guess is that the vast majority of brushes will _not_ be complex, and this will not be a major problem, and I won't have to bother coding this. ;) I'm also considering letting the user allow intermediate look directions (i.e. at 45 degree increments instead of 90). Because I'm kind of coding blind (not having the ability to really edit a map yet), I'm not sure if this will be a problem or not. I guess time will tell... > Comments anybody? Likewise... - -Chris Quest page at http://www.cis.ohio-state.edu/~carollo/quest.html ------------------------------ From: Bernd Kreimeier Date: Thu, 6 Jun 1996 20:52:26 +0200 (MET DST) Subject: Re: Editor GUI design >editing at the level of edge/vertex/entire-brush is necessary >in some fashon, but each introduces problems (convexity of brush, >coplanarity of faces) Indeed. Add to the big ToDo list: - - Brush convexity checking - - Brush merge adjacent coplanar - - Brush remove redundant planes (will not create facets) >Obviously primitives like cubes >or tetrahedra should be implemented, There are two approaches: a) Dialog Boxes and GUI interacts (mouse) to create one of a fixed set of primitives b) a generic Load/Save Template mechanisms, and scaling/translation/rotation manipulating a bounding box rep c) both I think (a) and (c) tend to clutter the GUI, but that is a matter of personal preferences. >For designing complex brushes it might be desirable to not display >all other brushes. Again two alternatives: a) a Selection/Filter aproach - you are still within MAP space b) a separate Brush Editor, in model space >When looking at a map at >some cockeyed angle, it no longer becomes clear how to easily >manipulate entities and brushes in three dimensions. Add the major axises to the preview. Define six keys to move along +/- X/Y/Z. One or more slanted views? >an "edit-the-current-brush-only" mode where >the camera can be rotated freely around the brush. In a predominantly XY-plane aligned world (direction of gravity is alsway along Z) it might be useful to have a rotate around the Z axis. There is the tall/short extrude feature in QuakeEd. Taking a XY convex polygon and extending it along Z (or some sloped axis) is a possible mode. Drawing the convex polygon in XY (2D view) in a separate window, for example. There are surely a lot of useful simplifications, and the use of Axial Blocks surely fits man-made environments. However I keep thinking that more or less 2D biased editing will be done anyway. Consider what I call a "Poseidon" level - e.g. a ship wreck on the beach, or even toppled, pockets of air, water surfaces, slippery decks, and no a single XY aligned plane in sight. QuakeEd might or might not be up to the task, but NAT's will be a major pain. You can't even take a given MAP and tilt and roll it a couple of degrees w/o screwing texture alignment (might be fixed if arbitrary texture coordinates are indeed possible now). You can't even do a yaw-rotation (around Z) with a given map or brush selection w/o taking care of the texture alignments, but that's a different issue. b. ------------------------------ From: Bernd Kreimeier Date: Thu, 6 Jun 1996 21:12:45 +0200 (MET DST) Subject: Palette Matching Has anybody taken a look at the Doom PlayPal vs. the Quake palette? I did some matching runs with various metrics in RGB space, and there are very few exact matches, and a larger number of severe mismatches. I haven`t (yet) tried to convert an actual DOOM texture to the Quake Palette, but prospects do not look good. Dithering might help. Has anybody with some experience in handling limited palettes tried? Which, in turn, means that converted or re-done Doom maps should possibly stick to the PlayPal - meaning they cannot use the skin textures matching the Quake palette. In addition, a palette lump should accompany the mipmaps (in the BSP or elsewhere). It`s only 768 bytes, after all, and in perfect agreement with the thinking that puts the mipmaps in the BSP. b. ------------------------------ From: Joel Huenink Date: Thu, 06 Jun 1996 16:00:05 -0500 Subject: Re: Palette Matching Bernd Kreimeier wrote: > > Has anybody taken a look at the Doom PlayPal vs. the > Quake palette? I did some matching runs with various > metrics in RGB space, and there are very few exact > matches, and a larger number of severe mismatches. I > haven`t (yet) tried to convert an actual DOOM texture > to the Quake Palette, but prospects do not look good. > Dithering might help. Has anybody with some experience > in handling limited palettes tried? > > Which, in turn, means that converted or re-done Doom > maps should possibly stick to the PlayPal - meaning > they cannot use the skin textures matching the Quake > palette. In addition, a palette lump should accompany > the mipmaps (in the BSP or elsewhere). It`s only 768 > bytes, after all, and in perfect agreement with the > thinking that puts the mipmaps in the BSP. > > b.Wouldn't basing quake maps on doom maps, and using their textures be copyright infringement? Why not just play doom if you like the map and textures so much, unless you really like a particular map, but I am sure the guys at ID will make som e fun levels. - -- Joel Huenink jh32322@ltec.net Creator of All Hell Coming to a PC near you http://www.conline.com/~huenink/ ------------------------------ End of quake-dev-digest V1 #9 ***************************** From owner-quake-dev-digest@gamers.org Sat Jun 8 22:22 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id WAA18656 for ; Sat, 8 Jun 1996 22:22:05 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id QAA06967 for quake-dev-digest-outgoing; Sat, 8 Jun 1996 16:21:51 -0400 From: owner-quake-dev-digest@gamers.org Date: Sat, 8 Jun 1996 16:21:51 -0400 Message-Id: <199606082021.QAA06967@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #10 Reply-To: quake-dev@gamers.org Errors-To: owner-quake-dev-digest@gamers.org Precedence: bulk X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 28711 X-Lines: 748 Status: RO quake-dev-digest Saturday, 8 June 1996 Volume 01 : Number 010 ---------------------------------------------------------------------- From: jelson@conline.com (Jim Elson) Date: Thu, 06 Jun 1996 16:16:17 -0500 Subject: Re: Editor GUI design At 05:13 PM 6/6/96 +0200, Bernd Kreimeier wrote: > >Reminds me. The screenshots there and incompetently toying >around with QuakeEd raised a few issues I would like get some >opinions on - namely what an editor should/should not do. > >Just to get things started (gee, from the looks of it I am >the only one using this mailing list), here`s one. More to >come. Hahahahahahaha. Perhaps some are like me, still making that conceptual leap from Doom editing to Quake Editing. :) (Very much looking forward to DOS/Win95 editor to facilate this) >1) The Axial Bias > >Possible solutions: > >-DXF/3DS Import I am extremely in favor of this option. When I 1st thought about making Quake levels, my mind immediately though of 3D CAD since I've done a bit of that before. (I do admit I still haven't figured out why QuakeEd is taking a different approach to designing the structure of a level) I also suspect that a DXF import will be highly desired by anyone else with experience in 3D CAD. (heh, finally got some hardware that won't make 3D CAD so damn tedious) - --H2H ============================================================================ H2HMud NorthAmerican DeathMatch Tourney Promo/Marketing Coordinator for "The New Technology: Evilution" - ---------------------------------------------------------------------------- jelson@conline.com; WEB page ==> http://www.conline.com/~jelson/index.html ------------------------------ From: Uffe Friis Lichtenberg Date: Fri, 7 Jun 1996 00:17:29 +0200 (METDST) Subject: Re: Palette Matching On Thu, 6 Jun 1996, Bernd Kreimeier wrote: > Has anybody taken a look at the Doom PlayPal vs. the > Quake palette? I did some matching runs with various > metrics in RGB space, and there are very few exact > matches, and a larger number of severe mismatches. I > haven`t (yet) tried to convert an actual DOOM texture > to the Quake Palette, but prospects do not look good. This corresponds exactly to some of ... (John Carmack?)'s comments. The palette chosen for Quake is far from the palette used in Doom. But I remember reading somewhere (in the log?) that palette now could be level based. Thus the problem seems easy to solve -- simply use the Doom palette. > Dithering might help. Has anybody with some experience > in handling limited palettes tried? In my experience dithering texture maps (at such a low resolution as those of Quake) never gives satisfactorily results. It can only get worse with the mipmapping applied. > Which, in turn, means that converted or re-done Doom > maps should possibly stick to the PlayPal - meaning > they cannot use the skin textures matching the Quake > palette. Any Doom conversion has to include converted sprites. (Just a new skin texture for the player and enemies to start with -- later on new models perhaps). Although low-res, the original sprites could probably be used more or less directly for this. > In addition, a palette lump should accompany > the mipmaps (in the BSP or elsewhere). It`s only 768 > bytes, after all, and in perfect agreement with the > thinking that puts the mipmaps in the BSP. I think (but am unsure) that this is already the case. (I hope.) Think of it: it bloody well *has* to. Otherwise creating Quake levels with completely different settings/themes will be nigh on impossible. Zonk, Uffe. [uphfe] uffefl@diku.dk - -- "This .signature hasn't been left unintentionally void of blankness" ------------------------------ From: Rob Shields Date: Thu, 06 Jun 1996 18:48:13 -0400 Subject: Re: Palette Matching Bernd Kreimeier wrote: > > Has anybody taken a look at the Doom PlayPal vs. the > Quake palette? I did some matching runs with various > metrics in RGB space, and there are very few exact > matches, and a larger number of severe mismatches. I > haven`t (yet) tried to convert an actual DOOM texture > to the Quake Palette, but prospects do not look good. > Dithering might help. Has anybody with some experience > in handling limited palettes tried? > > Which, in turn, means that converted or re-done Doom > maps should possibly stick to the PlayPal - meaning > they cannot use the skin textures matching the Quake > palette. In addition, a palette lump should accompany > the mipmaps (in the BSP or elsewhere). It`s only 768 > bytes, after all, and in perfect agreement with the > thinking that puts the mipmaps in the BSP. > > b. My last project before QMapHack was a set of utilities for personal use that would take a set of images and orient them to use the same palette. With some modifications, I could attempt to convert some DOOM2 textures to QUAKE textures. However, I have not had much experience a far as DOOM2 file formats, so I need to know how to extract the textures and palette from DOOM2 to try this. Rob Shields ------------------------------ From: Uffe Friis Lichtenberg Date: Fri, 7 Jun 1996 01:13:46 +0200 (METDST) Subject: RE: Editor GUI design On Thu, 6 Jun 1996, Olivier Montanuy wrote: > Comment is simple: Quake levels are closed. just like Descent mines. > how the heck do you think one creates a mine? You walk inside and you > cut your way throught the walls, using a suitably shaped object. I don't think you're right. (Have you ever tried using Devil to create Descent levels? Tedious at best, undescribable at worst.) Construction of a level would probably be easier if you had only the `constructive' approach, not the `destructive'. There will of course always be situations where the destructive approach could be easier/more intuitive, but I think this is fewer times than the other way around. (Am I making any sense? Sorry, it's late.) Any editor worth it's salt will have both options of course. What we'll really need for Quake Editor Development is a set of CSG library functions. (Doing the union/intersection/negation calculations, converting to meshes for display, saving as .map primitives, and so on.) Once I get some time on my hands (yeah right) I'll probably start there and work my way up to the GUI later on. > The .MAP format made of filled convex blocks isn't suitable, in my not > possibly humble opinion. That's the way you build houses in the open, > not the way you dig mines. What do we care about the exterior of the level? > How come it's even calculated? It can even cause errors (leakage). Another facet of good editors -- scene validation. Leakage should be simple though. John Carmack even told us (somewhere) how he does. > And of course, you should be able to edit the level while walking > inside, not via some lame combination of 2D views or delayed camera view. I agree on you totally here. After trying out Build (although it is severely limited) I have become convinced that this is the only way really good levels can be built. (It makes it so easy to add that final touch, and placing the really cool details.) > That screams for a portal based scheme. ? The Way My Ideal Editor Would Work - ---------------------------------- (And no I am not implying that I will ever try to implement this. It could be fun, but I could never find the time for it.) * Basically there should be three modes for editing level layout: 1) Brush editing A library of `building blocks' will be necessary to create levels in a reasonable amount of time. Also this is handy to create a consistent look throughout the levels. (Placing similar looking columns, furniture and so on helps maintain a theme.) These brushes has to be creatable and editable. Also CSG must be present to combine brushes. Basically union, intersection and negation is necessary. In my experience CSG eases editing very much. It allows you to create simple to semi-complex stuff in no time and has a very nice learning curve for beginners (or non-techies). 2) Map editing Using the brushes to add to the scene (place stuff) or subtract from the scene (drill holes). Also some operations to translate or rotate large parts of (or perhaps the entire) scene must be present. Moving and deleting individual brushes after they are placed must also be possible. This is used to build architecture, place furniture and other such stuff. Also textures and lights can placed at appropriate places. Lights are of course only used in pre-processing. I am guessing dynamic lights will be entities. 3) Entity placement Placing monsters, health, dynamic lights, switches, doors, bridges and what not. All the rest, so to speak. All these three modes should ideally be accessable at the same time so you don't have to spend time switching screens or even programs. All modes must also be able to work on subsets of the level so the user can concentrate on the task at hand. All editing should be possible using the following views (now this is where I get out of hand): a) Isometric Generic isometric with a view-vector and view-window defined. Hot keys or menu items for `snapping' the view to +X, -X, +Y, -Y, +Z and -Z must be available. Also you must be able to snap to the nearest 45 degree vector so you can get that typical isometric top-down view. b) Perspective The well known view-point and view-direction scheme. As used in Quake. Also hot keys for `snapping' the view should be available. If possible a `Quake Simulation' would be ideal. It doesn't have to simulate AI or any such stuff. But trying the level out (even just in wire-frame) with scene-gravity, and other such server parameters set, could be very useful. (For instance: checking to see whether the player can reach a ledge by jumping or getting a feel for the size of the level.) Both views should be available in wire-frame and textured modes. Texture mapping does not have to be very accurate (ie. perspective correct in perspective mode is not necessary). Just enough to enable proper texture alignment. Both modes should be able to use colour to enhance depth perception and minize drawing overheads. Anyway, this is probably best doable in an environment where 3D API's are available that will allow hardware accelleration and so forth. Wire-frame (with hidden surface removal) should be possible anywhere though. ("Put away that Speccy, Kiddo" :) All editing must be done with an editing plane defined (moving vertices and so forth parallel to it). And for rotation, arbitrary axises (sp?) must be placable. Note: I think a properly done isometric view-scheme is more important than the perspective ``walking in the level'' view-scheme. Also texture mapping, z-buffering and even projection is a lot easier in this. * For the CSG routines it is of prime concern to: 1) Keep precision high, so brushes don't become more and more complicated because of repeated intersections and unions. 3D Studio has this problem to a high degree. Math should probably be integer were possible. (Isn't this why John Carmack chose to have plane definition vectors integer in the .map file?) 2) Fast. We do not wish to wait all day just because we tried to cut a cube out of a wall. Internal map representations should probably maintain a strong position coherence between brushes, so we don't have to check every brush against each other everytime we move something. 3) Perform closures correctly. (Is this the wrong term? I'm rephrasing from memory.) [Foley, et al, Principles and Practice...] has some nice comments on this. Don't know how implementation friendly all of the algorithms are though. * This is of course without considering .mdl editing, .qc editing (seems like a lot of the switch logic and similar stuff has to be placed here), texture-editing, sprite-editing, sound-editing, etc. Any comments? Bye, Uffe. [uphfe] uffefl@diku.dk - -- "Doom was fun, Quake was fun. Now for a *real* challenge... REAL LIFE!" - Anonymous moron "That sucks, let's burn it!" - Beavis (Non-Anonymous moron) ------------------------------ From: Mads Dydensborg Date: Fri, 7 Jun 1996 13:23:23 +0200 (METDST) Subject: Re: Editor GUI design On Thu, 6 Jun 1996, Bernd Kreimeier wrote: > > > Just to get things started (gee, from the looks of it I am > the only one using this mailing list), here`s one. More to > come. Since so few are using this at the moment, please don't flame a newbee for some (more or less) stupid comments. > > 1) The Axial Bias > > I haven`t had the opportunity to do serious work with QuakeEd, Well, only a few has. I'm not one of them either, but.. [..] > > -Brush (Group) rotation operations > -Brush Templates, > (sets of) polyhedra approximating curved, non-axial surfaces, > just a libary > -a separate Brush Editor (Mode) All of this, should of course be a minimum IMHO. > -DXF/3DS Import A DXF => brush converter would be sufficient IMO. [about views during editing] > > Possible solutions: > > -mlook mode > -4 Views, three of them axial, one free > > Comments anybody? What I would try, (But I don't know if it can be done), would be to have an 'instant' preview window, that is the equviliant of the view when playing Quake. When editing I belive frame rates in the order 1-3 ps would be much better than fixed views, and the view could be controlled in the same matter as the player in Quake. I hope that this can be possible using e.g. OpenGL or similar - the typical Quake editor will probably have some very decent hardware. I realise that the map format is not ideal for fast 3d rendering, but the OpenGL stuff I've seen has been quite fast, even for texturemapped stuff. Well, that is what I would try to aim for. >From a not-arrogant dane Mads +----------------------------------------------------------------------+ | Mads Bondo Dydensborg. Student at DIKU, Copenhagen - Denmark. | | Email: madsdyd@diku.dk www: http://www.diku.dk/students/madsdyd/ | +----------------------------------------------------------------------+ ------------------------------ From: Rick Clemmer Date: Fri, 07 Jun 1996 07:50:19 -0500 Subject: Re: Palette Matching At 06:48 PM 6/6/96 -0400, you wrote: >X-gamers.org: quake-dev@gamers.org > >Bernd Kreimeier wrote: >> >> Has anybody taken a look at the Doom PlayPal vs. the >> Quake palette? I did some matching runs with various >> metrics in RGB space, and there are very few exact >> matches, and a larger number of severe mismatches. I >> haven`t (yet) tried to convert an actual DOOM texture >> to the Quake Palette, but prospects do not look good. >> Dithering might help. Has anybody with some experience >> in handling limited palettes tried? >> >> Which, in turn, means that converted or re-done Doom >> maps should possibly stick to the PlayPal - meaning >> they cannot use the skin textures matching the Quake >> palette. In addition, a palette lump should accompany >> the mipmaps (in the BSP or elsewhere). It`s only 768 >> bytes, after all, and in perfect agreement with the >> thinking that puts the mipmaps in the BSP. >> >> b. > >My last project before QMapHack was a set of utilities for personal use that would take a set of images and >orient them to use the same palette. With some modifications, I could attempt to convert some DOOM2 textures >to QUAKE textures. However, I have not had much experience a far as DOOM2 file formats, so I need to know how >to extract the textures and palette from DOOM2 to try this. > Rob Shields Get WinTex 4.2 it can read the DOOM/DOOM2 pallettes and textures. After it reads them just save them to a file. Rick Clemmer ------------------------------ From: Olivier Montanuy Date: Fri, 7 Jun 1996 15:10:29 +0200 Subject: RE: Editor GUI design >Construction of a level would probably be easier if you had only the >`constructive' approach, not the `destructive'. The "mine" image wasn't correct in fact Building a Quake levels should be more like building a space station (well, if you already practiced this as a hobby...). You start from a room, and add more room elements. Convex, like the brushes, but instead of being filled, their are empty. The calculation cannot be more complex than with current brushes. Of course, we could also use normal filled brushes (for some internal furniture) but mainly it has to be done with empty ones. It's as constructive as your approach, but with different stuff. and at least you don't have to wonder about the "exterior", and possible leakage (which are going to be a bore). >Any editor worth it's salt will have both options of course. What we'll >really need for Quake Editor Development is a set of CSG library functions. Ok for the functions. But I think it's the current .MAP format that causes troubles. Whatever CSG you use, you'll have to convert the result into a set of filled brushes, which will make a lot of data. > Note: I think a properly done isometric view-scheme is more important > than the perspective ``walking in the level'' view-scheme. I agree with this... as long as the level is some kind of building with layers. With caves, it's useless. How about VR helmets, now. Olivier ------------------------------ From: "Dark Shadow" Date: Fri, 7 Jun 1996 10:19:25 -0400 Subject: RE: Palette Matching - ---------- > From: Bernd Kreimeier > To: quake-dev@gamers.org; bernd@marvin.nero.uni-bonn.de > Subject: Palette Matching > Date: Thursday, June 06, 1996 3:12 PM > > > Has anybody taken a look at the Doom PlayPal vs. the > Quake palette? I did some matching runs with various > metrics in RGB space, and there are very few exact > matches, and a larger number of severe mismatches. I > haven`t (yet) tried to convert an actual DOOM texture > to the Quake Palette, but prospects do not look good. > Dithering might help. Has anybody with some experience > in handling limited palettes tried? > > Which, in turn, means that converted or re-done Doom > maps should possibly stick to the PlayPal - meaning > they cannot use the skin textures matching the Quake > palette. In addition, a palette lump should accompany > the mipmaps (in the BSP or elsewhere). It`s only 768 > bytes, after all, and in perfect agreement with the > thinking that puts the mipmaps in the BSP. > > > b. Question: Can't you just completely replace the Quake palette with the DOOM palettes? This is a technique I used to totally convert DOOM to the Heretic palette on a project of mine (never released) that made all the nice textures of Heretic (and later HeXeN) fit in DOOM without all that crap that looks like you're on an LSD trip. Since the textures are included in each map file, from what I've read, you could totally replace the palette lump in the BSP and include all the "new" DOOM textures needed in there. Is this just being stupid, or what? - -j ------------------------------ From: Bernd Kreimeier Date: Fri, 7 Jun 1996 16:33:36 +0200 (MET DST) Subject: ADMIN reminder About each recent posting in the "Palette Matching thread" used full quotation. Please remove all obsolete lines and restrict to the necessary parts. Thank you. b. ------------------------------ From: Bernd Kreimeier Date: Fri, 7 Jun 1996 16:41:33 +0200 (MET DST) Subject: RE: Palette Matching > From: "Dark Shadow" > > From: Bernd Kreimeier > > Has anybody taken a look at the Doom PlayPal vs. the > > Quake palette? I did some matching runs with various > Question: Can't you just completely replace the Quake palette with the > DOOM palettes? Sure. You will not be able to combine Quake and DOOM textures. To be able to mix needs a good palette matching. > Since the textures are > included in each map file, from what I've read, Nope. The mipmaps are in the BSP file. > you could totally replace > the palette lump in the BSP I checked the worklog, and did not find the note the Uffe Friis mentioned. For all I know, it is still in the WAD2. b. ------------------------------ From: Mike Ruete Date: Fri, 07 Jun 1996 10:57:21 -0500 (EST) Subject: Re: Editor GUI design On Thu, 6 Jun 1996, Chris Carollo wrote: > > -4 Views, three of them axial, one free > > In Quest, I'm including four primary look directions (+X, +Y, -X, > -Y), and also the ability to look in the +Z and -Z directions (in > reference to primary look direction). All vertex/edge/brush editing > is done perpenticularly to the camera direction. This way, the > user cannot change the "depth" of any entity, which is fairly > intuative. Perhaps you should consider the ability to change the camera direction to be perpendicular to, or coplanar with any surface of the level. In most cad programs, this is a very useful ability. I'd also suggest adding the ability to "grab" a face of a brush and move it "in and out" along it's normal. This would be most useful for six-sided polyhedra, but could have it's uses elsewhere. I've done a reasonable amount of CAD work, and I find multiple views to be extremely helpful. When I edit, I usually have an isometric view, a left side view, a front view, and a top view. I edit in the left, front, and top, but I often use the isometric for getting a feel for what I'm building, and also for selecting edges and faces that would otherwise be overlapped and hard to select in axial views. If I were making an editor, I'd code my wire-frame renderer to work in its own separate window. This way spawning another view and switching the "primary" one would be a lot easier. > The downside is that designing very complex brushes (no faces > pependicular to any of the view directions) can be a real pain. > I'm thinking of adding a "edit-the-current-brush-only" mode where > the camera can be rotated freely around the brush. My guess is that > the vast majority of brushes will _not_ be complex, and this will > not be a major problem, and I won't have to bother coding this. ;) That's not really a valid assumption, though. Speaking as a member of TeamTNT (creators of TNT: Evilution and ICARUS: Alien Vangaurd), I can assure you that what people, especially talented level authors, look forward to most about Quake level editing is the ability to make wacky, non-orthogonal walls/cielings/whatever. If we wanted to do more mostly orthogonal stuff, we'd just keep editing DOOM. I think non-axial views and the ability to (relatively) easily create *very* complex brushes is vital. - -Mike Ruete ------------------------------ From: Bernd Kreimeier Date: Fri, 7 Jun 1996 17:37:29 +0200 (MET DST) Subject: Re: Editor GUI design >From: Mike Ruete > Perhaps you should consider the ability to change the camera >direction to be perpendicular to Second that. I think texture alignment should work like this: click on the facet in any view, one view shows the facet with textures, perpendicular, and the adjacent facets with perspective correct texture mapping. This is for manually fixing NAT screwups. >I'd also suggest adding the ability to "grab" a face of a brush >and move it "in and out" along it's normal. Agreed. Add to this: create facet from vertex (triangle on a cube, as many vertices as incoming edges in general), and collapse facet to vertex. In both cases, you might click on a facet (i.e. the new one), and again a view perpendicular is spawned. Moving the vertices in 2D will tilt the plane in 3D. >I'd code my wire-frame renderer to work in its own >separate window. This way spawning another view and switching the >"primary" one would be a lot easier. This should work within one window as well, with 1 and 4 overlayed Drawing Panes, or am I mistaken. Anyway, the basic idea is sound: each renderer is one object with one (part of) the window. I loathe the windowitis that drowns my desktop in a dozen separate ones, though. >I think non-axial views and the ability to (relatively) easily >create *very* complex brushes is vital. I agree. Think of (approximations) of pipes/spheres/tanks. It does not look like creating a six- or many-sided pillar is a on-stop-shop task in QuakeEd. b. ------------------------------ From: Mike Ruete Date: Sat, 08 Jun 1996 11:17:33 -0500 (EST) Subject: Re: Editor GUI design On Fri, 7 Jun 1996, Bernd Kreimeier wrote: > This should work within one window as well, with 1 and 4 overlayed > Drawing Panes, or am I mistaken. Anyway, the basic idea is sound: > each renderer is one object with one (part of) the window. I loathe > the windowitis that drowns my desktop in a dozen separate ones, > though. If you mean like what WinTex does, I hate that two. What I had in mind was something where you have a main view window, and that window is subdivided into smaller windows. Also, I'm not too familiar with XWindow, so I may have no clue what you're talking about. :) > I agree. Think of (approximations) of pipes/spheres/tanks. It > does not look like creating a six- or many-sided pillar is a > on-stop-shop task in QuakeEd. Speaking of which... Back to the idea of primitives. All primitives should have a "root" point/axis, and there should be plenty of options for aligning that within your level. A couple methods that spring to mind are setting the root point of the primitive on the endpoint/intersection of an edge, and aligning the axis parallel/perpendicular to an existing edge. Also, rotating a primitve about its root axis should probably be the final step in primitive insertion. - -Mike Ruete ------------------------------ From: Nick Rasmussen Date: Sat, 08 Jun 1996 12:08:18 -0500 Subject: Too tied to brushes? Are brushes really the way to go with a new editor? Obviously, if you want to use id's qbsp et al you have to have brushes in the .map file, but I think that the task of creating the brushes is one that could be handled by the editor as the map is saved. A much more intuiative interface (for me at least) is one where you control texture on a per-polygon (and perhaps a per-group of polygons) level. This, along with a perpendicular-to-polygon viewpoint would lend itself easily to alinging textures. Also, not having to bother with the brushes would probably allow faster level design. - -Nick Rasmussen ------------------------------ From: Bernd Kreimeier Date: Sat, 8 Jun 1996 22:21:40 +0200 (MET DST) Subject: Re: Editor GUI design From: Mike Ruete >All primitives should have a "root" point/axis, and >there should be plenty of options for aligning that >within your level. You've lost me. Could you explain? Is this selecting an edge, and/or a vertex, as a frame of reference for moving/rotating the brush? As for aligning two brushes, this reminds me of some related questions: a) is an editing mode with polyhedra-polyhedra 3D collision detection worth the hassle? b) here is a next interaction: pick two facets of two brushes. Now press "glue". One brush will be rotated and translated to stick to the other, selected facet on selected facet. Now there are only 3 degrees of freedom left: in the plane defined by the two parallel facets, move in x,y, or rotate by some angle. >>windowitis >If you mean like what WinTex does, I hate that too. I was actually thinking Sun Mailtool... dunno about WinTex, unfortunately it does not run with Linux :-(. b. ------------------------------ End of quake-dev-digest V1 #10 ****************************** From owner-quake-dev-digest@gamers.org Mon Jun 10 16:51 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id QAA26086 for ; Mon, 10 Jun 1996 16:46:45 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id KAA29716 for quake-dev-digest-outgoing; Mon, 10 Jun 1996 10:46:00 -0400 From: owner-quake-dev-digest@gamers.org Date: Mon, 10 Jun 1996 10:46:00 -0400 Message-Id: <199606101446.KAA29716@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #11 Reply-To: quake-dev@gamers.org Errors-To: owner-quake-dev-digest@gamers.org Precedence: bulk X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 27292 X-Lines: 754 Status: RO quake-dev-digest Monday, 10 June 1996 Volume 01 : Number 011 ---------------------------------------------------------------------- From: Bernd Kreimeier Date: Sat, 8 Jun 1996 22:32:50 +0200 (MET DST) Subject: Info from John Carmack (9) Here's another one. Btw., the flip/mirror question was indeed a stupid one - recognized this too late. And it must be s_ofs t_ofs rot_angle s_scale t_scale obviously, as most Plane lines read "...0 0 0 1 1" now. b. - ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Fri Jun 7 20:29 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Fri, 7 Jun 96 13:26:18 -0500 To: Bernd Kreimeier Subject: Re: q&a (6) Content-Type: text/plain; charset="us-ascii" Content-Length: 3559 You wrote: > > Q: gravity is fixed along Z. Would there be unreasonable overhead > assigning a gravity/current/force vector to a volume (like the > water/lava attribute is maintained)? We have "push triggers" that assign a velocity when you are inside them. We use them for flinging players through gerbil tubes. They aren't exactly what you want (you have no control when in them), but it is just qc code and could be changed easily. There are efficiency issues with using them all over the place, but they aren't too bad. > Q: besides lava-style texture animation, is there a simple s/t > scroll animation? Different speeds? Not for normal textures, because the light map samples are tied to a block structure. I could slide the turbulent textures, because they don't have lightmaps, but I haven't put any interface in for it. It will probably show up in Quake 2. > Q: wouldn`t it be better to include the palette (768 bytes) along > with the mipmap lumps in the BSP? Solely for using DOOM playpal, or > other full palette replacements. MDL skins etc. will be a problem, > but entities are external references anyway. The palette is included along with the misc graphics, like the console and status bar. If you want to use a different palette, you are going to have to create all new graphics for everything else. I really doubt it is worth it. > > Q: am I mistaken that, with "s/t_ofs s/t_scale rot", it is not > possible anymore to flip/mirror a texture, because of using NAT's? A negative scale is a flip. > > This is confusing :-(. Ceterum censeo: shouldn't NAT's be assigned > within QuakeEd/any editor, and the result be saved as (s,t). > Semi-auto texture alignment is an editor feature. The brushes > aren`t human readable anyway. Ah well, I will shut up on this one. > The .map file is the editor file format, so it has representations convenient for the editor. The .bsp file has representations convenient for rendering. I tried just putting in s/t vectors for the planes, but it makes many editor operations cumbersome. I know, I know. It doesn't feel right to me either. > Q: the MAP format does not allow for persistent hierarchy/grouping > (which is useless for qbsp, but useful for editing). Care to > comment on: > > --------------------------------- >{ > "classname" "worldspawn" > "message" "The House" > { > "_label" "The Bathroom" > { > ( .., .., .. ) WALLTILE .... > ( .., .., .. ) WALLTILE .... > ... > } > { > // more brushes > } > // end bathroom > } > { > "_label" "The Living Room" > { > ( .., .., .. ) CARPET .... > // more brushes > } > } > // more rooms >} > ------------------------------- This is changing with my NT editor. The entity grouping groups brushes very nicely allready. I am just going to add a little change to qbsp so that an entity with a classname of "submodel" or something will just be merged into the world entity for bsp generation. > The MAP files will have a life expectancy exceeding Quake's by far. > As far as 3D map editing is concerend, it is time to think > "progressive refinement" - or "kaizen". Btw., the more I think my > way through brush based editing, the more I like it - this has been > a damn good idea. Yes, I still think I made the right decision for solid based editing, and I think it will be adopted widely. I was charmed to see Epic using my "brush" terminology in describing their unreal editor :-). John Carmack - ----- End Included Message ----- ------------------------------ From: Bernd Kreimeier Date: Sat, 8 Jun 1996 22:41:27 +0200 (MET DST) Subject: Re: Info from John Carmack (4) John Carmack wrote: >> will the linux version be ... as modules (gcc-linkeable) >I have intentions to do so, but since Dave Talor left id This is a comment from Dave Taylor. - ----- Begin Included Message ----- >From ddt@crack.com Mon Jun 3 20:25 MET 1996 From: Dave Taylor To: Bernd.Kreimeier@NeRo.Uni-Bonn.DE Subject: Re: Linux Quake port > a) Thanks heaps welcome > b) If you get around to release a LinuxQuake, would it be possible > to release it as linkable modules like the intended DJGPP release > (see mail quoted below)? Should be. > c) ... > Would it be possible to run LinuxQuake with DDE/IPC > to control player position and LOS from the editor, i.e. to > use LinuxQuake as an interactive preview (including monster > animation)? It would of course be possible to write this. However, it won't be written. Sorry. =-ddt-> - ----- End Included Message ----- ------------------------------ From: jschuur@onlinemagic.com Date: Sun, 9 Jun 1996 00:39:40 +0000 (GMT) Subject: list your quake editing project i'd like to list all the quake editors currently under developement on aftershock, in it's diy section. have a look at http://www.nuqneH.org/aftershock/diy/editorsmake.html and drop me a line if you're working on an editor you'd like to have mentioned there. -- joost schuur, Online Magic Ltd. ----------- Tel: +44 171 820 7766 -- ----------------------------------------------------------------------- ---------------------------------------------------------------------- - --- http://www.nuqneH.org/~jschuur/ ---- jschuur@onlinemagic.co.uk --- ------------------------------ From: Andrew Gilpin Date: Sat, 08 Jun 1996 23:29:07 -0500 Subject: Re: list your quake editing project jschuur@onlinemagic.com wrote: > > i'd like to list all the quake editors currently under developement on > aftershock, in it's diy section. have a look at > > http://www.nuqneH.org/aftershock/diy/editorsmake.html > > and drop me a line if you're working on an editor you'd like to have > mentioned there. > > > > -- joost schuur, Online Magic Ltd. ----------- Tel: +44 171 820 7766 -- > ----------------------------------------------------------------------- > ---------------------------------------------------------------------- > --- http://www.nuqneH.org/~jschuur/ ---- jschuur@onlinemagic.co.uk --- I am one of the programmers working on QMapHack, but I think it is already listed on the DIY page. Anyways the homepage for QMapHack is http://www.eve.net/~rshields/ - -- Andrew Gilpin mailto:agilpin@eve.net http://www.eve.net/~agilpin/ ------------------------------ From: Uffe Friis Lichtenberg Date: Sun, 9 Jun 1996 20:58:34 +0200 (METDST) Subject: RE: Editor GUI design On Fri, 7 Jun 1996, Olivier Montanuy wrote: > Building a Quake levels should be more like building a space station > (well, if you already practiced this as a hobby...). ;) > You start from a > room, and add more room elements. Convex, like the brushes, but instead > of being filled, their are empty. > The calculation cannot be more complex than with current brushes. Well, that's OK if you want to build a space station/mine/and so on, but for other architectural ideas it might not be ideal. I agree the _calculations_ can't be more complex than the other way round, but converting them back to .map is surely gonna be more complex when you do subtractive CSG operations rather than additive. Still, a good editor should support both ways... > It's as constructive as your approach, but with different stuff. > and at least you don't have to wonder about the "exterior", and possible > leakage (which are going to be a bore). Well sure, leakage is gonna suck, but with proper .map validation routines it should be possible to detect automatically and perhaps even fix semi-automatically. > Ok for the functions. But I think it's the current .MAP format that causes > troubles. Whatever CSG you use, you'll have to convert the result into a set of > filled brushes, which will make a lot of data. Exactly. It the to .map function that will be the hard one to code. I have been thinking somewhat like this: BTW: This is C++ which makes me think: what would be of most interest to the rest of the Quake editing community, C or C++? (Mads: I'm not going to use Delphi, no I'm not! ;) class CSGtree { public: CSGtree(Brush b); // Instantiate leaf // + other constructors and the usual stuff CSGtree operator+(const CSGtree other) const; // return union of *this and other CSGtree operator*(const CSGtree other) const; // return intersection of *this and other CSGtree operator-(void) const; // (unary minus... is this the correct syntax? can't really remember) // return negation of *this PolygonMesh toPolygonMesh(void) const; // return polygon mesh representing CSGtree CSGtree normalize(void) const; // return `normalized' CSG representation (self-made terminology) // (ie. one using only unions; an any-order traversal of the // tree would produce output suitable for a .map file) Brush toBrush(void) const); // return a single brush representing *this (if possible) CSGtree transform(Matrix4x4 m) const; // transform node and leaves using the given matrix CSGtree translate(Vector3 v) const; // translate node and leaves using the given vector // (ie. setup matrix and use transform() for naive implementation CSGtree rotateX(float a) const; // rotate... // + all the other handy editing functions you could think of... } (Of course this interface is very `top-level' and should be optimized with references or pointers where appropriate. Also non-const (but state-changing) functions should be available to offer efficiency where you know you won't be needing the `old' instance. This should give the general idea... Otherwise tell me I'm rambling :) (I'm assuming proper classes for PolygonMesh and Brush, but this should be somewhat more trivial. PolygonMesh would probably just be a list of polygons, but rendering could possibly benefit from using BSP or other pre-sorting, as they shouldn't be recalculated constantly. A Brush would probably just be a list of planes. Here BSP might be useful too, who knows.) All operations should then be performed upon CSG representations with operators at the nodes and brushes at the leaves. The tricky functions will be toPolygonMesh(), normalize() and toBrush(). toPolygonMesh() should be managable. The trick will be to keep the polygon count relatively low (ideally as low as possible). If the given CSGtree is a leaf (ie. a brush) it should be (relatively) trivial to perform all intersections between the planes to get list of polygons. Otherwise you would just apply the funcion recursively and then unite/intersect/negate polygon meshes. `Dead' polygons (ie. polygons inside the object, never visible) should of course be culled. Real problem: speed and accuracy. Check out 3D Studios boolean operations on their triangle-meshes. Verry buggy/slow/inadequate. Speed will probably never reach real-time rates, so an editor will need to remember the PolygonMesh returned by toPolygonMesh() and only force a recalculation when necessary. normalize() should identify the smallest amount of brushes necessary for the conversion. Unions are easy: they convert one-to-one, but if the union can be represented as one brush (ie. it is still convex) it should be reduced to that (using toBrush()). Intersections are easy too: just collapsing the two brush representations (list of planes) produces correct output, but redundant planes (ie. planes that have no influence on the objects shape) should be removed. As goes for negation: well, I'll have to think on that (anybody?) as this might influence the rest of the process. Perhaps converting a negation of an n-planed brush to n-large-enough-brushes defining the outside as inside would be sufficient. But it must also be applicable to a CSG'ed child... Hmmm... toBrush() simply checks wether the CSG representation is convex and, if so, converts it to a plane-list (ie. brush). Redundant planes are stripped. (But how to identify these? Oh well, paper and pencil...) I have a feeling all this work has been done before, so I'll probably be doing some litterature searching soon. Anybody know any good texts on CSG? > I agree with this... as long as the level is some kind of building with layers. > With caves, it's useless. Of course. I forgot layers! A good editor _must_ be able to define part of the scene as a group (/layer) and enable the user to easily distinguish between the groups (/layers). Probably using colours. This of course has no relation to what you just said but the word `layer' triggered something :) For caves you are right. The only way to do this easily is to walk around inside the level. Perspective and all... > How about VR helmets, now. Heh... Even if I could afford one (which I can't) I wouldn't use one, let alone buy one. The quality of available/semi-affordable VR helmets I have tried is low.... (I take this was a jest anyway ;) Bye, Uffe. [uphfe] uffefl@diku.dk - -- "This .signature hasn't been left unintentionally void of blankness" ------------------------------ From: Uffe Friis Lichtenberg Date: Sun, 9 Jun 1996 21:01:36 +0200 (METDST) Subject: RE: Palette Matching On Fri, 7 Jun 1996, Bernd Kreimeier wrote: > > you could totally replace > > the palette lump in the BSP > > I checked the worklog, and did not find the note the Uffe Friis > mentioned. For all I know, it is still in the WAD2. I was probably wrong... (On the other hand... Oh well, better go searching ;) Zonk, Uffe. [uphfe] uffefl@diku.dk - -- "This .signature hasn't been left unintentionally void of blankness" ------------------------------ From: Uffe Friis Lichtenberg Date: Sun, 9 Jun 1996 21:19:53 +0200 (METDST) Subject: Re: Editor GUI design On Sat, 8 Jun 1996, Bernd Kreimeier wrote: > a) is an editing mode with polyhedra-polyhedra > 3D collision detection worth the hassle? Hm. Possibly. But it will be a bitch to code efficiently. Let's concentrate on functions that will allow us to align objects first, like (b). Then work from that. > b) here is a next interaction: pick two facets of > two brushes. Now press "glue". One brush will > be rotated and translated to stick to the > other, selected facet on selected facet. Now > there are only 3 degrees of freedom left: > in the plane defined by the two parallel facets, > move in x,y, or rotate by some angle. Ooh I like that. I hadn't really given much thought to alignment functions yet... What about (I assume a work-plane and work-line has been defined): c) `Snap to plane'. Translate selected object along work-plane normal so the center of the object (ie. (0,0,0) in object coordinates) lies on the work-plane. d) `Snap to line'. Translate selected object along a normal to the work-line, where the normal used goes through the center of the object. The center of the object ends up on the work-line. e) `Rotate about line'. Using the work-line as axis, rotate selected object any amount. f) `Move parallel to plane'. View switches so the view-plane is parallel to the work-plane. Objects can then be moved parallel (in screen XY) to the work plane. Moving the object along a work-plane normal (in screen Z) could possibly be achieved using another set of keys or a held mouse-button or something. g) `Drop object'. Place object in 3-space and let go. Object falls (along gravity vector) to the floor. (Option: if the floor is tilted the object migh slide until it comes to rest???) h) Work-plane must be translatable and rotatable (around work-line). Also it must be settable to any face in the scene or to a span of any three vertices. i) Work-line must be translateable and rotatable (around another work-line?). Also it must be settable to any edge in the scene or to a span of any two vertices. j) `Hang object'. Place object in 3-space and let go. An invisible wire is connected between the work-line (arbitrarily placed or closest point) and the center of the object. Then the object is transformed as if it was hanging in that wire from the work-line. k) I could go on... ;) Zonk, Uffe. [uphfe] uffefl@diku.dk - -- "This .signature hasn't been left unintentionally void of blankness" ------------------------------ From: Mike Ruete Date: Sun, 09 Jun 1996 17:10:11 -0500 (EST) Subject: Re: Editor GUI design On Sat, 8 Jun 1996, Bernd Kreimeier wrote: > >All primitives should have a "root" point/axis, and > >there should be plenty of options for aligning that > >within your level. > You've lost me. Could you explain? Is this selecting > an edge, and/or a vertex, as a frame of reference for > moving/rotating the brush? Yes, that's exactly what I meant. You'd have to select and edge (or a line selected from two points) that would be your axis, then you select another point (usually on the axis) which would be the origin of the brush's frame of reference. Then when you went to insert the brush, for example, you could select the mid-point of an existing edge to put the origin at, and then choose, for example, to align the axis with another existing edge. > a) is an editing mode with polyhedra-polyhedra > 3D collision detection worth the hassle? I doubt it. Doesn't on of id's utilities (qbsp, I think) do clipping of brushes before the final list of vertices and edges is determined (and before nodes are built)? Of course, if you're using home-grown node builders and other utils (which I'm sure we all eventually will be seeing as we can't all get access to a 4-processor alpha for nodes and lightmaps), then it's most definitely worth the hassle, because you probably wouldn't be able to make a proper map without it. - -Mike Ruete ------------------------------ From: Mike Ruete Date: Sun, 09 Jun 1996 17:21:19 -0500 (EST) Subject: Re: Info from John Carmack (4) > This is a comment from Dave Taylor. [snip] > > c) ... > > Would it be possible to run LinuxQuake with DDE/IPC > > to control player position and LOS from the editor, i.e. to > > use LinuxQuake as an interactive preview (including monster > > animation)? > > It would of course be possible to write this. However, it won't be > written. Sorry. This sounds like the Duke3D (build) editor. If you haven't seen it, you owe it to yourself to check it out and get an idea of its power. It actually uses the build engine inside the editor to show you *exactly* what your level will look like in the game (of course, your gamma settings won't be the same, and some of the sprites are scaled differently). It also allows a lot of editing in the 3d preview mode. Things like light levels, textures, floor/cieling height/slants can be changed. It's really an incredibly powerful editor, and if I ever try to develop a quake editor, i'd try and make it look alot like the Duke3d editor. Oh, and running the editor in 800x600, it displays the 3d preview faster than the actual game runs in 320x240. :) - -Mike Ruete ------------------------------ From: Rob Shields Date: Sun, 09 Jun 1996 22:45:47 -0400 Subject: Doom2 pics with Quake palette I have been able to convert the Doom2 images to use the Quake palette. I used DMView and just extracted all of the pics, then converted them all, mainly because I did not want to sort through 2288 images looking for textures. We now have the 2288 Doom2 images using the Quake palette. They take up 13.6 megabytes uncompressed, 5.5 megabytes zipped with the -ex parameter. They mostly look the same as the originals, if they are different they are slightly darker giving a "scarier" effect. Now that I have these images, how should I go about getting them to those in this mailing list who want them? Rob Shields ------------------------------ From: Bernd Kreimeier Date: Mon, 10 Jun 1996 11:13:08 +0200 (MET DST) Subject: Re: Editor GUI design >> a) is an editing mode with polyhedra-polyhedra >> 3D collision detection worth the hassle? > I doubt it. Doesn't on of id's utilities (qbsp, I think) do >clipping of brushes before the final list of vertices and edges is >determined (and before nodes are built)? > > -Mike Ruete Been misleading. I meant as a GUI option for editing - a paradigm :-). It does some kind of auto-alignment for brushes: set a gravity or a push direction, and drop the thing into the map. You only have to check all facets of the moving brush against all others, is O(N_brushes) or O(N_facets). This is not useful for CSG operations, obviously :-). b. ------------------------------ From: Bernd Kreimeier Date: Mon, 10 Jun 1996 11:35:50 +0200 (MET DST) Subject: Re: Doom2 pics with Quake palette > From: Rob Shields > I have been able to convert the Doom2 images to use the Quake palette. Great. Saves me some hassle. > They mostly look the same as the originals The match I made with a 2*delta_Red + 3*delta_Green + 1*delta_Blue gave less than 30 exact matches, and about the same with a perceived distance >= 20.0. Prospects did not look to good. Will be interesting to see your images (and the mipmapped versions, later). > how should I go about getting them to those in this mailing list > who want them? Legal issues: you should not distribute DOOM registered or commercial textures. It would be great if you could separate those from the DOOM shareware WAD. Next, the conversion is a "derivative work". We should ask id prior to any distribution. Finally, the Quake palette has changed (there are more than 16 whites in a sequence, and John Carmack mentioned additional explosion colors, see Info (7) mail) - thus the matches might change again. A few shareware textures as example, exported as GIF might be a good idea. Perhaps you could download the DOOM Palette GIF from my palette page at http://www.gamers.org/dEngine/quake/wad_conv and apply the same conversion, I will happily upload the result, and look at the index->index mapping. Does anybody know what kind of palette matching algorithm DMVIEW actually uses? Is the source available (the author around)? b. P.S.: the remark by John Carmack in Info (5) seemed to indicate that Adrian Carmack and Kevin Cloud did not like the results of a similar conversion. I wonder what kind of matching they tried, and when. ------------------------------ From: Olivier Montanuy Date: Mon, 10 Jun 1996 11:37:32 +0200 Subject: Re: Editor GUI design > If you mean like what WinTex does, I hate that two. What I had >in mind was something where you have a main view window, and that window >is subdivided into smaller windows. Also, I'm not too familiar with >XWindow, so I may have no clue what you're talking about. :) Just to let you know: the main reason why WinTex opens a dozen small windows that keep popping out everywhere ... is because of a limitation of Visual Basic. Of course I would prefer to have just ONE windows, and alter it's shape depending on context. It's the best solution. I hope everyone will do that for Quake editors! But it's just not possible with a lame tool like VB. If you look at the WinTex main window, it already has 4 overlapped frames (with only one visible) and that's enough to make Vb crawl like hell. Olivier (WinTex runs fast on a P200) ------------------------------ From: matt.tagliaferri@pcohio.com (Matt Tagliaferri) Date: Mon, 10 Jun 1996 09:23:00 -0500 Subject: Re: Editor GUI design q > Just to let you know: the main reason why WinTex opens a dozen small w q > that keep popping out everywhere ... is because of a limitation of Vis q >Basic. q > Of course I would prefer to have just ONE windows, and alter it's shap q > depending on context. It's the best solution. I hope everyone will do q > for Quake editors! q > But it's just not possible with a lame tool like VB. If you look at th q > WinTex main window, it already has 4 overlapped frames (with only one q >visible) q > and that's enough to make Vb crawl like hell. q > Olivier I do NOT want to start any "my tool is better than yours" war here, I would just like to let Olivier know that I too was a VB programmer, and converted to Delphi with the help of a fellow programmer I met in the Doom editing mailing list. If you have a basic knowledge of Pascal, you're more than 1/2 way there. IT's just as easy a tool to use as VB, once you know a few tricks. If you have any interest in learning this tool, Olivier, please contact me privately. I'd be happy to help in any way I can, including sharing source with my Delphi-converted DoomCAD to get you started. matt tagliaferri matt.tagliaferri@pcohio.com - --- * PW * _ _ ------------------------------------------------------------- |_|_| PC-OHIO PCBoard Online * pcohio.com * V34+ 33.6: 216-381-3320 |_|_| The Best BBS in America * Cleveland, OH * Go Tribe ------------------------------------------------------------- ------------------------------ From: Mike Ruete Date: Mon, 10 Jun 1996 10:49:19 -0500 (EST) Subject: Re: Editor GUI design On Mon, 10 Jun 1996, Olivier Montanuy wrote: > Just to let you know: the main reason why WinTex opens a dozen small windows > that keep popping out everywhere ... is because of a limitation of Visual Basic. That's why god (or at least someone at Bell Labs) gave us C. :) > Olivier > (WinTex runs fast on a P200) - -Mike Ruete (WinTex runs fast on a P100 w/ 32MB EDO ------------------------------ End of quake-dev-digest V1 #11 ****************************** From owner-quake-dev-digest@gamers.org Wed Jun 12 09:23 MET 1996 Received: from olymp.informatik.uni-bonn.de (root@olymp.informatik.uni-bonn.de [131.220.4.1]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id JAA00981 for ; Wed, 12 Jun 1996 09:23:11 +0200 (MET DST) Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with ESMTP id AAA18295; Wed, 12 Jun 1996 00:39:18 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id SAA11600 for quake-dev-digest-outgoing; Tue, 11 Jun 1996 18:20:40 -0400 From: owner-quake-dev-digest@gamers.org Date: Tue, 11 Jun 1996 18:20:40 -0400 Message-Id: <199606112220.SAA11600@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #12 Reply-To: quake-dev@gamers.org Errors-To: owner-quake-dev-digest@gamers.org Precedence: bulk X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 26147 X-Lines: 709 Status: RO quake-dev-digest Tuesday, 11 June 1996 Volume 01 : Number 012 ---------------------------------------------------------------------- From: Jim Lowell Date: Mon, 10 Jun 1996 10:44:34 -0500 Subject: Tools (was Re: Editor GUI design) At 10:49 AM 6/10/96 -0500, Mike Ruete wrote: > > >On Mon, 10 Jun 1996, Olivier Montanuy wrote: > >> Just to let you know: the main reason why WinTex opens a dozen small windows >> that keep popping out everywhere ... is because of a limitation of Visual Basic. > > That's why god (or at least someone at Bell Labs) gave us C. :) > ... and C is why Borland gave us Delphi. :) - -= Jim Lowell =- ------------------------------ From: Rob Shields Date: Mon, 10 Jun 1996 12:46:00 -0400 Subject: Re: Doom2 pics with Quake palette Bernd Kreimeier wrote: > Legal issues: you should not distribute DOOM registered or commercial > textures. It would be great if you could separate those from the > DOOM shareware WAD. Next, the conversion is a "derivative work". We > should ask id prior to any distribution. Finally, the Quake palette > has changed (there are more than 16 whites in a sequence, and > John Carmack mentioned additional explosion colors, see Info (7) > mail) - thus the matches might change again. > > A few shareware textures as example, exported as GIF might be a good > idea. Perhaps you could download the DOOM Palette GIF from my palette > page at http://www.gamers.org/dEngine/quake/wad_conv and apply the > same conversion, I will happily upload the result, and look at the > index->index mapping. > > Does anybody know what kind of palette matching algorithm DMVIEW > actually uses? Is the source available (the author around)? > > b. DMView did not do the palette matching, I did. My algorithm extracted the Quake palette from GFX.WAD, and the Doom2 palette from the first bitmap it scanned. I then made a look up table between the two palettes as to which entries in the Doom2 palette corresponded to which entries in the Quake palette. If there were no exact matches, I found the closest one by using an adapted version of the distance formula, (((r2-r1)^2)+((g2-g1)^2)+((b2-b1)^2))^(1/2). Then I just went through the bitmaps created by DMView, replaced the palette with the Quake palette, then went through the actual picture data and replaced the old bytes with the corresponding new values as defined in the look up table. So I now have 2288 .BMP files which use the Quake test palette. I wrote the program in QuickBASIC 4.5 for ease of debugging, and I can post the source code here if you want. Rob Shields ------------------------------ From: Bernd Kreimeier Date: Mon, 10 Jun 1996 19:03:22 +0200 (MET DST) Subject: Re: Doom2 pics with Quake palette From: Rob Shields [ ADMIN - please do not do full quotes - b. ] >Bernd Kreimeier wrote: >> Does anybody know what kind of palette matching algorithm DMVIEW >> actually uses? Is the source available (the author around)? >DMView did not do the palette matching, I did. > ... >If there were no exact matches, I found the closest one by using >an adapted version of the distance formula, > ((r2-r1)^2)+((g2-g1)^2)+((b2-b1)^2))^(1/2). > ... >I wrote the program in QuickBASIC 4.5 for ease of debugging, and I >can post the source code here if you want. Not necessary, but I would appreciate confirmation of the exact matching formulae. What does "adapted" mean? Remark: the distance formulae above does not take into account the human eye's differing sensibility for the base colors - usually, we are most sensitive for varying Green, and far less for Blue. This should change some of the matches (and results). Have you tried e.g. the 2/3/1 weighted formulae, or something else (some day I will try HSV just for curiosities sake), or the straight 1/1/1 weights only? b. Btw.: perhaps we should postpone further experimentation until the final Quake palette is available. ------------------------------ From: Mads Dydensborg Date: Mon, 10 Jun 1996 21:29:15 +0200 (METDST) Subject: Off topic : Delphi NOTE : This message concerns Delphi and is meant primarily for Quake developers (wannabe's), that would like to develop using Delphi. If you want to reply/comment, you should answer to me personally, unless b. gives a green light for discussion. (Hope this one starter is OK. Don't flame, please). There has been some people commenting about Delphi, and ease of use, etc. I too use Delphi (and prefer it to both C(++) and VB) I would like to hear if there is a general interest among Delphi- subscribers to this list, in establishing some Delphi-Quake forum? The forum should off course be regarded as an supplement to this list and other ressources (like the developer pages, etc), and should just help Delphi programmers with implementing Quake related stuff. I personally could envision that the forum could contain information as : - - interfacing with OpenGL. - - interfacing with DirectDraw - - BSP file handling routines - - PVS building routines - - MAP handling routines - - CSG handling routines - - MipMap handling routines (Well, I did write something here ;-) - - etc All of these will propably quickly be available with C(++) interfaces, but I, for one, would like to have some true Delphi code to work with. Would anyone else care to contribute to something like this? Please answer directly to madsdyd@diku.dk (unless you dare cross b.'s directions.) Mads (Once again : Please forgive me for beeing slightly off-topic). +----------------------------------------------------------------------+ | Mads Bondo Dydensborg. Student at DIKU, Copenhagen - Denmark. | | Email: madsdyd@diku.dk www: http://www.diku.dk/students/madsdyd/ | +----------------------------------------------------------------------+ ------------------------------ From: Rob Shields Date: Mon, 10 Jun 1996 15:42:17 -0400 Subject: Re: Doom2 pics with Quake palette Bernd Kreimeier wrote: > Not necessary, but I would appreciate confirmation of the exact > matching formulae. What does "adapted" mean? Remark: the distance > formulae above does not take into account the human eye's differing > sensibility for the base colors - usually, we are most sensitive for > varying Green, and far less for Blue. This should change some of the > matches (and results). Have you tried e.g. the 2/3/1 weighted formulae, > or something else (some day I will try HSV just for curiosities sake), > or the straight 1/1/1 weights only? > > b. > > > > Btw.: perhaps we should postpone further experimentation until the > final Quake palette is available. Sorry, I wasn't very clear. All I meant by adapted was that I had changed the x,y, and z to r, g, and b. The program only uses equal weighting for all differences, but it could be easily modified to do otherwise. Also, when we have a final version of Quake, once we know where the palette is I simply have to rewrite the part of the code that extracts the Quake test palette so that it extracts the real Quake palette. Once the Doom2 palette image from the Quake-Dev support pages is posted in converted form (I have already converted it and b. will probably post it soon) we can try the weighted formula and compare the two images. Rob Shields ------------------------------ From: Denis Date: Mon, 10 Jun 1996 23:21:14 +0200 Subject: Re: Doom2 pics with Quake palette Hi! At 11:35 10.06.1996 +0200, you wrote: >The match I made with a 2*delta_Red + 3*delta_Green + 1*delta_Blue >gave less than 30 exact matches, and about the same with a perceived >distance >= 20.0. Prospects did not look to good. 30 matches? Hmm? >Does anybody know what kind of palette matching algorithm DMVIEW >actually uses? Err, no, but I used to add a FitPalette function to NWTpro some months ago. This is to fit two different palettes, no dithering or something, just finding the closest match... (I made this off my mind, so don't expect anything) PalA[768] has the original palette and PalB[768] has the 'to' palette - both in RGB-form (values don't exceed 64 for 256 colors). - --- char DPal[256]; for (dmax=3000,i=0;i<256;i++) { for (k=0;k<256;k++) { h1=(PalA[i*3]-PalB[k*3]); h2=(PalA[i*3+1]-PalB[k*3+1]); h3=(PalA[i*3+2]-PalB[k*3+2]); d=sqrt(h1*h1+h2*h2+h3*h3); if (dP.S.: the remark by John Carmack in Info (5) seemed to indicate that >Adrian Carmack and Kevin Cloud did not like the results of a similar >conversion. I wonder what kind of matching they tried, and when. What I (we) always most hated about the Doom palette was its incredible lack of dark red colors... cya Denis - --- Denis Moeller, author of NWTpro v1.4 and TiC's WAD Reviews. e-mail: d.moeller@rendsburg.netsurf.de, #irc: panza http://www.geocities.com/Hollywood/2299/ ------------------------------ From: jelson@conline.com (Jim Elson) Date: Mon, 10 Jun 1996 17:12:06 -0500 Subject: Re: Doom2 pics with Quake palette At 12:46 PM 6/10/96 -0400, quake-dev@gamers.org wrote: >Bernd Kreimeier wrote: > >> Legal issues: you should not distribute DOOM registered or commercial >> textures. >> b. > >I wrote the program in QuickBASIC 4.5 for ease of debugging, and I can post the >source code here if you want. I'm not sure, but pessimistic, about how Wilbur would fill about distributing those GFX. However, although it'd be more work for them, providing the source would allow others to duplicate your results without legal entanglements. - --H2H ============================================================================ H2HMud NorthAmerican DeathMatch Tourney Promo/Marketing Coordinator for "The New Technology: Evilution" - ---------------------------------------------------------------------------- jelson@conline.com; WEB page ==> http://www.conline.com/~jelson/index.html ------------------------------ From: Jim Lowell Date: Mon, 10 Jun 1996 18:46:45 -0500 Subject: Sorta off-topic : Delphi At 09:29 PM 6/10/96 +0200, Mads Dydensborg wrote: > >There has been some people commenting about Delphi, and ease of >use, etc. I too use Delphi (and prefer it to both C(++) and VB) > >- interfacing with OpenGL. >- interfacing with DirectDraw >- BSP file handling routines >- PVS building routines >- MAP handling routines >- CSG handling routines >- MipMap handling routines > I'm the guy who got Matt interested in Delphi and use is a ton myself. My main interest in this direction would be to use Delphi to generate a set of published free DLLs that other developers could use regardless of what language they're programming in. If someone were to do this, it would make tools-development fast. Delphi is a VERY easy language to get DLLs out in. Of course, along those lines, if John Carmack were to encapsulate some of his common NT Quake-editor routines into DLLs and publish the interface for them, then we could just use those. Is John on this mailing list? Does anyone want to ask him to do this? :) - -= Jim Lowell =- ------------------------------ From: Bernd Kreimeier Date: Tue, 11 Jun 1996 16:58:00 +0200 (MET DST) Subject: Re: Doom2 pics with Quake palette From: Jimmy Sieben (private mail, public reply) >On Mon, 10 Jun 1996, Bernd Kreimeier wrote: >> Legal issues: you should not distribute DOOM registered or commercial >> textures. It would be great if you could separate those from the >> DOOM shareware WAD. Next, the conversion is a "derivative work". We ... > Just curious, why would shareware textures be different? I thot those >are still copyrighted by id? That's why I mentioned "permission", as in "permitted derivative works". Because the DOOM.EXE is identical in shareware/registered/retail, permission of redistribution is not likely for DOOM2 and registered artwork. Of course, we might not get permission for shareware even. OTOH, id might put it under the same free license John Carmack mentioned in Info (3), which is kinda necessary with mipmaps in the BSP files. On the gripping hand, distribution of a conversion tool that everyone applies to whatever DOOM stuff he (rightfully) owns is still the last resort. b. ------------------------------ From: Bernd Kreimeier Date: Tue, 11 Jun 1996 17:42:56 +0200 (MET DST) Subject: Re: Off topic : Delphi Mads wrote: >Delphi forum >unless b. gives a green light for discussion. As long as postings are Quake related, and not too specific (like "debug my source" or "how do I install the compiler") this is perfectly appropriate. Feel free to drop references, announcements, and pointers. As I did with Mesa and the GUI stuff, and others hopefully will. A Delphi forum with a source repository sounds like a very good idea - as would be a similar C or C++ repository. >I personally could envision that the forum could contain >information as : > - BSP file handling routines > - PVS building routines I strongly second the notion of establishing a reference library of some kind, be it for C, C++ or Delphi. b. P.S.: gotta relax that "iron fist in the iron glove" approach a bit, it seems :-). ------------------------------ From: Troy Stephens Date: Tue, 11 Jun 1996 12:05:00 -0400 Subject: PVS generation (Please forgive my ignorance if this topic has already been discussed; I'm a newcomer to this list.) I'm interested in sharing ideas and info regarding visible-surface determination in general, and the techniques Quake uses in particular. I just got through reading Mike Abrash's Jan/Feb '96 DDJ article "Inside Quake: Visible Surface Determination", and I'm left with one big question in particular: I understand how a BSP tree annotated with potentially visible set (PVS) info can be used to speed culling and reduce overdraw. But how exactly is the PVS precomputed? I spent a little time thinking about it this morning, and it certainly seems to me that the key lies in judiciously choosing a few sample points within a convex subspace to serve as representative viewpoints. Once you have a suitable set of sample viewpoints, you should be able to determine which leaves are definitely not at all visible from ANY of the sample points, and that presumably gives you the PVS for that convex subspace. (I think of it as calculating a PVS for each sample viewpoint, then merging the PVSs for all the sample viewpoints conservatively, so that a leaf is only kicked out of the PVS for the subspace if it isn't visible from ANY of the sample viewpoints.) I suspect that maybe the corner vertices of a convex subspace might serve as suitable representative viewpoints (i.e. that they can be used to generate a correct PVS for the subspace in this way), but I haven't yet thought about it enough to prove or disprove this to myself. Anyone have any ideas, experience, insights (or inside info?) in this area? - -Troy ------------------------------ From: bstastnX@td2cad.intel.com Date: Tue, 11 Jun 1996 09:27:44 -0700 Subject: Planes Vs Polygons Hello all, I am interested in how people are holding the brush information within their editors. Are people converting the data from the .map file into polygons right away? Or are people keeping the plane representation for editing and just converting to polygons during the display level in the editors? Does anyone see an advantage to keeping the Plane information handy during editing that I may be missing? thanks bret stastny ------------------------------ From: Bernd Kreimeier Date: Tue, 11 Jun 1996 19:09:05 +0200 (MET DST) Subject: Re: PVS generation >How is it done See the summary of Michael Abrash's article on the Quake Developers Pages (VSD - Visible Surface Determination), and the Info(5) mail in the june archive. See especially the PhD thesis by Seth Teller which is available online (pointer on said page), and clarifies some issues. The basic idea is determining "portals": polygons that allow for looking into adjacent leafs. As far as I understand, one takes each portal of a given leaf, and determines some kind of beam tree/ frustrum through the portals in adjacent leafs, and so on. The generated frustrums/beams will be split and cut by each subsequent portal, until they are completely stopped by a wall. Think of it as each window (portal) of a leaf being an area light source casting an anti-penumbra into the world. Every other leaf reached by the light is part of the PVS. Sampling on a grid is definitely not a good idea. Doing a simple raycasting from each center of a leaf might serve as a "fast vis" function. Clipping by distance is another idea that will not correctly determine a PVS, but will be fast. Any other ideas? b. ------------------------------ From: Rob Shields Date: Tue, 11 Jun 1996 14:51:58 -0400 Subject: Re: PVS generation Bernd Kreimeier wrote: > Sampling on a grid is definitely not a good idea. > Doing a simple raycasting from each center of > a leaf might serve as a "fast vis" function. > Clipping by distance is another idea that will not > correctly determine a PVS, but will be fast. Any > other ideas? > > b. > > A BSP builder could have several options for quality. One could raycasting from the center of a leaf, another could be from the center and the corners, etc. Increasing the number of origins for the rays each higher level of quality. Rob Shields ------------------------------ From: larsen@sunset.cs.utah.edu (Steve Larsen) Date: Tue, 11 Jun 1996 13:25:50 -0600 Subject: Re: PVS generation > >>How is it done > [snip, snip] >Sampling on a grid is definitely not a good idea. >Doing a simple raycasting from each center of >a leaf might serve as a "fast vis" function. >Clipping by distance is another idea that will not >correctly determine a PVS, but will be fast. Any >other ideas? Agreed. A grid, and in particular choosing the "corners" or center of the leaf, will fail very frequently. I have considered a few different approaches, including (listed in order of complexity): 1. Above mentioned radial test. 2. Using full portal-based adjacency graph. 3. Using a distance constrained portal sequence. Step through the portals adding only leaves within a certain radius from the source leaf. 4. Using simplified portal stabbing line algorithm that over- exagerates the PVS. In addition, there are two additional possibilities I think are relevant. Both correctly calculate the PVS, not approximate as above: 5. Seth Teller and Michael Hohmeyer have demonstrated a O(n*log(n)) method for portals comprised of isothetic rectangles. 6. Many others (including Teller et al) have contributed algorithms to compute stabbing lines for a collection of oriented polygons. Most of these are in the O(n^4) range, but decrease as constraints are applied. (NOTE: n is number of edges in portal set for above). Here is my take on these methods, YMMV. 1. This will work only in small, enclosed areas. Any large areas will be rife with artifacts. 2. The full adjacency graph will probably wind up being near the entire set of leaves for most levels. Very little would be gained over the trivial accept method. 3. I believe this method has promise as a "quick and dirty" PVS process. It will have artifacts as well as 1. However, since you are actually following the portal graph, and hence rejecting many near but non-visible leaves, you can extend the radius and decrease the frequency of error. The calculations should be quite managable on a PC, IMO. 4. Haven't really explored the possibilities here yet. This could work pretty well, or could also wind up being close to 5, 6 in complexity depending on what "simplified" methods could be discovered. 5. This is great as long as all your doors are axial rectangles. 6. Full blown method. Will likely be VERY computationally expensive. May not be feasible for use on a PC. One nice thing about these PVS calculations is that they are perfectly suited to parallelization. So, if you have access to an MP machine you could greatly benefit. My gut feeling is this for generating .bsp files: BSP node generation: This will become a trivial step. Should be able to get it down so that it is within 2-3 times as slow as generating DOOM maps (which on any Pentium is most negligible, so I guess it will be 1/2 to 1/3 negligible ;) Lightmap generation: If you have a PVS set available (and a PVS aware lightmap generator), you could probably do a pretty decent lightmap in say twice as long as the BSP. Visibility: Discussed above. I expect this to end up taking > 75% of the time for full-blown level generations when all is said and done. These are my opinions/guesses, not fact. I could be way off on this. I will not be responsible for lying to millions of people ;) Steve ------------------------------ From: Matt Houser Date: Tue, 11 Jun 1996 15:47:59 -0400 (EDT) Subject: Re: Planes Vs Polygons In the production of 'Shaker' I use the conversion from planes to polygons only for display purposes... Why? So I don't have to calculate the planes back later for saving to map files... also, because it's easier to make sure things are coplanar when you work with planes than it is when working with vertices or lines. Some people may have get used to it but it's the best safeguard for coplanarity (a word?) The conversion to vertices and polygons is only for the user to see what he's doing, to see how planes interact with each other... I see no other real purpose that doesn't really screw up the simplicity. Take for example a cube. If you manipulate just one of the vertices, you'll screw up the co-planarity of atleast 1 side... If you "push" and "pull" the planes, you ensure things are coplanar. ...Matt - -- ================================================================== Matt Houser IRC: Fisty email: mwhouser@interlog.com, mwhouser@undergrad.math.uwaterloo.ca URL: http://www.undergrad.math.uwaterloo.ca/~mwhouser - -- "After all this time, fruit salid still starts with an 'F'!" ------------------------------ From: Troy Stephens Date: Tue, 11 Jun 1996 18:21:09 -0400 Subject: Re: PVS generation Bernd Kreimeier wrote: > > See the summary of Michael Abrash's article on the > Quake Developers Pages (VSD - Visible Surface > Determination), and the Info(5) mail in the june > archive. See especially the PhD thesis by Seth > Teller which is available online (pointer on said > page), and clarifies some issues. Thanks. The message you mentioned helped a bit. I also downloaded the first part of Seth Teller's thesis this morning (and learned that lpr truncates postscript files bigger than 1 meg on the Unix machine I regularly use!). I had the opportunity to meet Seth this past semester when he (an alum of our physics dept.) dropped by to give a talk about his work. Glad I didn't miss that one. The walkthru video he showed was pretty darn impressive for a 3/4 million polygon dataset. I'm also interested in how John Carmack implemented his version, though, since it is probably quicker on the precomputation end, and adequate for models more on the order of 10,000 polygons in complexity. > The basic idea is determining "portals": polygons > that allow for looking into adjacent leafs. As far > as I understand, one takes each portal of a given > leaf, and determines some kind of beam tree/ > frustrum through the portals in adjacent leafs, > and so on. The generated frustrums/beams will > be split and cut by each subsequent portal, until > they are completely stopped by a wall. This much makes sense. I think the detail that I'm missing, though, is how the origin(s) for the beam tree(s) through a portal is/are selected. I'll have to see what Seth Teller has to say about this. > Doing a simple raycasting from each center of > a leaf might serve as a "fast vis" function. > Clipping by distance is another idea that will not > correctly determine a PVS, but will be fast. Any > other ideas? The trick with this PVS stuff, of course, is, failing all else, you have to be conservative: it's okay (though undesirable) to mark a leaf that can never be visible from leaf X to be potentially visible from leaf X, but you can't mark a leaf as invisible from leaf X if you should be able to see any part of it from at least one viewpoint in the leaf X subspace... I'll let you know what I find out after giving Seth's thesis a look. Thanks again for the pointers! - -Troy /\/\o Troy Stephens '97 / \ \/\ Wesleyan University / \ \ \ tstephens@wesleyan.edu - ---------------------------------------------------------------------------- http://www.con.wesleyan.edu/~tstephens/tstephens.html ------------------------------ End of quake-dev-digest V1 #12 ****************************** From owner-quake-dev-digest@gamers.org Mon Jun 17 20:51 MET 1996 Received: from olymp.informatik.uni-bonn.de (root@olymp.informatik.uni-bonn.de [131.220.4.1]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id UAA10163 for ; Mon, 17 Jun 1996 20:51:06 +0200 (MET DST) Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with ESMTP id UAA13585; Mon, 17 Jun 1996 20:50:40 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id OAA01472 for quake-dev-digest-outgoing; Mon, 17 Jun 1996 14:50:12 -0400 From: owner-quake-dev-digest@gamers.org Date: Mon, 17 Jun 1996 14:50:12 -0400 Message-Id: <199606171850.OAA01472@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #13 Reply-To: quake-dev@gamers.org Errors-To: owner-quake-dev-digest@gamers.org Precedence: bulk X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 26455 X-Lines: 756 Status: RO quake-dev-digest Monday, 17 June 1996 Volume 01 : Number 013 ---------------------------------------------------------------------- From: Olivier Montanuy Date: Wed, 12 Jun 1996 12:11:02 +0200 Subject: Re: PVS generation >The basic idea is determining "portals": polygons >that allow for looking into adjacent leafs. Well, if they really have to determine portals, I can't help but wonder why the heck they need a BSP tree. Anyone who played Duke Nukem knows that a portal-based scheme is more flexible than a BSP based scheme. > The generated frustrums/beams will be split and cut by each >subsequent portal, until they are completely stopped by a wall. That would probably be a suitable description for the 3D engines of both Descent and Duke Nukem. > Every other leaf reached by the light is part of the PVS. > Any other ideas? Calculate PVS on the fly, like every serious game does ;-) Actually, if your leaf has areas not accessible to players, those areas might register into the PVS other leaves that no player will ever see. Then the engine will calculate all the 3D transform for these leaves, just to discard it later. So I suspect the PVS calculation need not be very precise. Anyway there ain't no good alternative to an Indigo Impact. Olivier ------------------------------ From: Bernd Kreimeier Date: Wed, 12 Jun 1996 16:04:13 +0200 (MET DST) Subject: Re: PVS generation From: Olivier Montanuy >but wonder why the heck they need a BSP tree. The advantage of a BSP is that there is an overall order of polygons. If you can afford sorting, or have a fast hardware z-buffer, and if there is no way to avoid overdraw, or terminate a front-to-back traversal as soon as the frame is complete, you do not need a BSP. Another, even more important advantage lost is hierarchical clipping (entire subtrees) against the view frustrum, in object space. The world has to be static if a PVS is used. Btw., IBM's DOOM clone WebView3D switched from 2D BSP to sector map usage. As for Descent and Duke Nukem, IIRC these are restricted geometry engines (distorted cubes, and DOOM-style), right? Of course one might get away with less lookups in these cases. As Michael Abrash quoted, "programming is an exercise in caching". Necessary, of course, because of limited resources. There is no way around hierarchical spatial subdivision. Whether you use BSP, Octree, or something else is up to you... > Anyone who played Duke Nukem knows that a portal-based scheme > is more flexible than a BSP based scheme. > ... > Calculate PVS on the fly, like every serious game does ;-) You know, an interactive preview with a Quake editor could actually put this to good use. This is what I had in mind with the Difference Engine renderer: write your own. If it happens to be too slow for actual gaming in the end, use it as a good preview with an editor :-). You will learn a lot, one way or the other. b. ------------------------------ From: Mike Ruete Date: Wed, 12 Jun 1996 11:32:07 -0500 (EST) Subject: Re: PVS generation On Tue, 11 Jun 1996, Troy Stephens wrote: > I'm also interested > in how John Carmack implemented his version, though, > since it is probably quicker on the precomputation end, I'm not convinced. I'm pretty sure I've heard (don't remember where) that some of the levels they have at id take up to an hour to computer the vis-lists on their 4-processor alpha. Even if that is faster than what teller does, I don't it's fast enough for the average level designer. - -Mike Ruete ------------------------------ From: Olivier Montanuy Date: Wed, 12 Jun 1996 17:48:50 +0200 Subject: Re: PVS generation > Another, even more important advantage lost is hierarchical >clipping (entire subtrees) against the view frustrum, I suppose portals can be checked against the view frustum, stopping the rendering if they are outside. >The world has to be static if a PVS is used. Reasonably static, not totally static. So long as all convex areas remain convex, and portals don't move... > As for Descent and Duke Nukem, IIRC these are restricted geometry engines Descent is restricted to cubes (but it can be generalised to any convex blob). Duke is more restricted than Quake, but no normal gamer will ever notice! Briges, slopes, superposed levels, ... of course water and lifts are done with teleporters. >As Michael Abrash quoted, "programming is an exercise in caching". and "cashing". Or so they say in Redmond. >You know, an interactive preview with a Quake editor could >actually put this to good use. This is what I had in mind with >the Difference Engine renderer: write your own. I wish I could! That idea raised almost 10 months ago when hacking out the UQS 2.2. Never found enough time since! That's why I lurk here, hoping someone will catch the bait. Difference Engine is a good idea. Free time is a better one! > If it happens to be too slow for actual gaming in the end, Methink you'll soon call it Descent3 or Prey ;-) Olivier ------------------------------ From: Uffe Friis Lichtenberg Date: Wed, 12 Jun 1996 18:01:30 +0200 (METDST) Subject: Re: PVS generation On Wed, 12 Jun 1996, Bernd Kreimeier wrote: > Another, > even more important advantage lost is hierarchical > clipping (entire subtrees) against the view frustrum, > in object space. But using a BSP certainly isn't the only way to subdivide space hierarchically. I have given it a lot of thought and I can't seem to understand why a BSP should be so much more effective than a portal-based scheme with a graph connecting the convex hulls. (Like Descent and probably Duke Nukem too.) > The world has to be static if a PVS is used. Exactly! A much too big disadvantage IMO! > There is no way around hierarchical spatial subdivision. > Whether you use BSP, Octree, or something else is up to > you... Of course. Unless you restrict yourself to ridiculously (sp?) simple geometry. Anyway, I'm drifting off-topic now I guess. I think I will give a graph-based approach a shot sometime. Just to see the difference. > > Calculate PVS on the fly, like every serious game does ;-) Agreed! (: Zonk, Uffe. [uphfe] uffefl@diku.dk - -- "This .signature hasn't been left unintentionally void of blankness" ------------------------------ From: Troy Stephens Date: Wed, 12 Jun 1996 14:12:23 -0400 Subject: Re: PVS generation Olivier Montanuy wrote: > > Calculate PVS on the fly, like every serious game does ;-) Something tells me I oughta know how to interpret that smiley, Olivier, but my ignorance has got the better of me here. Are there actually any games that do PVS or PVS-like computations on the fly? (And if so, do they run on anything less than an SGI workstation?) > Anyway there ain't no good alternative to an Indigo Impact. Awww. But that sucks all the fun out of clever optimizing!... ;-) /\/\o Troy Stephens '97 / \ \/\ Wesleyan University / \ \ \ tstephens@wesleyan.edu - ---------------------------------------------------------------------------- http://www.con.wesleyan.edu/~tstephens/tstephens.html ------------------------------ From: Troy Stephens Date: Wed, 12 Jun 1996 14:23:44 -0400 Subject: Re: PVS generation Olivier Montanuy wrote: > > > As for Descent and Duke Nukem, IIRC these are restricted geometry engines > Descent is restricted to cubes (but it can be generalised to any convex > blob). Duke is more restricted than Quake, but no normal gamer will ever > notice! Briges, slopes, superposed levels, ... of course water and lifts > are done with teleporters. Where can one come by technical info on the Descent engine? - -Troy ------------------------------ From: Olivier Montanuy Date: Thu, 13 Jun 1996 10:58:19 +0200 Subject: Re: PVS generation > Are there actually any games that do PVS or PVS-like computations on >the fly? Descent, for instance. "on the fly" computation is made for a single point (the player) and is fast, whereas for a whole volume it's much more complex. But you have to do it for all players position, i.e. almost all the time. Guess why Descent can set a limit on the max distance for rendering. For more info, see the Descent editing FAQ and the Descent engine description. I don't know of any other real full 3D games that does it, and Descent is pretty limited to mine-like levels. Maybe id is right, but I doubt it. >> Anyway there ain't no good alternative to an Indigo Impact. >Awww. But that sucks all the fun out of clever optimizing!... ;-) Well, a dude from SGI told me they had to use a Z buffer (no other way possible) and for anti-aliasing they rendered 8 pixels for one on the screen (and took the mean color, I suppose). Then I looked at my pentium and millenium, and cried. Olivier ------------------------------ From: Bernd Kreimeier Date: Thu, 13 Jun 1996 13:28:51 +0200 (MET DST) Subject: Re: Doom2 pics with Quake palette I have updated the Palette Conversion pages at http://www.gamers.org/dEngine/quake/wad_conv/ with pictures demonstrating the unweighted match provided by Rob Shields, and the weighted match done by myself. There are two small PWADs that demonstrate the effects if used with DOOM (thanks to Rand Phares for the sample PWAD) - now you can see the world of DOOM through the eyes of Quake (hype mode off :). There are some remarks and references on the page. In short, doing a color-by-color matching will render [sic!] the artwork next to useless. I will try a global optimization that trades color accuracy (which will be less than sufficient anyway) for preserving the textures. I have already implemented a stocastic local search, results to follow. b. ------------------------------ From: phares@dg-rtp.dg.com (Rand Phares) Date: Thu, 13 Jun 1996 10:30:27 -0400 Subject: Re: Doom2 pics with Quake palette > ... > There are two small PWADs that > demonstrate the effects if used with DOOM (thanks > to Rand Phares for the sample PWAD) - now you can > see the world of DOOM through the eyes of Quake Glad it was OK. I wrote the RGB shift program last night to create the 13 secondary palettes, and will work on the HSV shift version tonight. I'll also take a look at the Quake/Doom palettes you've posted on the Web page. rand ------------------------------ From: "Brian K. Martin" Date: Thu, 13 Jun 1996 11:04:23 -0400 (EDT) Subject: Re: Doom2 pics with Quake palette > > > I have updated the Palette Conversion pages at > > http://www.gamers.org/dEngine/quake/wad_conv/ > I guess it isn't gonna work. I forgot if this was suggested, but I think the solution (which is no solution) is to do something like the doom convert program which converts doom2 files to doom1 or what ever. What I mean is you just have to go and find the closest texture match. If there is a doom texture with an average color of green, you match it with a quake texture that is kinda green. Of course one could try to remap the palettes by hand, and not worry if there is a blue to white fade, make it blue to black, or green to black. The results may not be too bad. brian martin ------------------------------ From: "Brian K. Martin" Date: Thu, 13 Jun 1996 13:43:47 -0400 (EDT) Subject: Re: Doom2 pics with Quake palette > > I guess it isn't gonna work. I forgot if this was suggested, > but I think the solution (which is no solution) is to do > something like the doom convert program which converts doom2 > files to doom1 or what ever. > uhhhh, I said that before playing the pwads. I guess the palette mapping is not too bad. I'd live with it for a deathmatch in dweller.. brian ------------------------------ From: "S. Patrick Gallaty" Date: Fri, 14 Jun 1996 21:52:56 +08:0 Subject: persisting servers and role playing I am curious to find out how many people here are interested in making servers with persisting characters, and are going to use quake to make an online MUD type of game? I for instance am one of those types who appreciates the hacking and toolmaking but my real skill is building worlds and organizing other people into coding efforts (I'm an archwiz on a large LPMUD). My plans are to make a game that's like the book 'Starship Troopers', with randomly generated missions, dropships, vehicles, etc. but with persisting characters and skill increases etc. I am interested to see how many others are interested in this same paradigm. I am willing to digest the answers to keep the traffic here down, or whatever. - -- S. Patrick Gallaty, Systems Administrator "Kein Vergnuegen ohne Gefahr!" patrick@diva.com ------------------------------ From: Bernd Kreimeier Date: Mon, 17 Jun 1996 11:23:52 +0200 (MET DST) Subject: Re: PVS generation Troy Stephens wrote: >> beam tree suggestion > I think the detail that I'm > missing, though, is how the origin(s) for the beam > tree(s) through a portal is/are selected. Disclaimer: this is entirely my guess, it doesn't look like Teller et.al. have tried something like this, and we have to wait for "vis" to check what John Carmack came up with. A beam-tree like approach could work like this: for each leaf ( == cell in Teller's description) for each portal to adjacent leafs for each portal in the adjacent leaf create an intial view frustrum from both portals while (beam tree not solid) { next leaf from BSP traversal for each portal within leaf if portal intersects beam tree update beam tree put leaf in PVS } The BSP traversal will of course clip subtrees against the beam tree or the intial frustrum. The processing is aborted as soon as the beam tree is solid. The disadvantage of beam trees Abrash mentioned is that performance is not level enough for realtime - this is no problem here. I do not dare think about complexity, though - depends on the relation between N_leafs and N_portals in the adjacency graph, i.e. bounds on the degree of the nodes, I guess. To answer the question: "create an intial view frustrum" could be anything. You might take each vertex of the first portal, and two adjacent vertices in the portal of the adjacent leaf, and create a clipping plane. Or you might determine the center of both portals, which will give you the overall direction, and use some bounding rectangles that will enclose the minimal beam tree. A side note: all this plane clipping stuff makes me wonder how PVS calculation on a hardware accelerator like the PowerVR might work... too bad that 3D accels aren't really coprocessors that could be queried conveniently. hope this helps b. ------------------------------ From: Bernd Kreimeier Date: Mon, 17 Jun 1996 11:24:57 +0200 (MET DST) Subject: Re: PVS generation Steve Larsen explained: >full portal based adjacency graph A side note: this beastie is valuable for all those considering writing a Bot. Precompute it, and use an A*-like shortest path, or your Bot will not find its way out of the bathroom with both hands and a ... map :-). > simplified portal stabbing line A stabbing line is a sightline intersecting all portals in a sequence. I have yet to think my way through this. Could you elaborate on the possible simplifications? > a O(n*log(n)) method for portals comprised of isothetic > rectangles You are talking about the algorithm referenced on pp. 55-58 in the thesis? Or the TH92 reference? Hmm, my dictionaries do not tell me what isothetic means... axial? > this is great as long as all your doors are axial rectangles Far out idea: approximate an arbitrarily oriented and shaped portal by a bounding box of six axial portals. This will increase the PVS in pathological cases, and increase the number of portals, but if O(n^4) is the alternative... > PVS-aware Lightmap generator A radiosity based approach might well not be worth the trouble of making it fit to NAT-grids, but at least it'd be something John Carmack hasn't done (yet). Is "light" actually a PVS aware raycaster? Sounds like a good idea, but for PC editing you will want a raycaster that does not require a PVS :-(. I wonder if John Carmack is actually using a stabbing line approach. The work log mentions portals, but no stabbing, and no adjacency graph (hah - finally put this stuff to some use, with good ol' grep). His Info(7) described a portal graph used for Sealing. Info (5) mentions not retaining the portal chain information. Hmmm. b. ------------------------------ From: Bernd Kreimeier Date: Mon, 17 Jun 1996 11:31:23 +0200 (MET DST) Subject: Info from John Carmack (10) - ----- Begin Included Message ----- >From johnc@idcanon1.idsoftware.com Sun Jun 16 19:40 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Sun, 16 Jun 96 12:38:35 -0500 To: Bernd Kreimeier Subject: Re: q&a (7) Content-Type: text/plain; charset="us-ascii" Content-Length: 4232 You wrote: > Q: spherical sky is approximated by six (qtest1?) or more polygons, > e.g. an isocahedron. Still true? How many triangles? All of them > culled/clipped against view frustrum each time there is a sky > surface within view? It isn't decomposed into polygons at all. The planar polygons that make up the sky are scaned just like a normal surface, but instead of doing a perspective subdivision, they do a spherical projection subdivision. Before we ship a 3d hardware version, we will have to subdivide them and just spherically project vertexes, but for software we are better off with what we have. > Q: dynamic lighting is based on lightsource/vertex distance? A > gradient in the ambient part of the light level calculation? Part > of the texture+lightmap->cached surface processing? It is done at the surface cache level, where every light sample has the dynamic lights intensitiy - distance added in. Having the entire scene dynamically lit cuts the game speed by about 30%, so it is mostly used for effects and accents. > > Q: does QuakeC allow for access to place billboards like the status > bar in the screen plane (overlay at x,y)? No. Early on, I tried to paramatize everything, so it would be a free form game engine, but expediency won out. > Q: all animated textures do not have lightmaps? This is a technical > necessity, or just too expensive (update cache every frame, instead > of shifting s,t)? Shouldn't these maxbright surfaces (lava) be area > lightsources for vis? > > I am still thinking texture animation should be entity based - > conceptually more elegant, but I am perhaps missing the amount of > overhead. Continuous frame cycling animation on regular surfaces has lightmaps, but the water and sky animations do not -- they bypass the surface cache entirely and draw straight to the screen. There is a slight amount of texture control on entities. A brush model entity (buttons, doors, etc) can control if it uses "normal" or "alternate" frames of animation. We use this so that buttons animate until the are pressed, then go to a darker dead texture when activated. I admit, it could use some more control here. > Q: is there a way to create walkable BSP objects? Could BSP objects > have a clipping/hull tree now? I don't think so - my guess is that > in a hierarchy of BSP's one would need to take into account all the > PVS's of those leafs in the parent tree it is (partially) in, in > addition to its own PVS. During the z-fill pass, of course, as long > as the POV is inside. Doable, but not on the list? Sorry, I don't understand. Doors, plats, trains, etc are all BSP objects that move through the world. The limitation is that the do not physically interact with the world or other BSP obejcts. Non-discrete box to BSP clipping is enough of a bitch, I don't even want to think about continuous bsp to bsp clipping. > Alternatively, is it possible to attach several BSP models to one > QuakeC entity - one point moves, and a dozen objects follows? In > this case, e.g. a vehicle could conveniently be composed from > several BSP models. No, not currently feasable, but we have had instances where we wanted to do that. > There is no way to assign multiple objects to the same entity, > right? Internal state and physics/visual representation are not > completely separable in Quake? Entities and drawable objects are one to one (or zero) mapped. I'm plenty open to still hearing wishes and suggestions now -- I'm going to be starting on my next generation engine in a month or so :-) John Carmack - ----- End Included Message ----- ------------------------------ From: Bernd Kreimeier Date: Mon, 17 Jun 1996 14:13:58 +0200 (MET DST) Subject: WAD2MAP conversion I did a few updates to the QuakeDev pages, one of them including a few thoughts on WAD2MAP conversion. Is somebody actually working on this? Iff, does your algorithm differ significantly from my approach? Does anybody have a pointer to a working code for 2D polygon partition? I had a look at the Joseph O'Rourke book, but doing a triangulization first, and than merging them again seems a bit of overkill. Usually we will deal with simple polygons and very few vertices. Any references? No, using a BSP is not a good idea :-). b. ------------------------------ From: larsen@sunset.cs.utah.edu (Steve Larsen) Date: Mon, 17 Jun 1996 12:49:52 -0600 Subject: Re: PVS generation > > simplified portal stabbing line > > A stabbing line is a sightline intersecting all portals > in a sequence. I have yet to think my way through this. > Could you elaborate on the possible simplifications? One of the methods Teller's thesis discusses regarding portal traversal is using groups of constrained stabbing lines to derive the antipenumbra of a line/surface light source. By intersecting these stabbing lines with other surfaces that contain portals, you can define a "visible area" on that surface. If a portal (or part of one) is contained in that area, you can add that portal to the sequence. However, finding these stabbing lines is not a trivial process. Now, I was thinking, what if you found stabbing lines that over-approximate the antipenumbra, but were easier to determine. Or a single stabbing line and then approximate the anti-penumbra using some heuristic. To be blatantly honest with you, I have really thought about it too much. It just seems like you could come up with a few ideas to try. > > a O(n*log(n)) method for portals comprised of isothetic > > rectangles > > You are talking about the algorithm referenced on pp. 55-58 > in the thesis? Or the TH92 reference? Hmm, my dictionaries > do not tell me what isothetic means... axial? Yes: isothetic rectangle == rectangle with edges parallel to principal axes. Ref: "Stabbing isothetic rectangles and boxes in O(n lg n) time" M. Hohmeyer and S. Teller Computational Geometry Theory and Applications 4 (1992) pp. 201-207 > > this is great as long as all your doors are axial rectangles > > Far out idea: approximate an arbitrarily oriented and shaped > portal by a bounding box of six axial portals. This will > increase the PVS in pathological cases, and increase the > number of portals, but if O(n^4) is the alternative... Yeah, I was thinking about this myself. Create an isothetic surface on the "wall" that contains the actual portal. The only drawback that I saw at a glance is that this exaggeration could potentially cause a large increase in the PVS. But to be fair, which of these approximations couldn't? Definitely worth some consideration. > > PVS-aware Lightmap generator > > A radiosity based approach might well not be worth the > trouble of making it fit to NAT-grids, but at least it'd > be something John Carmack hasn't done (yet). Is "light" > actually a PVS aware raycaster? Sounds like a good idea, > but for PC editing you will want a raycaster that does > not require a PVS :-(. I am not sure how "light" works. The lightmap generator I made will consider the PVS before building a lightmap for a surface. Working with the NATs was really not that big a deal, tho I must admit that I haven't tried it yet on a slanted surface, so it might be broke as hell in that case. ;) > I wonder if John Carmack is actually using a stabbing line > approach. The work log mentions portals, but no stabbing, > and no adjacency graph (hah - finally put this stuff to > some use, with good ol' grep). His Info(7) described a portal > graph used for Sealing. Info (5) mentions not retaining the > portal chain information. Hmmm. I don't think he is using stabbing lines in the strictest sense of the word, but I'm sure he's using a very similar concept. It will be interesting to see what he has done, if he releases the source. Steve ------------------------------ End of quake-dev-digest V1 #13 ****************************** From owner-quake-dev-digest@gamers.org Mon Jun 24 23:06 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 XAA05678 for ; Mon, 24 Jun 1996 23:06:18 +0200 (MET DST) Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with ESMTP id XAA28985; Mon, 24 Jun 1996 23:04:30 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id QAA07369 for quake-dev-digest-outgoing; Mon, 24 Jun 1996 16:26:39 -0400 From: owner-quake-dev-digest@gamers.org Date: Mon, 24 Jun 1996 16:26:39 -0400 Message-Id: <199606242026.QAA07369@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #14 Reply-To: quake-dev@gamers.org Errors-To: owner-quake-dev-digest@gamers.org Precedence: bulk X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 23939 X-Lines: 683 Status: RO quake-dev-digest Monday, 24 June 1996 Volume 01 : Number 014 ---------------------------------------------------------------------- From: "Brian K. Martin" Date: Mon, 17 Jun 1996 15:48:31 -0400 (EDT) Subject: MedDLe source code, if you want it... Since I'm gonna begin windows programming meddle, I have no time for dos meddle. The source is at http://www.phyast.pitt.edu/~brianm/mdlv1src.zip It is close to the released version of meddle with a couple of improvements. I'll warn you, the source is a mess, but you may get some texture mapping, or mouse functions out of it. I also included a crappy 3ds to mld converter. It may be of some use to someone. brian martin (zombywoof) ------------------------------ From: Chris Carollo Date: Mon, 17 Jun 1996 22:31:06 -0400 Subject: texture WAD? Out of curiosity, is anyone working on a utility that will manipulate texture WADS? i.e. Add/Remove/Import/Export textures into a texture "library"? I'm guessing that most editors will use a WAD file, following the lead of QuakeEd. I'd rather not spend my time on one if someone else is already working on one... :) - -Chris ------------------------------ From: stokfam@wisdom.psinet.net.au (Michael Stokes) Date: Tue, 18 Jun 1996 16:24:02 +0800 Subject: Re: texture WAD? >Out of curiosity, is anyone working on a utility that will >manipulate texture WADS? i.e. Add/Remove/Import/Export textures >into a texture "library"? > >I'm guessing that most editors will use a WAD file, following >the lead of QuakeEd. I'm working on a "Quake Desktop" that incorporates that kind of WAD editing features & other stuff... Mike. =============================================== Michael J Stokes http://www.psinet.net.au/~stokfam =============================================== ------------------------------ From: "Brian K. Martin" Date: Tue, 18 Jun 1996 09:26:57 -0400 (EDT) Subject: mdl source url... So sorry. The correct address is http://www.phyast.pitt.edu/~brian/mdlv1src.zip not /~brianm/ ------------------------------ From: Greg Lewis Date: Tue, 18 Jun 1996 16:50:25 -0400 (EDT) Subject: BSP edge list I've got a question concerning the edge lists. I'm iterating the surface data to find and draw all of the edges onscreen. From the Qspec 3.1 I assumed that if I go through the List of Edges and take the sign into account, the edges will always be given in a counterclockwise order around the surface. And, thus I would only need to compute half of the vertices (since the start of one is the end of the next edge). However, while going through the list it looks like the end of one edge is NOT always the same position as the start of the next edge. (I believe the first time this happens is surface 9, edge 1.) Can anyone confirm/deny this? It seems to me like the edges should form a closed polygon, i.e. each vertex is the start of one line and the end of another (after taking the sign flip into account). Greg P.S. CC's to me are appreciated, as I am on the digest and would like an answer soon. :) ------------------------------ From: Jim Bucher Date: Tue, 18 Jun 1996 17:10:41 -0500 Subject: Re: BSP edge list Greg Lewis wrote: > > I've got a question concerning the edge lists. I'm iterating the > surface data to find and draw all of the edges onscreen. From the Qspec > 3.1 I assumed that if I go through the List of Edges and take the sign > into account, the edges will always be given in a counterclockwise order > around the surface. And, thus I would only need to compute half of the > vertices (since the start of one is the end of the next edge). However, > while going through the list it looks like the end of one edge is NOT > always the same position as the start of the next edge. (I believe the > first time this happens is surface 9, edge 1.) Can anyone confirm/deny > this? It seems to me like the edges should form a closed polygon, i.e. > each vertex is the start of one line and the end of another (after taking > the sign flip into account). The edges do not always form a closed polygon. They surfaces are also not always convex, and sometimes they have holes in them. For instance on map test1 the room with the lava and yellow armor has a floor with holes in it. This floor is all one surface. If I remember right the edges are comprised of indicies into a vertex list. So you should be able to transform the verticies in the vertex list and avoid transforming the same vertex twice. ------------------------------ From: Bernd Kreimeier Date: Wed, 19 Jun 1996 09:52:49 +0200 (MET DST) Subject: Re: BSP edge list Greg Lewis wrote: > And, thus I would only need to compute half of the > vertices (since the start of one is the end of the next edge). From: Jim Bucher >So you should be able to transform the verticies in the vertex >list and avoid transforming the same vertex twice. Yep, a separate vertex transformation pass is a common approach. Internally, the vertex is stored as struct tVertex { // world space coordinates float _x; float _y; float _z; // transformed view space coordinates float _tx; float _ty; float _tz; }; or the likes. One could add the screen space coordinates as well from perspective projection. However, this approach clearly does not scale - you will transform all the vertices in the world, even if only a few percent are actually within the view frustrum or close. You might maintain bool flags to indicate transformation has already been done, or you might flag all vertices in the PVS, and transform only those, or might transform all vertices in the leafs of the BSP actually reached during traversal... which would bring you back to your original problem. Now and then I am considering a sorting of the vertex list by leaf (roughly, not perfectly), with a first_vertex, nOf_vertices pointer into the vertex list for each leaf (will have to be overlapping). This is probably not worth the trouble. Any other ideas? b. P.S.: is there really a non-closed polygon? From the description of Quake's rasterizer I knew that concave polygons and holes are handled, but I cannot imagine how this will work with non-closed polygons. Any examples? ------------------------------ From: Olivier Montanuy Date: Wed, 19 Jun 1996 11:14:30 +0200 Subject: RE: BSP edge list >the edges will always be given in a counterclockwise order around the surface. Sort of. Actually, I wrote this because there must be a way, when scan converting, to decide which side is in the surface, and which side is not. The easiest way is to respect some sign. I checked this with my little wireframe viewer, but not for every surfaces. The orders in which the edges are given is totally irrelevant. Two consecutive edges need not share a common vertex, though they often do. That scheme is suitable for software 3D rendering, but maybe not for hardware:-) Don't rely too much on the BSP format. Seems there were a lot of useless or duplicated stuff there: it was only a test, after all. I expect the final BSP format to be much cleaner. >It seems to me like the edges should form a closed polygon, This ain't the Windoze API. No need of closed polygons. Olivier MONTANUY FT.CNET/LAA/EIA/AEA Tel: +33 96051751 Fax: +33 96053667 Email: montanuy@lannion.cnet.fr ------------------------------ From: Olivier Montanuy Date: Wed, 19 Jun 1996 12:29:28 +0200 Subject: Re: BSP edge list >P.S.: is there really a non-closed polygon? Never saw any. Each time I tried to analyse edge lists, they always turned out to be closed polygons (with possible holes). Non-closed polygon is impossible, unless there's a bug somewhere. > but I cannot imagine how this will work with non-closed polygons. That would make one mother of a garbage on screen. Such effect can happen when you pervert some of the unknown bits. But I don't remember which ones (leaves? surfaces?). Olivier - --- End Included Message --- Olivier MONTANUY FT.CNET/LAA/EIA/AEA Tel: +33 96051751 Fax: +33 96053667 Email: montanuy@lannion.cnet.fr ------------------------------ From: Mads Dydensborg Date: Wed, 19 Jun 1996 14:28:15 +0200 (METDST) Subject: Re: Sorta off-topic : Delphi On Mon, 10 Jun 1996, Jim Lowell wrote: > At 09:29 PM 6/10/96 +0200, Mads Dydensborg wrote: > > > >There has been some people commenting about Delphi, and ease of > >use, etc. I too use Delphi (and prefer it to both C(++) and VB) [..] > I'm the guy who got Matt interested in Delphi and use is a ton myself. My > main interest in this direction would be to use Delphi to generate a set of > published free DLLs that other developers could use regardless of what > language they're programming in. If someone were to do this, it would make > tools-development fast. Delphi is a VERY easy language to get DLLs out in. There is off course room for this in the idea I had. Personally I would prefer source, (delphi source in special), both to learn from and use only partly or similar. Should I ever get the time, and disk quota, I would love to include general libs as either DLL's, DCU, OBJ, OCX or whatever. Anyway. I received respons from several people. I'm currently trying to build some pages that has some of the above material. (Note however, that these I will never be able to do - even remotly - what b. does. I know my limits ;-). I hope these pages can serve as a starting ground for Quake/Delphi coders. I will try to get my act together and put them up real soon. NB: I will include on the pages, the names of all people that wrote me. (Not their mail, but their names and email adresses.). Should anyone wish _not_ to be on this list, please mail me again. (I know. It should be the other way around, but taking the purposes of the mails into account, I hope this is okay). Once again ; Are you interessted in developing in Delphi, feel free to mail me about what you are doing, etc. Mads +----------------------------------------------------------------------+ | Mads Bondo Dydensborg. Student at DIKU, Copenhagen - Denmark. | | Email: madsdyd@diku.dk www: http://www.diku.dk/students/madsdyd/ | +----------------------------------------------------------------------+ ------------------------------ From: Jim Bucher Date: Wed, 19 Jun 1996 10:36:07 -0500 Subject: Re: BSP edge list Bernd Kreimeier wrote: > You might maintain bool flags to indicate transformation has > already been done, or you might flag all vertices in the PVS, > and transform only those, or might transform all vertices in > the leafs of the BSP actually reached during traversal... > which would bring you back to your original problem. I think the transformation flag is the best approach. In fact I suggested this idea to Greg Lewis in email after he responded that transforming all verts would be slow for large data sets. I feel that the best idea would be to cull the scene as much as possible and then transform the visible surfaces by going through the surface and edge lists as Greg was doing. Except, instead of transforming each vertex that you come to, first check the transform flag to see if the vertex has already been processed. > P.S.: is there really a non-closed polygon? This was a mistake, I don't think there are any non-closed surfaces. I meant to say that not all surfaces are polygons, since some of them have holes. ------------------------------ From: bstastnX@td2cad.intel.com Date: Thu, 20 Jun 1996 08:54:18 -0700 Subject: Editor advice Needed. Hello, I claim not to be a graphics guru so forgive me if this is simple by everyones standards but I Have Looked for this information (Graphics Gems, Book Store) and I can not find a working solution. I am reading in the .map quake level files and can find the intersection of the planes of a Brush. I would like to make these planes into sides of a polygon. The problem is that I can not get the points into a clockwise ordering. Does anyone know a solution that will take into account concave polygons? OR Should I be creating some type other type of structure that overcomes this problem. An Edge list of some sort? (not sure if this would even overcome my problem) Since some of you have working level viewers I was wonder if you could share your general approach with me/others? now you can get back to you talk about PVS Generation :) thanks, bret ------------------------------ From: Bernd Kreimeier Date: Thu, 20 Jun 1996 18:45:45 +0200 (MET DST) Subject: Re: Editor advice Needed. > From: bstastnX@td2cad.intel.com > but I Have Looked for this information (Graphics Gems, Book Store) > and I can not find a working solution. Not in the Gems? > The problem is that I can not get the points into a clockwise > ordering. I am not sure I understand. Does your algorithm just emit a bunch of vertices in no particular order? If you just need to determine whether the polygon is CW or CCW, see comp.graphics.algorithms FAQ maintained by Joseph O'Rourke (recommended): Section 2. 2D Polygon Computations - ----------------------------------------------------------------------- Subject 2.07: How do I find the orientation of a simple polygon? Compute the signed area (Subject 2.01). The orientation is counter-clockwise if this area is positive. A slightly faster method is based on the observation that it isn't necessary to compute the area. One can find the lowest, rightmost point of the polygon, and then take the cross product of the edges fore and aft of it. [ ...]Code for this is available at ftp://grendel.csc.smith.edu/pub/code/polyorient.C (2K). - ----------------------------------------------------------------------- Subject 2.01: How do I find the area of a polygon? The signed area can be computed in linear time by a simple sum. The key formula is this: If the coordinates of vertex v_i are x_i and y_i, twice the area of a polygon is given by 2 A( P ) = sum_{i=0}^{n-1} (x_i y_{i+1} - y_i x_{i+1}). Reference: [O' Rourke] pp. 18-27; [Gems I] Rokne, pp. 5-6. To find the area of a planar polygon not in the x-y plane, use: 2 A(P) = abs(N . (sum_{i=0}^{n-1} (v_i x v_{i+1}))) where N is a unit vector normal to the plane. The `.' represents the dot product operator, the `x' represents the cross product operator, and abs() is the absolute value function. [Gems II] pp. 170-171. Perhaps you will find some valuable hints in the QuakeEd sources, see SetBrush.h/m, on the Source oberview page at http://www.gamers.org/dEngine/quake/QuakeEd/source.html. > Does anyone know a solution that will take into account > concave polygons? The algorithms quoted above will. However, there cannot be concave polygons on a Brush. A Brush is a convex polyhedron, and each facet has to be a convex polygon by definition. Brush-brush intersection is a different issue. hope this helps b. ------------------------------ From: Bernd Kreimeier Date: Thu, 20 Jun 1996 20:41:00 +0200 (MET DST) Subject: Page update: texture mapping I updated the QuakeDev pages. The most interesting part is the summary of Chris Hecker's article series on Perspective Texture Mapping - recommended. There are a few other updates (a few changes of the primer, the 3DGPL, the PCPGE etc.). b. ------------------------------ From: Matt Houser Date: Thu, 20 Jun 1996 22:59:54 -0400 (EDT) Subject: .map algorithms There have been many questions: "how do I convert planes to vertices", etc. Well I put up a page answering many of these questions... Check it out... http://www.canweb.net/~fisty/shaker/algorithms.html - -- ================================================================== Matt Houser IRC: Fisty email: mwhouser@interlog.com, mwhouser@undergrad.math.uwaterloo.ca URL: http://www.undergrad.math.uwaterloo.ca/~mwhouser ------------------------------ From: Bernd Kreimeier Date: Fri, 21 Jun 1996 16:01:48 +0200 (MET DST) Subject: Quake Source Repository I forgot to mention: there is a small Quake Source Repository on the QuakeDev pages now. Currently it includes QuakeEd, MedDLe by Brian Martin, and the demo sources by Michael Abrash (plane clipping, edge-sorted rasterizer) and Chris Hecker (perspective texture mapping with pentium FDIV pipelining). Thanks to the respective authors for permission. I would like to invite everybody who has written a working utility and is willing to provide the sources to drop a uuencoded zip or an URL in my mailbox. Note that I will remove binaries sooner or later. Binary distribution is better done using ftp.cdrom.com and mirrors. The Repository is intended as some kind of archive in which you could track down working solutions to problems like plane-plane intersections etc.. If we ever manage to establish a working Reference Library, it might even save us some re-inventing the wheel. b. ------------------------------ From: Olivier Montanuy Date: Mon, 24 Jun 1996 17:05:43 +0200 Subject: Quake license forbids Quake specs? I read the Quake shareware license. Seems we cannot release specs for that one: all reverse engeneering is prohibited, and specs *are* reverese engeneering. Is it voluntary from id, or just an artefact? Anyway I won't release new specs before I receive the reg. version. I'm very disapointed by the distribution scheme, for people outside of the US. What a mess! Only pirates will get this game in due time. 50$ is cheap, but can't they use a decent postal service for 10$ more? The Arrogant Frog (These are my views, not those of the boss that snoop my mail) ------------------------------ From: Bernd Kreimeier Date: Mon, 24 Jun 1996 17:40:02 +0200 (MET DST) Subject: Info from Jay Wilbur (CEL) I got a clarification from Jay Wilbur on the misleading statements in the license overview file distributed with the Quake shareware 0.91 release. Further details will be put in the Licenses/Legal section, http://www.gamers.org/dEngine/license/. b. - ----- Begin Included Message ----- >From jayw@idsoftware.com Mon Jun 24 17:01 MET 1996 From: Jay Wilbur To: "'Bernd.Kreimeier@NeRo.Uni-Bonn.DE'" Cc: "'Mike Wilson'" Subject: RE: CEL Date: Mon, 24 Jun 1996 10:01:34 -0500 >Q1: Is the CEL (Commercial Exploitation License) > supposed to apply to selling home-brew levels > and utilities? No...the CEL is setup for folks who want to try and commercially exploit Quake (make money using the registered version of Quake). Registered versions based servers, location based entertainment, etc. Not for those who want to make add-ons or utils. The policy on that sort of stuff is: 1. Levels that use our data can be freely distributed...nobody and charge for them. 2. Unique levels that do not use any of our data are original works owned by the developer and may be distributed as he/she sees fit. 3. Utilities that use our data can be freely distributed...nobody and charge for them. 4. Utilities that do not use any of our data are original works owned by the developer and may be distributed as he/she sees fit. I have a cool "Made for Quake" logo program that is setup to address retailer publishers who will put Quake Utilities/level packs* out. It is not designed to work with small time developer/publishers. I will address this problem soon. Check out the registered version of Quake for more details on this program. *: Only items 2&4 above can get into the "Made for Quake" logo program. Items 1&3 above cannot participate in the "Made for Quake" logo program since nobody can charge for them. >Q2: Is it possible to get a copy of the CEL file > (comexp.txt, as mentioned in licinfo.txt)? It will ship with the registered version. Feel free to post this. - --- -j The official release date for all id's products: AS SOON AS IT IS FINISHED! - ----- End Included Message ----- ------------------------------ From: Bernd Kreimeier Date: Mon, 24 Jun 1996 18:14:51 +0200 (MET DST) Subject: Re: Quake license forbids Quake specs? > From: Olivier Montanuy > I read the Quake shareware license. Seems we cannot release > specs for that one: all reverse engeneering is prohibited, > and specs *are* reverese engeneering. Is it voluntary from > id, or just an artefact? It was no different with qtest1, and it is neither voluntary nor an artifact - they have no choice in the matter. To protect their intellectual property, id Software cannot possibly permit reverse engineering. Publishing specs is not illegal. Obtaining the content of such specs by illegal means is prohibited. id cannot give permission to create specs by hacking - they can look the other way. This is surely an unfortunate situation, but a familiar one. Fancy tapdancing ahead. As soon as John Carmack releases the sources of qbsp&Cie., specs will be possible based on the I/O code. Another straight solution is id Software hiring somebody to write down some Official Specs, and be done with it. For now, I prefer to abandon the topic. The situation will not improve by discussing it at length. > I'm very disapointed by the distribution scheme, for > people outside of the US. 50$ is cheap, but can't they > use a decent postal service for 10$ more? Drop a complaint to id Software and/or the distributor in question. I did. Won't do any good to do it here. b. ------------------------------ From: Marja K Ivars Date: Tue, 25 Jun 1996 00:03:25 +0300 (EET DST) Subject: Re: Quake license forbids Quake specs? On Mon, 24 Jun 1996, Bernd Kreimeier wrote: > > From: Olivier Montanuy > > I read the Quake shareware license. Seems we cannot release > > specs for that one: all reverse engeneering is prohibited, > > and specs *are* reverese engeneering. Is it voluntary from > > id, or just an artefact? > > Publishing specs is not illegal. Obtaining the content of such > specs by illegal means is prohibited. id cannot give permission > to create specs by hacking - they can look the other way. > This is surely an unfortunate situation, but a familiar one. Hmm. What exactly is reverse engineering? If I do "strings quake.exe" to get some fancy potential console keywords which id will probably never bother to document, have I "modified, disassembled, reverse engineered or decompiled the Software"? Just curious. Lauri ------------------------------ End of quake-dev-digest V1 #14 ****************************** From owner-quake-dev-digest@gamers.org Tue Jun 25 23:12 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 XAA08475 for ; Tue, 25 Jun 1996 23:12:45 +0200 (MET DST) Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with ESMTP id XAA09657; Tue, 25 Jun 1996 23:09:22 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id PAA22870 for quake-dev-digest-outgoing; Tue, 25 Jun 1996 15:58:44 -0400 From: owner-quake-dev-digest@gamers.org Date: Tue, 25 Jun 1996 15:58:44 -0400 Message-Id: <199606251958.PAA22870@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #15 Reply-To: quake-dev@gamers.org Errors-To: owner-quake-dev-digest@gamers.org Precedence: bulk X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 25588 X-Lines: 667 Status: RO quake-dev-digest Tuesday, 25 June 1996 Volume 01 : Number 015 ---------------------------------------------------------------------- From: Michael Hartle Date: Mon, 24 Jun 1996 23:20:30 +0200 Subject: Re: Quake license forbids Quake specs? > Hmm. What exactly is reverse engineering? If I do "strings quake.exe" to > get some fancy potential console keywords which id will probably never > bother to document, have I "modified, disassembled, reverse engineered or > decompiled the Software"? > [...] > Lauri Reverse engineering means the process of finding out how id wrote the software in order to run this fast, with these features, how they did this or that - the technologies - in order to use them in your programs. The exact meaning has to be defined by a lawyer, I suppose. Correct me if I am wrong... this is the way I do understand it. Regards, Michael ------------------------------ From: phares@dg-rtp.dg.com (Rand Phares) Date: Mon, 24 Jun 1996 18:50:55 -0400 Subject: Re: Quake license forbids Quake specs? Michael Hartle writes: > Reverse engineering means the process of finding out how id wrote the > software in order to run this fast, with these features, how they did this > or that - the technologies - in order to use them in your programs. The > exact meaning has to be defined by a lawyer, I suppose. Correct me if I am > wrong... this is the way I do understand it. You don't have to understand how id did it. Reverse Engineering means coming up with a way to make an identical product by examining the product itself. rand ------------------------------ From: Tom Wheeley Date: Mon, 24 Jun 96 10:55:20 GMT Subject: Standard configuration file >From what I recall from the doom editing days, it seemed that every utility or editor liked to have its own config file, and managing these if you did something as advanced as move your Quake directory could be a bit of a pain. (Especially if you used several editors). What I am proposing is a standard config file which *all* editors and utilities use to get info on their settings and peoples Quake location and prefs etc. To make things easier for Windows programmers, I suggest this be designed in thw Windows .ini file format -- built in routines in Windows for these, and easy enough for DOS programs to read. Putting things in the Win95 registry would be nice, but difficult fro DOS / (Win 3.x?) people to access. lines should of course be commented with a `#'. Thus there would be a main section: [quake] loc=c:/quake pak=c:/quake/id1/pak0.pak # Or whatever the name of reg pak may be (perhaps including hardware settings) mouse=logitech mousebut=3 vidmode=0 Then people could add [SuperQuakeEditor] advanced=yes QueryOnExit=no to control editor specific settings. This file (quake.ini ? editing.ini ?) could be kept in the Quake dir, or perhaps in C:\ (messy) or in the path somewhere. It should really be findable wherever the user is when running their editor, encouraging people to edit files not in their Quake dir :-) Comments? This would only work if most people used it, but I think everyone would benefit. Perhaps source for accessing the file could be kept in the source repository, to make it very easy for developers? .splitbung - -- * TQ 1.0 * The 'Just So Quotes'. "It wasn't her fault. She suffers from UTKPS." "What's that ?" "Unfortunate Tendency to Kill People Syndrome." ------------------------------ From: Jim Bucher Date: Mon, 24 Jun 1996 20:29:41 -0500 Subject: File format changes The format for the MDL files looks like it has changed slightly. My MDL viewer breaks on the new format. After a brief analysis it looks like only the frame info has changed. They now store a description of each frame in the file. Before I dig further, I was wondering if anyone has already figured it out. I think that the BSP format has changed also, since my printout of the header of start.bsp does not look right, although I have not looked into this at all yet. ------------------------------ From: Steve Simpson Date: Mon, 24 Jun 1996 21:42:47 -0400 Subject: Re: Standard configuration file sounds good. the source for reading it from dos could be shared too. ------------------------------ From: Sandro Hawke Date: Mon, 24 Jun 1996 22:16:17 -0400 Subject: Is there a Quake Client-Server Protocol Spec Has someone developed a specification of the quake client-server protocol? I see lots of information in the archives of this list and elsewhere about Quake's graphics algorithms and file formats and data structures, but very little about its networking. My own interest is in networking. I saw some old information about the server source code being released, but then a few weeks ago John Carmack supposedly said "I have gotten a little more reticent about releasing object code and some C code just from a control point of view," talking about the server, I think. I apologize in advance if I've missed some obvious source, and will summarize any substantial results to the list. -- sandro (sandro@roads.org) ------------------------------ From: Rene Post Date: Tue, 25 Jun 1996 08:12:12 +-200 Subject: RE: File format changes - ------ =_NextPart_000_01BB626E.08C9FB40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jim, >---------- >From: Jim Bucher[SMTP:jim@gcchem.com] >Sent: dinsdag 25 juni 1996 3:29 >To: quake-dev@gamers.org >Subject: File format changes > >The format for the MDL files looks like it has >changed slightly. My MDL viewer breaks on the >new format. After a brief analysis it looks like >only the frame info has changed. They now store >a description of each frame in the file. Before >I dig further, I was wondering if anyone has >already figured it out. Along with some minor changes there seems to be a different frame type used in flames.mdl and in some other MDLs. I have QuakeMe working for the frame type present in the QTest and I think I have almost found the format of the second frame type. Following are the changes I have found in the MDL format: Header: Version changed from 3 to 6 At the end of the header there are 2 extra 32bit values. A long and a float, I don't know yet what these are. Textures: Nothing changed Triangles: OnSeam was indicated with 0x00, now is indicated with 0x20 Frames: Every frame starts as before with the 32 bits value that I now think is the frame type. Followed as before by the lowerbounds vertex Followed as before by the upperbounds vertex New are the 4 vertices that follow. I have yet to understand what they do. ? Could it have something to do with the direction of lightsources ? The rest of the frame consists of the actual frame vertices. Normally the frame type is 0x0 and then the frame vertices are made up out of four 8 bits values. Some MDLs use a different frame types. e.g. flames.mdl When the frame type contains 0x01000000 a vertex is made up out of four 32 bits values instead of the normal 8 bits value. I think the frame type number is in little endian (motorola) format. Because that would make it frame type 1. Rene Post renep@xs4all.nl - ------ =_NextPart_000_01BB626E.08C9FB40 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhUGAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBJAG ACABAAABAAAADAAAAAMAADADAAAACwAPDgAAAAACAf8PAQAAAEcAAAAAAAAAgSsfpL6jEBmdbgDd AQ9UAgAAAABxdWFrZS1kZXZAZ2FtZXJzLm9yZwBTTVRQAHF1YWtlLWRldkBnYW1lcnMub3JnAAAe AAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAFQAAAHF1YWtlLWRldkBnYW1lcnMub3JnAAAAAAMA FQwBAAAAAwD+DwYAAAAeAAEwAQAAABcAAAAncXVha2UtZGV2QGdhbWVycy5vcmcnAAACAQswAQAA ABoAAABTTVRQOlFVQUtFLURFVkBHQU1FUlMuT1JHAAAAAwAAOQAAAAALAEA6AQAAAAIB9g8BAAAA BAAAAAAAAANhNAEIgAcAGAAAAElQTS5NaWNyb3NvZnQgTWFpbC5Ob3RlADEIAQSAAQAYAAAAUkU6 IEZpbGUgZm9ybWF0IGNoYW5nZXMAEwgBBYADAA4AAADMBwYAGQAIAAwADAACABQBASCAAwAOAAAA zAcGABkABwAkABoAAgA5AQEJgAEAIQAAADQ3N0ZFREQ5NUJDRUNGMTFBMTM4NDQ0NTUzNTQwMDAw ABcHAQOQBgA0BwAAEgAAAAsAIwAAAAAAAwAmAAAAAAALACkAAAAAAAMANgAAAAAAQAA5AMBtjj9d YrsBHgBwAAEAAAAYAAAAUkU6IEZpbGUgZm9ybWF0IGNoYW5nZXMAAgFxAAEAAAAWAAAAAbtiXT+O 2e1/SM5bEc+hOERFU1QAAAAAHgAeDAEAAAAFAAAAU01UUAAAAAAeAB8MAQAAABAAAAByZW5lcEB4 czRhbGwgbmwAAwAGEBmz5ckDAAcQpAUAAB4ACBABAAAAZQAAAEhJSklNLC0tLS0tLS0tLS1GUk9N OkpJTUJVQ0hFUlNNVFA6SklNQEdDQ0hFTUNPTVNFTlQ6RElOU0RBRzI1SlVOSTE5OTYzOjI5VE86 UVVBS0UtREVWQEdBTUVSU09SR1NVQkoAAAAAAgEJEAEAAAC+BQAAugUAAKUMAABMWkZ1WVDkUf8A CgEPAhUCqAXrAoMAUALyCQIAY2gKwHNldDI3BgAGwwKDMgPFAgBwckJxEeJzdGVtAoMzdwLkBxMC gH0KgAjPCdk78RYPMjU1AoAKgQ2xC2DgbmcxMDMUUAsKFFEFC/JjAEAgSGkgSg0HcCwKhQqLbGkx OIIwAtFpLTE0NA3wJwzQHUMZ3yA+C0oxNtcKoANgE9BjBUAtIKcKh68eHx8uDDAgJkYDYTohp8cf vQyCGxIgQnURcASQgFtTTVRQOmoHcEhAZ2MnAW0uBaBt/l0hTyJfI28GUQIwJM8l24JkC4BzZGFn IBhACCBqdQMAIDE5OcA2IDM6MjkonymvMSq/IFRvLB8l23F1UGFrZS0NsHYn0GHrB4ARoC4FsGcv jzCfMa9xBgB1YmogYTLvJdtG6QMQZSACEHIAwAVAEXHnGRAHkBvdMzYdfzcJPM9/Pk83ehpFMkcn EDvWO+Eg4nRDcU1ETDvQO6EEICkVoG9rRRFpNPAgaX8FQBGAPLhA30HvIDU8VGQEIHMcoGdodGx5 qi4F0HlEg3YIkHcEkPwgYhYQNOAEIAIgREJGT7tHX0JubgfRO+RKYEEBgK1LMWFLUQiQZlBgbgdA /xOwBABF0kU4TD9NT0JuAiDfSkBEQwNQNXFF0G4CEEYCz0lWSmBDYUqQbm8H4BPAfwWwUk9TX1Rv UHANsAT0af1L0W9Q0EuAEXBV91W0O6F9SmBCDcBYP1lPWl8FQEmbLeEuUGYIcERRcixhgfp3VsF3 AiAEgQuALlAGkP1Q4XkCIDvARh9fX2BvW2HabEtxZEqQHRBnCHBJsb9F4QhgT+AKjxocaOVBFaC/ Y1ED8ERQSdADcDvAbQuAvwWxPFVEQhYQSdAJ4G1tAd1WkGI7wFuBBpBmbUECMNFV9XR5cF5mdRGw aFHHA6AY4QeBLm1kAyAAcP9wQ2vzIEAnEUSCNbAbbGGQ1RGAdjvAUTTSTTvAYuDccmtjQkQWbwgg E1AHkPNuwl1FUVQHkFthcVFhkPtEUAuAa2GAaOVzswdABGD/d1ECEC6wScBVwzv0XGFEUt8RsAWg cVFvCHKtRgbwFaD/A/BjUQrAb0FDcWymc5V5hNddRUSTO/M6G2xIZ6EEkP2AhlY1kVwiSWYDUi8w bdL+NmrWBUBEUgnwScB6lScQj4GSbRV9ohHgZXh0VhDpLzAyYkXhdgdAClByl75BRSF9cnFRUHAY 4G88IFViYmQCICcFQGtX0nn/EcBikBGAhIMRsH2Scq13MOuG0Gghc4CGTnIBY0JJZZ+LrQchGRBE 8YCGT24GYO81cGKTC4At8GM8IEmxa6P8MHgc4GJgV9JRUpEuAdDXfC1WEoz3RXPQcmfRVhP7E8AK wHQEIFbBbhBeMmuU/0RShyBLUEXgBCCHg0RBPCH/YZBX0nfkUVF1TGjWfQRJse2W+GJVpJvScgbg eaGYgXsEkBPQeGjvGhybr5y3dX5wb4Cdj56fGkkHwn2mNP+io5FAbPND430iSmBzlYpy/23heaE1 kQGQcVGKtkqQicDpaNY/IAhRbGhTc7Nr8v+NpG3hicCXiC3wFhAgcFwl70nza/AIcKYyP4wWQ3F2 Qf96d1YEeyFRQZbBepUA0Iyw/wdAVfWl5nKto4+kljvyfSD/Vap141FRkgFxM0RRXVWxq399kwDA DbCh4WiSXFJ5gXK9svU4mEmyb7N/GpRTbAI/cmJwAm4/b0Q1sFyALmf3SmBwmLvFV7csdeN7IQGQ /y4BkfIZMMOTUGGitJKSuN//CHCYHAQgu8UuARPQZ7B6hj9sYbURumto1nfGdU1udf8G0EsxkqNF gQJAO7GE4Y9xnCAoBGBYIQbwYSlPh/9eEJFQvlKZA2LgqlK7xQDAa0W0dYkxcq1SCfA7wFAHeUG7 XG6xZXBAeHP6NLUhLlWAP59ArRvGFTECANdAAAADABAQAAAAAAMAERAAAAAAQAAHMKB270BYYrsB QAAIMKB270BYYrsBHgA9AAEAAAAFAAAAUkU6IAAAAABlhA== - ------ =_NextPart_000_01BB626E.08C9FB40-- ------------------------------ From: Olivier Montanuy Date: Tue, 25 Jun 1996 11:55:16 +0200 Subject: RE: File format changes >The format for the MDL files looks like it has changed slightly. >I think that the BSP format has changed also, I can confirm this. Brian is working on the new MDL format, and I'll be working on the new BSP format. But you'd be better off hacking it out yourself, since we may not be allowed to publish. I suspect also that Carmack is gonna change those formats again, for the actual Quake release. Current version is 0.91, and AFAIR DOOM didn't work decently before 1.2, and didn't run great before 1.666. Nothing is stable, except the .MAP: they have too much of them to change them now ;-) Olivier ------------------------------ From: Bernd Kreimeier Date: Tue, 25 Jun 1996 11:58:10 +0200 (MET DST) Subject: Re: Is there a Quake Client-Server Protocol Spec So far there isn't. I am curious myself if/when we will see qbsp&Cie. or parts of the server/client code. The former might well take till the registered version is ready for delivery, or till somebody finishes a tool to create MAP files. I have no idea about when to expect the latter, but I agree it is a very interesting topic indeed, for several reasons: observer clients using broadcast/multicast, tweaking Quake into an Previewer for an editing tool, and Bots, to name a few related issues. regards b. ------------------------------ From: "Brian K. Martin" Date: Tue, 25 Jun 1996 11:00:11 -0400 (EDT) Subject: Re: Standard configuration file > > What I am proposing is a standard config file which *all* editors and > utilities use to get info on their settings and peoples Quake location and > prefs etc. > > [quake] > loc=c:/quake > pak=c:/quake/id1/pak0.pak # Or whatever the name of reg pak may be > > This file (quake.ini ? editing.ini ?) > could be kept in the Quake dir, or perhaps in C:\ (messy) or in the path > somewhere. It should really be findable wherever the user is when running > their editor, encouraging people to edit files not in their Quake dir :-) > What is the use of the ini file in the quake directory? how could you find the file if you move the directory? I think if you just have a .cfg file in the utility directory it is fine. Every editor is gonna have different needs. It will just be a mess trying to standardize it. On the otherhand, I would like to see a standard way for everyone to store their brushes (a brush file). I haven't looked at the quake ed source, but I would like to have this standard. Then I can make a brush editor, and all the map editors could use each others brushes. brian ------------------------------ From: "Brian K. Martin" Date: Tue, 25 Jun 1996 11:04:08 -0400 (EDT) Subject: Re: File format changes > > The format for the MDL files looks like it has > changed slightly. My MDL viewer breaks on the > new format. After a brief analysis it looks like > only the frame info has changed. They now store > a description of each frame in the file. Before > I dig further, I was wondering if anyone has > already figured it out. > I verify. Maybe the header slightly changed too. I was gonna work on it soon. I will post to the list anything new, as I hope yunz will if you find anything... b ------------------------------ From: Rick Clemmer Date: Tue, 25 Jun 1996 10:39:18 -0500 Subject: Re: Standard configuration file At 10:55 AM 6/24/96 GMT, you wrote: >X-gamers.org: quake-dev@gamers.org > >>From what I recall from the doom editing days, it seemed that every utility >or editor liked to have its own config file, and managing these if you did >something as advanced as move your Quake directory could be a bit of a pain. >(Especially if you used several editors). > >What I am proposing is a standard config file which *all* editors and >utilities use to get info on their settings and peoples Quake location and >prefs etc. > >To make things easier for Windows programmers, I suggest this be designed in >thw Windows .ini file format -- built in routines in Windows for these, and >easy enough for DOS programs to read. Putting things in the Win95 registry >would be nice, but difficult fro DOS / (Win 3.x?) people to access. > >lines should of course be commented with a `#'. > >Thus there would be a main section: > >[quake] >loc=c:/quake >pak=c:/quake/id1/pak0.pak # Or whatever the name of reg pak may be > >(perhaps including hardware settings) > >mouse=logitech >mousebut=3 >vidmode=0 > >Then people could add > >[SuperQuakeEditor] >advanced=yes >QueryOnExit=no > >to control editor specific settings. > I know this sort of off topic but DOOM's dehacked had a .ini file. So it would know where DOOM was. mdk187 (It is a good day to die) on TEN Rick ------------------------------ From: Jim Bucher Date: Tue, 25 Jun 1996 10:46:29 -0500 Subject: Re: File format changes I partly decoded flame2.mdl last night. It looks to me like the frame information is now seperated into animation and frame info. The header now contains the number of animations, instead of the number of frames. Like Rene stated there are two extra dwords at the end of the header. Then everything is the same until you get to the frames data. There is now an animation block instead of a frame block. The number of animation blocks depends on the the number of animations given in the model header. The animation block contains a 16 byte header. The first dword looks like it is the animation type. The next dword is the number of frames for the animation. I don't know what the next two dwords are. This is followed by 4 bytes for each frame in the animation. I have not yet tried to decipher what these 4 bytes are. Then for each frame in the animation there is frame data block. The only thing about the frame block that has changed is the header. The header is now 24 bytes. It contains 8 bytes, 8 character for the frame name, and then 8 more bytes. I have not tried to determine what the other 16 bytes are yet. This structure only seems to apply to flame.mdl and flame2.mdl It looks like the structure of the animation block changes depending on the animation type. ------------------------------ From: "Ryan Drake" Date: Tue, 25 Jun 1996 09:17:29 -0400 Subject: Quake-edit API, Shareware vs Reg. First of all, has there been any progress made on the "standard" quake editing DLL that was brought up earlier on the list? Something like that would be a "good thing" if people were to get together and work on it. Just simple things like ReadPakFileEntry or GetWADTexture - stuff that would be common to most editors. With something like this, many editors could call functions in the same DLL, which would really help future editor coders who dont feel like re-inventing the wheel. An extra bonus of this that i did not see mentioned is that everytime a new upgraded or optimized DLL comes out it will automatically benefit any programs which link it. Im just lurking, and i don't really have alot of time to code quake editors (i wish i did!) but i just remember this striking me as a good idea. Another question has come to mind: How will level editors be able to produce MAPs that only work with registered versions of quake and NOT the shareware? I hoped id would have solved that problem for us and just disabled the loading of external maps in the shareware version, but i seriously doubt they had the time to put code like that in, considering they cant even get the Soundblaster Pro support to work ;-) Later all... - -- +-----------------------------------------------------------------------+ | Ryan Drake Sanity is the trademark of a weak mind. | | stiletto@psu.edu -- Mark Harrold | | http://www.crayola.cse.psu.edu/~drake/home.html | +-----------------------------------------------------------------------+ ------------------------------ From: Bernd Kreimeier Date: Tue, 25 Jun 1996 21:30:29 +0200 (MET DST) Subject: Re: Quake-edit API, Shareware vs Reg. >Another question has come to mind: How will level editors be >able to produce MAPs that only work with registered versions >of quake and NOT the shareware? >I hoped id would have solved that problem for us and just >disabled the loading of external maps in the shareware version, John Carmack seems to have done the Proof Of Purchase check he mentioned once. In principle, it should be impossible now to load any maps despite the shareware maps. In consequence, tweaking the shareware to load any other BSP file is only possible by violating the license. I'd appreciate if this is not discussed on the list. As for the POP check, this is a relief - we do not have to worry about keeping maps from working with shareware. This is a Good Thing. The drawback is there will be no check for level editing tools till the registered version ships. b. ------------------------------ From: Jonathan Mavor Date: Tue, 25 Jun 1996 14:05:19 -0700 Subject: My Quake Editor I've quickly caught up on the past messages from the list. I thought I would describe my editor, where it is and where I want it to go. I'm writing the editor using VC++ 4.1/MFC to run under 95 and NT (I'm developing it on 95). It's using an MDI paradigm so you can have multiple maps open at one time. I'm using the standard technique of brushes. You can create different brushes using different dialogs that I have (for instance cube, spheroid and cylinder right now). I want to have importing of brushes and a lofter in there also. Within the world brushes can be rotated, scaled, translated and sheared on any axis. The one interesting thing about my editor is that I'm allow concave brushes to be used. When I export to quake .MAP format these brushes will be broken up into multiple convex brushes. Since I am allowing these, my brush dialogs allow the creation of hollow brushes (for instance hollow tubes, spheres and boxes right now). I'm also planning to put in dialogs to create stairs (maybe even spiral), rings etc. Within the world right now you can add and subtract brushes to the world. I'm going to put in intersection and deintersection so you can create new brushes by doing operations with the world. Now, the neatest thing about my editor is that all the CSG is done in realtime. When you add a brush to the world the world immediately changes and you get the true solid representation of the world. Currently there are 5 window types (each window can be set to any type using the menu). There is my old back-to-front windows GDI renderer, a solid fill renderer like r_drawflat 1, and 3 ortho views (front, top, side). In the renderer you can move around with 6dof and look at how your level will actually be. Things I have planned for this editor: 1. I'm going to put in a full perspective texture mapper, the user will be able to select a polygon or groups of polygons while walking around in the world and change the texture. They will also be able to align it etc (ala buildEd). 2. I'm going to put in a raytracer, mipmapping etc so you can see what the lighting looks like. For a fast machine what I want to do when you place a light is to have it as a dynamic light, when the user clicks I will raytrace the polygons within range of that light and update the world so they can quickly make wicked looking lighting. 3. I'm going to fix up the GUI more as there are some issue with moving around and zooming in ortho views. I'm going to put in lots of functions to align brushes with parts of the world that are already there. 4. I'm going to put in some sort of grouping selection system for brushes so you can edit a small part of the world in the ortho views at one time. Each "group" will have it's brushes show up as a different colour. 5. I'm going to put in a brush wireframe 3d mode so that you can modify brushes that have been added/subbed from the world (move, delete etc). Since the renderer uses the BSP I build when csging you will have to rebuild the bsp after using this mode. I already have a reasonably optimal procedural csg bsp builder going which allows you to rebuild the world (it's SLLLLLOOOOOW though). I'm also going to do a full undo system and any other things which make an editor cool. For the future I'm thinking direct3d support, and possibly directdraw. I'm using createdibsection right now for the output from the renderer. I'm going to be choosing some beta testers soon to release my editor to (once I get the tmapping and texture selection in). Any questions/comments? L8r, Jon ------------------------------ From: "Ryan Drake" Date: Tue, 25 Jun 1996 17:02:10 -0400 Subject: Re: Quake-edit API, Shareware vs Reg. > John Carmack seems to have done the Proof Of Purchase check > he mentioned once. In principle, it should be impossible now > to load any maps despite the shareware maps. OK. This means that we don't have to include an "installer" that checks to make sure the end-user has the regged version. > In consequence, tweaking the shareware to load any other BSP > file is only possible by violating the license. I'd appreciate > if this is not discussed on the list. Agreed. > The drawback is there will be no check for level editing > tools till the registered version ships. I don't really see this as a drawback (the old bug vs feature argument), in fact it lets us get a head start on _developing_ quake editors while the registered version is not out. As long as no one _distributes_ quake editors that utilize stuff in the shareware vesrions, I dont see anything wrong with getting a jump on the editors. Editors that rip stuff from the shareware would only be in violation if they are distributed. Once the registered version of quake comes out, developers will need only make minor changes (hopefully) for the release version. - -- +-----------------------------------------------------------------------+ | Ryan Drake Sanity is the trademark of a weak mind. | | stiletto@psu.edu -- Mark Harrold | | http://www.crayola.cse.psu.edu/~drake/home.html | +-----------------------------------------------------------------------+ ------------------------------ End of quake-dev-digest V1 #15 ****************************** From owner-quake-dev-digest@gamers.org Wed Jun 26 16:52 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id QAA10838 for ; Wed, 26 Jun 1996 16:50:44 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id KAA30746 for quake-dev-digest-outgoing; Wed, 26 Jun 1996 10:49:06 -0400 From: owner-quake-dev-digest@gamers.org Date: Wed, 26 Jun 1996 10:49:06 -0400 Message-Id: <199606261449.KAA30746@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #16 Reply-To: quake-dev@gamers.org Errors-To: owner-quake-dev-digest@gamers.org Precedence: bulk X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 25837 X-Lines: 697 Status: RO quake-dev-digest Wednesday, 26 June 1996 Volume 01 : Number 016 ---------------------------------------------------------------------- From: casey@e-Commerce.Com (Casey Barton) Date: Tue, 25 Jun 1996 18:00:32 -0400 Subject: Re: My Quake Editor On Jun 25, 2:05pm, Jonathan Mavor wrote: > The one interesting thing about my editor is that I'm > allow concave brushes to be used. When I export to quake .MAP > format these brushes will be broken up into multiple convex > brushes. This feature is undoubtedly going to make the difference between a useable and unusable editor. It fantastic that you've already tackled the problem! One post here a short while ago pointed out the fact that a standard brush file format for Quake editors would be a great thing for the community to have. An archive of complex brushes on the net could reduce the time needed to put together a nice level by an order of magnitude. [Lots of cool features and ambitious plans deleted] > I'm going to be choosing > some beta testers soon to release my editor to (once I get > the tmapping and texture selection in). I'd love to be a part of this! - -- Casey Barton (a guy) | casey@e-commerce.com | www.e-commerce.com/~casey ------------------------------ From: "Drizzt Do'Urden" Date: Tue, 25 Jun 1996 15:19:58 -0700 (PDT) Subject: Re: Quake-edit API, Shareware vs Reg. On Tue, 25 Jun 1996, Bernd Kreimeier wrote: > > >Another question has come to mind: How will level editors be > >able to produce MAPs that only work with registered versions > >of quake and NOT the shareware? > >I hoped id would have solved that problem for us and just > >disabled the loading of external maps in the shareware version, > > John Carmack seems to have done the Proof Of Purchase check > he mentioned once. In principle, it should be impossible now > to load any maps despite the shareware maps. > > In consequence, tweaking the shareware to load any other BSP > file is only possible by violating the license. I'd appreciate > if this is not discussed on the list. As for the POP check, > this is a relief - we do not have to worry about keeping maps > from working with shareware. This is a Good Thing. > > The drawback is there will be no check for level editing > tools till the registered version ships. > > b. Not that I should know this, but I have found that by unpacking id1.pak from the leaked beta3 release, and copying over the progs, sounds, and maps directorys, you can play most of the registed levels with few or no errors. There is currently nothing stopping users from typing "map e3m5" or some such to use a registered level. Perhaps if id were to make regged/shareware BSP formats slightly incompatible. i.e. regged can read both, shareware can read only one. And then release a version of qbsp that only compiles the registered type. ------------------------------ From: Jonathan Mavor Date: Tue, 25 Jun 1996 16:11:25 -0700 Subject: Re: My Quake Editor At 06:00 PM 6/25/96 -0400, you wrote: >On Jun 25, 2:05pm, Jonathan Mavor wrote: >> The one interesting thing about my editor is that I'm >> allow concave brushes to be used. When I export to quake .MAP >> format these brushes will be broken up into multiple convex >> brushes. > >This feature is undoubtedly going to make the difference between a useable and >unusable editor. It fantastic that you've already tackled the problem! > Aha! But that part isn't done yet. However, I have a pretty darn good idea how to do it (make a bsp for the brush filtering the polys down to the bottom of all of the leaves and then sealing the volume). >One post here a short while ago pointed out the fact that a standard >brush file format for Quake editors would be a great thing for the >community to have. An archive of complex brushes on the net could reduce >the time needed to put together a nice level by an order of magnitude. > That's a DAMN good idea. What's wrong with using the .MAP format to make up brushes though? Instead of having a level it just has a brush. I'll be having a export brush menu item and I'll try and import a few formats (LWO for SURE). If someone sends me a decent DXF parser I'll stick that in too (I hate dxf). > >I'd love to be a part of this! > I'll think about it. Keep bugging me ;) L8r, Jon ------------------------------ From: Tom Wheeley Date: Tue, 25 Jun 96 23:06:37 GMT Subject: Standard configuration file In article <199606251500.LAA16053@minerva.phyast.pitt.edu> you write: > > > > What I am proposing is a standard config file which *all* editors and > > utilities use to get info on their settings and peoples Quake location and > > prefs etc. > > > > [quake] > > loc=c:/quake > > pak=c:/quake/id1/pak0.pak # Or whatever the name of reg pak may be > > > > This file (quake.ini ? editing.ini ?) > > could be kept in the Quake dir, or perhaps in C:\ (messy) or in the path > > somewhere. It should really be findable wherever the user is when running > > their editor, encouraging people to edit files not in their Quake dir :-) > > > > What is the use of the ini file in the quake directory? how could you > find the file if you move the directory? I think if you just have a > .cfg file in the utility directory it is fine. Every editor is gonna > have different needs. It will just be a mess trying to standardize it. Please read what I wrote. Firstly the sentence beginning "It should really be findable..." Secondly the bit you snipped regarding separate sections for people's own editors. Of course, the more info that can be kept in the main section the better. That's why I suggested it here. > On the otherhand, I would like to see a standard way for everyone to > store their brushes (a brush file). I haven't looked at the quake ed > source, but I would like to have this standard. Then I can make a brush > editor, and all the map editors could use each others brushes. .splitbung - -- * TQ 1.0 * The 'Just So Quotes'. Bus error: passengers dumped ------------------------------ From: Matt Houser Date: Tue, 25 Jun 1996 23:33:41 -0400 (EDT) Subject: Re: Standard configuration file > On the otherhand, I would like to see a standard way for everyone to > store their brushes (a brush file). I haven't looked at the quake ed > source, but I would like to have this standard. Then I can make a brush > editor, and all the map editors could use each others brushes. Working on shaker, I thought that a separate Brush editor would be beneficial... Right now I have "Brush" files that simply are the "brush" part from the .map files. So loading a brush from a .map file is as easy as loading from my "brush" files. Anyways, a standard would be nice, that way _I_ wouldn't have to worry about a brush editor and other people, could focus on that. ...Matt - -- ================================================================== Matt Houser IRC: Fisty email: mwhouser@interlog.com, mwhouser@undergrad.math.uwaterloo.ca URL: http://www.undergrad.math.uwaterloo.ca/~mwhouser ------------------------------ From: Michael Dewberry <72614.2725@CompuServe.COM> Date: 26 Jun 96 00:38:56 EDT Subject: RE: Preventing shareware editing Re the question of how id will prevent editing of the shareware version, This is an interesting question. I have already successfuly added sounds to the game by placing them in the /sound/* subdirs of id1 (which seems to be the equivalent of inserting them into the .pak). Using .bsp files added in this way also seems to work: i.e., if I make a copy of e1m7 and put it in /id1/maps/new.bsp, "map new" will load up The House of Cthon. Haven't tried it with any modified levels (becuase I don't have any) but it would stand to reason that it would work. Unless Quake checks the time/date/size of the bsp files it loads, it would appear that adding levels to the shareware is technically possible, all legal and moreal questions aside. I want to think that I've missed something; I know id was not careless enough to let it be this easy. I really do hope that I'm wrong; I'm not out to make the shareware version more desirable than paying for the full set. But I've almost finished episode 1 on nightmare, and I already consider myself a registered user since I've ordered my copy. I just don't want to wait 6 more weeks for it to get here. :) ------------------------------ From: Jonathan Mavor Date: Tue, 25 Jun 1996 22:20:17 -0700 Subject: Re: Standard configuration file At 11:33 PM 6/25/96 -0400, you wrote: >Right now I have "Brush" files that simply are the "brush" part from the >.map files. So loading a brush from a .map file is as easy as loading >from my "brush" files. > >Anyways, a standard would be nice, that way _I_ wouldn't have to worry >about a brush editor and other people, could focus on that. > I agree, I think that is a good standard. However, since my editor can use concave brushes when I save them out to this format I have to break them up into multiple concave brushes. If nobody else is going to use concave then I'll probably just have my own format for my brushes, but also will load .MAP style brushes, as well as export (but busted up which is sub-optimal). Hopefully, I'll have a decently fast perspective texturemapper in my engine by the end of the week. L8r, Jon ------------------------------ From: Bernd Kreimeier Date: Wed, 26 Jun 1996 11:35:43 +0200 (MET DST) Subject: Re: Quake-edit API, Shareware vs Reg. >From Ryan Drake >> The drawback is there will be no check for level editing >> tools till the registered version ships. >I don't really see this as a drawback How would you possibly test a BSP builder with a shareware that does not load external files? W/o hacking the check, which will NOT be tolerated on this list. b. ------------------------------ From: Bernd Kreimeier Date: Wed, 26 Jun 1996 12:09:47 +0200 (MET DST) Subject: ADMIN: final warning Please consider this your final warning: discussing of leaked beta3, hacking the POP check or the CRC's, and any related activity will have you unsubscribed w/o notification and locked from the list. If you are concerned about issues that might significantly decrease id Software's revenue by illegal activity, I suggest contacting id Software directly. If you have found a severe flaw in their current concept, they will surely appreciate both a detailed description, and your discretion until a fix is available. Both id Software and we are walking a thin line here, and I would hate to see their willingness to hand us an open architecture rewarded by publishing this kind of hacks. I will not tolerate any further discussion on this list that might intentionally or unwillingly help people to work around the POP mechanism. b. ------------------------------ From: Bernd Kreimeier Date: Wed, 26 Jun 1996 12:12:45 +0200 (MET DST) Subject: Info from John Carmack (11) Note the part on releasing the tools. b. - ----- Begin Included Message ----- >From johnc@idcanon1.idsoftware.com Wed Jun 26 05:34 MET 1996 From: John Carmack Date: Tue, 25 Jun 96 22:34:20 -0500 To: Bernd Kreimeier Subject: Re: q&a? >Err - "interact" does mean "intersect" here? Surely there is >interaction (i.e. collisions have to be detected). Anyway... Actually... Brush models do NOT do collision detection with each other. There are a few reasons for this. The practical one is that if they collided, every door frame and life bottom would have to be hollowed out to receive the moving object, creating lots of wasted geometry. A more serious one is that doing proper continuous collision between arbitrary models is a real bitch of a problem. Simple intersection testing isn't bad -- merge the two BSP trees and look for double solids, but saying: "This complex object is moving towards this other one, give me the exact time of impact" is HARD. Server time already chews up a lot of processing. > I do not understand how the world can contain concave polygons > or polygons with holes, using a BSP Qtest1 had non-convex polys, but quake 0.91 does not. If you put the polygons on the seperating planes instead of in the leafs, they can be any type you wish. There are tradeoffs both ways. > Non-moving objects could be maintained in lists of pointers > in each leaf they're partially in (or subtree they're completely Basically. The culling is actually done on the server side now, to keep network traffic down. The refresh is just presented with a list of objects already known to be in the pvs. >To be a vehicle, it has to have a walkable inside. Thus it has >to have a clipping hull, just like a very small level. Now what >happens once the POV or an entity is inside the bounding box of the >vehicle? Each movement has to checked against the BSP/hull of the Brush objects do have proper clipping hulls, so you could ride around in one, but they do not contribute at all to the PVS culling. They are added as edges, so there is no extra overdraw of the world, but all the geometry is still processed. > > > >Release of tools and source code for user prog coding and level > >building. > To keep us from asking this too often: will this happen prior to > shipping CD registered? pop.lmp will prevent testing third party > levels until then. Yes, it is likely the utilities will be released in the next week or two, I just need to spend an hour or so packing them up and writing some brief comments about them. I worry a little that I would be encouraging people to hack around the crc checks, though. > I am preparing a WAD2MAP conversion for DOOM levels: now I suspect > that you won't be too enthusiastic to see dumptruck loads of DOOM > levels used with Quake, so feel free to object. Btw., are the > s_scale/t_scale entries already processed by Quake 0.91, or are > they just dummies? Yes, the s/t vectors are properly used in 0.91. A wad converter might be an interesting way to bootstrap some development until real editors are available. Use a wad tool for geometry, then run it through light and vis. You should be aware that some styles of levels that are commonly created in DOOM will take an extremely long time to vis: huge open areas with lots of two sided lines in them. > > >Writing a proper full radiosity replacement for the light utility. > > I plan on looking at HELIOS by Ian Ashdown, to see whether it could > tweaked to use a NAT grid. It should be reasonable to resample any given light map to Quake's grid. > > >Reasonable user suggested improvements (keep it in the discussion > >groups please, I get enough mail as it is) > > Uhmmm - this got me sending this out-of-turn mail. If you want me > to abandon the q&a from now on, please let me know. In any case, > I'd like to invite you to use the Hypermail archive of the Quake > Developers list at your convenience, at > http://www.gamers.org/dEngine/quake/#QDevArchive. I almost never mind answering well thought out technical questins -- its the "I want to duck!!!!" type emails that bug me. > > >The Next Generation Technology. (no, I won't give you a code name > >to talk about!) > > Well, this is a game you already lost: we will talk about NGT - be > it Next Generation Technology or Next Game Title or Nifty Gruesome > Texturemapper... thanks for coining this one ;-). :-) John Carmack - ----- End Included Message ----- ------------------------------ From: Olivier Montanuy Date: Wed, 26 Jun 1996 12:36:14 +0200 Subject: About the new BSP format I hacked the stuff a bit (as part of my Python training course ;-) The BSP format has really changed quite a lot: some structures have been sized down, a new structure has been inserted, but the general idea seems to be the same (the hulls are there, as usual). Seems they added some more optimisation tricks to Quake 0.91, and the last thing I wanna do is tell away their secret -- assuming I could possibly understand it. Anyway entities definitions and textures don't seem to have changed. I will only publish those details that could have an impact of .MAP editors, in term of new possibilities for the game. Of course I found none, for the moment. Olivier for all you C and C++ fanatics that want a familiar language for fast prototyping, take a look at http://www.python.org. ------------------------------ From: Bernd Kreimeier Date: Wed, 26 Jun 1996 13:25:58 +0200 (MET DST) Subject: Re: My Quake Editor >Jon wrote: >>standard brush file format >What's wrong with using the .MAP format to make up brushes though? Exactly. See Info(9) posted to this list. The MAP file format is well suited to store single brushes, brush templates, groups of brushes (notably needed for rooms :) and template of the latter. >using a BSP to turn a non-convex solid into brushes While looking for 2D polygon partition (for WAD2MAP) I got the impression that solving this for 3D will be less than fun. Thus the BSP might be a good idea, but it will introduce splits in what the level creator wants to be a single surface. How does QuakeEd handle the splitting of the result of a CSG operation (Boolean operation on two brushes like carving will not produce Brushes)? Has anybody taken a close look? >import LWO Is this significantly easier than 3DS or DXF? LW does export at least one of the latter, IIRC. >Matt Houser wrote >I thought that a separate Brush editor would be beneficial... A Brush editor seems not very different from a Map editor (as Brushes are best stored like MAPs :). There are certain GUI modes that work best on a single brush, though (i.e. split a vertex to create a facet, or move plane along normal, etc.). If CDE for Linux ever gets delivered, and I get anything decent done, I hope to have QED being at least an imaginative single brush editing tool... How about a plugin interface for brush editing ;-). >Jon again: > Hopefully, I'll have a decently fast perspective >texturemapper in my engine by the end of the week. Be sure to get Chris Hecker's articles and source (start in the papers section of the QuakeDev pages). This is the single best and monst thorough texture mapper I have seen, and it should be very fast as well. b. ------------------------------ From: "John B. Williston" Date: Wed, 26 Jun 1996 08:52:10 +0000 Subject: Re: My Quake Editor Jonathan Mavor wrote: > I'm writing the editor using VC++ 4.1/MFC to run under > 95 and NT (I'm developing it on 95). It's using an MDI paradigm > so you can have multiple maps open at one time. A hint: you may find resource caching to be an absolute necessity under Windows95. I used the MDI pardigm for WadAuthor and quickly discovered a need for it. [lots of neat brush ideas snipped!] Sounds like a good idea, particulary if you support importing from AutoCAD, Ray-Dream Designer, or other well-defined 3D packages. [lots of graphical ideas snipped!] > I'm also going to do a full undo system and any other things > which make an editor cool. For the future I'm thinking direct3d > support, and possibly directdraw. I'm using createdibsection > right now for the output from the renderer. I'm going to be choosing > some beta testers soon to release my editor to (once I get > the tmapping and texture selection in). Do yourself a *very* big favor: start using Direct3D right now and forget the CreateDIBSection junk. I've been a DirectX beta tester since the beginning, and Direct3D will take care of *many* issues for you. > Any questions/comments? You certainly have very ambitious goals. In my experience, the number of goals met is a largely a measure of character and drive. Good luck! I haven't decided if I'm going to do a QuakeAuthor yet, but I'm thinking about it in a very serious fashion ... John - -- http://ourworld.compuserve.com:80/homepages/williston_consulting/ ___ ___ \ \ ____ / / Williston Consulting \ \/ \/ / _____________ "Software worth buying" \ /\ / / _________/ \_/ \_/ / / 70541.1335@compuserve.com / /_________ us018032@interramp.com /_____________/ ------------------------------ From: "Ryan Drake" Date: Wed, 26 Jun 1996 09:39:49 -0400 Subject: Re: Quake-edit API, Shareware vs Reg. > >From Ryan Drake > >> The drawback is there will be no check for level editing > >> tools till the registered version ships. > >I don't really see this as a drawback > > How would you possibly test a BSP builder with a shareware > that does not load external files? W/o hacking the check, > which will NOT be tolerated on this list. You cant test the builder, but you can at least _look_ at the format of the BSP's in the shareware and write code that outputs in that format. I am in no way suggesting anyone hack the check, and the last thing I wanted to do when I brought this topic up was to encourage that. Boy did I open a can of worms. On a side note, it's good to hear Carmack is planning on releasing the MAP -> BSP tools. Did he say whether they will be as source? - -- +-----------------------------------------------------------------------+ | Ryan Drake Sanity is the trademark of a weak mind. | | stiletto@psu.edu -- Mark Harrold | | http://www.crayola.cse.psu.edu/~drake/home.html | +-----------------------------------------------------------------------+ ------------------------------ From: Bernd Kreimeier Date: Wed, 26 Jun 1996 15:28:23 +0200 (MET DST) Subject: Re: My Quake Editor >John B. Williston wrote: >Do yourself a *very* big favor: start using Direct3D right now Curious: is there a decisive advantage of using Direct3D instead of OpenGL? Note I do not consider hypothetical or even real speed advantages decisive. OpenGL is portable (e.g. to UNIX, Linux, NT), Direct3D to my knowledge isn't (NT?). That might have been the reason for John Carmack choosing OpenGL, perhaps. >I've been a DirectX beta tester since the beginning, and Direct3D >will take care of *many* issues for you. Could you summarize the major design differences of Direct3D vs. OpenGL? I've always wondered (having no access to Direct*), and this would certainly be valuable info. b. ------------------------------ From: "Brian K. Martin" Date: Wed, 26 Jun 1996 10:26:29 -0400 (EDT) Subject: Re: Standard configuration file > > In article <199606251500.LAA16053@minerva.phyast.pitt.edu> you write: > > > > > What is the use of the ini file in the quake directory? how could you > > find the file if you move the directory? I think if you just have a > > .cfg file in the utility directory it is fine. Every editor is gonna > > have different needs. It will just be a mess trying to standardize it. > > Please read what I wrote. > > Firstly the sentence beginning "It should really be findable..." > I publicly apologise if I sounded like I was attacking you... I wasn't. I'm sorry. I was trying to make a joke. You see, if you store the location of the quake directory, in the quake directory... forget it.... I was just voicing my opionion that it might just end up a mess (like win.ini). brian ------------------------------ From: "Chris Cason" Date: Thu, 27 Jun 1996 00:27:55 -0800 Subject: Re: My Quake Editor > Could you summarize the major design differences of Direct3D vs. > OpenGL? I've always wondered (having no access to Direct*), and > this would certainly be valuable info. I second this - I'm having trouble deciding between the two myself. I've tried hunting around but didn't find much of substance at the time I looked. I'd appreciate some sort of comparison (or a pointer to one.) - -- Chris Cason ------------------------------ From: Tom Wheeley Date: Tue, 25 Jun 96 23:12:37 GMT Subject: Quake-edit API, Shareware vs Reg. In article <199606251558.PAA17498@r02n06.cac.psu.edu> you write: > Another question has come to mind: How will level editors be able to > produce MAPs that only work with registered versions of quake and NOT the > shareware? I hoped id would have solved that problem for us and just > disabled the loading of external maps in the shareware version, but i > seriously doubt they had the time to put code like that in, > considering they cant even get the Soundblaster Pro support to work ;-) > Well, although it doesn't prove anything, `strings quake.exe`, included: You must have the registered version to use modified games .splitbung - -- * TQ 1.0 * The 'Just So Quotes'. "Many people would rather die than think; in fact, most do." -- Bertrand Russell ------------------------------ End of quake-dev-digest V1 #16 ****************************** From owner-quake-dev-digest@gamers.org Thu Jun 27 13:39 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id NAA12498 for ; Thu, 27 Jun 1996 13:13:35 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id HAA07104 for quake-dev-digest-outgoing; Thu, 27 Jun 1996 07:12:30 -0400 From: owner-quake-dev-digest@gamers.org Date: Thu, 27 Jun 1996 07:12:30 -0400 Message-Id: <199606271112.HAA07104@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #17 Reply-To: quake-dev@gamers.org Errors-To: owner-quake-dev-digest@gamers.org Precedence: bulk X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 28710 X-Lines: 714 Status: RO quake-dev-digest Thursday, 27 June 1996 Volume 01 : Number 017 ---------------------------------------------------------------------- From: Jonathan Mavor Date: Wed, 26 Jun 1996 08:40:32 -0700 Subject: Re: My Quake Editor At 01:25 PM 6/26/96 +0200, you wrote: > >Exactly. See Info(9) posted to this list. The MAP file format >is well suited to store single brushes, brush templates, groups >of brushes (notably needed for rooms :) and template of the latter. > Exactly. However, I am going to have a format for my editor because of the need for concave brushes. (I wish we could just re-write idbsp to take concave brushes and then allow them in the maps. My bsp builder already does this so maybe I'll take a crack at it... ). >While looking for 2D polygon partition (for WAD2MAP) I got the >impression that solving this for 3D will be less than fun. Thus >the BSP might be a good idea, but it will introduce splits in >what the level creator wants to be a single surface. > Too bad. The way I handle this now is by creating co-planar polygons which reference the same texture, vectors etc. When exported to a .MAP file it will indeed be multiple polygons. This will of course only happen in concave brushes as convex brushes don't get split by a bsp. (Aren't bsps GREAT!). >>import LWO >Is this significantly easier than 3DS or DXF? Yes. Since I already have it from something else ;) >>Matt Houser wrote > >How about a plugin interface for brush editing ;-). I am SERIOUSLY considering a DDE plug-in interface to my editor so that people can edit brushes and have them instantly appear. This would be in a later version though ;) >Be sure to get Chris Hecker's articles and source (start in the >papers section of the QuakeDev pages). This is the single best >and monst thorough texture mapper I have seen, and it should be >very fast as well. I grabbed it. Looks interesting. One I get the texture cacheing down I'll probably use his texturemapper (but I'll have to set it up to use texture vectors instead of verts). Of course for wrapping textures I'll have to use something else. L8r, Jon ------------------------------ From: Bernd Kreimeier Date: Wed, 26 Jun 1996 18:20:16 +0200 (MET DST) Subject: Re: My Quake Editor >Jon Mavor wrote: > Exactly. However, I am going to have a format for my >editor because of the need for concave brushes. Hmmm. For clarity's sake, there is no such thing as a concave brush in my dictionary :-). More serious, this is not a good idea. Brush/MAP representations are minimal, and might exceed Quake's lifespan. BSP is one technique to generate lookups for speeding up rendering from this general purpose scene description. You might as well generate a sector map from the MAP files, for a different renderer. Or use MAP directly with PowerVR from VideoLogic, for all I know. >This will of course only happen in concave brushes >as convex brushes don't get split by a bsp. (Aren't bsps >GREAT!). This is confusing me. If you are doing a BSP on a per-Brush basis (one BSP for each pseudo-brush, i.e., splitting all those non-convex polyhedra you call Brushes :), this will generate Brushes of some kind from the non-convex solids. If you are processing the whole scene in one big BSP, of course a partition plane could intersect a convex brush as well, right? >>>import LWO >>Is this significantly easier than 3DS or DXF? >Yes. Since I already have it from something else ;) Hmmm. As I recently purchased LW 5.0, is this source available under some reasonable license? >I am SERIOUSLY considering a DDE plug-in interface >to my editor so that people can edit brushes and have them There is a DDE subset implemented in wxWindows that works with UNIX sockets as well. Perhaps it's possible to use this separately from the gargantuan GUI libs - another cross-platform portability suggestion. b. ------------------------------ From: Bernd Kreimeier Date: Wed, 26 Jun 1996 18:54:04 +0200 (MET DST) Subject: Info from John Carmack (12) >From johnc@idcanon1.idsoftware.com Wed Jun 26 18:47 MET 1996 A preliminary document for quake developer types: Quake's data access by John Carmack - ------------------- The user community work with DOOM was exciting and gratifying to watch. I have designed the quake architecture in a way that should address some of the awkwardness encountered in modifying DOOM, as well as enabling changes never before possible. You must have a full registered version of quake to use any of these options. DOOM wad files could not override all data types due to some data being implicitly ordered. Quake has no sense of ordering in it's data files, so any file can be overiden. Some of the DOOM hacks involved patching the executable to change game rules. In Quake, almost all of the game characteristics are in the interpreted progs.dat file, which can be freely overiden. A DOOM directory with lots of add ons was a mess. In quake, things are cleanly separated, so you can add and remove user games with a single xcopy or deltree. A quake directory with three add on games could just be: quake.exe id1/ test/ mygame/ test2/ All of Quake's data access is through a hierarchal file system, but the contents of the file system can be transparently merged from several sources. The game requests data as a pathname, like "sound/player/death1.wav", but the game system is free to find that file in different pak files or directory trees. The "id1" directory is taken to be the game directory by default. A modified version of quake can be run with "quake -game mygame". This makes quake take files from the mygame directory if present, or from the id1 directory if not found in mygame. All created files (savegames, config files, demos, screen shots, etc) are written to the game directory, so games will never interfere with each other. During development of an add on game, you will probably leave the data you are generating as separate files, like: mygame/progs.dat mygame/maps/start.bsp mygame/sound/player/death1.wav When you are ready to distribute your game to other people, you may want to generate a pak0.pak file of your directory. It isn't necessary, but it saves some space and speeds acess a bit. mygame/pak0.pak mygame/readme.txt The "-game mygame" command creates a search path: mygame/pak0.pak (if present) mygame/pak1.pak (if present) mygame/pak??? mygame/ ... id1/pak0.pak (if present) id1/pak1.pak (if present) id1/pak??? id1/... You can type "path" at the quake console to see what the current search path is. For certain special needs, you can specify an explicit path with the -path command. "-path c:/localid f:/quake/id1/pak0.pak" would look on the c: drive first, then fall back to the release data on f: for files not found. ------------------------------ From: jmccrind@cs.uct.ac.za (James McCrindle) Date: Wed, 26 Jun 1996 20:31:20 +0200 (SAT) Subject: Re: My Quake Editor [opengl95 vs Direct3D] pretty simple: direct3d is faster, opengl is more portable. or at least that's been my experience so far j. ------------------------------ From: "John B. Williston" Date: Wed, 26 Jun 1996 15:16:52 +0000 Subject: Re: My Quake Editor Chris Cason wrote: > > > Could you summarize the major design differences of Direct3D vs. > > OpenGL? I've always wondered (having no access to Direct*), and > > this would certainly be valuable info. > > I second this - I'm having trouble deciding between the two myself. I've > tried hunting around but didn't find much of substance at the time I looked. > I'd appreciate some sort of comparison (or a pointer to one.) Let me toss my brief 0.02 in here. OpenGL is a well-defined set of API's that is available on many platforms. However, as is seemingly the case with virtually all Unix-originated technologies, it is clearly something that accreted over time. I.E. I find the API to have a "designed by committee" look and feel. On Windows/NT, OpenGL performance is acceptable for moderately complex scenes; on my P120 w/32 MB RAM very complex scenes bog down pretty badly. Under Windows95, the performance stinks at present until Microsoft marries OpenGL to DirectDraw. I created a quick little example that simply rotates a multi-colored cube in each window; under WindowsNT 8 separate windows looked great, whereas under Windows95 the animation was quite jerky with only 2 windows open. Direct3D is one of the DirectX technologies. It is built upon the COM foundation used by OLE at the heart of Windows95. While some of its conventions are a bit strange for those familiar with 3D programming, it is pretty simple to use once you get the hang of it. The biggest endorsements for Direct3D, IMO, are: 1) It's built on DirectDraw, thus inheriting the custom drivers that take advantage of accelerated video cards. 2) It will be built right into the operating system. 3) It supplies high and low level API's to work with primitives or complete 3D objects as needed. 4) It has good support for user interaction with a scene; I had a difficult time getting this to work under OpenGL, although I will admit this might be due to a lack of OpenGL knowledge on my part. In the last four or five months of QuakeAuthor research, I've learned a great deal about OpenGL vs. Direct3D. At one point, I was even considering doing my own 3D engine, but I suspect no matter what I do Direct3D will always be faster. John - -- http://ourworld.compuserve.com:80/homepages/williston_consulting/ ___ ___ \ \ ____ / / Williston Consulting \ \/ \/ / _____________ "Software worth buying" \ /\ / / _________/ \_/ \_/ / / 70541.1335@compuserve.com / /_________ us018032@interramp.com /_____________/ ------------------------------ From: Jonathan Mavor Date: Wed, 26 Jun 1996 12:28:26 -0700 Subject: Re: My Quake Editor At 06:20 PM 6/26/96 +0200, you wrote: >More serious, this is not a good idea. Brush/MAP representations >are minimal, and might exceed Quake's lifespan. BSP is one >technique to generate lookups for speeding up rendering from >this general purpose scene description. You might as well >generate a sector map from the MAP files, for a different >renderer. Or use MAP directly with PowerVR from VideoLogic, >for all I know. > I didn't say that I was going to output the bsp. Just use it to generate the NEW list of convex brushes which make up the concave brush. These brushes will be indistinguishable from any other. >This is confusing me. If you are doing a BSP on a per-Brush >basis (one BSP for each pseudo-brush, i.e., splitting all >those non-convex polyhedra you call Brushes :), this will >generate Brushes of some kind from the non-convex solids. >If you are processing the whole scene in one big BSP, of >course a partition plane could intersect a convex brush as >well, right? Yes. But the "non-convex polyhedra" don't necessarily have a bsp. The world is represented by one big bsp which is created from the CSG's polygon of the original brushes, then those polygons are put through a bsper. So my bsp building process for the world is: 1) Make a big list of polygons from all the brushes. 2) Procedural CSG each polygon against all brushes to generate new polygons or possibly invalidate this polygon. 3) Delete all invalidated polys from the list 4) Send this list to a normal recursive bsp builder. When you are normally editing and add a brush to the world it filter all the polygons of the brush to inside/outside nodes of the world, and then filters all close polygons of the world through the brush to do the csg. You end up with more splits like this but the world can be rebuilt later if you want more speed. The actual DATA that makes up the map are all of the add's and sub's of the brushes. The bsp is just convienient for rendering. I mention before that to BREAK UP the "non-convex-brushes" I was going to use a bsp, not that this bsp existed all the time. >Hmmm. As I recently purchased LW 5.0, is this source >available under some reasonable license? > I'll see if I can dig it up. It's basically a little program that I wrote for LW4.0 files which converts them to a .3DM format. It was a quick hack but I think it should work. (3DM is 3dmodel, list of verts then a list of polys very simple). >There is a DDE subset implemented in wxWindows that works >with UNIX sockets as well. Perhaps it's possible to use >this separately from the gargantuan GUI libs - another >cross-platform portability suggestion. I'll check it out once I get to that stage. I seriously doubt that this editor will ever got ported to any non-windows operating system. Although I'm trying to not tie myself completely to the doc/view system. Everything is in C++ classes and theoretically could be ripped apart without too much trouble. L8r, Jon ------------------------------ From: jschuur@onlinemagic.com Date: Wed, 26 Jun 1996 20:39:02 +0100 (BST) Subject: qbsp/vis/light sources out subject line says it all... ftp://ftp.idsoftware.com/idstuff/source/qbsp.tar.gz here the .txt file: This is the source for the three utilties that a .map file passes through before it becomes a finished .bsp file. I went through 28 iterations of the output format, and eight major rewrites of the code during the development, so there are probably a few code skeletons lying around. I have compiled this code on nextstep, digital unix, irix, and nt, so it should be easily portable to any environment you choose. The digital unix version is multi-threaded to run on SMP systems. The NT version has not been tested very well. qbsp : this does the CSG operations on the brushes, fills away the outside of the map, generates a bsp and all of the polygons required for drawing, bsps for the clipping hulls, and copies all of the textures that are actually used out of the editor's wad files into the output bsp files. In hindsight, I wish I had split this program up a little more. There is an awful lot of code in it. qbsp can generates these files: map.bsp - the output map file to be read by quake or light / vis map.prt - the portal file to be read by vis map.h1 map.h2 - hull files written by forked processes. Can be safely deleted. map.pts - pointfile for tracing leaks in the level. In quake, you can type "pointfile" and it will leave a trail of dots from the outside to the first entity it ran into. Qbsp will refuse to generate a .prt file if the map is not completely sealed in. It is possible to vis an unsealed map, but it could take hours. Seal it up first. light : this takes the .bsp file generated by qbsp and does light casting from all of the light objects in the map. Normally, it takes one light sample for each lightmap point, but the "-extra" parameter causes it to take four samples (and four times as long to run) and average them. The lighting model used has little theoretical grounding (it has linear fallof, for instance), it was just tweaked until it looked good. vis : this takes the .prt file generated by qbsp, along with the .bsp file, and generates a compressed bit array of the potentially visible set of each leaf. This can take a very long time, depending on the input data. The time is related to the number of portals off of each leaf. A simple wolfenstein like level would have leafs with an average of only two portals from each leaf, and would vis very fast. The worst case for vising would be a stadium environment, where you have a huge area with lots of things sticking out of the ground but not contacting other major occluders. A single large room like that can take more time to process than an entire level made up of more densly occluded areas. These utilities are very processor intensive. Here at id, we share a four processor alpha 4/275 for all map processing. The final levels in quake take about 15-20 minutes each to fully process, which means that on a pentium 90 it would probably take abo ut 2 1/2 hours. Obviously not something you want to do very often. You can make a .bsp file that can be run by quake with just the qbsp program. When it is loaded into the game, it will be fullbright, and will allways draw the entire level (slow). This is fine for developing small tests, but different methodologies are required for developing full size levels. Our map editor lets us region an active work area, so construction is usually done a couple rooms at a time, allowing qbsp + light to be done quickly, and not requiring a vis at all. Once a level has been completed, entities (monsters, items, etc) can be moved or changed without reprocessing the entire level by running qbsp with the -onlyents parameter. This does not work for doors, triggers, etc that are composed of brushes. One of these days I will get around to coding that... Our map editor also has a "relight" option, which does a qbsp -onlyents, then a light, while still leaving the vis information intact. There are oportunities for network level parallization with some recoding. Qbsp uses fork level parallization to utilize up to three processors, and it would be trivial to change to allow it to be run on three computers. Light is embarassingly parallel, and can be divided arbitrarily. Vis id highly parallel, but it takes some advantage of order of completion in the serial case, so scaling is not quite linear. There are certainly major algorithmic optimzations that can be made to the code to improve the processing speed. The vis speed for bad cases could be improved dramatically by growing together leafs that have large numbers of portals into larger psuedo-leafs. The ray casting method I used in light is of debatable speed for the normal sampling level, but at the -extra sampling level it would almost certainly be faster to process an entire view from each light, rather than each light to each sample point. That would be a total rewrite, though, not a simple patch. I use doubles everywhere in these programs. At one point this was necessary to avoid some problems, but I tightened up the numerics in the program since then, and it may not be needed any more. I don't recall the change being a huge speed lose, in any ca se. John Carmack Id Software - -= joost schuur tel - +44 171 820 7766 =- - -= software person email - jschuur@onlinemagic.com =- - -= online magic ltd, london www - http://www.nuqneH.org/~jschuur/ =- ------------------------------ From: "Ryan Drake" Date: Wed, 26 Jun 1996 16:15:14 -0400 Subject: Re: Info from John Carmack (12) The last "Info from John Carmack has inspired me to write a "Quake Add-on manager" to allow dos-illiterate end users to painlessly install/remove/manage/launch add-on levels. If anyone has any ideas as far as cool features for this, please email me privately - i doubt discussion about what is essentially an "installer" is appropriate for the list. > In Quake, almost all of the game characteristics are in the interpreted > progs.dat file Has anyone looked at the PROGS.DAT file yet? I would imagine its complexities warrant another list altogether! - -- +-----------------------------------------------------------------------+ | Ryan Drake Sanity is the trademark of a weak mind. | | stiletto@psu.edu -- Mark Harrold | | http://www.crayola.cse.psu.edu/~drake/home.html | +-----------------------------------------------------------------------+ ------------------------------ From: Mackey McCandlish Date: Wed, 26 Jun 1996 16:28:34 -0400 Subject: qbsp Joost just mentioned on irc that qbsp has been released, available on cdrom.com I believe. Any more informed person feel free to step in. -*Avatar*- http://faraday.clas.virginia.edu/~fsm3m A new wacky gif every day! ------------------------------ From: Raphael.Quinet@eed.ericsson.se Date: Thu, 27 Jun 1996 02:18:17 +0200 (MET DST) Subject: Makefile and comments on qbsp/vis/light I saw Joost's message just when I was about to go back home, and I immediately started ftp and downloaded the source code provided by John Carmack. I also downloaded Quake, because I had not tried the shareware version yet due to lack of time and other "real life" constraints. :-) I had to re-write the Makefile, but once I did that, everything compiled correctly. I tried that under Solaris 2.5 on a SparcStation 20, but this should work with most UN*X systems. Since my Makefile is small and could be useful for other people, I included it at the end of this message. I hope that nobody will complain... A few random comments: - - dm1.bsp, which is included in the archive, is the good old test1.bsp It works fine if you save it in .../id1/maps/dm1.bsp and load it by typing "map dm1" in the console. - - You'd better have a machine with lots of memory in order to run qbsp. Fortunately, this wasn't a problem for my workstation. For example, running qbsp on dm1.map took 65 Mb of memory after a few seconds. If your machine has less than 64 Mb of RAM, it will probably swap all the time. - - qbsp crashed with a bus error after 5 minutes and dumped a rather large core file (66 Mb). I don't have the time to check what was wrong. Anyway, qbsp will never be able to finish if it cannot find the textures that are referenced in the map file (these should be loaded from "gfx/medieval.wad"). Errrmm... Well, actually I can rebuild "medieval.wad" from the textures included in the bsp file using QEU 0.4, but I don't think this is morally right. - - in cmdlib.c, I had to modify line 504 and replace: #ifdef _SGI_SOURCE by: #if defined(_BIG_ENDIAN) || defined(__sun) || defined(sparc) || defined (__sgi) Otherwise, the endianness would not be correct on a SparcStation (the line above is the same as the one I use in GAEL and QEU; tell me if that doesn't work for some systems). - - light and vis take a lot less memory than qbsp. Running light on dm1.bsp took one minute and a half, and vis took eight minutes (with the default options, no optimisations, on a single processor). Your mileage may vary... Here is the modified Makefile: - ---------- cut here ---------- cut here --------- cut here ---------- # Makefile for building the Quake tools "qbsp", "light", "vis", ... # Works fine with GNU make and gcc under Solaris 2.5, should also work # for most UN*X systems. Change "CC" and "CFLAGS" as appropriate. CC = gcc CFLAGS = -g -Wall # CFLAGS = -O3 -ffast-math -mv8 EXES = qbsp light vis bspinfo entmap all: $(EXES) clean: /bin/rm -f *.o $(EXES) QBSPOBJS = region.o map.o brush.o cmdlib.o csg4.o surfaces.o \ mathlib.o merge.o outside.o portals.o qbsp.o \ solidbsp.o tjunc.o writebsp.o bspfile.o nodraw.o qbsp : $(QBSPOBJS) $(CC) -o qbsp $(QBSPOBJS) -lm LIGHTOBJS = threads.o bspfile.o cmdlib.o light.o ltface.o \ mathlib.o trace.o entities.o light : $(LIGHTOBJS) $(CC) -o light $(LIGHTOBJS) -lm VISOBJS = vis.o flow.o cmdlib.o mathlib.o bspfile.o \ soundpvs.o vis : $(VISOBJS) $(CC) -o vis $(VISOBJS) -lm BSPIOBJS = bspinfo.o bspfile.o cmdlib.o bspinfo : $(BSPIOBJS) $(CC) -o bspinfo $(BSPIOBJS) -lm ENTMOBJS = entmap.o cmdlib.o entmap : $(ENTMOBJS) $(CC) -o entmap $(ENTMOBJS) - ---------- cut here ---------- cut here --------- cut here ---------- Have fun! - -Raphael P.S.: If you send a mail to me, don't expect a reply before next week. I'm too busy with my regular job for the moment and the two hours that I just spent on qbsp will not help my projects... :-/ ------------------------------ From: Jim Bucher Date: Wed, 26 Jun 1996 23:22:47 -0500 Subject: Re: Makefile and comments on qbsp/vis/light I have also made a makefile for watcom. If anyone wants it email me, or if noone objects, I can post it here. However, I was not able to get qbsp to run under DOS. I get an out of memory error immediately after running the program. I have not dug into the source to see what is going on yet. Has anyone tried to get qbsp to run under DOS? ------------------------------ From: Stephen Crowley Date: Wed, 26 Jun 1996 23:53:21 +0000 Subject: Re: Makefile and comments on qbsp/vis/light Jim Bucher wrote: > > X-gamers.org: quake-dev@gamers.org > > I have also made a makefile for watcom. If anyone wants it > email me, or if noone objects, I can post it here. However, > I was not able to get qbsp to run under DOS. I get an out of > memory error immediately after running the program. I have > not dug into the source to see what is going on yet. Has > anyone tried to get qbsp to run under DOS? I have a makefile for djgpp v2. I also get memory errors right when it starts but when I free up 60-140mb on my drive I can run all of them. Except the only map I can build is johnc99 the small one room map. I can also post the makefile here if it is ok. I believe cwsdpmi.exe is limited to 128meg virtual memory but I think it can be recompiled to allow more I will look into this. ------------------------------ From: The Dewb <72614.2725@CompuServe.COM> Date: 27 Jun 96 01:58:08 EDT Subject: RE: Makefile and comments on qbsp/vis/light >I have also made a makefile for watcom. If anyone wants it >email me, or if noone objects, I can post it here. However, >I was not able to get qbsp to run under DOS. I get an out of >memory error immediately after running the program. I have >not dug into the source to see what is going on yet. Has >anyone tried to get qbsp to run under DOS? I successfully compiled qbsp on Win95/VC++ 4.0, but the executable crashes on all but the most trivial .map files (i.e. single-room cubes.) It looks like 16MB just isn't enough.. The only change I had to make to the NT makefile was adding soundpvs.obj to the vis files list. ------------------------------ From: jschuur@onlinemagic.com Date: Thu, 27 Jun 1996 12:04:53 +0100 (BST) Subject: an attempt at using the new id tools well, i had a go at using the tools on our ultra sparc here, used raphaels makefile, applied the endian patch and the compiled succesfully. i went to the dEngine web site and got johnc99.map, adn added a "1.000000 1.000000" at the end of each hull definition, since this is what the new .map format that carmack mentioned in one of his mails seems to require. upon running qbsp 'johnc99.map' i get the following output: Project directory: outputfile: johnc99.bsp - --- LoadMapFile --- johnc99.map 6 brushes 4 entities 1 miptex 3 texinfo building hulls sequentially... - --- Brush_LoadEntity --- 6 brushes read - ---- CSGFaces ---- 36 brushfaces 58 csgfaces 12 mergedfaces - ----- SolidBSP ----- 24 split nodes 6 solid leafs 19 empty leafs 0 water leafs 24 leaffaces 24 nodefaces - ----- portalize ---- - ----- FillOutside ---- 36 outleafs - ----- SolidBSP ----- 6 split nodes 6 solid leafs 1 empty leafs 0 water leafs 6 leaffaces 6 nodefaces - ---- MergeAll ---- 6 mergefaces writing johnc99.prt Bus error suggestions? might this be because i don't actually have the textures in base.wad or is it terminating abruptly due to something else? a few more questions come to mind: - what is the correct order for running the tools? qbsp -> light -> vis? - i placed dm1.bsp in id1/maps and ran it as 'map dm1' from the console and it worked. i thought add on levels weren't supposed to work with the shareware? - textures... how could i legally (assuming i don't redistribute them) compile a .wad of textures using what's in the .bsp files? - are there .map versions of tworooms.bsp or first.bsp available? or other small levels? (other than dm1 (aka test1), johnc99 and jrbase1 (aka e1m1) - -= joost schuur tel - +44 171 820 7766 =- - -= software person email - jschuur@onlinemagic.com =- - -= online magic ltd, london www - http://www.nuqneH.org/~jschuur/ =- ------------------------------ End of quake-dev-digest V1 #17 ****************************** From owner-quake-dev-digest@gamers.org Thu Jun 27 19:42 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id TAA15734 for ; Thu, 27 Jun 1996 19:38:45 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id NAA11033 for quake-dev-digest-outgoing; Thu, 27 Jun 1996 13:30:58 -0400 From: owner-quake-dev-digest@gamers.org Date: Thu, 27 Jun 1996 13:30:58 -0400 Message-Id: <199606271730.NAA11033@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #18 Reply-To: quake-dev@gamers.org Errors-To: owner-quake-dev-digest@gamers.org Precedence: bulk X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 25369 X-Lines: 684 Status: RO quake-dev-digest Thursday, 27 June 1996 Volume 01 : Number 018 ---------------------------------------------------------------------- From: "Drizzt Do'Urden" Date: Thu, 27 Jun 1996 04:37:03 -0700 (PDT) Subject: Re: Graphics .wads (fwd) - ---------- Forwarded message ---------- Date: Wed, 26 Jun 96 23:34:02 -0500 From: John Carmack To: Drizzt Do'Urden Subject: Re: Graphics .wads >> Just curious...when will the graphics .wad files be released to the >> public. I recall reading that they would be make so. >> > >I just assumed some enterprising hacker would extract them out of the levels... > >We have given license to redistribute our graphics in not-for-profit user levels. > >John Carmack > I guess this means we can recreate our own graphics .wad files without fear of backlashes from id. This leads me to the question; are the graphics stored in the wad2 files in mip format, or bsp format? -Brent ------------------------------ From: Bernd Kreimeier Date: Thu, 27 Jun 1996 14:11:34 +0200 (MET DST) Subject: Re: Graphics .wads (fwd) >From Brent: > This leads me to the question; are the graphics stored in >the wad2 files in mip format, or bsp format? Steve Larsen will prolly know better, IIRC the QuakeEd source sets a type indicator 66dec to identify a mipmap lump as used by QuakeEd. Look into TexturePalette.m for details. >From Ron Pepper, private mail: >I just compiled QuakeEd1.2 for x86 Nextstep. >I unpacked the shareware pak file..but can't access it. I am too busy right now to check with the m68k version, has anybody of those few with access to the NeXT already tried QuakeEd with an unpacked gfd.wad from the shareware? I could put together a NeXT Quake Toolkit, but qbsp,vis,light will crawl on a 68k machine... Btw., the "qlumpy" utility that creates mipmaps (dithered if necessary) from WAD95 files with TEXTURE and patches is not included. b. ------------------------------ From: Mads Dydensborg Date: Thu, 27 Jun 1996 14:23:13 +0200 (METDST) Subject: Delphi ressource (beta) Hi, I've tried to put together some pages about developing Quake utilities using Delphi. They are located at http://www.diku.dk/students/madsdyd/quake/quakehome.htm There are embarringsly few ressources available, but it is my hope, that all DelpQuakers (<- Im looking for a word here), will contribute with info, files, source etc. Information need not be strictly Delphi related - OCX, DLL's and general Windows information that can be considered usefull for DelpQuakers are very welcome too. As of now, the pages are of very little use. I encourage all to contribute, and will do my best to keep the pages updated with the information you supply, so we have a commen development base for future use. The source code for the base classes in MipDip is coming up. I'm currently rewriting large portions, but it should be available for use sometimes in a couple of weeks. (In case you are interesseted). Non delphi developers are welcome to visit also, but due to the quota restrictions I can not put any non-delphi related quake info up. Mads +----------------------------------------------------------------------+ | Mads Bondo Dydensborg. Student at DIKU, Copenhagen - Denmark. | | Email: madsdyd@diku.dk www: http://www.diku.dk/students/madsdyd/ | +----------------------------------------------------------------------+ ------------------------------ From: Raphael.Quinet@eed.ericsson.se Date: Thu, 27 Jun 1996 14:52:49 +0200 (MET DST) Subject: Re: an attempt at using the new id tools On Thu, 27 Jun 1996, jschuur@onlinemagic.com wrote: [...] > upon running qbsp 'johnc99.map' i get the following output: [...] > ---- MergeAll ---- > 6 mergefaces > writing johnc99.prt > Bus error > > suggestions? might this be because i don't actually have the textures > in base.wad or is it terminating abruptly due to something else? I get exactly the same results during the "MergeAll" phase for dm1.map. I ran gdb to find out what was wrong, and... I found nothing. It crashes during an operation on vectors and I see nothing wrong there (the pointers point to valid locations and there are no unaligned data accesses). Maybe this is a memory problem? I had Emacs, FrameMaker and Netscape running at the same time, so maybe it ran out of memory and swap space? I will try to run the program on a machine which has 128 Mb or 256 Mb of RAM (mine has only 64 Mb of RAM and 70 Mb of swap) and see if it makes any difference. > - what is the correct order for running the tools? qbsp -> light -> vis? You have to run qbsp first. I'm not sure about the order of the other two. Maybe vis, then light? Maybe it doesn't matter? > - i placed dm1.bsp in id1/maps and ran it as 'map dm1' from the console > and it worked. i thought add on levels weren't supposed to work with > the shareware? Yeah, I was also a bit surprised about that. > - textures... how could i legally (assuming i don't redistribute them) > compile a .wad of textures using what's in the .bsp files? As soon as I have the time to finish it, I will release my little "miptex" utility, as part of QEU 0.4. It takes a texture from BMP or PPM file (8 or 24 bits), does the rescaling and anti-aliasing and saves it in a WAD2 file. Well, I also have a tool called "stealtex", which steals textures from a BSP file and puts them back into a WAD2 file, but I don't think I should release that one. Hmmm... But it looks like this is the tool you want, so maybe I will release it after all. But with a big warning about copyright issues, derivative works and such. Also, I wrote a program called "palcvt" which converts a picture (taken from a BMP, PPM, WAD or WAD2 file) to the Doom or Quake palette and does optional dithering (bidirectional Floyd-Steinberg dithering). This is very useful for taking textures from Doom and storing them in a Quake WAD2 file. Maybe I will merge "palcvt" and "miptex" into a single program. I told Bernd that I would release QEU 0.4 and the GAEL library this week because the small tools were almost finished, but I would like to improve "miptex" and "palcvt" before releasing them. I probably won't have the time to do that before the middle of next week. I hope that you will be patient enough. Also, GAEL (GAme Editing Library) is probably what several of you are looking for: it provides simple routines for loading and saving data from/to WAD and WAD2 file (among other things). I decided to split QEU in two parts (GAEL and the tools themselves) so that anyone can use the functions provided by the library without having to deal with QEU stuff. - -Raphael (Gee, why am I wasting my time writing this instead of finishing my work?) ------------------------------ From: Bernd Kreimeier Date: Thu, 27 Jun 1996 15:18:38 +0200 (MET DST) Subject: Re: an attempt at using the new id tools >You have to run qbsp first. I'm not sure about the order of the other >two. Maybe vis, then light? Maybe it doesn't matter? See readme.txt, and QuakeEd sources. light is not PVS aware. vis does not care about lightmaps. To my understanding, it is perfectly your choice - have a maxbright BSP with PVS for fast rendering, or a shadowed BSP dead slow w/o PVS. No, it does not matter ;-). b. ------------------------------ From: jschuur@onlinemagic.com Date: Thu, 27 Jun 1996 14:24:19 +0100 (BST) Subject: Re: an attempt at using the new id tools On Thu, 27 Jun 1996 Raphael.Quinet@eed.ericsson.se wrote: > I get exactly the same results during the "MergeAll" phase for > dm1.map. I ran gdb to find out what was wrong, and... I found > nothing. It crashes during an operation on vectors and I see nothing > wrong there (the pointers point to valid locations and there are no > unaligned data accesses). Maybe this is a memory problem? I had this was a 128 meg machine with at least half that memory free and plenty of swap space. i don't think it can be a memory problem if we're only using johnc99.map (it only took a few seconds to run) > file. Well, I also have a tool called "stealtex", which steals textures > from a BSP file and puts them back into a WAD2 file, but I don't think I > should release that one. Hmmm... But it looks like this is the tool you > want, so maybe I will release it after all. But with a big warning about > copyright issues, derivative works and such. considering the previous forwarded mail from john carmack and the license that comes with quake i think you can release this. looking forward to it. > (Gee, why am I wasting my time writing this instead of finishing my work?) i ask myself that all the time. - -= joost schuur tel - +44 171 820 7766 =- - -= software person email - jschuur@onlinemagic.com =- - -= online magic ltd, london www - http://www.nuqneH.org/~jschuur/ =- ------------------------------ From: Bernd Kreimeier Date: Thu, 27 Jun 1996 14:56:26 +0200 (MET DST) Subject: Re: an attempt at using the new id tools >i went to the dEngine web site and got johnc99.map, adn added a >"1.000000 1.000000" at the end of each hull definition, In the ./archive/ section there is a maps subdirectory, in which you will find the map files I used with QuakeEd, including an already fixed johnc99.map. As soon as we get the texture references figured out, I will add the "wad" lines, etc. >Bus error Reproduced, happens with dm1.map as well. Solais 2.5 and gcc-2.7.2. It is in tjunc.c/FindEdge() (if this is not a bogus), in the VectorSubtract macro (do not use macros, my mother always told me). I will leave this to those who prefer a C version :-). Here's what I will do: compile it as C++, and replace the CPP defines with inlines and consts. I threw in all the C warnings GCC supports on top of -Wall, and got drowned in conversions, missing prototypes etc. - I want a C++ version anyway. This will be maintained with CVS, and I will happily include all bug fixes, patches and Makefiles anybody wants to submit. b. P.S.: it works under Linux, btw. :-) until it needs the gfx/medieval.wad. Now where's that unpack... P.P.S.: I had a hard time getting the archive (got it from www.stomped.com/files.html, finally), and I am currently unable to get connection to upload it on www.gamers.org in the ./archive/ section, so better not look for it there. ------------------------------ From: Mike Ruete Date: Thu, 27 Jun 1996 10:04:00 -0500 (EST) Subject: Re: Makefile and comments on qbsp/vis/light On Wed, 26 Jun 1996, Jim Bucher wrote: > I have also made a makefile for watcom. If anyone wants it > email me, or if noone objects, I can post it here. However, > I was not able to get qbsp to run under DOS. I get an out of > memory error immediately after running the program. I have > not dug into the source to see what is going on yet. Has > anyone tried to get qbsp to run under DOS? I haven't tried, but I'm speculating that perhaps with an unlimited swapfile under win95, and a lot of free hard drive space, it just might be possible to get it to run. - -Mike Ruete / Gripp ------------------------------ From: Jonathan Mavor Date: Thu, 27 Jun 1996 07:52:40 -0700 Subject: Re: an attempt at using the new id tools At 12:04 PM 6/27/96 +0100, you wrote: > - are there .map versions of tworooms.bsp or first.bsp available? or > other small levels? (other than dm1 (aka test1), johnc99 and jrbase1 > (aka e1m1) > As soon as I heard the the utilities were release I made a super fast export to .MAP format. If you guys want to give me the specs to a simple room I can make it up in my editor and export to .MAP. BTW anyone know how to represent a subtract in the .MAP file? Do you just reverse the order of the plane points? I'll make up a small map (maybe several versions, each one more complex) and make these .MAPs available. Also, from what I'm hearing it sounds like someone is going to have to either fix or re-write qbsp so that it functions on a 16meg machine (I consider 16meg to be an acceptable minimum). I would also greatly appreciate it if someone could send me a pkzip archive with all of the files (as I don't have access to tar/gzip). Bernd what about a spot on your web page for a "dossified" version of the stuff (is that allowed?). L8r, Jon ------------------------------ From: "Gustavson Guy W." Date: Thu, 27 Jun 96 10:59:00 CDT Subject: Added server polling functionality It appears that the methods used to query quake servers over the net has stayed simular enough the Steve's qstat program still works with the shareware version. Tword the end of the developments cycle there was talk of adding the ability to determine what players where on what server, and what the frag count was along with other info. Did this happen? If so is there a new version of qstat on the way? Also Steve, the list I give to qstat for detecting servers has reached several hundred by now. Occasionaly the last few severs return things like 0/1238102987 players active. If you need a long list to check it with I'll send you a copy of my current list. Also I belive that it would be nice to allow the user to select the timeout for the servers. Many of the servers don't appear to be returning info in two seconds due to net lag I'd guess. ------------------------------ From: Bernd Kreimeier Date: Thu, 27 Jun 1996 18:02:08 +0200 (MET DST) Subject: Re: an attempt at using the new id tools >BTW anyone know how to represent a subtract in >the .MAP file? Do you just reverse the order of >the plane points? There is no such thing. If I do understand the MAP format right (means you don't :), there are only convex polyhedra. Period. They intersect freely, and an intersecting group of Brushes will define a non-convex boundary representation that has to be split to polygons by qbsp, but that's it. If you do CSG using QuakeEd, the editor splits a resulting non-convex solid into Brushes ASAP. >re-write qbsp for 16MB Hmmm. At this time, I am not even sure I'll succeed in compiling it as C++... >tar/gzip The GNU-WIN32 distribution (and DJGPP, I presume) should provide both. I am afraid www.gamers.org will not offer the bandwidth or disk space to maintain multiple copies of the same stuff just because of different archiving preferences.... I will do a source overview page like for QuakeEd, if anything fails. Btw., we joining the Department of Redundancy Department right now - the same map in different archives, some cmdlib.c etc. in both archives, and lots of different versions floating around soon. I will put the map files separately, but as for the sources, this is going to be difficult. If John Carmack is going to release updated versions, a CVS import is recommended. b. b. ------------------------------ From: John Cash Date: Thu, 27 Jun 96 11:05:49 -0500 Subject: Re: Added server polling functionality You wrote: > It appears that the methods used to query quake servers over the > net has stayed simular enough the Steve's qstat program still works > with the shareware version. > > > Tword the end of the developments cycle there was talk of adding > the ability to determine what players where on what server, and > what the frag count was along with other info. Did this happen? If > so is there a new version of qstat on the way? > > > Also Steve, the list I give to qstat for detecting servers has > reached several hundred by now. Occasionaly the last few severs > return things like 0/1238102987 players active. If you need a long > list to check it with I'll send you a copy of my current list. Also > I belive that it would be nice to allow the user to select the > timeout for the servers. Many of the servers don't appear to be > returning info in two seconds due to net lag I'd guess. Yes, you can get a fair bit of info out of a Quake server now. I plan to do a fairly detailed post so you guys can start making use of it, but I've been too busy bug fixing to do so yet. - --- John Cash "I want to move to theory, everything works in theory" ------------------------------ From: larsen@sunset.cs.utah.edu (Steve Larsen) Date: Thu, 27 Jun 1996 10:10:26 -0600 Subject: wad2, id tools, QuakeC, etc b. wrote: > >From Brent: >> This leads me to the question; are the graphics stored in >>the wad2 files in mip format, or bsp format? > >Steve Larsen will prolly know better, IIRC the QuakeEd source >sets a type indicator 66dec to identify a mipmap lump as used >by QuakeEd. Look into TexturePalette.m for details. Well, just so happens that I do ;) The textures are stored in the wad files in exactly the same way they are stored in the .bsp files. So the answer to your question is yes. BTW, I wrote a simple little program that will take a .bsp file and extract the textures into a wad2 file. I could make that available if anyone would like it. b. wrote: >From Ron Pepper, private mail: >>I just compiled QuakeEd1.2 for x86 Nextstep. >>I unpacked the shareware pak file..but can't access it. > >I am too busy right now to check with the m68k version, has >anybody of those few with access to the NeXT already tried >QuakeEd with an unpacked gfd.wad from the shareware? I could >put together a NeXT Quake Toolkit, but qbsp,vis,light will >crawl on a 68k machine... I haven't tried it with the shareware, but to my knowledge, the (gfx.wad?) only stores lumps for graphics like the console background, status bar, etc. Qtest had no mip-mapped textures in the gfx.wad. Further, QuakeEd will take a dump if the first lump in the wad that you try to import is not the palette for the textures. So, keep that in mind if you all try to generate your own wad2 texture files for QuakeEd. BTW, here is some info that I gathered last night with the id tools: I re-built dm1.map into dm1.bsp using all three tools. These are the results for my computer (and the command-line I used, just for reference): qbsp: (qbsp dm1.map) : 130 seconds light: (light dm1.bsp) : 63 seconds vis: (vis dm1.bsp) : 367 seconds This was on a P5-100 with 64M of ram running win95. I thought this was pretty encouraging. BTW, for those who didn't know, dm1 is just test1 from qtest. Anyway, this isn't a huge level, but it isn't trivial either. Unless I misunderstood, the above should have built full versions of all repective parts. If you used the various short-cuts, or cut out some of these all together, I think you bould get turn around in probably 2-3 minutes for most levels. If you work on the level in parts, as suggested by Carmack I believe, it should be a lot less. Anybody have any idea what's up with the QuakeC compiler? I would like to start making some levels now ;) Steve ------------------------------ From: Jonathan Mavor Date: Thu, 27 Jun 1996 09:33:21 -0700 Subject: Re: Makefile and comments on qbsp/vis/light At 10:04 AM 6/27/96 -0500, you wrote: > > >On Wed, 26 Jun 1996, Jim Bucher wrote: > > I haven't tried, but I'm speculating that perhaps with an >unlimited swapfile under win95, and a lot of free hard drive space, it >just might be possible to get it to run. > I'd like to report a sucessful compilation of DM1.MAP. Actually it crapped out at the end saying it couldn't find the wad file but the portals and hulls are there. I freed up about 128meg of disk space (first time I ran was with 27meg free and it crashed). Instead of using a makfile, I loaded up developer studio and put all of the files for qbsp into the project workspace. I started off the project as a console app (which is what qbsp really is). I have a P120, 16meg running Win95 (yes it worked under 95!!). As soon as a I get a wad file (ANY WAD FILE) I expect to be able to put a simple 2 room level into quake exported from my editor (with whatever texture I can get into a wad2). L8r, Jon PS I already have the tools so no more .ZIP files please!! ;) ------------------------------ From: "Brian K. Martin" Date: Thu, 27 Jun 1996 12:53:02 -0400 (EDT) Subject: Re: an attempt at using the new id tools > > I would also greatly appreciate it if someone could send me a pkzip > archive with all of the files (as I don't have access to tar/gzip). > Bernd what about a spot on your web page for a "dossified" version > of the stuff (is that allowed?). > Although this is non-quake... WinZip will do all the tar/gzip stuff automagically. It is shareware and the win95 version is great. ------------------------------ From: Jonathan Mavor Date: Thu, 27 Jun 1996 10:18:24 -0700 Subject: The new tools Ok, I've now sucessfully compiled and run all of the new tools. I qbsp'ed DM1 (except when it gets to the wad), I did a quick vis on it (definate slowdown) and modified light and re-traced dm1 (i made all the light values double, it was a LOT brighter, then I changed vis back). If anyone wants the win32 console app exes or anything else I'll get them ready. I'm still looking for a wad2 file with a texture in it!! L8r, Jon ------------------------------ From: jschuur@onlinemagic.com Date: Thu, 27 Jun 1996 18:36:24 +0100 (BST) Subject: Re: The new tools On Thu, 27 Jun 1996, Jonathan Mavor wrote: > Ok, I've now sucessfully compiled and run all of the new > tools. I qbsp'ed DM1 (except when it gets to the wad), I > did a quick vis on it (definate slowdown) and modified light > and re-traced dm1 (i made all the light values double, it > was a LOT brighter, then I changed vis back). > > If anyone wants the win32 console app exes or anything > else I'll get them ready. I'm still looking for a wad2 file > with a texture in it!! it'd be great if you could upload these with a short set of instructions to ftp.cdrom.com/pub/idgames2/incoming. (archive maintainer there ;) - -= joost schuur tel - +44 171 820 7766 =- - -= software person email - jschuur@onlinemagic.com =- - -= online magic ltd, london www - http://www.nuqneH.org/~jschuur/ =- ------------------------------ From: Jonathan Mavor Date: Thu, 27 Jun 1996 10:24:41 -0700 Subject: Re: wad2, id tools, QuakeC, etc At 10:10 AM 6/27/96 -0600, you wrote: > >b. wrote: >Well, just so happens that I do ;) The textures are stored in the >wad files in exactly the same way they are stored in the .bsp files. >So the answer to your question is yes. BTW, I wrote a simple little >program that will take a .bsp file and extract the textures into a >wad2 file. I could make that available if anyone would like it. > ME ME ME!!! Could you fattach it to me? This is all I'm looking for so that I can actually make a level!! >This was on a P5-100 with 64M of ram running win95. I thought this was >pretty encouraging. BTW, for those who didn't know, dm1 is just test1 >from qtest. Anyway, this isn't a huge level, but it isn't trivial either. >Unless I misunderstood, the above should have built full versions of all >repective parts. If you used the various short-cuts, or cut out some >of these all together, I think you bould get turn around in probably >2-3 minutes for most levels. If you work on the level in parts, as suggested >by Carmack I believe, it should be a lot less. Now that these tools are released I'm really encouraged. Since I now know exactly what algorithm Carmack used for the lights I can ray-trace the exact same way in my level. This means that I should pretty well be able to get the levels in my editor to look exactly like quake. This means that for geometry and lighting you shouldn't have to export and save yourself a pile of time. Since it would ray-trace each light as you placed it in the level (and doing one light is very fast) you can probably speed up the level design process (at least for placing lights). Once I get the tmapping/lighting in a little quake simulation (so you can tell jump heights etc) would be really cool. Ok, I'm off now to make a little level with only convex brushes and one bright light in the center. Once I get a WAD2 I'll see if I can't get it up and running. L8r, Jon ------------------------------ End of quake-dev-digest V1 #18 ****************************** From owner-quake-dev-digest@gamers.org Fri Jun 28 18:41 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id SAA18795 for ; Fri, 28 Jun 1996 18:33:18 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id LAA22541 for quake-dev-digest-outgoing; Fri, 28 Jun 1996 11:34:13 -0400 From: owner-quake-dev-digest@gamers.org Date: Fri, 28 Jun 1996 11:34:13 -0400 Message-Id: <199606281534.LAA22541@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #19 Reply-To: quake-dev@gamers.org Errors-To: owner-quake-dev-digest@gamers.org Precedence: bulk X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 22505 X-Lines: 613 Status: RO quake-dev-digest Friday, 28 June 1996 Volume 01 : Number 019 ---------------------------------------------------------------------- From: Bernd Kreimeier Date: Thu, 27 Jun 1996 20:35:25 +0200 (MET DST) Subject: Re: an attempt at using the new id tools >error with Solaris 2.5 qbsp I am compiling qbsp from *.cc now (introduced a few header files by splitting bsp5.h, removed one redundancy already - there is nothing like plowing your way through somebody else's code :). It does not abort with a Bus Error under Solaris 2.5. >It is in tjunc.c/FindEdge() (if this is not >a bogus), in the VectorSubtract macro (do not use macros, >my mother always told me). I will leave this to those >who prefer a C version :-). No warranty: as soon as I made it a function with proper prototype, I got notified that it is called with float* here instead of double* (as anywhere else, it seems). This might well end up in accessing memory that the process does not own, hence a Bus error. However, just replacing all floats in bspfile.h with doubles did not fix the Solaris problem with the C version. I'd rather have inline and const... To check the output, now, I'll have to get that mipmap WAD, too. The dm1.prt and dm1.h2 files are identical (Linux qbsp.c run compared with Solaris qbsp.cc run). The *.h1 are not. Hmmm. b. ------------------------------ From: Mackey McCandlish Date: Thu, 27 Jun 1996 15:14:55 -0400 Subject: Quake's Palette I've started doing textures for whatever Quake projects I embark on, and I'm wondering if anybody knows if Quake's palette is changeable or not. In DOOM, changing the palette required changing all 10-14 playpal/colormap entries. Is this so with Quake? I've heard horror stories that Quake's palette is hardcoded. If this is the wrong place to ask this, somebody private email me where this SHOULD be asked. -*Avatar*- http://faraday.clas.virginia.edu/~fsm3m A new wacky gif every day! ------------------------------ From: Bernd Kreimeier Date: Thu, 27 Jun 1996 21:28:49 +0200 (MET DST) Subject: Re: Quake's Palette >I'm wondering if anybody knows if Quake's palette is >changeable or not. In DOOM, changing the palette required >changing all 10-14 playpal/colormap entries. Is this so >with Quake? Give or take an entry, yes, I'd guess. >I've heard horror stories that Quake's palette is hardcoded. Take the time to read the infos from John Carmack, and the palette discussions in the archive at www.gamers.org - you will find that (a) the palette was already in the WAD2 (see UQS), (b) the colormap entries should have been moved from the EXE to the WAD2 by now, and (c) you will have to replace the status bar, sprites and MDL skin textures as well. Matching structured palettes has been discussed as well, so far it seems inconclusive. hope this helps b. ------------------------------ From: "Ryan Drake" Date: Thu, 27 Jun 1996 16:07:58 -0400 Subject: Re: Quake's Palette > Take the time to read the infos from John Carmack, and the > palette discussions in the archive at www.gamers.org - you > will find that (a) the palette was already in the WAD2 (see UQS), > (b) the colormap entries should have been moved from the > EXE to the WAD2 by now, and (c) you will have to replace the > status bar, sprites and MDL skin textures as well. Matching > structured palettes has been discussed as well, so far it > seems inconclusive. Wow.. that sounds like alot of fun. If I were a betting man, i would guess that a palette-altering util will be in high demand once levels start becoming more creative. i.e. give the program a palette and a PAK file and it goes to work: for each bitmap it finds it 1] converts it (as closely as it can, possibly following a set of rules) to the new palette, and 2] writes the bitmap back into the PAK. And after it is all done, copies the palette into the WAD2 file. Sounds like a monumental task to me. - -=Stiletto=- - -- +-----------------------------------------------------------------------+ | Ryan Drake Sanity is the trademark of a weak mind. | | stiletto@psu.edu -- Mark Harrold | | http://www.crayola.cse.psu.edu/~drake/home.html | +-----------------------------------------------------------------------+ ------------------------------ From: Matt Houser Date: Thu, 27 Jun 1996 17:20:54 -0400 (EDT) Subject: Standard Brush Format I really like the idea of a standard brush file format. This gives the possiblities for people to design brushes using a "brush editor" then importing that brush into a map editor without too much fuss. I for one am willing to get the ball rolling on this one... I would really like to see this done. So I guess if you have any really good ideas on this format... email me and we'll get this going. ...Matt - -- ================================================================== Matt Houser IRC: Fisty email: mwhouser@interlog.com, mwhouser@undergrad.math.uwaterloo.ca URL: http://www.undergrad.math.uwaterloo.ca/~mwhouser ------------------------------ From: "Brian K. Martin" Date: Thu, 27 Jun 1996 17:37:48 -0400 (EDT) Subject: distribution of id data... I just fixed my model editor so that it works with the new mdl format (exect flame). In doing so I added gourard shading to the texture mapping routine... i.e. I use the quake colormap.lmp What I wanted to know is: Can I distribute this color map with my veiwer? Several people use the quake palette so I would guess that it is OK, it's sorta the same thing. But I am afraid to take anything for granted... I guess I could just read it from the GRX directory if need be.. In general though, what type of info is safe to be re-distributed? None? brian ------------------------------ From: Jim Bucher Date: Thu, 27 Jun 1996 17:15:32 -0500 Subject: Re: Standard Brush Format Matt Houser wrote: > > I really like the idea of a standard brush file format. This gives the > possiblities for people to design brushes using a "brush editor" then > importing that brush into a map editor without too much fuss. Why not save brushes in the .map format? ------------------------------ From: Matt Houser Date: Thu, 27 Jun 1996 18:42:49 -0400 (EDT) Subject: Re: Standard Brush Format > > Why not save brushes in the .map format? > Please note that the .map format does not contain only brushes but they must be encabsulated within entities... But if we follow the same format just kind of ignoring the entity stuff then it could work... ...Matt - -- ================================================================== Matt Houser IRC: Fisty email: mwhouser@interlog.com, mwhouser@undergrad.math.uwaterloo.ca URL: http://www.undergrad.math.uwaterloo.ca/~mwhouser ------------------------------ From: "Alex R. Moon" Date: Thu, 27 Jun 1996 19:23:49 -0500 Subject: Re: Standard Brush Format Matt Houser wrote: > > Why not save brushes in the .map format? > > > Please note that the .map format does not contain only brushes but they > must be encabsulated within entities... > But if we follow the same format just kind of ignoring the entity stuff > then it could work... Well what we're really talking about here is a kind of super-brush. A single convex polyhedron is not very exciting and doesn't really deserve an editor of its own, but editing a small group of brushes into a super-brush in a dedicated editor which could then be imported into a map editor could be very useful and is what we're talking about here. What we essentially need then a format which can group a bunch of brushes together. We could either do this by have a format which just lists the brushes one by one by their map-style descriptions for a single super-brush, or we could use the existing concept of entities (which do an excellent job of grouping brushes already) to do the grouping for us. Carmack mentioned in one of the info's that he was going to add a special entity class of "submodel" for brush grouping to the map format. If we used that for brush-type files, it would have many advantages. First, the brush files would be syntactically identical to the map files -- the same parsing would work for both. Secondly, using entity-style grouping would allow for many super-brushes to be stored in a single brush file, so you could have a "stairs.bsh" file which could contian a normal staircase, a spiral staircase, and perhaps many other kinds of stair templates in a single place. Finally, using an entity-based format would allow brush templates to have default entity classes assigned to them. Say you have a "doors.bsh" file with various kinds of doors in it with their classnames already set to the appropriate kind of door class. - -- Alex R. Moon | "If you explain something so clearly that odin@mdn.com | no one can misunderstand, someone will." amoon@odin.mdn.com | ------------------------------ From: Jonathan Mavor Date: Thu, 27 Jun 1996 19:00:21 -0700 Subject: Level Report I'd like to report that I have my first custom map up and running!!!! I made a map in my editor with all convex brushes and wrote a simple exporter to .MAP format. The exporter is hardcoded for 1 texture (because I don't have texture selection in the editor yet). I hope I can get a .MAP export that will export all brushes going sometime (sub's, and concaves by busting them up). After I exported the level I edited it manually to add some lighting in and then ran qbsp and light on it. At first vis didn't seem to want to work because qbsp wouldn't generate a prt file but I guess that it's working now because I'm vising in the background as I write this. Since we aren't supposed to distribute user levels before the full version comes out I guess I shouldn't give it to anyone. It's such a small map and there is nothing in it though (not as small as johnc99.map but small and useless for anything real). What do you guys think? Maybe some sort of limited distribution? If nothing else I'll send out some screen shots of it.... L8r, Jon PS vis is done took 75 seconds on my p120 -16meg ------------------------------ From: Jonathan Mavor Date: Thu, 27 Jun 1996 19:04:08 -0700 Subject: Re: Standard Brush Format At 07:23 PM 6/27/96 -0500, you wrote: >Matt Houser wrote: > First, the brush files would be syntactically identical to the map files -- >the same parsing would work for both. Secondly, using entity-style grouping >would allow for many super-brushes to be stored in a single brush file, so >you could have a "stairs.bsh" file which could contian a normal staircase, a >spiral staircase, and perhaps many other kinds of stair templates in a single >place. Finally, using an entity-based format would allow brush templates to >have default entity classes assigned to them. Say you have a "doors.bsh" >file with various kinds of doors in it with their classnames already set to >the appropriate kind of door class. I think that this is probably a good idea. I'm going to write some utils in my editor to generate stuff like stairs but for doors, door frames and weird complex shapes having a standard format would be very good. And since the map format already exists with entities in place then this is even better. As a matter of fact, we should be able to define a piece of quake-c code to go with the entity (or at least an example). BTW can bsp entities be rotated??? L8r, Jon ------------------------------ From: FiSTY Date: Thu, 27 Jun 1996 23:25:15 -0400 (EDT) Subject: Re: Standard Brush Format > BTW can bsp entities be rotated??? entities can't be rotated per say but you could rotate each of the brushes within it ...Matt =========================================== FiSTY fisty@yoss.canweb.net the shaker project - http://www.canweb.net/~fisty/shaker/ ------------------------------ From: Jonathan Mavor Date: Thu, 27 Jun 1996 21:07:11 -0700 Subject: Re: Standard Brush Format At 11:25 PM 6/27/96 -0400, you wrote: >> BTW can bsp entities be rotated??? > >entities can't be rotated per say but you could rotate each of the >brushes within it What I mean is can you rotate them in the game? I know that they can be moved but can the be rotated? For instance could you have a floor that rocks back and forth? L8r, Jon PS My map is now a bit more complex and includes some water. Tomorrow I'm going to quickly put in the ability to place lights, player starts and to select textures (although the texture won't be shown in the engine -yet). ------------------------------ From: stokfam@wisdom.psinet.net.au (Michael Stokes) Date: Fri, 28 Jun 1996 13:28:44 +0800 Subject: Shareware Textures in WAD2 I have just uploaded a program that can convert the textures in BSP files into a large WAD2 file. It automatically extracts the maps from the pack file if not already done so. I have tested it by re-extracting the textures, and also by using it with QBSP to generate a level (johnc99).. It is uploaded at ftp.cdrom.com/idgames/quake/incoming I uploaded 3 versions of it..oops..I kept making last minute changes. The actual file is mk_wad2.zip.really.fixed. Hopefully Joost the archive maintainer will work out what I did..if not then perhaps he's reading this. :) Because I only have a DX/2 66 with 8MB ram I can't test it with QBSP'ing other levels. Let me know how you go.. Mike. =============================================== Michael J Stokes http://www.psinet.net.au/~stokfam =============================================== ------------------------------ From: FiSTY Date: Fri, 28 Jun 1996 01:58:13 -0400 (EDT) Subject: Re: Standard Brush Format On Thu, 27 Jun 1996, Jonathan Mavor wrote: > At 11:25 PM 6/27/96 -0400, you wrote: > >> BTW can bsp entities be rotated??? > > > >entities can't be rotated per say but you could rotate each of the > >brushes within it > > What I mean is can you rotate them in the game? I know > that they can be moved but can the be rotated? For instance > could you have a floor that rocks back and forth? a bsp is completly static... you cannot move anything in the bsp... for moving floors, doors, etc. you need to make separate entities and associate QuakeC code to them... =========================================== FiSTY fisty@yoss.canweb.net the shaker project - http://www.canweb.net/~fisty/shaker/ ------------------------------ From: Stephen Crowley Date: Fri, 28 Jun 1996 00:20:39 +0000 Subject: Shareware texture wads I have a page with 5 texture wad zips on it and qbsp tools for dos and win32 plus the source with new makefiles for dos(djgpp) and solaris (someone posted solaris make here earlier). I also have a few maps there too. (no new ones yet) The textures are from sw and qtest combined so I wouldn't miss any (hopefully). They are base.zip, medieval.zip, metal.zip, start.zip, wizard.zip. I did not do anything but package these together into wadfiles I think this is ok from what I read here, if it's not I will promptly take them off. NOTE: These are for developers only I in no way mean for these to encourage distrubiting levels that work with the shareware version of quake. The page is at http://www.wf.net/~stephenc, you will have to put up with my stupid links at the bottom of the page. ;-) Stephen ------------------------------ From: jschuur@onlinemagic.com Date: Fri, 28 Jun 1996 11:58:12 +0100 (BST) Subject: Re: Shareware Textures in WAD2 On Fri, 28 Jun 1996, Michael Stokes wrote: > It is uploaded at ftp.cdrom.com/idgames/quake/incoming > I uploaded 3 versions of it..oops..I kept making last minute changes. > The actual file is mk_wad2.zip.really.fixed. Hopefully Joost the archive > maintainer will work out what I did..if not then perhaps he's reading this. hope you guys didn't have to wait too long. it's in the newstuff directory now at cdrom.com, - -= joost schuur tel - +44 171 820 7766 =- - -= software person email - jschuur@onlinemagic.com =- - -= online magic ltd, london www - http://www.nuqneH.org/~jschuur/ =- ------------------------------ From: Bernd Kreimeier Date: Fri, 28 Jun 1996 16:41:15 +0200 (MET DST) Subject: Re: distribution of id data... Here is my final attempt to draw a conclusion. In summary, I understand that non-commercial distribution of maps, BSP's, WAD2's and infos is tolerated and/or encouraged. I consider a WAD2 equivalent to a BSP (it contains mipmaps and artwork that is redistributable), and infos equivalent to source (describing a BSP file format or reading the source has the same effect). Same for distributing the palette lump or MDL reading source: MedDLe with quake palette is a utility containing id data. Yes, I know that qbsp does not provide insights on MDL lumps, no, I don't think this makes a difference. >From now on, I will simply expect id to voice their objections, and will not inquire again. I would appreciate if related questions are NOT posted to the list - ask id if you are still not sure, and post a straight answer should you actually get one. No offense intended, but we are simply getting nowhere. Quod erat demonstrandum... b. - ----- Begin Included Message ----- >From jayw@idsoftware.com Fri Jun 28 15:14 MET 1996 Hi Bernd, The licenses will probably be modified up to the day the reg. version is released. Sorry but there will not be an early release of these documents. I thought my last message clearly defined what the deal is. Let me try to simplify it further. The simple rules for Quake map/utility distribution: 1. user-developed/user-modified maps & utilities can only work with the registered version. (Just to be clear here...user-developed/user-modified maps & utilities cannot work with the shareware version of Quake.) 2. If the map/utility contain id data (other then the id code John Carmack release to the world) it cannot be sold. The registered version end-user license will give you the limited right to develop maps/utilities that use id data...this right ends at commercial exploitation of the map/utility. 3. If you create a map/utility that does not use any id data (other then the id code john Carmack release to the world)...it is your map/utility. You may copyright it, give it away, sell it, etc. 4. You may not use any of our trademarked or copyrighted properties (game gfx, logos, names, etc.) to market your game. In other words...QuakeEd is a nono ("qed", "an editor that works with Quake" is OK), marketing your product with a 1/4 page ad in a game magazine that shows screenshots from Quake is a nono, Any use of the Quake, id, or NIN logo (except the placement of NIN ammo boxes into levels that can not be sold) is a nono. > >Could we safely assume that all of the non-commercial >activities going on (creating mipmap WAD2 files for >qbsp and distributing them, creating BSP files including >mipmaps and distributing them, distributing information >about qbsp internals and WAD/BSP file formats, distributing >binaries of qbsp and modified sources) are indeed safely >within the terms of the prospective licenses? > >Or, the other way round: the topics that are in violation >of the licenses are the ones I already put on the off topic >list: POP, CRC, encryption, hacking related parts of the EXE, >use of leaked alphas and betas. > >The cautious "do you think this is okay with id?" postings >will continue to increase the traffic w/o solving the problem. >I will have to find a solution one way or the other, and would >appreciate any comments, suggestions or clarifications. > - --- -j The official release date for all id's products: AS SOON AS IT IS FINISHED! - ----- End Included Message ----- ------------------------------ From: Jim Lowell Date: Fri, 28 Jun 1996 10:24:41 -0500 Subject: Clarification requested (was Re: distribution of id data...) When Jay Wilbur says: >The simple rules for Quake map/utility distribution: > >1. user-developed/user-modified maps & utilities can only work with the >registered version. (Just to be clear here...user-developed/user-modified >maps & utilities cannot work with the shareware version of Quake.) Does he mean that: 1) The game is ALREADY set up to disallow external levels in the shareware version, thereby lifting the burden of pop from everyone. or 2) It's just illegal to make a level that works with the Shareware version of Quake and is therefore up to editor designers to come up with a way to prevent this. I ask because it sounds like Jon has gotten a user level to work with the shareware version of Quake and this would seem to be in contradiction to Jay's statement. - -= Jim Lowell =- ------------------------------ From: tevans@netcom.com (Terry Evans) Date: Fri, 28 Jun 1996 09:32:37 -0700 (PDT) Subject: Re: Clarification requested (was Re: distribution of id data...) > Does he mean that: > > 1) The game is ALREADY set up to disallow external levels in the shareware > version, thereby lifting the burden of pop from everyone. > > or > > 2) It's just illegal to make a level that works with the Shareware version > of Quake and is therefore up to editor designers to come up with a way > to prevent this. > > I ask because it sounds like Jon has gotten a user level to work with > the shareware version of Quake and this would seem to be in contradiction > to Jay's statement. > > -= Jim Lowell =- Along the same lines, has anyone tried the -game option with the SW version to see if it is allowed/disallowed? I'd try myself, but I'm at work right now. Terry tevans@netcom.com ------------------------------ End of quake-dev-digest V1 #19 ******************************