GooberMan Posted January 20, 2019 (edited) I've been working on a little something in my spare time over the last few weeks. Many years ago, when I was doing 3D floor layouts in Prime Directive, it was really annoying me that the tools were so obtuse. It required essentially a hacker's knowledge of exactly how the feature works to place them. Draw a 2D sector, draw a control sector, set up the lines. Doing anything reasonably complicated with them required thinking in full 3D in a 2D space. The community has long used a baked binary format - the WAD - as both its source and target data, and it annoyed me that GZDoom Builder didn't support a custom source data, allow arbitrary placement of 3D floors, and bake that data down to a WAD during the save operation. Of course, adapting GZDoom Builder or even writing a new editor is a big task. There's a bit of a different solution out there. Enter BSP2Doom. Quake has existed for a while now. There's full 3D editors and everything. And Doom engines have supported 3D floors for a while now. Translating Quake maps to Doom isn't the impossible task it used to be. Honestly, I know community loves building these big sprawling vista maps at the moment, but it really felt like overkill looking at last year's Cacoward winners and every one had a vista screenshot. So let's see what kind of gameplay we can get out of Doom if we start thinking about it with verticality as an actual thing. Besides. I spend my work day knee-deep in Unreal Engine doing everything from bug fixes and optimisations; to finishing half-implemented features the UE team left about. This is relaxing and far less insane in comparison. The workflow goes something like the following: Use another tool in this package - Doom2QWad - to create a texture WAD that Quake editors can read This will also spit out configurations for Quake editors in the future Load up an editor like Trenchbroom Create a Quake level using Doom assets Compile your map. EricW's tools are the gold-standard in the Quake community at the moment. Do the following: Run qbsp. You don't get geometry otherwise. Run light. Your map will be fullbright otherwise. Don't build vis data. This is normally where you'd do such a thing for a Quake map. It's 100% unnecessary here Run BSP2Doom. This will spit out Doom-compatible data from your newly compiled Quake map. Run your normal node builder on the new map WAD. Run your map. The resulting map is not meant to be edited in a Doom editor. Depending on the options given to the BSP2Doom utility, the map could look anywhere between normal and nightmarish when loaded in a Doom editor. The WAD here is exactly a cooked data format. Only ever edit the source format. The code isn't ready for public release. It does already live on Github in a private repository though, so all I'll need to do is flick a switch when it's ready. Regardless, I plan on releasing it with a mapset rather than just dumping it on the community. I have a couple of maps in mind, but I'll also be on the look-out for experienced mappers who want to explore what Doom can do when properly exploiting a 3D playspace. No slaughter, no everything-is-a-trap, no epic vistas. Drop the cliches and let's see what else can be squeezed out of Doom. Also of note: I'm resurrecting Calamity with this tool. The old code I wrote will basically be ignored. Much of the code I'm writing now will make it in to Calamity with an optimisation pass or ten. It's all being written ground-up in D, which is resulting in some really clean code (the UDMF parser is ultra clean; the BSP parser reasonably clean; the WAD parser less so because it's an insane format wholly reliant on the original implementation). Progress Quake BSPs - Geometry shell done. 3D floors about 80% done. Doors and platforms TBD. Lightmaps working but constantly being tweaked. Coloured lighting (ie .lit files) supported. Quake overbrights supported. GoldSrc (Half-Life, Counterstrike) BSPs - Preliminary. Data structures almost identical to Quake BSPs, just need to build some test maps. Quake 3 BSPs - Preliminary. Data structures defined, but need to handle bezier patches before I can attempt to support it. A big question I have is how to support doors and platforms. I haven't decided if I want to bake them in to the map geometry, or use all the polyobject tricks I whipped up a few years back. I will likely try both approaches. Engines supported GZDoom - Working off 3.6.0 as a base, probably works fine on earlier builds Eternity - The UDMF namespace is fully supported at the least, but since the GZDoom implementation heavily relies on shaders this will probably need the software fallbacks I'm coding k8vavoom - Same deal with the shaders. A way to hook in to its own lightmap system with my pre-baked lightmaps will be fab and mostly eliminate the need for shader work. Output formats Map UDMF Textures PNG Doom lumps Packaging Doom WAD ZDoom folder structure Run 7zip or equivalent in your build pipeline if you need a PK3, this is designed to be a scriptable tool and not an all-in-one solution The theory behind translating geometry Spoiler The Doom map format is a two-dimensional format with three-dimensional data tagged in to it. There's a few things you need to do here. There's a word for a projectionless view of a three-dimensional space - orthographic. A Doom map as you see it in your editor is essentially a top-down orthographic view of a 3D space. This is the clue in how to translate a Quake BSP to a Doom map. Any surface that you can see looking top-down or bottom-up in a Quake map gets translated to a sector. Linedefs are thus defined by these surfaces. Any vertical surface disappears in an orthographic projection, so we translate these to sidedefs. Sectors with more than one floor and one ceiling surface get their additional surfaces sorted, control sectors created, and become 3D floors as you know them. Sounds pretty simple, yeah? The implementation can get a bit tricky, but it really isn't an unsolvable problem. As Quake levels are comprised of convex polygons, this also has the effect that every sector generated is convex. Some merging might be possible, but will likely be a pointless endeavour for any mildly complicated 3D map. Considering the Doom community has had no issue with making tiny detail sectors in their maps for well over a decade now, nor with making giant open vista maps, bigger convex sectors won't be that much of a problem in terms of performance. A responsible mapper will also want to take Doom BSPs in to account and provide negative space often from a top-down view. I think sourceports with 3D floors take those sector heights in to account when traversing the BSP, but it's still better to be safe than sorry. Things? Entities? Spoiler Currently, I search for specific Quake-style entities - info_player_start and light - and translate them directly to things. This will be expanded in the future to generate Quake editor definitions. Quake style lighting is quite different - how do you handle it? Spoiler There's several approaches that are being taken with lighting: Bake to vanilla textures - New 8-bit textures created with lightmaps pre-multiplied Ordinary - Full RGB lightmaps Quake - Paletted resolution of lightmap intensity, more accurately reproducing Quake overbrights Lighting system implementation details Spoiler The GZDoom material system is quite limited. It's designed for a specific purpose, and the recent PBR addition has done little to change that. I've tried to make it as unobtrusive as possible, both so that long-term maintenance on future GZDoom revisions won't break released mapsets; and so that people who like to load mods on top of mapsets will have less than a handful of issues when doing so. GLDEFS are generated with a material entry for each surface. Lightmaps are slotted in to the brightmap texture slot. Brightmaps are essentially additive lightmaps in GZDoom's material system. As we are using Quake lighting, we don't want Doom's lighting to interfere at all. Sector lights are set to 0 by default. For aesthetic reasons you may want to have a different minimum sector light (serving as an ambient light for things), so the shader forcibly discards Doom lighting anyway. Quake lightmaps are rendered at 1/16th the resolution of their surface textures. To keep memory coherency (ie a strict 2D layout in memory), they also render surfaces according to their texture rotation and thus include extra information that is never actually rendered in some circumstances. To avoid looking blocky, they get bilinearly interpolated at render time. Currently, all lightmaps are inflated to their full resolution and bilinear filtering applied at compile time. The intention here is that bilinear filtering gives undesirable results when hard shadows are encountered, so supporting different filtering methods will be implemented. Examples here to give you an idea of what can be done. Lightmaps are currently rendered as full RGB PNGs to support coloured lighting. DDS support will come so that I can store them as DXT1 textures directly (which should quite honestly be more than enough considering lightmap data has no real fidelity to speak of). Getting data in to GZDoom shaders can be difficult. Any extra data needed, subsequently, will be shipped over to the shaders via additional textures. This essentially gives complete control to the data being shipped over. Depending on whether you've picked Quake style lighting or not, an extra texture called ECOLMAP is added. ECOLMAP is just like the normal Doom colormap, except an extra 32 light levels have been added to it. Quake's overbrights essentially mean that Quake lights go from 0 to 2. Or, if we were to talk in terms of Doom sector lighting, 0 to 511. As such, an extended colormap lets us support overbrights as originally intended. This also means that we need to do paletted lookups. Greyscale extures get rendered out in Quake mode that represent exactly Doom palette indices. These get translated to X coordinate lookups for ECOLMAP. The lightmap level gets translated to Y coordinate lookups. Sidedefs represent a peculiar problem. ZDoom sectors support rotation - just add the sector rotation to your view rotation and voila, arbitrarily rotated flats - but walls do not. This is likely because it would require throwing out the column renderer in software mode. On top of this, multiple 3D floors in a sector will only refer to one set of midtex offsets. This makes supporting Quake surfaces entirely through mapdata a pointless endeavor. Using rendered textures that manually render rotation and scale will work, but the amount of unique texture data will be reduced in general with a texture per unique lightmap that provides data such as rotation and scale for the base texture. I am still not terribly happy that GZDoom does not supply a second set of texture coordinates for the brightmap channel. But we can deal with this quite adequately. Querying texture sizes and deriving additional texture coordinates will mean the only unique textures used are the new lightmaps (and the greyscale paletted entries if you're in full Quake mode). Sector lighting is not only basically ignored, but not good enough to light things. Quake light entities are translated in to GZDoom dynamic lights. Kinda. Lightmaps mean our surfaces are already lit by pre-placed lights, but placing a dynamic light means they get double lit. The solution is a hack, but it's a fun one: Quake lights get translated to dynamic spotlights with a full 360 degree arc. The lighting shader will thus look out for a matching spotlight and ignore if it one is encountered. No one in their right mind should ever place a spotlight like this, but it's the only way that has currently come to mind to light things and not light flats/textures. material_normal.fp currently is the only file I directly override from GZDoom, and that's solely because there is no configurability in its lighting system. And it is not future proof in the slightest. A modification to gl_shader.cpp to check for the existence of ProcessMaterialLight before loading in light_fragprog will mean I can avoid overriding material_normal.fp altogether. Screenshots Spoiler Ordinary overbrights Quake overbrights They're not perfect yet. I need to tweak the ECOLMAP generation algorithm to properly match the Quake brightness ramp. ECOLMAP Lightmaps, light things, and a manually placed dynamic light Playing around with EricW's light tools with light bouncing enabled, every light in this scene emits pure white Edited January 20, 2019 by GooberMan 51 Share this post Link to post
Gez Posted January 20, 2019 If I'm not mistaken, in ZDoom UDMF, each surface can have its own light level defined. So you could keep ambient sector lighting for things while having walls and flats at 0 light. Might be safer on the longterm than the hack with glitched spotlights that don't light geometry for some unclear reason. On an unrelated point, I remember that @printz also once made a Quake-to-3D floor converter, though less ambitious than this. 0 Share this post Link to post
GooberMan Posted January 20, 2019 I mean, I'd really like to not use that spotlight hack. The thing that'd make or break your suggestion is how Cacodemons floating across 3D floors will be affected by doing solely sector lighting. I've not seen a Quake poly inhabit anything larger than a 192x192 space, which sure is smaller than many DOOM.WAD/DOOM2.WAD sectors but also isn't really fine grained enough for subtle lighting. So I'd want to split in to further subsectors for an all-sector approach. 0 Share this post Link to post
Remilia Scarlet Posted January 20, 2019 How complex can the geometry be with this? Like, could it theoretically handle something like ad_sepulchre or Grendel's Blade? 2 Share this post Link to post
Gez Posted January 20, 2019 Foggy Bogbottom would be massively improved by having an automap available. 5 Share this post Link to post
GooberMan Posted January 20, 2019 25 minutes ago, YukiRaven said: How complex can the geometry be with this? Like, could it theoretically handle something like ad_sepulchre or Grendel's Blade? If you can build it in Quake, I can translate it. With some exceptions. One map I would like to make is something of a demolished building/ship crash kind of map. Which means doors would naturally want to be sloped. I can't translate dynamic objects to Doom like that. Certainly the portcullis style of doors would demand doors get implemented exclusively with 3D floors instead of polyobjects, but that also immediately rules out many Quake style doors. Moving platforms will work if I embed those ACS scripts I wrote, but there's also some changes I've long wanted to get in to polyobject collision resolution that would stop the desync bugs that are possible currently. 3 Share this post Link to post
Remilia Scarlet Posted January 20, 2019 Neat! Color me highly interested. This would solve two problems for me: needing a way to better handle 3D architecture in GZDoom, and give me a good editor in Linux. Are liquids translated to swimmable 3d floors? 0 Share this post Link to post
Edward850 Posted January 20, 2019 (edited) 1 hour ago, GooberMan said: And Doom engines have supported 3D floors for a while now While you might already know this, note that with Eternity it doesn't quite have 3D floors in the same way ZDoom does. Instead it has fully traversal portals, so instead of making a shape of a floor flagged from a control sector, you'd sort of make a map sandwich and a part of the floor/ceiling (or walls) is linked together. GZDoom does support these as well although I'm unsure of its compatibility level and naturally the line actions are different. 0 Share this post Link to post
Doomkid Posted January 20, 2019 This is really incredible, finally we have the ability to make 3D maps in such an easy way. Great stuff. 4 Share this post Link to post
GooberMan Posted January 20, 2019 8 hours ago, Edward850 said: While you might already know this, note that with Eternity it doesn't quite have 3D floors in the same way ZDoom does. Instead it has fully traversal portals, so instead of making a shape of a floor flagged from a control sector, you'd sort of make a map sandwich and a part of the floor/ceiling (or walls) is linked together. GZDoom does support these as well although I'm unsure of its compatibility level and naturally the line actions are different. I've never looked that deep in to Eternity, but that certainly kills the initiative I have to support it. It's not an impossible task. But it sounds like it means making a ton of horizontal map slices. Another implementation detail I neglected to mention is that I do all the heavy lifting in an intermediate format (hence why Quake 3 BSPs are on the cards), so sorting in to horizontal slices and running the code I already have on the results would be the obvious way to do it. Sounds fairly tedious to get up and running though. 1 Share this post Link to post
GooberMan Posted January 20, 2019 8 hours ago, YukiRaven said: and give me a good editor in Linux. Actually, this reminds me. The Quake community's editors and documentation are in a far worse state than here in the Doom community. I'm hoping an influx of people interested in Quake mapping would help that out. I'm also not a complete fan of Trenchbroom. Its entity property editor is fairly barebones - anyone used to Doom Builder is in for a shock. And its insistence on not providing standard move/rotate/scale gizmos is frustrating. Doing fine grained movement with camera angles it doesn't expect (ie anything approaching horizontal) often results in my brushes moving out to the distance. I also think that brush/entity selection would benefit greatly from a hierarchy view, not just from an organisational standpoint but to allow simple mass selection and things like group movement by selecting a parent node. I'm half tempted to write a Quake editor myself from here. That's probably one side project too far for me right now. 8 hours ago, YukiRaven said: Are liquids translated to swimmable 3d floors? That's the plan. Liquids are a little bit tricky in the BSP - no entity, capping surfaces only, name of the surface special-cased by qbsp and the engine. FWATER1 will be a solid wall by default. I need to double check the Quake source code for implementation details to see if there's anything I'm missing, but at the very least this is going to require user input to define liquid surfaces and my tool will generate Quake-compatible surface names from there. 3 Share this post Link to post
boris Posted January 20, 2019 7 minutes ago, GooberMan said: I've never looked that deep in to Eternity, but that certainly kills the initiative I have to support it. It's not an impossible task. But it sounds like it means making a ton of horizontal map slices. The complexity would probably go through the roof. Look at DM4, the stairs that lead to the quad damage. You'd pretty much have to horizontally slice the map for every single step, and that'd also affect other parts of the map like the shotgun room. Also, unless the Eternity wiki is out of date, Eternity's slopes are visual only, without physics. 0 Share this post Link to post
GooberMan Posted January 20, 2019 (edited) 21 minutes ago, boris said: Look at DM4, the stairs that lead to the quad damage. You'd pretty much have to horizontally slice the map for every single step, and that'd also affect other parts of the map like the shotgun room. That also sounds like a good stress test for Eternity's portals, since a thing would overlap several portals fairly often. Still. Supporting Eternity is well on the backburner for now. Especially if that's true about its slopes. EDIT: Another implementation detail. I'm setting floor and ceiling planes instead of using slope line actions. Having to make a ton of control sectors to make basic slopes doesn't sound like my cup of tea. Something as simple as this would need a control sector: Edited January 20, 2019 by GooberMan 1 Share this post Link to post
Remilia Scarlet Posted January 20, 2019 2 hours ago, GooberMan said: anyone used to Doom Builder is in for a shock. I definitely was, but in the opposite direction you described. Doom Builder now feels horribly clunky to me without shearing, brush cutting, CSG, visual scaling of faces, a clear entity properties panel... But that's me. It doesn't feel like Blender and that makes me very happy. TrenchBroom is part of why I've since moved on to Quake. 0 Share this post Link to post
GooberMan Posted January 20, 2019 The side-panel list of entity properties is certainly the better way to go than the DEU-style properties boxes that Doom Builder uses. Trenchbroom's panel however just feels so manual-labor compared to modern engine editors. It can definitely be improved, especially with some docking support so that I can have the panel floating wherever I want. But yes, everything else I basically agree with. Quake editing pipelines more closely resemble modern engines. 0 Share this post Link to post
Linguica Posted January 20, 2019 2 hours ago, GooberMan said: Quake editing pipelines more closely resemble modern engines. 4 hours ago, GooberMan said: The Quake community's editors and documentation are in a far worse state than here in the Doom community. Maybe these are related!! 1 Share this post Link to post
printz Posted January 20, 2019 15 hours ago, Gez said: On an unrelated point, I remember that @printz also once made a Quake-to-3D floor converter, though less ambitious than this. Yeah, I made a tool called MAPtoWAD (no relation with that Wolf3D tool) which converts Half-Life .map files (made with Worldcraft 3) into UDMF TEXTMAPs, using 3D floors everywhere inside a large box. All brushes which had vertical side faces and only two horizontal or sloped ones would become 3D floors in GZDoom. It would not produce normal sectors, practically everything, save the walls and the necessary control sectors, would be 3d floors. Every place had the same light level, so I would only rely on "light" entities to produce GZDoom dynamic lights. I lost interest on the tool when I realized that just producing 3D floors wouldn't scale well (because there's no BSP optimization in GZDoom for them), especially when you'd overlap partially many of them: lots of tiny sectors would result and the performance would tank. Dynamic GZDoom lights were also terribly slow and I found it too hard to convert Quake lights into classic Doom sector lights. I also didn't quite know how to implement doors. I guess that having to deal with .map files instead of .bsp files meant that I had to work with building blocks (polyhedrons) instead of actual rooms, so I had no clear information what is going to be a sector, so all I could produce were 3D floors. Source code link: https://www.dropbox.com/s/y7xnf78ks3ynav5/MAPtoWAD.zip?dl=0 @GooberMan: Are you going to place linked portals instead of 3D floors if the two overlapping areas are unrelated? I mean that if passage 1 is above passage 2 and they're only connected in a hub room, place a linked portal near the hub room. Possibly helped by the Quake map author placing a special "portal" brush to mark where the portal should appear. 2 Share this post Link to post
Edward850 Posted January 20, 2019 7 hours ago, GooberMan said: I've never looked that deep in to Eternity, but that certainly kills the initiative I have to support it. Unfortunately that certainly kills my interest in this thread. It's not really any interesting if all this works on is the two least-doom ports we have. 0 Share this post Link to post
GooberMan Posted January 20, 2019 (edited) 6 hours ago, Linguica said: Maybe these are related!! I know a number of people on these forums would agree with your suggestion, but I find it to have a degree of false equivalence. There's several orders of magnitude more people making content with modern engines and modern editors than the Doom and Quake communities combined. There's plenty of theories one could put forward as to why people are more drawn towards Doom rather than Quake editing. Certainly from a pure map-creation perspective, there's nowhere near the variety in Quake bestiary as there is in Doom's bestiary. I'm tempted to make a parody Quake map called "I'm a piece of shit that thinks placing Spawns, Vores and Shamblers everywhere is a good challenge" but the straight-up truth of the matter is that your only other alternative is four types of melee enemy (two with alternate ranged attacks), the Scrag, zombies, and a couple of grunts. E4 is fantastic because it acknowledges that and goes for environmental tomfoolery. Doom mapping is often called simple because it's just like drawing a map on a piece of paper. Quake mapping, on the other hand, is a lot like building with Lego. This reminds me too. I saw a commit go in to the Trenchbroom Github that finally fixes subtractive geometry operations to operate on the world instead of needing to select everything else and then selecting the single brush you want to subtract last. And a new version was released a few days ago. Time to download that. EDIT: Yep. That significantly increases the editing experience. Edited January 20, 2019 by GooberMan 3 Share this post Link to post
GooberMan Posted January 20, 2019 4 hours ago, printz said: @GooberMan: Are you going to place linked portals instead of 3D floors if the two overlapping areas are unrelated? I mean that if passage 1 is above passage 2 and they're only connected in a hub room, place a linked portal near the hub room. Possibly helped by the Quake map author placing a special "portal" brush to mark where the portal should appear. Purely to keep my sanity, I'm focusing on getting it working in GZDoom first without portal tomfoolery. That certainly sounds like a great suggestion though for optimisation purposes. It almost starts resembling Doom 3 editing in that respect, placing down sectors for the portal culler. To that end: 3 hours ago, Edward850 said: Unfortunately that certainly kills my interest in this thread. It's not really any interesting if all this works on is the two least-doom ports we have. This will be an open source project. I'd be open to the right pull request from the right programmer. Programming in D really isn't that hard, at least the part that will need modifying. The UDMF parser makes heavy use of compile-time introspection and code generation, but the code that actually builds Doom compatible geometry should be quite readable to anyone with a basic understanding of C#. I'm not sure I'll have the patience or interest myself to do all the portal tomfoolery, but we'll see how things go when it's getting closer to release time. 0 Share this post Link to post
Linguica Posted January 21, 2019 2 hours ago, GooberMan said: I know a number of people on these forums would agree with your suggestion, but I find it to have a degree of false equivalence. There's several orders of magnitude more people making content with modern engines and modern editors than the Doom and Quake communities combined. Those modern game engines and editors are also several orders of magnitude more complex and have god knows how many person-years invested in their creation and debugging. To the extent that the Quake "editing pipeline" is more onerous and requires more tools and steps and editing knowhow, the number of people willing to make such tools for free, and make them work well, is going to decrease accordingly. 4 Share this post Link to post
Pirx Posted January 21, 2019 23 hours ago, YukiRaven said: How complex can the geometry be with this? Like, could it theoretically handle something like ad_sepulchre or Grendel's Blade? a bit off topic, but thanks for mentioning these maps... i haven't been following the quake mapping scene as closely as i do with doom's and i can't believe what i've missed... yeah ;) and this tool sounds like a revolution in doom 3d-mapping. 4 Share this post Link to post
hidfan Posted January 21, 2019 I find this quite impressive :) Id's quake editor (now Radiant) always looked to me like a doom editor: a 2D top view for line defs and a little "z" vertical window for sector's height. On the lighting subject, an extended method, that needs a special shader to run, so it's not easily compatible: half life2's lightmaps store 3D lighting (you have 3 lightmaps: horizontal, vertical, front), useful for bump/normal maps. Anyway, ray/path tracing for everyone is not far away and could do marvels in doom. Probe lighting could be a PBR compatible lighting solution meanwhile. 3 Share this post Link to post
GooberMan Posted January 21, 2019 (edited) 12 hours ago, Linguica said: Those modern game engines and editors are also several orders of magnitude more complex and have god knows how many person-years invested in their creation and debugging. To the extent that the Quake "editing pipeline" is more onerous and requires more tools and steps and editing knowhow, the number of people willing to make such tools for free, and make them work well, is going to decrease accordingly. Granted. I can certainly go in to plenty of detail here as to exactly where that complexity is, and why the fundamentals of item placement and object manipulation can be comparable between Quake and modern engine editors (and why that only takes a man-month to get a good quality implementation competitive with Unity and Unreal). But why do more people try to create tools for Doom instead of Quake? Doom is a far more obtuse from a data perspective than Quake, and Doom editing is only in the reasonably good state it's in right now because people looked at the tools and the pipeline and thought they could do better. What if we were still using XWE instead of SLADE? What if Doom Builder was never written? There's certainly still improvements that can be made to the Quake pipeline. Custom monsters are a big one - ZDoom has plenty of "drop in" custom monsters. That still need you to manually construct a DECORATE with all the combined entries, but it's still a reasonably smooth process. There's no particular reason a progs.dat manager that handles new monster definitions and generates appropriate support code can't be done, other than no one wants to do it. So people still have to invoke QC. Trenchbroom also really needs to ditch those CAD views and provide multiple 3D viewports. CAD view really does nothing to help a normal person look at a Quake editor and think "I can use this". Real time lighting preview is certainly quite achievable as well, either by using modern rendering techniques or going old-school and using surface caching similarly to how the original Quake software renderer operated. But here I am writing a tool to improve the Doom editing experience, with a tangential goal of improving the Quake experience by getting more people interested in Quake editing. Interesting aside: Dusk's levels are Quake[1] BSPs converted to Unity. Perhaps we're on the threshold of a Quake resurgence. Quake 2, though, is in an even worse place (and with only one source port worth talking about). Quake 3, well, Googling for various terms only shows me quake3world as a hub and that seems fairly barebones. [1] Well, honestly, I say Quake but I figure GoldSrc would be the better option since each embedded texture contains its own palette. 3 Share this post Link to post
ketmar Posted January 21, 2019 (edited) 1 hour ago, GooberMan said: Real time lighting preview is certainly quite achievable as well, either by using modern rendering techniques or going old-school and using surface caching similarly to how the original Quake software renderer operated. yeah, k8vavoom does it The Old Way. realtime with shadows. as for "why doom"... i thing this is due to lower mental entering costs. i.e. people looking at doom and thinking: "ok, it is still 2d, like simply drawing on a paper" (it is not quite true, but it looks like that). and for Q they seen it as Hard 3D Architecting. besides, it is quite easy to write a doom automap-style renderer. and WOW! i am working with engine data already! writing even wireframe view for Quake looks harder. so, in the end, people did more for doom 'cause it looks easier to do. also, there is anoter very important factor: Quake and Quake 2 are boring games. each in its own different sense, but boring. i am still playing vanilla doom episodes, but i hardly can remember when i played quakes last time. i mean: "ok, i want to play it, from start to finish". so when you're doing, for example, DooM sourceport, you will immediately have at least two great games to play with it. for Quakes... "yeah, looks impressive. now, can we have some REAL game to play?" ;-) p.s.: just in case. people, i didn't said that quakes were bad! let's not start it all again here. ;-) 1 Share this post Link to post
Dark Pulse Posted January 21, 2019 Let's all just duplicate UnrealEd and be done with it. View > Viewports > Fixed, click OK. 0 Share this post Link to post
Bauul Posted January 21, 2019 I just think more people map for Doom because more people like Doom these days? Anyway, back on topic: this looks extremely interesting, especially for those of us who try to push the modern source ports hard. Although I'm now just hoping this hasn't outdated all my forthcoming UDMF maps by the time they get released! I'm particularly interested in the lightmap approach. I appreciate the example screenshots, but is there a chance you could quickly mock up say a light shining through horizontal bars to really give us a sense of how they look in practice? 1 Share this post Link to post
Bridgeburner56 Posted January 21, 2019 This is very interesting for a mapper like me. Watching with intense curiosity 2 Share this post Link to post
GooberMan Posted January 21, 2019 3 hours ago, Bauul said: I appreciate the example screenshots, but is there a chance you could quickly mock up say a light shining through horizontal bars to really give us a sense of how they look in practice? That's the first time I tried using such small bits of geometry, and I immediately found issues. I can give you a couple more screenshots of some limping-along version though to give you an idea: You can really see the low fidelity of Quake lightmaps here - each texel of the lightmap is equivalent to 16x16 texels of the texture it operates on. Quake 3 lightmaps can work better, but they also come with their own set of quirks. There are also ways to cheat Quake lightmaps, that I only realised after delving deep in to their implementation details. Quake lightmaps are generated entirely in texture space. The physical surface size matters not. So if you were to double the texel density of a surface - say, by scaling the texture - you also get higher resolution lightmaps. I might branch EricW's tools and work out a way to let you scale lightmap generation for BSP2Doom's purposes. 3 Share this post Link to post