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

Visplane Error

Recommended Posts

I've received an error such as this
"R_DrawPlanes: visplane overflow (130)" in the middle of the game when I was running my wad under vanilla Doom2 port. Does anyone have a clue of what it is all about?

Share this post


Link to post

Or run it on a source port.

Pretty much all source ports have eliminated this problem.

Share this post


Link to post

Does anyone have a clue of what it is all about?

This means that there are too many visible planes (or sidedefs) in view. Basic DooM2's engine cannot handle the display of so many sidedefs at one time, so it crashes. Do as Nigel suggests, and use a source port. If it's your own map, and you want it to run on vanilla DooM, do as Espi suggests and reduce the level of detail.

Share this post


Link to post

Apparently, judging from what I have read in the textfile that comes with BSP, it's not about linedefs, but SEGS/SSECTORS (One of the two). I gather it's something about how areas (Sectors) have to be broken into triangles to be drawn, or something, and it's many of those in view at the same time that causes VPO. Linedefs just cause HOM.

I have no idea, so don't quote me 100%, but BSP can reduce the chance of it happening. Read the docs.

Share this post


Link to post

it's not about linedefs, but SEGS/SSECTORS (One of the two)

The thing is, if you create complex floor or ceiling sectors without assigning them a height parameter (i.e., they are flat on the floor or ceiling), then you won't get a VPO error. These are the linedefs that you refer to. However, if you assign the sectors height parameters, so that sidedefs are created, then the VPO error is likely to occur. It's sidedefs, not linedefs, that cause the problem. Likewise, it's sidedefs without textures that cause HOM.

Thanks for the info on BSP. I didn't realize that the node-builder breaks up sectors into triangular segments.

Share this post


Link to post

A Linedef always -has- to have at least 1 Sidedef which -has- to point to a "sector" no matter what the "height" is. IOW, a "sector" does NOT define the geometry of a level. It's something a lot of "tutorials" get confused on. For example, a "sector" can be all over the map, that's what "packing sectors" is all about.

Nodes are nodes are nodes and BSP is not any different. What was thought to work actually works only in certain small levels. Basically not a useful option:)

Nodes are not triangles - they define a bounding area which in turn define convex areas.

SSECTORS/SEGS are related. SSECTORS tell how many SEGS there are in the area they define. SEGS define the actual "line" geometry: point-to-point, angle and linedef relation. Nodes point to SSECTORS.

If you take an area with enough "pedestals" of the same height to cause a vis overflow (a simple way to verify this stuff), all you have to do is combine all the "sectors" defining the pedestals and it no longer will have the problems. The number of linedefs and sidedefs stay exactly the same. The sidedef sector references have been consolidated by "merging/packing".

DOOM code does a SSECTOR->SEGS lookup in NODES to define the area.

The end

Share this post


Link to post

Yes, I have found that BSP is only *sometimes* useful at reducing the chances of VPO. But, it worked for my E1 contest map.

Share this post


Link to post

Visplanes have absolutely nothing to do with sidedefs. 1 visplane is generated for every unique flat/lightlevel/height combination of floor areas that are currently in view.

In other words, if you make a checkerboard with 500 squares but all have the same flat, lightlevel, and height, then only 1 visplane is generated for the entire area. But change every other tile into a different flat or raise the sectors up 1 unit, and suddenly the engine needs to generate a ton of visplanes.

If you don't believe me, then load up Lee Killough's visplane overflow demo wad that comes with BSP. The problem with HOM is from the 2s sidedefs. When the game exits, however, the problem is with visplanes, and those visplanes are generated when you hit the switch in the middle that lowers the light level of every other square in the checkerboard.

Remember -- 2S HOM = sidedef problem
visplane overflow = sector problem

Share this post


Link to post

Visplanes have absolutely nothing to do with sidedefs.

Sort of correct - indirectly they do since sidedefs define sectors:) Did you read what I wrote above? That's actually a simpler way to demonstrate the problem without hom artifacts involved.

Carefully read what Lee wrote. He was "guessing" how the engine works, I wrote exactly how it works since the code came out since then.

Now, the interesting thing is that if you rebuild the Conduits.wad (the one you referenced) with DeePbsp (using default settings from DeePsea) pressing the switch won't cause a vis overflow. Yet, technically, using the "standards" given it shouldn't work:) So you see, it's a tricky little devil.

You can examine both types of nodes using the DeePsea node viewer - on the Edit menu / Node Viewer.

Share this post


Link to post

In other words, if you make a checkerboard with 500 squares but all have the same flat, lightlevel, and height, then only 1 visplane is generated for the entire area. But change every other tile into a different flat or raise the sectors up 1 unit, and suddenly the engine needs to generate a ton of visplanes.

My mistake about the nomenclature (linedef vs. sidedef) -- as Jack correctly pointed out every linedef has 2 sidedefs, even if they are not textured. I guess I was using the terminology (textured sidedef vs. sidedef) interchangeably, but my meaning was as stated above, and I described the reason for the problem in a non-technical manner. What I said was exactly what's in the quote above -- "The thing is, if you create complex floor or ceiling sectors without assigning them a height parameter (i.e., they are flat on the floor or ceiling), then you won't get a VPO error".

Share this post


Link to post

"The thing is, if you create complex floor or ceiling sectors without assigning them a height parameter (i.e., they are flat on the floor or ceiling), then you won't get a VPO error".

Not really (see Quasar's statement).

If you give -flat- sectors different light levels it will cause a VPO. Similarly, the flat graphics have to be the same. So it's not a "height" issue, but a "difference" issue. That's why packing sectors will get rid of the problem.

The nodes/vis type discussions seem to come and go. There is a lot of incorrect data written about this and other Doom editing facets because people never check out the facts:)

Share this post


Link to post
Guest
This topic is now closed to further replies.
Sign in to follow this  
×