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.

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.

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.