Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Enjay

Visplane overflow detector

Recommended Posts

Well, here's a little problem that falls neatly between a source ports question and an editing question I guess. Is there a way (eg a source port designed to highlight them) that you can check a map to see if it has any visplane overflows?

Share this post


Link to post

GhostlyDeath did something with Chocolate Doom for Essel for KDIKDIZD. But as for a systematic way of checking a map through calculation, I would love to see something like that. How hard could it be for someone knowledgeable enough about it?

Share this post


Link to post

Aha, yes, I knew I'd heard someone mention it. I think it must have been Essel.

Certainly a tool that was able to analyse a level to find such things would be good but, presumably, it would have to do some line of sight calculations from every possible location on the map and then find some meaningful way of reporting that back.

Share this post


Link to post

I remember that Lee Killough added a feature to his BSP builder that could help automatically identify potential visplane overflows.

Share this post


Link to post

Logically, the problem isn't overly complex and would require an algorithm somewhat similar to that employed to generate the GLPVIS data used by some ports (only Vavoom?).

Share this post


Link to post

The problem with doing it automatically is that it'd likely take an excessively long time to check every possible X/Y/Z combination at every angle. If you fudge it and have it only check every few units or so, you could easily miss VPOs. There's also the issue of figuring out where the player is able to actually stand inside the map, and what's not accessible (not just void space, but also high ledges and stuff behind impassible lines, and areas that can only be teleported to).

Share this post


Link to post

There is no need to fudge it, the PVIS algorithm I mentioned does pretty much exactly what is needed here. There is no need to check every single X/Y position in the map at every angle, only all POVs with unique in-view seg lists.

Yes, the PVIS algorithm is expensive but the average map only takes about a minute to process on average spec modern hardware.

Share this post


Link to post

Please keep the discussion going - especially if it results in a new util - but thanks to essel because he fixed me up with a copy of GhostlyDeath's modified choco doom and it did exactly what I needed. :)

Share this post


Link to post
kristus said:

SMMU had a VPO indicator IIRC. Possibly still in Eternity.

It is, but the values are completely different than what you'd get from vanilla Doom. Boom, as well as the other ports down the line, made a lot of changes to how visplanes are split. As such it's not really reliable in the least as a VPO detector.

Share this post


Link to post

For accuracy you can't beat the actual DOOM rendering code, which could process a single view very quickly when not actually drawing anything.

Like Essel says if you use a grid then you can miss VPOs, however you could produce a "heat map" where, for example, red shows values that close to the limit, which would still be very useful I think.

Any tool will need to detect movable sectors (doors, lifts etc) and process them in their most open state.

Share this post


Link to post
DaniJ said:

There is no need to fudge it, the PVIS algorithm I mentioned does pretty much exactly what is needed here. There is no need to check every single X/Y position in the map at every angle, only all POVs with unique in-view seg lists.

Yes, the PVIS algorithm is expensive but the average map only takes about a minute to process on average spec modern hardware.


I like the sound of this. please tell us more.

Share this post


Link to post

I believe it's still going to be more complicated than PVIS because merging and splitting of visplanes must be accounted for, and height differences along the z axis must be accounted for (a floor doesn't generate a visplane until it comes into view for example). A simple seg list is just the start of what must be considered at each point. You then have to more or less do a watered-down DOOM rendering process at each of those points in order to calculate the visplanes. I could see this taking a significantly longer amount of time, but probably not so long that you can't go do a speedrun of Metroid Zero Mission and have it be finished by the time you get back. ;)

Essel is correct about EE's visplane counter. EE now seems to generate a significantly *higher* number of visplanes for certain scenes due in large part to differences in how sky is now treated. I've seen it flagging VPOs in Heretic maps where it is impossible to ever get any in heretic.exe, so you'd have to set the customizable threshold value to greater than 128 - probably somewhere around 140. This is just too inexact to really be useful as a testing tool. It only still exists because it was inherited from SMMU and it's more work to strip it out at this point than it is to just leave it in.

Share this post


Link to post

I guess it would depend if you really need a concrete answer to the question "will location <x> <y> <angle> cause doom2.exe to exit with a visplane overflow?" with zero margin for error. If all you need is some metric to gauge probability then that can be calculated simply from the number of visible segs by studying how the renderer calculates visplanes.

However, as others have said this method will never be as accurate as simply using the original DOOM renderer. I must also state that my knowledge of the inner workings of the original renderer are limited and probably too high-level to fully appreciate the problem presented.

Share this post


Link to post
Quasar said:

Essel is correct about EE's visplane counter. EE now seems to generate a significantly *higher* number of visplanes for certain scenes due in large part to differences in how sky is now treated.

True. I came across this alot while testing B2B for visplane overflows, often getting VPO notifications in places where they couldn't be recreated in doom.exe. A few of them weren't flukes though, so it's probably better that the detector is more sensitive than less sensitive. At the time, I just assumed it might be detecting potential HOM and not necessarily crash-inducing overflows.

Share this post


Link to post
fraggle said:

I remember that Lee Killough added a feature to his BSP builder that could help automatically identify potential visplane overflows.

esselfortium said:

Boom, as well as the other ports down the line, made a lot of changes to how visplanes are split. As such it's not really reliable in the least as a VPO detector.

For those who don't know, the original documentation (with examples) is reproduced here.

Share this post


Link to post

Anyone has a working link for the eternity engine prior to the 3.37 version?? I really want to use that VPO's detector, I'm working in a vanilla project and I don't want to erase sectors blindly and compulsively just to prevent those VPO's. Thanks!

Share this post


Link to post
nicolas monti said:

Anyone has a working link for the eternity engine prior to the 3.37 version?? I really want to use that VPO's detector, I'm working in a vanilla project and I don't want to erase sectors blindly and compulsively just to prevent those VPO's. Thanks!

Try Chocorenderlimits instead. It's a modification of Chocolate Doom that provides accurate and detailed information on visplanes, drawsegs, and some other limits, including a mode that allows you to view the actual shapes of each visplane to get a better idea of which structures are causing splits.

Part of the reason that EE's VPO detector was eliminated in later versions is because the renderer is so different from vanilla's that its readings are completely irrelevant to actual vanilla mapping. Even the comparatively minor changes made in the Boom code that Eternity evolved from were enough to already make the overflow detector a useless and misleading feature when it was first introduced in SMMU.

Share this post


Link to post
esselfortium said:

Try Chocorenderlimits instead. It's a modification of Chocolate Doom that provides accurate and detailed information on visplanes, drawsegs, and some other limits, including a mode that allows you to view the actual shapes of each visplane to get a better idea of which structures are causing splits.

Part of the reason that EE's VPO detector was eliminated in later versions is because the renderer is so different from vanilla's that its readings are completely irrelevant to actual vanilla mapping. Even the comparatively minor changes made in the Boom code that Eternity evolved from were enough to already make the overflow detector a useless and misleading feature when it was first introduced in SMMU.

Thanks Essel!

Share this post


Link to post

Another thing you could try is a utility that andrew apted developed (which is a lot like he describes a few posts up) that shows a top down view of all the potential problem areas of your map where VPOs can happen. I havent used it yet but I think someone made a doombuilder 2 plugin for it too. Its called "visplane explorer" I think. Id link to it but im posting from my phone

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
×