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

Visplane Explorer : new 0.80 version

Recommended Posts

Visplane Explorer is a program to visualize possible visplane overflow errors in DOOM maps.

This version adds support for viewing other overflowables: DrawSegs, SolidSegs and Openings. The drawsegs view is particularly important, since there are places in maps where these overflow but visplanes don't.

The openings are not very important, they very rarely come close to overflow and when they do, the drawsegs or visplanes are already very high (often many times the limit). So I was tempted to simply drop that view, but perhaps there are maps where this becomes the limiting factor.

I found solidsegs to be surprising, as these often get very close to overflowing, and if they do then the engine won't catch it -- it will simply corrupt memory and that might make DOOM crash, or just royally muck everything up.

Other changes include a simpler color palette, which shows more clearly the overflowing areas (in bright red or pink shades), and a few other fixes. Drag'n'drop a wad onto the EXE should work now, and if it contains a single map then that map is automatically chosen.

This package includes a windows binary, a linux binary, a test map, and the source code.

LINK: http://awwports.sourceforge.net/files/visexp080.zip

P.S. you can toggle the different views quickly with these keys: V, D, S and O

Share this post


Link to post
Guest



This is freaking awesome. I'm not gonna pretend to even begin to understand the guts of how this works, even though I have been doing a bit of reading about visiplanes recently.

This is immeasurably quicker than the traditional way of checking visiplanes... which is, of course, fire up chocorenderlimits and wander around the map staring at things and watching the little visiplane number.

'Course the limiting factor here is that obviously this can only calculate a visiplane count based on the map in its starting state, i.e. no doors open, no walls lowered, no new areas exposed, and it goes without saying that these things can vastly alter a visiplane map.

If you look at the top left area, you can see a big open area, surrounded on its left, top and right sides by a corridor, and these three sides are connected by 3 sectors (currently closed). Obviously when these three sectors open, it will thoroughly alter the visiplane count. And even if you don't know this map, you can pick out plenty of other areas where joining sectors are closed off.

I mean, I know little about programming and I imagine this would be a lot of work, but I wonder how possible it would be do write something that could do exactly what this program now does, but with the map in a 'totally open' position. I guess this program in its current form must take into account floor and ceiling heights to test the number of visiplanes at any given position. Would it be possible to incorporate linedef triggers into this? So say a door at map start had floor and ceiling heights of 0 and 0. And when the door was opened by a nearby switch, the door ceiling height raised to 72. Then the visiplane calculator would work out from the triggers and sector tag, that this particular sector now has floor and ceiling heights of 0 and 72 instead of 0 and 0, and recalculate the visiplane count accordingly.

Again, I know crap all about this stuff, but I am just wondering if such a thing is in any way a reasonable idea. It is probably possible, but whether the workload of doing something like this would be simply too high, I don't know.

Anyway, thanks for this little program, it is pretty darn neat.

Share this post


Link to post

Really an amazing tool you've put together here andrewj. I'm gonna play copycat and post a shot like Kyka did.

http://mekworx.phenomer.net/mekastuff/wads/btsx/btsx_tl_vis.png
(And some more.)

It looks like all the hunting the testers and myself did to squash VPOs paid off (mostly...I see a potential hotspot in one map).

I'd like to echo Kyka's thoughts about possibly having a feature which would display the visplanes/etc beyond doors and whatnot. If such a feature is even possible to implement, that is. Generally it's good practice to keep all that stuff open while making the map so you can test for overflows. So it follows that running the map in that state would work too, of course. But hey, if it's possible to check visplanes/etc past closed doors/lifts/etc with some code, then I would say that it would greatly increase the usefulness of the tool :)

Also, would it be possible to have a little finer zoom control? Not a big deal but it would be nice if you can.

I'm having an odd bug where the window is offset wrong when I maximize it. Instead of taking up the screen like you think it would, it's offset to the left off-screen and is slightly too tall (it gets drawn underneath the start bar).

Thanks for the awesome tool by the way! This should prove to be very handy in the future.

Share this post


Link to post

Just for the fun of it here a shot from Vrack3:



That bright pink is "Extreme!". Heh.

Share this post


Link to post

I actually liked the old heat colors for the visplanes more.

Share this post


Link to post

Re: doors lifts etc. Would an option that evaluates the map with all sector floors set to 0 and ceilings set to 128 work?

Share this post


Link to post
traversd said:

Re: doors lifts etc. Would an option that evaluates the map with all sector floors set to 0 and ceilings set to 128 work?

That might bring visplanes into view that would not have mattered otherwise. Or merge previously multiple visplanes into one.

Share this post


Link to post

Well if we care about visplanes, then it's vanilla Doom, with a finite number of sector effects. So, for each sector that's either a door, or tagged with a trigger linedef, it could go through all possible phases and choose the worst case for visplane counting.

Share this post


Link to post

For Doom that's correct - but not for Hexen. There you can't even predetermine what kinds of movement a sector might do, thanks to ACS.

Share this post


Link to post
boris said:

That might bring visplanes into view that would not have mattered otherwise. Or merge previously multiple visplanes into one.


Yeh, that is true. Maybe an option in the gui to click(toggle) on a sector which highlights it's edges. The VP discovery process then considers the sector as matching the lowest adjoining floor and highest adjoining ceiling? That would allow you to cover most doors, plats and simple arrangements of sectors that lower.

