[Gtkradiant] q3map2 -convert -format map - working on texture alignment

[Randy Reddig]

Nice work!

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.

Randy


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  
> rather
> brute force approach... it still decompiled a map in 13 seconds with
> completely correct texture alignment. In many cases there is no  
> matching
> surface, but this seems to happen only for invisible brush faces or
> textures/common/* stuff (the latter don't need texture alignment
> anyway).
>
> Now there are some things that hold me off from posting the patch in  
> its
> 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.  
> The
> big problem with that is that GtkRadiant usually cannot read that
> format, unless you toggle "Alternate texture projection" - in which  
> case
> 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  
> restarting
> 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  
> worked
> fine (luckily, _keeplights was used), preserved texture alignment, and
> for an odd reason, the resulting .bsp performs BETTER than the  
> original
> 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  
> that
> some surfaces are oddly chopped up into triangles prisms.
>
> The current version of the patch can be found at
> http://emptyset.endoftheinternet.org/~polzer/nexuiz/q3map2-convert-map-bprimit.diff
> - 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
> http://zerowing.idsoftware.com/cgi-bin/mailman/listinfo/gtkradiant
>