PRT file viewing

[ericwa]

Just a wishlist thing, but it would be cool to have rendering of portals from PRT files. I imagine having "Load PRT" and "Unload PRT" menu items, similar to the ones for PTS files.

Also nice would be supporting the vanilla PRT1 format + the extended formats used by tyrutils and txqbsp-xt when detail brushes are in use.

[kduske]

Can you attach a map file with one prt file in each format? Also is there a description or spec of these files?

[mfxausberlin]

I support this. The info from a prt file may be cluttered visually, but it
can help trace down unnessary portals.
This again helps to fix maps that are currently "unvisable" due to complex
architecture. (think tronyn maps for example, that take a months to compile)

my2cents

Maik

2016-01-11 22:25 GMT+01:00 Eric Wasylishen notifications@github.com:

Just a wishlist thing, but it would be cool to have rendering of portals
from PRT files I imagine having "Load PRT" and "Unload PRT" menu items,
similar to the ones for PTS files

Also nice would be supporting the vanilla PRT1 format + the extended
formats used by tyrutils and txqbsp-xt when detail brushes are in use

—
Reply to this email directly or view it on GitHub
#1157.

[ericwa]

I didn't find a spec after doing a quick search, but I can prepare a test map + a PRT in each format, and a description of how to parse them.

They're pretty simple formats; each line describes a polygon with the number of verts and the x/y/z coordinates of each vertex.

[kduske]

Great, please do. If it's that simple, I'll add it right away.

[ericwa]

Here's the sample map + 3 types of prt file: portaltest.zip

The PRT1 format is: (my comments wrapped in C-style comments)

PRT1 /*file type */
6 /* number of leafs (TB can ignore) */
5 /* number of portals, starting on the next line, one portal per line. */
4 /* number of verts for this portal */ 1 4 /* 1 and 4 are the leaf indices, TB can ignore */ (-96 -32 80 ) (-96 160 80 ) (0 160 80 ) (0 -32 80 ) /* these are the 4 verts */
4 1 2 (208 -64 80 ) (64 -64 80 ) (64 160 80 ) (208 160 80 ) 
8 2 3 (64 80 48 ) (64 80 16 ) (64 64 0 ) (64 32 0 ) (64 16 16 ) (64 16 48 ) (64 32 64 ) (64 64 64 ) 
8 3 4 (0 80 48 ) (0 80 16 ) (0 64 0 ) (0 32 0 ) (0 16 16 ) (0 16 48 ) (0 32 64 ) (0 64 64 ) 
3 4 5 (-64 -32 0 ) (-32 -32 0 ) (-48 -32 64 ) 

Also, the vertex coordinates can be floats.

PRT2 (used by tyrutils) is the same, except there is an extra line in the header to ignore (number of clusters):

PRT2 /*file type */
10 /* number of leafs (TB can ignore) */
6 /* number of clusters (TB can ignore) */
5 /* number of portals. */
4 /* number of verts for this portal */ 1 4 /* 1 and 4 are the leaf indices, TB can ignore */ (-96 -32 80 ) (-96 160 80 ) (0 160 80 ) (0 -32 80 ) /* these are the 4 verts */
4 1 2 (208 -64 80 ) (64 -64 80 ) (64 160 80 ) (208 160 80 ) 
8 2 3 (64 80 48 ) (64 80 16 ) (64 64 0 ) (64 32 0 ) (64 16 16 ) (64 16 48 ) (64 32 64 ) (64 64 64 ) 
8 3 4 (0 80 48 ) (0 80 16 ) (0 64 0 ) (0 32 0 ) (0 16 16 ) (0 16 48 ) (0 32 64 ) (0 64 64 ) 
3 4 5 (-64 -32 0 ) (-32 -32 0 ) (-48 -32 64 ) 
/* The rest of the file can be ignored, it contains the cluster/leaf mapping */
0 -1
1 -1
2 3 4 5 6 -1
7 -1
8 -1
9 -1

This is the format used by txqbsp-xt. It's the same as PRT2, except the header order is different, and the cluster/leaf mapping after the portals is different, but that's not needed to render the portals.

PRT1-AM /*file type */
6 /* number of clusters (TB can ignore) */
5 /* number of portals. */
10 /* number of leafs (TB can ignore) */
4 1 4 (-96 -32 80 ) (-96 160 80 ) (0 160 80 ) (0 -32 80 ) 
4 1 2 (208 -64 80 ) (64 -64 80 ) (64 160 80 ) (208 160 80 ) 
8 2 3 (64 64 0 ) (64 32 0 ) (64 16 16 ) (64 16 48 ) (64 32 64 ) (64 64 64 ) (64 80 48 ) (64 80 16 ) 
8 3 4 (0 64 0 ) (0 32 0 ) (0 16 16 ) (0 16 48 ) (0 32 64 ) (0 64 64 ) (0 80 48 ) (0 80 16 ) 
3 4 5 (-64 -32 0 ) (-32 -32 0 ) (-48 -32 64 ) 
0
1
2
2
2
2
2
3
4
5

Let me know if anything is unclear :-)

[ericwa]

Also, here's a sample of how gtkradiant draws them of my test map: