Reliable Nodebuilding for Large Maps?

I'm currently using ZDBSP, BSP-W32, whatever nodebuilders that came packaged with Doom Builder.

I've had the problem of node builders failing on my larger maps for quite awhile now, it happens on my more complex maps like Stargate, Unholy Cathedral, and currently my newest map21 through Doom Builder and Doom Builder 2.

The nodebuilding failure comes and goes, sometimes when I save and the nodebuilders fail, I add an extra sector or two into my maps and the problem is solved... other times, it just fails no matter what I do, like currently.

I'm not sure what to do for larger maps (map21 and the unholy cathedral is approximately 64k segs) to make the nodebuilding successful. Help?

Share this post


Link to post

If it fails due to exceeding the seg limit there really isn't much you can do except using a source port and node format that can handle it.

The only option right now is ZDoom's compressed node format but no other port in existence has implemented support for it yet.

Share this post


Link to post

Maybe useful to ship the next version of DB2 with a ZDBSP profile included that compresses the nodes.

If you feell like making your own nodebuilder profiles, you can go into the Compilers\Nodebuilders\ directory in your Doom Builder 2 directory. There you will find the profiles in .cfg files. The cfg files that come with DB2 will be overwritten, so make a new .cfg with a different name for your own profiles. Then paste the following structure in the file and edit it as you like:

nodebuilders
{
	// The following is a unique name you can make up yourself.
	// It is recommended to begin with the compiler name.
	zdbsp_myownprofile
	{
		// The title to be displayed in the editor
		title = "ZDBSP - Normal";
		
		// The compiler to use (the 'zdbsp' compiler is further defined in other .cfg files)
		compiler = "zdbsp";
		
		// The parameters to use in this profile
		parameters = "-o%FO %FI";
	}
}
For example, if you want compressed nodes for ZDoom, you add -z before the -o in the parameters. So the line would look like this:
		parameters = "-z -o%FO %FI";
The parameters have some special placeholders %FO and %FI which are the input and output files. Don't touch them.

Share this post


Link to post
Graf Zahl said:

If it fails due to exceeding the seg limit there really isn't much you can do except using a source port and node format that can handle it.

The only option right now is ZDoom's compressed node format but no other port in existence has implemented support for it yet.

Okay, but...

The ZDoom wiki says
Compressed nodes contain all the same information as regular nodes but are stored in a single lump and compressed as a zlib data stream. They also support more than 65535 segs and vertices by storing them using four bytes instead of two.

(emphasis mine)

From the wiki the format sounds fairly straightforward and I would have been inclined to attempt to write some patches to support it, until I read the part about mandatory zlib. It's offputting to have to add a library dependency I don't otherwise need and would only be used occasionally on the very biggest of big maps.

Besides, why compress? Wads are already distributed compressed in zip files, after all.

Share this post


Link to post

What's the problem with zlib? You'll need it anyway if you want to support PNG graphics.

Besides, it's ridiculously easy to use. Just add the files to the project and it's done.

That said, I had no influence in the decision to compress it and I wouldn't have done it.

Share this post


Link to post

RjY said:
Besides, why compress?

Isn't that what allows ZDoom somewhat bigger maps? With Doom, for example, you can have a blockmap of up to 64KB, and if you compress the blockmap with ZenNode or the like, you can make Doom load bigger maps.

Share this post


Link to post
Graf Zahl said:

If it fails due to exceeding the seg limit there really isn't much you can do except using a source port and node format that can handle it.

The only option right now is ZDoom's compressed node format but no other port in existence has implemented support for it yet.

Actually, Doomsday is also capable of loading maps which would overflow the segs limit (Doomsday ignores any and all BSP data included with a map anyway).

Share this post


Link to post

Just to clarify, for all DVII maps when their nodes were successfully built, are under the 2^16 seg limit.

As for compressed nodes, would PrBoom+ be able to read it? My goal is to keep all maps under the 2^16 seg limit, but even at that, random nodebuilding failures starts to happen around the 40-50k seg limits, not sure why though. I have some basic knowledge of nodebuilding, but not enough to know why this keeps happening at random.

Share this post


Link to post
Doom Marine said:

Just to clarify, for all DVII maps when their nodes were successfully built, are under the 2^16 seg limit.

