Any plans to rewrite the Node Builder? (AKA, BSP wishlists)

[RockstarRaccoon]

Does anyone know if anyone is planning to update the Node Builder any time soon? If so, I'd kinda like to throw down some suggestions and have a discussion about that...

The following thread may either be a set of pipe-dreams, or a set of possible features for the next (G)ZBSP format.

I know the current Node-Builder is built to run at load-time, which is a bit odd to me, seeing as the editor builds the UDMF nodes. Having a more robust version of the node-builder which runs in the map editor and doesn't worry about time might be a good idea. I know when I write things like scaling and pre-rendering algorithms, I write them with the intention to be load-time and not runtime, because I assume I'll have enough access to build stop to build things before showing them.

- Hints
The first thing I'd add to this new node-builder is the ability for the mapper to give the thing hints somehow. The uses for this are limited, but simply being able to tell it "the player will be here more than here" could be helpful for optimization. The bigger thing that'd be useful for though...

- Z-Layers
I'd add in some support for Z-heights, and that'd be where hints would shine: if I could say "BSP trees built here should have one at this height and one at this height," I could optimize for having really large outdoor levels without having to put random blank spots in them. For example, screwing around with Darkmere, I remade the castle, and I thought it'd be neat if you could see it from all the way across the map, but I'm a bit concerned that it'd be a large amount of detail if the renderer tried to go after everything that was behind the walls, rather than realizing the player will never see over that: I'm going to end up putting a big mountain in the middle of my swamp just to prevent this. :\ The way this would work: you'd pick a couple Z-Heights (like, below the tops of your tall buildings, a height where you think your player isn't going to go any higher, or just beneath a cliff face the player will be looking at a bunch of cave entrances) The Node-Builder would then make several versions of each BSP sector, stacked on top of each other, and run the algorithm based on where the floor and ceiling heights were, ignoring geometry which was clearly out of view. In game, the renderer would only have to pay attention to what can be seen from the height the player was at.

The big snag I see with this is how to support the fact that floors and ceilings can move, but I think if the Node Builder did this, it'd make larger maps (like my outdoor crap) which cause slowdown on computers like mine which weren't built for games run far smoother. If this could be made to support 3D floors, even better, because that's my favored method of room-over-room. Perhaps something could be done where the Z-nodes, instead of simply being a separate rendering list, are a list of what's blocked by what, and can change their minds on the fly if something changes height? This might get a bit similar to how Build does it at some point, but that might not be so bad...

- Portals / Mirrors
Support for portals and mirrors is another thing: if we had nodes for portals and mirrors, it wouldn't have to render everything behind the portal at all times. Only problem I'm seeing here is that the current method for drawing portals is going to be hard for it to pick up on... but what if we could throw down hints and link them to the portal? Like... tell the portal to use a certain BSP node when rendering, possibly just based on a distance in front of the portal? That'd help with the framerate slowing to a crawl I experience every time I have a portal anywhere near the screen...

