Do vanilla Doom nodebuilders with UDMF TEXTMAP support exist?

[printz]

I'm developing UDMF support for a vanilla Doom compatible engine. For now (ad-hoc and not standardized), NODES/REJECT/BLOCKMAP/SEGS/SSECTORS are expected to be between TEXTMAP and ENDMAP.

Is there a nodebuilder that:

1) Detects UDMF map and reads (and then updates with extra vertices) the TEXTMAP?
2) Generates the BSP and other postprocess lumps and places them, in arbitrary order, between TEXTMAP and ENDMAP?

Of course ZDBSP is there, but can it do this or is it limited to ZNODES?

[Gez]

Vanilla nodes would also require adding a VERTEXES lump...

ZDBSP is the only nodebuilder compatible with UDMF so far, and it is limited to ZNODES.

[andrewj]

UDMF supports arbitrary precision vertices -- vanilla nodes simply won't cut it.

You're gonna have to add code for reading ZNODES, like it or not.

[Graf Zahl]

ZDBSP's UDMF support was written with ZDoom's needs in mind - since at that time it was the only port supporting UDMF.

As such it only does what ZDoom requires, meaning GL nodes in ZDoom's extended format. Compression is neither required nor encouraged.

The 'classic' node structure will cause major problems anyway because most of the structures in there lack the required precision to deal with non-integer vertices so you really should not bother with these since fixed point precision vertices are part of the UDMF base specification. Even ZDoom had to change the format of the ZNODES lump because it was discovered that not having fixed point precision in the node lines was enough to generate broken nodes.

In short: Don't bother with classic nodes, you'll shoot yourself in the foot because they are ill-equipped to support UDMF's minimum needs.

Writing a ZNODES loader is certainly the easier solution here. You should also provide an internal blockmap builder because ZDBSP will not create a blockmap for UDMF (for the simple reason that creating this on the fly is sufficiently cheap, even on large maps.) And since no REJECT builder for UDMF exists - and probably never will - just skip that lump.

[jmickle66666666]

Wouldn't it be possible (though not ideal) to convert the map to standard doom format from UDMF, then process in any nodebuilder, then convert the relevant lumps back to UDMF?

[Graf Zahl]

No. UFMF - even in its base specification contains features that cannot be stored in the old binary map format - the most important one being fixed point precision vertex coordinates.

You'd end up with some horribly broken BSP if you'd try to process such a map.

It'd also render all advantages of UDMF useless. The mere point of the format is to be able to provide MORE features than the binary map format. Moreover, if the features need to be limited, any such implementaton would NOT be UDMF anymore, because due to the limitations imposed by the crippled node format it wouldn't be able to implement the full spec.

Sorry, but I really don't get it why this is even being considered. There's really nothing with extended nodes that'd break a simpler source port - the only consideration that needs to be taken care of is that GL nodes contain segs that are not part of any linedef. I know that these may crash the original sight checking code if not being taken care of - and they need to be skipped when being processed by the renderer, but that really should be it.

I'm certainly not spending time on ZDBSP because someone thinks that they need a different node format than what has already been established and andrewj's post suggests that it won't be different for glbsp.


It should also be noted that the UDMF spec makes absolutely no provisions about any such machine generated lumps. A 'proper' UDMF implementation must - if I read the spec correctly - be able to load maps WITHOUT them - in other words: an integrated node and blockmap builder would be a mandatory requirement to read a map in the base UDMF namespace!

[scifista42]

Graf Zahl said:

No. UFMF - even in its base specification contains features that cannot be stored in the old binary map format - the most important one being fixed point precision vertex coordinates.

You'd end up with some horribly broken BSP if you'd try to process such a map.

In other words, it is possible, as long as the given map doesn't rely on such inconvertible features. OK?

[jmickle66666666]

Graf Zahl said:

It should also be noted that the UDMF spec makes absolutely no provisions about any such machine generated lumps. A 'proper' UDMF implementation must - if I read the spec correctly - be able to load maps WITHOUT them - in other words: an integrated node and blockmap builder would be a mandatory requirement to read a map in the base UDMF namespace!

I agree that this is the ideal situation and think sourceports should try to include a node builder nowadays. it makes sense that this is what should be focused on instead of (an ultimately non-permanent) solution for leading udmf with extra lumps.

[Graf Zahl]

scifista42 said:

In other words, it is possible, as long as the given map doesn't rely on such inconvertible features. OK?

What would be the point? Either a port supports UDMF or it doesn't. If it does, this would be a crutch at best and a breaking issue at worst.

On the other hand if some people really think this is the way to go they have to declare their port non-UDMF-compliant because they essentially only support a subset of it.

That's really all that's to say about it.