KatsBits Community

Quake 4 Portal 'popping'

kat · 1 · 8073

0 Members and 1 Guest are viewing this topic.

Offline kat

  • Administrator
  • Hero Member
  • *
    • Posts: 2709
    • KatsBits
What is Portal 'popping'?
This problem is bound to crop up sooner or later if you're doing any Quake 4 (or Doom 3 for that matter) level editing. In a nut shell it can be described as areas of a level 'popping' in and out of being rendered despite properly placed and functioning portals; a portals status - open or closed - doesn't appear to have any bearing on whether the problem occurs; in other words, as the screenshots below show, areas of the map appear to suddenly go missing resulting in the display of the grey 'void' (the 'outside' of the level) where the brushwork should have been.

Using "r_showportals 1" to display 'open' portals, shown as a green outline, which should draw anything behind it. Despite this however, the portal rendered at the back of the scene, whilst open, is showing missing sections of the map resulting in the grey 'void' being visible.

Using "r_showtris 2" to show the 'optimised' tris (polygons) being drawn to screen around the broken popped portal.

Even though "r_usescissor 0" is set in the shot above, it has to be reset for the tris to kick back into being displayed correctly. Moving slightly will result in the popped tris again.

Why does portal popping happen?
As the moniker suggests it's to do with the portals themselves, they're 'broken' in a manner of speaking and the result is what's seen above in game. Technically it's something to do with what's called a 'floating point error', an issue that Radiant has had for a long time so do with the coordinates used to describe brushes in the map file; sometimes the number contains too many decimal places (something like '0.8576366747474662939' instead of '0.857') which the editor and compile process can't handle properly.

What causes 'portal popping'?
It happens whenever a brush, which will be used for a portal in Quake 4, has been over manipulated; this includes being rotated, re-sized, edge and volume dragged - pretty much anything that you would do normally to a brush, that also includes cloning and duplicating previously used brushes set up as portals.

How do I fix it or prevent portal popping from happening?
Try not to manipulate a brush into shape or position if it's to be used as a portal. Usually simply deleting the offending brush and remaking it, rather than duplicating or copying a previously made one will fix the problem. But, because this is to do with floating point problems as mentioned above doing that may not remove the problem completely, so in such instances the only recourse left is to 'cut' the portal into shape; the portal brush will need to be drawn out as a block (it's needs to be drawn 'in situ' so the initial block out is placed over an area the portal needs to eventually sit in) and then using the clipper tool, cut to size, shape and fit of the area it's going to portalize.

Doing this is the only way at the moment to fix persistent portal popping errors.

Additional Reading
- For more on using Portals click here (Kat's Klorr development article)