Copy Link
Add to Bookmark
Report
Quake Editing Digest Volume 1 : Number 8
quake-editing-digest Thursday, 14 March 1996 Volume 01 : Number 008
Re: Quake tools in C++
Re: Quake tools in C++
Re: .MDL animations
Map Conversion Utility, Anyone?
Re: Map Conversion Utility, Anyone?
Re: Map Conversion Utility, Anyone?
Re: .MDL animations
Re: .MDL animations
Forward: Intermediate file format
Re: Forward: Intermediate file format
----------------------------------------------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@nero.uni-bonn.de>
Date: Sun, 10 Mar 1996 10:15:51 +0100 (MET)
Subject: Re: Quake tools in C++
> From: Steve Simpson <ssimpson@world.std.com>
> I'm interested in writing some Quake tools in C++, preferably using
> the C++ Standard Template Library (STL). I'll be developing using
> Win95 with memory mapped files. Are there others out there with
> similar interests (i.e. using C++ rather than C)?
All my tools (which are not primarily intended for Quake) are/will be
written in C++. I do not think, however, that I will use the STL.
From what I have seen, gcc-2.7.2 still has problems with STL, and
I consider UNIX (read: linux) and GCC (hopefully including DJGPP) my
base plattform. Is there any particular reason for your suggesting
STL? Haven
b.
------------------------------
From: Steve Simpson <ssimpson@world.std.com>
Date: Wed, 13 Mar 1996 08:18:35 -0500
Subject: Re: Quake tools in C++
Bernd Kreimeier wrote:
>
> > From: Steve Simpson <ssimpson@world.std.com>
>
> > I'm interested in writing some Quake tools in C++, preferably using
> > the C++ Standard Template Library (STL). I'll be developing using
> > Win95 with memory mapped files. Are there others out there with
> > similar interests (i.e. using C++ rather than C)?
>
> All my tools (which are not primarily intended for Quake) are/will be
> written in C++. I do not think, however, that I will use the STL.
> >From what I have seen, gcc-2.7.2 still has problems with STL, and
> I consider UNIX (read: linux) and GCC (hopefully including DJGPP) my
> base plattform. Is there any particular reason for your suggesting
> STL? Haven
>
> b.
I'm learning STL and looking for a project to try to put it to practical
use. It certainly doesn't have to be used on this project. I'd simply
be looking for ways where it could be used. The important thing is
doing it in C++. STL is secondary but may be useful.
Steve Simpson
------------------------------
From: "John B. Williston" <us018032@interramp.com>
Date: Wed, 13 Mar 1996 11:09:43 -0500
Subject: Re: .MDL animations
Brian K. Martin wrote:
> p.s. MDL (MedDLe) is up to version 1.0 and now has 3d texture mapped
> graphics and stuff.. http://www.phyast.pitt.edu/~brian/mdlv10.zip
I really like the job you've done on MedDLe. I'm trying to learn 3D
graphics right now myself -- are you still willing to share the code?
I suspect it would be helpful as a learning excercise. Thanks in advance!
John
- --
http://ourworld.compuserve.com:80/homepages/williston_consulting/
___ ___
\ \ ____ / / Williston Consulting
\ \/ \/ / _____________ "Software worth buying"
\ /\ / / _________/
\_/ \_/ / / 70541.1335@compuserve.com
/ /_________ us018032@interramp.com
/_____________/
------------------------------
From: Scott Coleman <asre@ni.net>
Date: Wed, 13 Mar 1996 10:11:09 -0800
Subject: Map Conversion Utility, Anyone?
In perusing the postings here, I've seen some discussions of homebrew Quake
editors. If it hasn't been already, I'd like to suggest that a map
conversion utility, which would convert existing DOOM maps to work with the
Quake Deathmatch Test engine, might be a good first project rather than a
full blown editor. My reasoning is as follows:
We all know that the Quake data file formats are in a state of flux, so a
full-blown editor would likely represent at least a not insignificant
amount of wasted effort because the end result would not work with the
next release of Quake. True, much of the investment in coding will be
reusable with little or no changes in the "Quake Final" editors. However,
the same is true for the routines developed for the conversion utility.
Among the advantages of making this map converter "detour" on the route to
a editor is that it would require less development time: a script driven
command line interface would suffice for the converter, as opposed to the
full blown 3D rendering and point-and-click interface which the editor
would require. With the thousands of existing DOOM levels as source
material, we'd have plenty to tide us over until the real Quake game and
levels arrive. Quake Ledges, anyone? How about Quake Danzig15? ;-)
At the rate you guys are hacking out the details, it shouldn't take more
than 2-3 weeks for a workable converter to come out - IF someone could be
persuaded to start working on one. Anyone up for it? BTW, once the
converter was finished, the code would of course serve as an excellent
foundation for the eventual editor.
One other wild idea: make the level compilers parallelizable over the
Internet. With a few cooperating net.folks, a group of hosts could be
organized to donate their spare CPU cycles to make the conversion process
move along more quickly. I confess I'm not an expert in the theory behind
the parallelization of algorithms such as BSP tree generation, so I don't
know how practical this is - either from a technical standpoint or from a
"political" standpoint - so feel free to slice it to ribbons. ;-)
Reaction? Comments?
begin 600 WINMAIL.DAT
M>)\^(@H2`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$-@ 0`
M`@````(``@`!!) &`#@!```!````# ````,``# #````"P`/#@`````"`?\/
M`0```%$`````````@2L?I+ZC$!F=;@#=`0]4`@````!Q=6%K92UE9&ET:6YG
M0&YV9RYU;FET+FYO`%--5% `<75A:V4M961I=&EN9T!N=F<N=6YI="YN;P``
M```>``(P`0````4```!33510`````!X``S !````&@```'%U86ME+65D:71I
M;F= ;G9G+G5N:70N;F\````#`!4,`0````,`_@\&````'@`!, $````<````
M)W%U86ME+65D:71I;F= ;G9G+G5N:70N;F\G``(!"S !````'P```%--5% Z
M455!2T4M141)5$E.1T!.5D<N54Y)5"Y.3P```P``.0`````+`$ Z`0````(!
M]@\!````! ````````.^/0$(@ <`& ```$E032Y-:6-R;W-O9G0@36%I;"Y.
M;W1E`#$(`02 `0`@````36%P($-O;G9E<G-I;VX@571I;&ET>2P@06YY;VYE
M/P!M"P$%@ ,`#@```,P'`P`-``H`"P`)``,`! $!(( #``X```#,!P,`#0`)
M``@`)0`#`!P!`0F `0`A````,C0V0S(X031!13=#0T8Q,4%$1C$P,#(P048T
M,#!!,3(`)@<!`Y &`/0'```2````"P`C```````#`"8```````L`*0``````
M`P`V``````! `#D`H/)*= @1NP$>`' ``0```" ```!-87 @0V]N=F5R<VEO
M;B!5=&EL:71Y+"!!;GEO;F4_``(!<0`!````%@````&[$0AT0Z0H;"5\KA'/
MK?$`(*] "A(``!X`'@P!````!0```%--5% `````'@`?# $````,````87-R
M94!N:2YN970``P`&$$S%#^4#``<0P08``!X`"! !````90```$E.4$5255-)
M3D=42$503U-424Y'4TA%4D4L259%4T5%3E-/345$25-#55-324].4T]&2$]-
M14)215=154%+145$251/4E-)1DE42$%33E1"145.04Q214%$62Q)1$Q)2T54
M3U,``````@$)$ $```!_!@``>P8``+P)``!,6D9U'T+Z2O\`"@$/`A4"J 7K
M`H,`4 +R"0(`8V@*P'-E=#(W!@`&PP*#,@/%`@!P<D)Q$>)S=&5M`H,S=P+D
M!Q,"@S0$UA,U"%!MW&EC!@0%X * ?0J ",_%"=D[&"\R-34"@ J!@PVQ"V!N
M9S$P,Q10KPL*%%$+\A-0;Q/08P5 2PJ/'#AC`$ @20.@< T$D'4`D!LP('1H
M97T?8&\3P!_!!" @$!@P+/D?,"=V(" 1L GP(7 #</4@(&0$`&,?H "0`B $
M(&QO9B# (>%B&# 'X%&8=6%K(" )@&ET!; \<RX?,"+P)" @P&%S=&XG!4!B
M(9('0!@P881D>2$29"!L:2/1XR0P(7!U9V<'D 5 ( "2805 82 `P' @!:#.
M;B%0$: BD2!U(' F@-)T)A%W:!:0:"E@"&#.;"9@*#0%0&5X! `@<N @1$]/
M32?B!" FT?DIT')K*6 D("FP( (CI*Y$)> @``# ="FA5"="G0GP9PN (0$6
M@&=H)4*))\%G;P1P(&9I$:#K!4 <T6H=$G(M<020)W*?)9$OP"GP`R "8&]W
M`Z#S) 0D<$UY,* EX"'0`P!_']$$`"6@!" "$#&P,@!S-CH=51U55R]!,;%K
M;O<R`"=T++AD)Z Q<0,0("#]`A!R+:$SH1@P)+ Q4A/ SR>@(" BX1L`=7@A
M$"'0W3%E+3'J*<4F@FPRTA-0_P>0"? GL05 -W E`">R-="W!4 +@ "09P,`
M+]!C`'#[)[$$8'4\42+A*6 \T0F _R/P#= 7T251/@`?H":Q(!'_"? F8#P1
M*? %0"G4/3(L'/TND'@PD3N@,P$X\R.C)'#V5!^0+J)U*:$BX2 ""X#_(5 3
MP > /%$X806@(B ?T?\#\#&R(" 8,!^@`: W<2QC_2D1=#=Q!;$UT"@@,3$G
M,6LX4B "(B.D1@N !T B]2/X2#(`92AA(1 @`D=@^R'Q,Y%T1%$WDA_S`V H
MX?\ND 0@#; A4!? 'W OL4SUZ2@_>2XT?$$$8!_5)?"Z=CX184DB(N$`P&L?
MQ.\SD2?X$] %P"(-L"0P"'#_2I HL4TF)K,GT#JE3&(GDN<DP2G4&#!Q=2_@
M(" W<-\$$4WU1<,@< > .CB"!03N9 40(5!&(FT#@29B+I#[.%%4`68`T$>A
M*>,G``W0_Q:03,A3IR$0,\%.0"!!/T'G)M$@`C&9,T0RX4"P!G$O']%:HB!
M6S$M6J$M8_TF@&,L0%LY*8- 8SJZ5W7])'!7+'8@``A@1V! L"+#_RJ\-W!.
M$3.C(= (<%NA+:'W!G$'0"E19291$8 A40M0]SQ!,M!>DFD-L"C0(L$H87\H
MT (P`Q%-(R7@`R CI&=W3"):HV:U<EH")' CI$PG"8 G,5W!;GD"(&4_OTLR
M): &X"C@+.8`<'HNX,0Q-6YP.RTI4$TV1-<PL2 @;C!U+W!U$[ X$_\1@&&0
M'\)N\B "5%$+<&;@^R$0),%S90$J`"4B`9 CT4<$8#@Q,2,R+3-H067^:S/2
M!< GT"P21W-3J";1UUIA./%O`2T?,$8APVY!_T\!*?(O,1]Q)P`E\%YD.+&_
M*H$L$G,3`Z!N021P06XC'RC0*!!,XB0@;G!"5%?_(1 "(%NA7/L^\B_!`P!T
MD/\)@$NT1D%;MB+A>>$1H2%Q_G(A43/!`Y$JL%N@,; \0O\"$#Z -P$HHDSF
M2W$",".P]P,@,D8T?$];`1SP,.)&L?LF8&FA85E 4J% 1&:C6E)^<#=A$: ?
M8 K -8$[H&E^>D=S:A,@`A] 5 $ND'3_9$4Q<0?1!:!.03"Q'\**XO\S\7:0
M7<$O<$UA*! BXQ/ 7P0@>><%L&NP`P!Z7F1D?P(@.-(@`2_@(7 =@2 @0_10
M54\`>6%@!Y$FT8>'_T\9'-%;H 01!&"!XA? ']'_=8-7D6&0.[ D<4\"BZ $
M$?TA,&T](X)#'W%%\V2T>9#^<C+0)6 I@$"Q( .)*(-S_R+A!T O@ 40+8%G
M(42R,\'X0E-03($)X"]P"?",(_\"(#F#E2"/P24Q-<,C$ ?@_Q-0`- @<#X`
M:J(SD3.1>1#?D% PTP-2)\$=`6@#`)W"WSBQ0+!@PTARGQ4B($ I$?^=LDJ0
MH"EY$#FABZ"(00-0?YLQ)M)A<3A!)V$FX 408N\&X " )'!P/U(EX)V1`B!G
M;G 6847"<S\T?!=1``&HL `#`! 0``````,`$1 `````0 `',&#^5[C_$+L!
>0 `(,&#^5[C_$+L!'@`]``$````!`````````(V1
`
end
------------------------------
From: "Brian K. Martin" <brian@phyast.pitt.edu>
Date: Wed, 13 Mar 1996 13:38:57 -0500 (EST)
Subject: Re: Map Conversion Utility, Anyone?
I think a doom map converter will be out as soon as some one
releases a utility which calculates the BSP tree for quake.
Isn't that what most of you are waiting for?
brian
------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Date: Wed, 13 Mar 1996 19:43:40 +0100 (MET)
Subject: Re: Map Conversion Utility, Anyone?
>I confess I'm not an expert in the theory behind
>the parallelization of algorithms such as BSP tree generation, so I don't
>know how practical this is
Creation of a BSP is a problem of making decisions (read: selecting the
right toplevel splits). This allows for brute force parallelization.
Heuristics or branch'n'bound are still exploring search trees - you might
try out alternatives in parallel.
I do not know about any BSP specific parallelization. Anybody?
Remebering the quoted John Carmack explanations, "qbsp" will not be the
problem anyway, nor will the radiosity-style "light". According to
this posting, the "vis"ibility list calculation is CPU intensive
despite being fully parallel.
Without looking into the details my guess is that parallelization of
this is not difficult (more or less optimal distribution of source nodes
on target processors), as long as each CPU gets a full copy of the
map data - any other node might be a possible destination for LineOfSight
and visibility checks.
On the other suggestions:
- - to my experience, a decent editor is 90% GUI in terms of development
effort. The WAD/PACK details do not matter in this regard. Come to
think of it, it is simply the same problem any decent 3D modeler faces.
Start thinking "plug-ins" instead of node builder etc. :-).
- - conversion of DOOM levels requires tools that depend on
WAD/PACK details - as those, in turn, depend on the algorithms
used. Read: id stating the files will change means the algorithms
will change. Thus the "qbsp"/"light"/"vis" tools will change.
While conversion is surely a step to go, I doubt it is a good
intermediate. You will probably neither see those in 2-3 weeks, nor
is the code likely be more reusable than any editor's.
Of course, simplified conversion (no lighting, dummy visibility lists)
are entirely possible.
- - a much more valuable intermediate might be working on VRML, DXF or 3DS
conversion, which would allow for both display (utilizing VRML browsers,
POVRAY) and map editing (commercial modeling software).
- - note that we do NOT have any map representation in the PACK/WAD/BSP.
It includes pre-processed lookups, but not the Constructive Solid
Geometry scene description. DOOM-speak: SSEGS, but no LINEDEFS.
We have to make up this up (e.g. by taking the Geometric Workbench
from Mantyla).
Of course, converting DOOM files has the advantage that there is
a generally accepted (albeit restricted) map representation, and
working editors. Thus you have a point.
>From: "Brian K. Martin" <brian@phyast.pitt.edu>
>I think a doom map converter will be out as soon as some one
>releases a utility which calculates the BSP tree for quake.
>Isn't that what most of you are waiting for?
Indeed :-).
b.
------------------------------
From: Jim Bucher <jim@gcchem.com>
Date: Wed, 13 Mar 1996 13:17:25 -0600
Subject: Re: .MDL animations
Brian K. Martin wrote:
> The data in the frame header defines the bounding block around
> the object. My guess is that the animation frame sequence is stored
> in the progs.dat file somewhere.
Could you post the format of the header?
> p.s. MDL (MedDLe) is up to version 1.0 and now has 3d texture mapped
> graphics and stuff.. http://www.phyast.pitt.edu/~brian/mdlv10.zip
I just checked it out. Pretty cool. My viewer also does 3D texture
mapping, and can cycle through the frames. I'll probably upload it to
ftp.cdrom.com in a couple of days. It will be called QMV05.ZIP. First I
am going to have some friends test it out.
------------------------------
From: "Brian K. Martin" <brian@phyast.pitt.edu>
Date: Wed, 13 Mar 1996 16:32:13 -0500 (EST)
Subject: Re: .MDL animations
>
>
>
> Brian K. Martin wrote:
>
> > The data in the frame header defines the bounding block around
> > the object. My guess is that the animation frame sequence is stored
> > in the progs.dat file somewhere.
> Could you post the format of the header?
>
first 4 bytes are 0. The next three are the lower limits, then a
mystery byte, the next three are the upper limits, then a mystery byte.
The x, y, z floats for each limit is found in the same way you find
the vertices (see quake specs).
In MedDLe, in 3d mode, hit 'h' and you will see the bounding box, then
cycle through the frames.
------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Date: Wed, 13 Mar 1996 23:01:50 +0100 (MET)
Subject: Forward: Intermediate file format
Forwarded to this mailing list.....
From: madsdyd@jarnsaxa.diku.dk (Mads Dydensborg)
Newsgroups: rec.games.computer.quake.editing
Subject: Intermidiate File format nessecary??
Date: 11 Mar 1996 17:49:16 GMT
HI all.
After reading the Unofficial Quake Specs, (Thanks to Olivier Montanuy and
cowriters), I'm left with the impression, that a BSP file, may not be the
best format to work with, during the *design* of a new level : When
creating the BSP file, surfaces may be split, new vertices and edges created,
etc. Oppisite to DOOM, where the SSEGS etc, where additional information.
Is this a correct understanding?
If yes, would it serve all purposes to agree on a format for exchanging
files under development? In this way, (if possible), a format for
editing could include ways to name mip-textures, etc. etc., and thereby maybe
even reduce the size of Quake add on levels : Collections of textures
could be distributed, and semicompiled levels could be distributed and
compiled by each user into BSP maps, from a tool designed for this.
Am I completly off track here? Probably.. :-)
Mads
- --
+---------------------------------------------------------------------+
| Mads Bondo Dydensborg. Student at DIKU, Copenhagen - Denmark. |
| Email: madsdyd@diku.dk www: http://www.diku.dk/students/madsdyd |
+---------------------------------------------------------------------+
------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Date: Wed, 13 Mar 1996 23:11:43 +0100 (MET)
Subject: Re: Forward: Intermediate file format
Forward of my reply....
From: bernd@NeRo.Uni-Bonn.DE (Bernd Kreimeier)
Newsgroups: rec.games.computer.quake.editing
Subject: Re: Intermidiate File format nessecary??
Date: 13 Mar 1996 12:45:14 GMT
In article <MADSDYD.96Mar11184917@jarnsaxa.diku.dk>
madsdyd@jarnsaxa.diku.dk (Mads Dydensborg) writes:
> From: madsdyd@jarnsaxa.diku.dk (Mads Dydensborg)
>
> After reading the Unofficial Quake Specs, (Thanks to Olivier Montanuy and
> cowriters), I'm left with the impression, that a BSP file, may not be the
> best format to work with, during the *design* of a new level : When
> creating the BSP file, surfaces may be split, new vertices and edges created,
> etc. Oppisite to DOOM, where the SSEGS etc, where additional information.
>
> Is this a correct understanding?
Yep. While the details of the BSP lookups will probably change significantly
until the final release of the shareware version, this particular detail
might not. It comes to my mind that distributing the preprocessed
lookup information (equivalent to SSEGS) while not using an level editing
information (equivalent to LINEDEFS) will make creating derivative works
and modification of both proprietary and free maps more difficult. Which
might or might not be done intentionally.
> If yes, would it serve all purposes to agree on a format for exchanging
> files under development? In this way, (if possible), a format for
> editing could include ways to name mip-textures, etc. etc., and thereby maybe
> even reduce the size of Quake add on levels : Collections of textures
> could be distributed, and semicompiled levels could be distributed and
> compiled by each user into BSP maps, from a tool designed for this.
Indeed. There are a lot of related issues (reference resource databases and
management of contribution repositories, the need of a CSG description
of a level for editing purposes, conversion issues of old resource
files aka WADs), and the fact that it will be futile to develop anything
sophisticated with only qtest1 in mind. Still any good proposal is
virtually worthless without a portable and commonly accepted reference library
supporting I/O based on any such non-id file format.
It will take some time. And most people will ignore even a decently
supported solution, solely because it is not used by id.
> Am I completly off track here? Probably.. :-)
I don't think so. Good point indeed. You might find some further
discussion of this on the Quake Developers mailing list
(majordomo@nvg.unit.no, send mail w/o Subject:, body: info quake-editing)
soon.
b.
- ---------------------------------------------------------------------------
"Problem solving is hunting. It is savage pleasure, and we are born to it."
- ---------------------------------------------------------------------------
------------------------------
End of quake-editing-digest V1 #8
*********************************
