Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Kyka

Doom2 visiplane limit...

Recommended Posts

128 or 256?

When testing a level in Chocorenderlimits, the visiplane limit says something like:

PLN: x/256 (Doom = 128) where x is obviously the number present on screen.

Does this mean that Doom 1 has a limit of 128 and for Doom 2 the limit has been increased to 256?

Or do both Doom 1 and Doom 2 have a visiplane limit of 128, and the 256 limit refers to something else?

Thanks guys.

Share this post


Link to post

Someone correct me if I'm wrong, but earlier version of Doom had stricter limits in place. So I'm guessing that's referring to Doom 1 and/or certain versions of the engine.

Doom 2 definitely has the 256 limit though. At least it had better or otherwise I've got a lot of vanilla work to throw in the trash :P

Share this post


Link to post
Guest

Mech, this is exactly what I thought also. But yet when I run chocolate doom to test a doom2 tnt map that I am making, it crashes when the visiplane limit goes over 128 rather than 256.

So I am a little confused here.

Thanks for clarifying tho.

Also looking forward to seeing some of this vanilla work of yours. :)

Share this post


Link to post

It's not 256, it's 128.

If the limit was lower in previous versions, it would have been 64 then I guess... Which definitely warranted to be doubled ASAP since there are many parts of the original doom1.wad where that can be reached.

Also, don't toss your vanilla stuff in the trash, convert it into Strife maps! :D

Share this post


Link to post
Guest

Thanks Gez.

Just out of interest, when the wiki says "The visplane overflow is a fatal error that occurs in vanilla Doom when there are more than 128 unique floor and ceiling surfaces (visplanes) on the screen simultaneously," exactly what is meant by the word 'unique'?

Say for example, one sector is being used for some inset lights in the ceiling. And say there are three distinct 'blocks' of lights, but all part of the same sector. Would this qualify as 6 visiplanes (floor and ceiling)? (Assume all three lights and the floors beneath them are visible onscreen at the time of visiplane counting.)

Now say for another example that there is a single long thin sector with a solid pillar between it and the player POV. The pillar will effectively 'cut' the long thin sector in 2, at least as far as the player's view is concerned. So does this then become 4 visiplanes (floor and ceiling)? The sector is a single sector, and is only broken by the POV of the player and not in actual map layout. IF the player were to move around the pillar so he could see the long thin sector as a whole, this then becomes 2 visiplanes instead of 4? or is it 2 either way?

Share this post


Link to post
KiiiYiiiKiiiA said:

Just out of interest, when the wiki says "The visplane overflow is a fatal error that occurs in vanilla Doom when there are more than 128 unique floor and ceiling surfaces (visplanes) on the screen simultaneously," exactly what is meant by the word 'unique'?

It's actually quite complicated, which is why there is chocorenderlimits instead of tools in a map editor.

Google for visplanes and Lee Killough and you'll find more information about it.

Share this post


Link to post
Guest

Thanks andrewj.

Found this which was a pretty good start.

You are not kidding when you say it is complicated.

Share this post


Link to post

What about an automatic version of chocorenderlimits? You run the program and it automatically checks for errors/limits in the entire map, and exports a txt file with the error/limit info + coordinates? Chocorenderlimits is really nice for looking around in-game for errors, but I think sometimes an automatic version would be nice too, you could use both.

Share this post


Link to post

Far too computationally excessive. There are two main issues:

Visplane depends on player position and orientation. To be exhaustive, you'd have to perform up to (4294967296 * 65536^2 * map width * map height) points tests. That's faaaaar too many, so you'll have to cut back and perform some sampling system where you don't actually test all positions and orientations. The sparser you go, the closer to remotely plausible automatic testing becomes; but also the more likely it is that it'll miss problems and therefore be useless.

Visplane also depends on map geometry, which is dynamic. A given viewpoint might be visplane-free until a door opens, or an elevator raises. So, you would also need to perform the whatever zillions of tests mentioned above for every possible combination of geometry change events that the map provides.


In short, you have the following two choices for a programmer:
1. Write a tool that's guaranteed to detect any possible visplane overflow in a map, provided a supercluster of a million Cray computers running until the heat death of the universe; or
2. Remove the visplane limit entirely by using a growing hash array like in Boom.

Unfortunately for vanilla purists, it's solution #2 that has been adopted.

Share this post


Link to post
Gez said:

1. Write a tool that's guaranteed to detect any possible visplane overflow in a map, provided a supercluster of a million Cray computers running until the heat death of the universe;

DO IT

Share this post


Link to post
Gez said:

Visplane depends on player position and orientation.

Testing every 16 units on X and Y axes, a couple positions on the Z axis, and the 8 major compass directions would be both feasible and still very useful. I envisage the result is a kind of "heat map" showing places which definitely overflowed (bright white), close to overflow (yellow), stuff to worry about (red), and blue/black for the rest.

Imagine if the user could zoom in to a certain "bright" area and the tests are done on a finer granularity -- heh, like some mandelbrot programs.

Visplane also depends on map geometry, which is dynamic. A given viewpoint might be visplane-free until a door opens, or an elevator raises.

Such a program "merely" needs to open all doors, lower all lifts (etc etc) to make the map as open as possible to conduct the visplane tests -- the result will be the worst case scenario (perhaps too much so), however it a map succeeds then you can be very confident that your map won't get visplane overflow when actually played in a limit-inflicted engine.

Share this post


Link to post

