Importing UDMF levels into the Godot engine

Discuss anything ZDoom-related that doesn't fall into one of the other categories.
User avatar
nova++
Posts: 177
Joined: Sat Sep 04, 2021 3:13 am

Importing UDMF levels into the Godot engine

Post by nova++ »

Once again I find myself with a difficult-to-categorize thing to share in the General forum.

I have been doing a thing on and off more or less because I can. It is exactly what the title says - I made a UDMF parser in the Godot engine that tugs a TEXTMAP lump out of a wad file and turns it into a data structure, and then builds a mesh from that.

Image

Of course there's still a long way to go, but data parsing gives me some pleasing brain tinglies for some reason (a warning sign, perhaps). I'll probably play with texture importing soon - parsing a TEXTURES lump (see, it's gzdoom related after all) and compositing patches into final textures, which there are in fact facilities for in the engine, so that helps. Just PNG lumps to start with since there's some convenient functions to ingest raw PNG binary data into an image object, maybe for funsies I'll try to make one that parses actual doom-format textures at a later time. Or the map format too for that matter. But one step at a time.

Image

Just one big monolithic and static mesh at the moment. For dynamic elements perhaps I would exclude potentially-dynamic sectors and render them with realtime procedural geometry instead. Also, I need to work out a way to properly subdivide non-contiguous bastard sectors as the triangulation routine I'm using only works with continuous, bounded polygons.

In this day and age, the amount of mesh data involved for even an immense level is laughably trivial. There is effectively no reason for me to go through the trouble of splitting up the mesh and culling parts of it unless, I dunno, overdraw or something becomes a major concern. Textures can just be crammed into a handful of texture arrays for the whole map and only take up a tiny number of drawcalls. Modern technology sure is amazing!

Anyway, I'll post on and off whenever I tinker with this and make some progress. We'll see what if anything it turns into.
User avatar
KynikossDragonn
Posts: 260
Joined: Sat Dec 12, 2020 10:59 am
Preferred Pronouns: He/Him
Operating System Version (Optional): Void Linux
Graphics Processor: Intel (Modern GZDoom)
Location: Independence, KS, USA

Re: Importing UDMF levels into the Godot engine

Post by KynikossDragonn »

That's funny, there's a plugin for Godot to import your Trenchboom maps into it. Cruelty Squad made ample use of it.

This is a rather curious project; I wonder how something like, say "Bastion of Chaos", would handle in Godot's renderer?
User avatar
nova++
Posts: 177
Joined: Sat Sep 04, 2021 3:13 am

Re: Importing UDMF levels into the Godot engine

Post by nova++ »

This is a dev build Godot 4.0, so it's a modern Vulkan renderer - the largest map I've tried turned out to be about 50,000 triangles, which is peanuts. Of course, that's with no textures, but still. If anyone's got any link to any obscenely large UDMF maps, I can feed them to my monster.

... I'll have to keep that trenchbroom plugin in mind, that could be useful for other things.
User avatar
Enjay
 
 
Posts: 26441
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland

Re: Importing UDMF levels into the Godot engine

Post by Enjay »

If you just want a big map with complex architecture (where line activations and gameplay are not important), and you can't find a suitable UDMF map, any ZDoomHexen map fitting the required parameters can be quickly and easily converted to UDMF in UDB:

Load the map in the ZDoomHexen format, hit F2 and open a UDMF configuration, save. Job done.

Like I indicated, there may be a few line actions etc that don't convert over well (most will) but if you only need the architecture, that'll come across just fine.

This means you could convert the ZDoom Community maps, for example. And they probably do what you want.
User avatar
nova++
Posts: 177
Joined: Sat Sep 04, 2021 3:13 am

Re: Importing UDMF levels into the Godot engine

Post by nova++ »

Alright, progress on texture loading. Not too bad thankfully... the parser is quick and dirty but functional and there's some nice functions to blit texture contents from one region to another, so building the textures after import is quite easy. However, it seems kind of picky about what PNG data it wants to process. I'll have to look into that more. Doing a "convert to -> PNG truecolor" in slade made everything work again and I am not sure why since they already were...

Image

PLASTR3 there is the compositing test, it's composed of a few patches:

Code: Select all

Texture "PLASTR3", 64, 128
{
	Patch "PLASTR1", 0, 0
	Patch "PLASTR1", 0, 64
	Patch "PLSTRM2", 0, 0
	Patch "WTRIM1", 0, 80
}
User avatar
nova++
Posts: 177
Joined: Sat Sep 04, 2021 3:13 am

Re: Importing UDMF levels into the Godot engine

Post by nova++ »

And now they are, in a very preliminary manner, loading into the level:

Image

Of course, this certainly makes the fact it skips the non-contiguous sectors much more obvious... I guess I'm going to have to start doing that soon.
SquarePeg
Posts: 4
Joined: Mon Jun 25, 2018 9:11 pm

Re: Importing UDMF levels into the Godot engine

Post by SquarePeg »

Is there a public github repo for this?
User avatar
nova++
Posts: 177
Joined: Sat Sep 04, 2021 3:13 am

Re: Importing UDMF levels into the Godot engine

Post by nova++ »

Well, I thought I had made a breakthrough in triangulating noncontiguous sectors but then I found edge cases that break it so... oh well.

Nonetheless, something else I'm poking at is a simple generic sky material - apply to any surface and it renders a skybox without fuss, none of the hacky sector tricks we've become accustomed to with doom. I'm honestly looking forward to building all this out. I can't consider this a "source port" though, because it's not running anything pre-existing, but there is a slowly growing chance that I may move my TC project into this framework if it goes well...
SquarePeg wrote:Is there a public github repo for this?
There is not. Everything's very kludgey and unoptimized right now, but I think I will put it up publicly eventually once it's in a more robust state. However, it probably would not be a nice neat package to just drop in but rather just a collection of source code to pilfer from for folks wanting to implement similar things.
User avatar
nova++
Posts: 177
Joined: Sat Sep 04, 2021 3:13 am

Re: Importing UDMF levels into the Godot engine

Post by nova++ »

Yaaayyy I think I got it. My general idea was right but I had to enlist a friend to help me work out the actual implementation. Still doesn't handle completely separated sectors but that should be easier, I hope.

Image

It works by finding the nearest point from one polygon to the next (pending checks to make sure it doesn't cross existing lines) then using that to splice a bridge into the resulting polygon. The red lines are two lines of a single continuous shape, just on top of one another. Kind of like the difference between the letter O and the letter C with its points infinitesimally close, for instance. Once it's a continuous bound, it's easy to feed the triangulation algorithm I already am using.

I THINK most of those edge cases should be resolvable by rearranging how it processes the different sector merges. Any walled-off area (that is still connected) should be accessible if the region blocking it is connected first. Maybe some sort of retry routine - if it can't find any clear paths from one sector to another, it will skip it, try a different one, then come back to the failed one afterward. That would probably be the most robust way to do it.
User avatar
nova++
Posts: 177
Joined: Sat Sep 04, 2021 3:13 am

Re: Importing UDMF levels into the Godot engine

Post by nova++ »

And finally I've got it integrated into the importer. It still has some edge cases it fails at but those are much rarer and weirder and I will worry about them later.

Image
(Man, I wish imgur would still let you view direct image links... no matter, I will be working out a homebrew solution soon enough I hope)

I suppose soon enough I'll be working out traversing the playable area... I could just apply a typical physics collider to the environment but it's kind of big for that, and I am kind of curious to attempt to imitate some of the gzdoom character physics code...

I am kind of wondering where the heck this falls in terms of the licensing for GZDoom. I'm not actually modifying it's source code, but I am parsing some of the same lumps (like TEXTURES and TEXTMAP), and might end up re-implementing some of its same code. I guess that doesn't matter until if/when I make some sort of releasable project out of this. So there is definitely plenty of time.
User avatar
nova++
Posts: 177
Joined: Sat Sep 04, 2021 3:13 am

Re: Importing UDMF levels into the Godot engine

Post by nova++ »

I'm at this again...



For movement I ended up leveraging Godot's built-in 2D physics because it's a lot faster and more robust than turning the whole level into polygon collisions, and given the constraints of the format (all walls vertical etc) it was much easier to simply define the level as a 2D physics space with line collision, selectively passing certain objects based on relative height differences. Vertical motion is done manually based on picking the highest and lowest ceilings and floors that the object currently overlaps.

Being able to bump other objects out of the way is an interesting side effect of things being just 2D rigidbodies. I'm not sure how much I'd want it in an actual game situation, but then again being able to run up to an enemy and shove them into a death pit is kind of cool...

------

Regarding my previous triangulation adventures - turns out there are some convenient libraries included with Godot (https://github.com/ivanfratric/polypartition) which proved absolutely invaluable for doing this and I immediately threw out a bunch of my code because this stuff worked much better.

I'm also using the triangulation as a means to map points into sectors. That, as well as the bounding box of a given sector, as well as a blockmap-like map of 256x256 unit level cells that contain info about what sectors and objects are inside them.
User avatar
DrPyspy
Posts: 263
Joined: Sat Feb 21, 2015 7:35 pm
Operating System Version (Optional): Windows XP Gangster Edition
Location: Utah, USA

Re: Importing UDMF levels into the Godot engine

Post by DrPyspy »

This is amazing stuff! I shall be watching with close interest ...
User avatar
nova++
Posts: 177
Joined: Sat Sep 04, 2021 3:13 am

Re: Importing UDMF levels into the Godot engine

Post by nova++ »

I appreciate the interest... I recently got moving sectors working, although I am kinda trying to think of how I want to actually implement that on the editor side. Linedef triggers and stuff are the classic way but seeing as I'm not beholden to the same engine limitations, the ball is kind of in my court. As long as I can make editors cooperate with the method, anyway... the main limitation of my method is having to know ahead of time which sectors are changing, since it then skips them in the main mesh generator and instantiates them as a dynamic sector object instead.

I admit, the lack of good linux compatibility among level editors and some inflexibilities in implementation (what, you mean they weren't designed to be twisted into working for a completely different engine? pffssshhh) is getting me down here and almost tempting me to try making my own. That... is a long and bumpy road to go down, though.

Return to “General”