Share this post


Link to post

I couldn't resist making this:



Why you want this plugin:
- Shorter workflow: No need to save the map and start VE... just press a button!
- Top performance: The plugin is multithreaded and uses all cores on your CPU to crunch the data.

A possible improvement I'd like to add later is the ability to select sectors which will open up for measuring (floor lowers and/or ceiling raises) to simulate open doors.

Some of the code is andrewj's source from Visplane Explorer and some is written from scratch. The original Visplane Explorer executable is not needed for this plugin as the plugin has everything it needs internally. The plugin is almost done for release (and will require a new version of Doom Builder 2 which will be released at the same time) so keep an eye out on this topic. I will probably make this release some time this week.

Share this post


Link to post

For sake of being sophisticated and gentlemanly, I feel it is appropriate to echo my most recent comment on this from IRC:

HOLY MEGABALLS

Share this post


Link to post

How are visplanes counted in each point? Does it do a 360-degree rotation and write down the maximum number of visplanes visible in that rotation?

Share this post


Link to post

Does it try some optimization or does it really look at each integer coordinate?

Share this post


Link to post

It starts rough and gets finer over time, so eventually it should have checked everything. Here's a shot from shortly after switching into the mode in map20 of av.wad, which will eventually look like the shot CodeImp posted:

Share this post


Link to post

Since this uses the vpo_lib part of the source from VE, I am hoping we could communicate any changes to it and share this part of the code so that we can both benefit from any new features. Until now I have refrained from making any more than absolute necessary changes to it (only added WINAPI to the exported functions) but there are definitely things to improve. Would you care to share this andrewj?

Share this post


Link to post
printz said:

How are visplanes counted in each point? Does it do a 360-degree rotation and write down the maximum number of visplanes visible in that rotation?

What boris said. But now that you mentioned it, I think I may add a drop-down option to the toolbar to choose how many angles to check (8, 16, 32 or more?).

Share this post


Link to post

If it's possible, I think the best solution would be to increase angle precision to specific areas only, as a second pass done automatically to map areas with the highest non-overflowing visplane readings found so far. That way, you could leave it running for a while longer and let it take a closer look to areas that might be at risk for overflow.

Also, does this consider other possible player heights at all? Even just the view-bobbing effect can have an effect on visplanes, and then when you add archvile jumps and ledges that can be jumped off of, things can get messy.

Share this post


Link to post
CodeImp said:

Since this uses the vpo_lib ...... Would you care to share this andrewj?

Yeah, sure.

We'll probably need a better repository for it, the current BZR repository has lots and lots of other junk in it, though I won't mind giving you commit access to it.

The only plans I had for vpo_lib was (a) Hexen support and (b) an ability to find the correct height a player would be at a spot (by checking for lines that intersect the 32x32 box around the test spot). Feel free to implement these yourself, I'm not sure when I'll feel like coding on this again.

esselfortium said:

Also, does this consider other possible player heights at all?

It only checks one height above ground, the top of the bobbing cycle (VIEWHEIGHT + MAXBOB), where VIEWHEIGHT is 41 and MAXBOB is 8 (the code has MAXBOB = 16, but it divides it by two when adding it).

Checking other heights is not really necessary imho, if you checked say 8 units below each ceiling you'd get some kind of worst case scenario, which I don't think would be the most useful information -- it is something that could be there as an option though.

Share this post


Link to post

Plugin is HERE at the bottom of the page. You need the new Doom Builder version 2.1.2.1545 for this plugin to work.

andrewj said:

We'll probably need a better repository for it, the current BZR repository has lots and lots of other junk in it, though I won't mind giving you commit access to it.

We could use my code stored at SourceForge, you can access it through SVN. Your VPO code is in a completely isolated project, right here:
https://doombuilder.svn.sourceforge.net/svnroot/doombuilder/trunk/Source/Plugins/vpo_dll
Like I said, I didn't change anything at all, except added APIENTRY to the exported functions. You can simply define APIENTRY as nothing on any platform other than Windows.

andrewj said:

The only plans I had for vpo_lib was (a) Hexen support and (b) an ability to find the correct height a player would be at a spot (by checking for lines that intersect the 32x32 box around the test spot). Feel free to implement these yourself, I'm not sure when I'll feel like coding on this again.

That's not a bad idea! I would like to add limit checks on number of vertices/linedefs/sidedefs/sectors because right now the library just crashes when the map exceeds 32767 anywhere. It should just returns an error code instead. Maybe also up the limits to 65k, but I'm not sure that is needed since vanilla Doom doesn't support that limit and any sourceport that does is probably already a limit-removing sourceport for which you don't need this plugin really.

Share this post


Link to post
CodeImp said:

Maybe also up the limits to 65k, but I'm not sure that is needed since vanilla Doom doesn't support that limit and any sourceport that does is probably already a limit-removing sourceport for which you don't need this plugin really.

Yeah, checking the number of lines/sides/vertices/etc. before is probably enough.

I guess the only reason to check the visplane explorer output in a limit-removing map is idle curiosity, so support for limit-removing/OpenGL only things (like UDMF maps for example) is not really important.

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
×