[Gtkradiant] q3map2 -convert -format map - working on texture alignment
ydnar at shaderlab.com
Sat Dec 29 08:50:18 CST 2007
You might have some luck determining which brushes are detail vs
structural by comparing the brush faces to sides of the BSP leaves. If
a brush face doesn’t directly correspond, it’s probably detail.
I tinkered with something like this a while ago when I wrote the
original -convert code, but the results were (extremely) leaky maps
and I dropped it.
On Dec 29, 2007, at 6:42 AM, Rudolf Polzer wrote:
> I finally could get q3map2 -convert -format map to correctly export
> texture alignment... using hacky methods, but it actually works.
> The big problem is: in a Q3BSP file, there is no link between brush
> sides and draw surfaces. This link is only needed for the texcoords...
> but these really need it.
> My approach to solve this is iterating through all triangles among the
> MST_PLANAR draw surfaces, and finding the one that is on the correct
> plane (and correct plane normal), has the correct shader, and shares
> most of the area with the winding from the brush side. So it is a
> brute force approach... it still decompiled a map in 13 seconds with
> completely correct texture alignment. In many cases there is no
> surface, but this seems to happen only for invisible brush faces or
> textures/common/* stuff (the latter don't need texture alignment
> Now there are some things that hold me off from posting the patch in
> current state... namely: I have no idea how to convert texcoords
> from a
> triangle to the normal .map texcoord system. I tried, and gave up,
> switching to the brush primitives format which is much easier to
> understand for me. Once I found the matching triangle, it's then
> just a
> matter of solving a 3x3 linear equation system using Cramer's rule.
> big problem with that is that GtkRadiant usually cannot read that
> format, unless you toggle "Alternate texture projection" - in which
> it fails to load REGULAR .map files. So brush primitives map files are
> highly annoying to mappers. BTW, does ZeroRadiant solve this and allow
> loading both map types without having to toggle an option and
> Radiant? And would it hold off that patch if the resulting .map files
> are no longer old-style .maps, but brush primitives .maps?
> The next problem is that I haven't yet found out how to detect which
> brushes are detail brushes and which aren't, so currently all get
> exported as structural. This highly increases the compile times of the
> resulting .map file. Any idea how I can do this?
> BTW: the test map I used for this is Nexuiz's map "starship"; whose
> source once got lost in a HDD crash. Decompiling and recompiling
> fine (luckily, _keeplights was used), preserved texture alignment, and
> for an odd reason, the resulting .bsp performs BETTER than the
> in DarkPlaces (in a test demo, it went up from 113.1781634fps to
> 148.7892154fps). The only odd thing in the resulting .map I see is
> some surfaces are oddly chopped up into triangles prisms.
> The current version of the patch can be found at
> - but I'd like to solve the remaining issues with it before I
> suggest it
> for inclusion.
> Rudolf Polzer
> Gtkradiant mailing list
> Gtkradiant at zerowing.idsoftware.com
More information about the Gtkradiant