KiiiYiiiKiiiA said:
128 or 256?
PLN: x/256 (Doom = 128) where x is obviously the number present on screen.

I think no one mentioned this so I'll say that it's higher so that chocorenderlimits can keep working while showing current values above 128. Note that the executable file for (the three-episode) DOOM v1.9 is exactly the same one used for DOOM II v1.9, just renamed. The Ultimate DOOM has a newer executable file based on that one, and they wouldn't have had any reason to reduce the visplane limit there.

Share this post


Link to post

Update your Chocorenderlimits version!

The number/256 count was just a misleading display, because of the fact that GhostlyDeath had doubled Chocorenderlimits' visplane allowance to 256 so that VPOs could be located without the program exiting upon finding them. In newer versions, it's just listed as number/128 as it should be.

There are other reasons to update, too...

Share this post


Link to post

Here is what a visplane "heat map" looks like for a certain map of DOOM 2:



The "heat" has been ramped up about three times (for testing), so normally this map would look a lot "cooler" with mostly blues. It actually runs quite quickly, thanks to the fact it doesn't need to actually render the walls or floors.

It will take a bit longer to make a proper tool out of this.....

Share this post


Link to post

It looks like some sort of pokemon pony with a derp face and squiggly hair facing left. Interesting, did you use lua for that too?

Share this post


Link to post
gggmork said:

It looks like some sort of pokemon pony with a derp face and squiggly hair facing left. Interesting, did you use lua for that too?

It's clearly a fish, which is fitting for Doomworld.

Share this post


Link to post

If you want to test some known VPO locations I know of at least one, in Hexen anyway (where the VPO limit is 160, even!). Bright Crucible.

Standing near the left hand side of the map backing into the southern corner from a medial position relative to the indentation in the wall near the left-side entrance to the location of D'Sparil's Heart, and looking out into the swamp. There's a VPO here, really sucks too.

Share this post


Link to post
Gez said:

It's not 256, it's 128

Whoops, I got the SEGS limit confused with VPO, heh. Yea, the VPO limit is 128. But I guess we all know that by now :P

That VPO heatmap thing is really neat looking. I'm sure there are quite a few guys who'd really be able to make good use of such a tool. I know I would :D

Share this post


Link to post

@andrewj: That definitely looks awesome for sure. Is the "heat" measuring the probability of a VPO at any given area?

Share this post


Link to post
Xaser said:

@andrewj: That definitely looks awesome for sure. Is the "heat" measuring the probability of a VPO at any given area?

No, it measures actual number of visplanes, using a cut-down version of DOOM's rendering code.

Share this post


Link to post
Dragonsbrethren said:

A visual example of why optimizing visplanes is a bitch:

Take a few steps back and 9 visplanes become 17.

A really good illustration of how the visplane algorithm works, btw. The door cutting across the top of the frame buffer causes the engine to be unable to merge those 10 planes comprising the ceiling that are otherwise homogeneous in quality. VPOs are more than just counting unique floor/ceiling combinations in cases like this.

Node lines also have a role to play, as Lee found out even before the release. By manipulating the BSP tree for simple levels he was able to discover that the choices made by the node builder also affect the merging and splitting of visplanes.

Share this post


Link to post

I have implemented brute forcing in Chocorenderlimits. It takes a REALLY long time though, although shortcuts are taken. I just need to write the interface to call the actual brute forcer though, then commit the changes to bitbucket, then build a binary for it.

My test map is MAP01. It display visplanes, drawsegs, openings, then sprites. The image is small, since I only used a granularity of 16, although you can choose any granularity down to 1 (which would probably take a few years to complete). The second map is AV.WAD MAP04.

The brighter the color, the closer to the limit. There are two phase transitions that change into more colors, but MAP01 does not exceed any of those transition phases.

It dumps two files, a nice PPM showing what the data looks like visually, and the raw data itself. So with the raw data you could in theory modify an editor like Doom Builder to display visplane data that you obtained.





So i'll be making an update soon.

Share this post


Link to post

My program, "Visplane Explorer", is coming along too.

I will post a test version soon.

Share this post


Link to post

That is so cool!

I have one suggestion though to make such a program more useful...

Would is be possible to output a "heatmap" where the most detail-heavy areas are in the "hot zone" compared with the rest of the map? Could be useful for finding the most render-intensive areas in limit-removing maps where the standard limits are exceeded. Basically a "relative heatmap". The current output (in GhostlyDeath's example) is able enough to identify these detail-heavy areas, but some higher contrast would help identify those problematic areas.

Also, what about a "combined heatmap" that could be used for CPU benchmarking? Although, thinking about it, different aspects of the renderer take more time than others, so it might be hard to "balance".

Share this post


Link to post
EarthQuake said:

That is so cool!

I have one suggestion though to make such a program more useful...

Would is be possible to output a "heatmap" where the most detail-heavy areas are in the "hot zone" compared with the rest of the map? Could be useful for finding the most render-intensive areas in limit-removing maps where the standard limits are exceeded. Basically a "relative heatmap". The current output (in GhostlyDeath's example) is able enough to identify these detail-heavy areas, but some higher contrast would help identify those problematic areas.

Also, what about a "combined heatmap" that could be used for CPU benchmarking? Although, thinking about it, different aspects of the renderer take more time than others, so it might be hard to "balance".


Chocorenderlimits has brute forcing options you can use with varying precision. You could choose a precision of 1 map unit and wait a few years to map the simplest map or it can be higher. You can also limit it to a certain area of the map and such.

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
Sign in to follow this  
×