Doom Comic
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Doom Editing > Visplane overflow detector
 
Author
All times are GMT. The time now is 04:51. Post New Thread    Post A Reply
Enjay
ASK ME ABOUT FOOTBALL / STEAM / DEAD CELEBRITIES / THE BLAIR WITCH PROJECT


Posts: 6381
Registered: 12-00


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?

Old Post 12-14-08 13:07 #
Enjay is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 10998
Registered: 07-07


Essel has something like that, used to test KDiKDiZD.

Old Post 12-14-08 13:40 #
Gez is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
EarthQuake
9.5 on the Richter!


Posts: 2839
Registered: 05-03


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?

Old Post 12-14-08 13:43 #
EarthQuake is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Enjay
ASK ME ABOUT FOOTBALL / STEAM / DEAD CELEBRITIES / THE BLAIR WITCH PROJECT


Posts: 6381
Registered: 12-00


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.

Old Post 12-14-08 14:43 #
Enjay is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Filled with the code of Doom


Posts: 7483
Registered: 07-00


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

Old Post 12-14-08 15:15 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
DaniJ
Senior Member


Posts: 2075
Registered: 08-03


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?).

Old Post 12-14-08 16:41 #
DaniJ is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
esselfortium
A Major Doomworld Concern


Posts: 6488
Registered: 01-02


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).

__________________
essel.spork-chan.net - doom stuff, artwork, and music by esselfortium

Old Post 12-14-08 17:38 #
esselfortium is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
DaniJ
Senior Member


Posts: 2075
Registered: 08-03


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.

Last edited by DaniJ on 12-14-08 at 19:49

Old Post 12-14-08 18:42 #
DaniJ is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Enjay
ASK ME ABOUT FOOTBALL / STEAM / DEAD CELEBRITIES / THE BLAIR WITCH PROJECT


Posts: 6381
Registered: 12-00


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. :)

Old Post 12-14-08 23:37 #
Enjay is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
kristus
Megablast!


Posts: 10605
Registered: 07-00


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

Old Post 12-15-08 00:24 #
kristus is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
esselfortium
A Major Doomworld Concern


Posts: 6488
Registered: 01-02



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.

__________________
essel.spork-chan.net - doom stuff, artwork, and music by esselfortium

Old Post 12-15-08 00:40 #
esselfortium is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
andrewj
Senior Member


Posts: 1628
Registered: 04-02


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.

Old Post 12-15-08 02:29 #
andrewj is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Csonicgo


Posts: 4430
Registered: 03-04



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.

Old Post 12-15-08 05:15 #
Csonicgo is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 5965
Registered: 08-00


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.

Old Post 12-15-08 19:56 #
Quasar is online now Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
DaniJ
Senior Member


Posts: 2075
Registered: 08-03


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.

Old Post 12-15-08 21:08 #
DaniJ is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Lüt
Administrator


Posts: 9170
Registered: 05-00



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.

Old Post 12-15-08 21:39 #
Lüt is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Xeriphas1994
Junior Member


Posts: 177
Registered: 06-07



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.

Old Post 12-15-08 22:52 #
Xeriphas1994 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
nicolas monti
Junior Member


Posts: 207
Registered: 01-11


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!

Old Post 11-11-13 19:13 #
nicolas monti is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
esselfortium
A Major Doomworld Concern


Posts: 6488
Registered: 01-02



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.

Old Post 11-11-13 19:27 #
esselfortium is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
nicolas monti
Junior Member


Posts: 207
Registered: 01-11



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!

Old Post 11-11-13 19:53 #
nicolas monti is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
40oz
Forum Spammer


Posts: 6571
Registered: 08-07


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

Old Post 11-12-13 01:31 #
40oz is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Dragonsbrethren
Senior Member


Posts: 2398
Registered: 03-09


Yeah, Visplane Explorer is really cool. It's great to use as a guideline for areas to test in ChocoRenderLimits. Here's the site for the stand alone program:

http://eureka-editor.sourceforge.net/?n=VisExp.Main

DB2 plugin can be gotten here:

http://doombuilder.com/index.php?p=plugins

Old Post 11-12-13 01:45 #
Dragonsbrethren is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
nicolas monti
Junior Member


Posts: 207
Registered: 01-11


Thanks Everyone, These tools are great, I was at the point of giving up the vanilla flavour, but this is helping to get me back on the line :p

Old Post 11-12-13 04:22 #
nicolas monti is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
gOrEE33
Warming Up


Posts: 25
Registered: 10-13


I don't think source ports can release visplane overflows.

Old Post 12-01-13 10:19 #
gOrEE33 is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
All times are GMT. The time now is 04:51. Post New Thread    Post A Reply
 
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Doom Editing > Visplane overflow detector

Show Printable Version | Email this Page | Subscribe to this Thread

 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON
 

< Contact Us - Doomworld >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.