- Distance
One final thing is distance: I'm curious if one could set up the node-builder to realize that something is so far away that the player won't possibly see it properly (especially if there's fog on the map) and tell the engine to do something less intensive with it (ignoring lighting effects, mipmapping, simplified geometry, just fogging it out, etc). If that was possible, it might also make for more efficient rendering...

Anyway, that's my pipe dream. Anyone else have any thoughts on this?

[Kinsie]

As much as I know you're trying to be helpful, it feels like you're trying to transpose rendering and optimisation concepts from brush-based 3D engines like Quake and Source into an engine where they may not necessarily be relevant.

[RockstarRaccoon]

A bit. Just thinking about how I often find myself doing these things, and what would help it run smoother...

[Gez]

Absolutely not feasible. You're looking at completely changing the way the entire engine works. Also if the node builder had to work in 3D instead of 2D, it's likely its computations would start taking long enough that on a complex map, it would become noticeable.

[Bauul]

Absolutely not feasible. You're looking at completely changing the way the entire engine works. Also if the node builder had to work in 3D instead of 2D, it's likely its computations would start taking long enough that on a complex map, it would become noticeable.

You mean we wouldn't all yearn for those early days of Quake mapping where compiling the BSP was something you had to leave running overnight?

Ah, good times!

[Rachael]

I think the big question is why do you keep trying to hit the node builder with all these optimization ideas?

I'm sorry to sound harsh with this - but it really comes down to this: if you are having render framerate issues, you're adding way too much detail to a single scene. That's it. No amount of "optimization" is going to fix your over-detailing. Taxing the engine is simply that - you're overworking it and it's time to scale back.

In the past I've given you at least one suggestion to curb some of this behavior - such as using models. If that's infeasible you can also try and stick most of your details into midtextures and try to use fewer of those and letting midtextures detail the scene as much as you can with a couple flat 2D surfaces.

Fewer 2-sided linedefs is the only way you're going to solve your problem. There's no way around it.

[Gez]

If you have something like a wall with small buildings on both sides, some of the buildings being tall enough to be seen behind the wall, though most of the details being hidden, what you could do is turn the wall into a one-sided thing, with a visual portal allowing to look at a simplified "behind" area which only features the bits that stick out, and none of the invisible detailing. In that situation, perhaps the overhead from processing a portal would be compensated by the reduction in complexity of the scene behind.

[RockstarRaccoon]

Uh... I should clarify something... I started this thread because I thought the idea was interesting, not to try and complain about known engine limitations. I'm actually using techniques in my maps, like the one I mentioned where you put empty areas in between high-detail areas, and have been paying attention to the bits about how models actually work better for details in this situation because they're rendered more efficiently than geometry. I also drew out a map idea which involved using portals for non-euclidian geometry, and specifically kept the issues with portals in mind. (Portals are the one thing I DO think need some work, though I think it's being worked on, so...)

My maps, because I'm pretty much a relic of the GLBoom era, actually run quite smoothly, aside from specific known points. I just thought this would be an interesting thread is all...


And Gez, that's what Wolfendoom does on the INTERMAP, Allied Headquarters, but I think that has mixed results when it comes to speed... Honestly, I'm still building my skills when it comes to portals, and I'd like to be better at the edges of rooftops and cliffs in the first place...

[Graf Zahl]

That still doesn't change the fact that your entire proposal is far outside the bounds of what constitutes the Doom engine.

If you want to get more performance out of wide open areas it needs to be done by adding some map features that'd allow the node builder to treat certain areas as special and handle the geometry inside them as one block. But that'd impose quite a bit of restrictons of what could be done in these parts. But this stuff is far from simple to implement and even further from simple to be used in maps.

[Graf Zahl]

but I think that has mixed results when it comes to speed...

What graphics hardware do you use? The performance characteristics of portals have changed dramatically over the years as hardware evolved.

[Nash]

If you want to get more performance out of wide open areas it needs to be done by adding some map features that'd allow the node builder to treat certain areas as special and handle the geometry inside them as one block. But that'd impose quite a bit of restrictons of what could be done in these parts. But this stuff is far from simple to implement and even further from simple to be used in maps.

Out of curiosity, what would those restrictions be? And how much inconvenience would it impose to the mapper, editor-wise?

[Graf Zahl]

The main issue would be, if such a group was created, it'd always have to constitute a single subsector in the node tree. So it must not block proper splitting of the map. If you create two such sections that cannot be divided by a straight line the node build would fail. It would also necessitate that no other parts of the map may intrude into concave parts of such a section. Concave parts should be discouraged, though, because such a section would determine visibility beyond it on a global basis (i.e. only check its outer bounds) so concave parts may pose an issue here

It is also important to know that moving sectors would always require a complete reconstruction of the section's geometry so having a lift or door in there may cost you more in the end than you gain.

To summarize, the mapper is required to have a detailed knowledge of how the engine works.