Enjay Posted December 14, 2008 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? 0 Share this post Link to post
Gez Posted December 14, 2008 Essel has something like that, used to test KDiKDiZD. 0 Share this post Link to post
EarthQuake Posted December 14, 2008 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? 0 Share this post Link to post
Enjay Posted December 14, 2008 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. 0 Share this post Link to post
fraggle Posted December 14, 2008 I remember that Lee Killough added a feature to his BSP builder that could help automatically identify potential visplane overflows. 0 Share this post Link to post
DaniJ Posted December 14, 2008 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?). 0 Share this post Link to post
esselfortium Posted December 14, 2008 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). 0 Share this post Link to post
DaniJ Posted December 14, 2008 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. 0 Share this post Link to post
Enjay Posted December 14, 2008 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. :) 0 Share this post Link to post
kristus Posted December 15, 2008 SMMU had a VPO indicator IIRC. Possibly still in Eternity. 0 Share this post Link to post
esselfortium Posted December 15, 2008 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. 0 Share this post Link to post
andrewj Posted December 15, 2008 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. 0 Share this post Link to post
Csonicgo Posted December 15, 2008 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. 0 Share this post Link to post
Quasar Posted December 15, 2008 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. 0 Share this post Link to post
DaniJ Posted December 15, 2008 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. 0 Share this post Link to post
Lüt Posted December 15, 2008 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. 0 Share this post Link to post
Xeriphas1994 Posted December 15, 2008 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. 0 Share this post Link to post
nicolas monti Posted November 11, 2013 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! 0 Share this post Link to post
esselfortium Posted November 11, 2013 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. 0 Share this post Link to post
nicolas monti Posted November 11, 2013 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! 0 Share this post Link to post
40oz Posted November 12, 2013 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 0 Share this post Link to post
Dragonsbrethren Posted November 12, 2013 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 0 Share this post Link to post
nicolas monti Posted November 12, 2013 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 0 Share this post Link to post
gOrEE33 Posted December 1, 2013 I don't think source ports can release visplane overflows. 0 Share this post Link to post