Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
GooberMan

Announcing BSP2Doom - build Doom levels with a Quake editor

Recommended Posts

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.

Share this post


Link to post

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.

Share this post


Link to post

Foggy Bogbottom would be massively improved by having an automap available.

Share this post


Link to post
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.

Share this post


Link to post

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?

Share this post


Link to post
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.

Share this post


Link to post

This is really incredible, finally we have the ability to make 3D maps in such an easy way. Great stuff.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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:

 

d0e8114.png

Edited by GooberMan

Share this post


Link to post
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.

 

Share this post


Link to post

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.

Share this post


Link to post
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!!

Share this post


Link to post
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.

Share this post


Link to post
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. 

Share this post


Link to post
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 by GooberMan

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post
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. ;-)

Share this post


Link to post

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?

Share this post


Link to post
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:

 

F6jk2Jx.png

 

HA4HW3U.png

 

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.

 

1XnngWn.png

 

I might branch EricW's tools and work out a way to let you scale lightmap generation for BSP2Doom's purposes.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×