As for compressed nodes, would PrBoom+ be able to read it? My goal is to keep all maps under the 2^16 seg limit, but even at that, random nodebuilding failures starts to happen around the 40-50k seg limits, not sure why though. I have some basic knowledge of nodebuilding, but not enough to know why this keeps happening at random.



What kinds of errors? Rendering glitches? How does the geometry look in these places? Another possibility is precision errors. The standard node format is not capable of storing any fractional position information of added vertices and I have seen maps where this caused significant rendering issues.

Share this post


Link to post

Zennode doesn't fix anything if it's precision issues. Like all other node builders it's limited by the storage format.

Share this post


Link to post

Only for Legacy's GL renderer. (and we all know how many problems that thing had!) :P

Share this post


Link to post
Graf Zahl said:

What kinds of errors? Rendering glitches? How does the geometry look in these places? Another possibility is precision errors. The standard node format is not capable of storing any fractional position information of added vertices and I have seen maps where this caused significant rendering issues.

Now that you've mentioned it, my map has tons of vertices and linedefs stacked on top of each other on the same coordinates, the hell planet texture at the end of map20 is an example of this.

Doom Builder 2 with ZDBSP will not build the segs lump for my 64k maps most of the time, and Doom Builder 1.68 with ZDBSP will give me a standard Error 5: invalid procedure message box. It's really a roll of a dice regarding the success of the nodebuilds on my current map.

There is a correlation between the frequency of stacked vertices/linedefs in a map and nodebuilding failure from what I've experienced.

Share this post


Link to post
kristus said:

Zennode is magical.

It also leaves slimetrails on "invisible platforms."

Share this post


Link to post
Doom Marine said:

It also leaves slimetrails on "invisible platforms."

Only if their sector numbers are lower than the solid sectors that surround them. I don't know why it has this requirement, but ZenNode will old render self-referencing sectors invisibly if their sector number is higher than that of the sector surrounding them. Try swapping out ZenNode.cfg in /Doom Builder 2/Compilers/Nodebuilders/ with http://sl4.poned.com/ZenNode.cfg and picking the "ZenNode Vanilla-Optimized" setting. It's what we use for KDiKDiZD's nodes, to reduce the generated seg count a bunch (among other things).

Share this post


Link to post
esselfortium said:

Try swapping out ZenNode.cfg in /Doom Builder 2/Compilers/Nodebuilders/ with http://sl4.poned.com/ZenNode.cfg and ...

aarrgg essel! :P Don't replace the configs that come with DB2, they WILL be overwritten when you install an update. You can just add a .cfg file with only the additional profile you need.

Share this post


Link to post

As I recall entryway did a test of these, it seems like two or three years ago and discovered that at that time deep bsp was the fastest nodes builder.

maybe he will wade in here on the subject, or you could PM him for his info. It is also on the board archive somewhere. an archive search for "deepbsp" or "deep bsp" might turn it up. I think that he might have started the thread as well, but not certain.

I like deep bsp a lot. Great for large maps.

This gets some results:
The search is for:
deep bsp nodebuilder
http://www.doomworld.com/vb/search.php?action=showresults&searchid=301135&sortby=lastpost&sortorder=descending



Edit:typo

Edit2:
I may have found it:
http://www.doomworld.com/vb/showthread.php?s=&threadid=40690&highlight=deepbsp

Share this post


Link to post

Is there a DeepBSP cfg avaliable for DB2 anywhere, and what's the latest version of it?

I'm having similar troubles in terms of map size on two maps I've been working on, and I'd love to see how DeepBSP handles them.

Share this post


Link to post

If it's just to see how well it works, run deepbsp from the command line. It is mean to be run from within DeePsea and so not all the options are available from the command line (I am sure there are command line switches, but I don't know what they are) however, in its basic format you can just run it like this (IIRC)

deepbsp infile.wad outfile.wad

zdbsp should give you better results for large zdoom and gzdoom specific maps though.

deepbsp is fast but so is zdbsp. Given that, on a modern machine, the differences, even on large maps, are likely to be less than a second, I don't see it as much of an issue if it is being done whilst saving a map. Gone are the days when a node build could take 5 minutes or more on my old 486... and don't get me started on reject builds. They could take half an hour or more. O_o

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