q3map2 -convert -format map - working on texture alignment

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.endoftheinter
net.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
Gtkradiantzerowing.idsoftware.com
http://zerowing.idsoftware.com/cgi-bin/mailman
/listinfo/gtkradiant

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.endoftheinter
net.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
> Gtkradiantzerowing.idsoftware.com
> http://zerowing.idsoftware.com/cgi-bin/mailman
/listinfo/gtkradiant
>


_______________________________________________
Gtkradiant mailing list
Gtkradiantzerowing.idsoftware.com
http://zerowing.idsoftware.com/cgi-bin/mailman
/listinfo/gtkradiant

Rudolf Polzer wrote:
> I finally could get q3map2 -convert -format map to
correctly export
> texture alignment... using hacky methods, but it
actually works.
>
>   
Is this for converting a Q3 .map file to e.g. a Quake2 .map
file?

-- 
Jay Dolan
jdolan.dyndns.org

A: Because it's difficult to read.
Q: Why is top-posting bad?
A: Top posting.
Q: What's the most annoying thing about email? 


_______________________________________________
Gtkradiant mailing list
Gtkradiantzerowing.idsoftware.com
http://zerowing.idsoftware.com/cgi-bin/mailman
/listinfo/gtkradiant

On Sat, Dec 29, 2007 at 09:53:01AM -0500, Jay Dolan wrote:
> Rudolf Polzer wrote:
> > I finally could get q3map2 -convert -format map to
correctly export
> > texture alignment... using hacky methods, but it
actually works.
>
> Is this for converting a Q3 .map file to e.g. a Quake2
.map file?

No, it converts a Q3 .bsp file into a Q3 .map file, by
restoring as much
as information of the .map file as possible.

Known issues with this "decompiling":
- embedded models get lost (I _could_ actually try
supporting them,
  maybe they actually are supported now, haven't tested it -
if they do
  get decompiled and just get broken texture alignment, I
know how to
  fix it, but I'd expect them to get lost totally - I'll
test this
  later, and possibly fix)
- brushes get split up into multiple brushes, making the map
harder to
  edit (the CSG Merge tool comes in handy then)
- lighting gets lost (unless the map originally had
_keeplights in its
  worldspawn entity)
- some special kinds of entities break (billboards, for
example, use
  their own surface type, but no idea what they even are)


_______________________________________________
Gtkradiant mailing list
Gtkradiantzerowing.idsoftware.com
http://zerowing.idsoftware.com/cgi-bin/mailman
/listinfo/gtkradiant

On Sat, Dec 29, 2007 at 09:50:18AM -0500, Randy Reddig
wrote:
> 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.

Hm... what about brushes that extend to the outside of the
map, that is,
brushes that can't be seen from anywhere? They don't get a
surface
index... thus, they can't be listed in the leafface list
either.

A single face matching however is no indicator for a
structural brush
either - often, detail brushes share a side with structural
ones.


_______________________________________________
Gtkradiant mailing list
Gtkradiantzerowing.idsoftware.com
http://zerowing.idsoftware.com/cgi-bin/mailman
/listinfo/gtkradiant

If the shader matches, and the brush face is larger than the
 
corresponding surface and leaf face, then you can probably
assume it’s  
structural.

Randy


On Dec 29, 2007, at 11:12 AM, Rudolf Polzer wrote:

> On Sat, Dec 29, 2007 at 09:50:18AM -0500, Randy Reddig
wrote:
>> 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.
>
> Hm... what about brushes that extend to the outside of
the map, that  
> is,
> brushes that can't be seen from anywhere? They don't
get a surface
> index... thus, they can't be listed in the leafface
list either.
>
> A single face matching however is no indicator for a
structural brush
> either - often, detail brushes share a side with
structural ones.
>
>
> _______________________________________________
> Gtkradiant mailing list
> Gtkradiantzerowing.idsoftware.com
> http://zerowing.idsoftware.com/cgi-bin/mailman
/listinfo/gtkradiant
>


_______________________________________________
Gtkradiant mailing list
Gtkradiantzerowing.idsoftware.com
http://zerowing.idsoftware.com/cgi-bin/mailman
/listinfo/gtkradiant

On Sat, Dec 29, 2007 at 05:07:42PM +0100, I wrote:
> Known issues with this "decompiling":
> - embedded models get lost (I _could_ actually try
supporting them,
>   maybe they actually are supported now, haven't tested
it - if they do
>   get decompiled and just get broken texture alignment,
I know how to
>   fix it, but I'd expect them to get lost totally -
I'll test this
>   later, and possibly fix)

Addition: I just managed to support them as good as
possible. I updated
the patch at
http://emptyset.endoftheinter
net.org/~polzer/nexuiz/q3map2-convert-map-bprimit.diff

The result is that it uses the autogenerated brushes from
q3map2 (only
works when the spawnflags for these were specified). Of
course, as you
know, q3map2 has issues generating these... my patch fixes
these. When
trying to decompile a map that was affected by the bug (but
not so much
that it actually led to gameplay problems), the clipping
problems immediately become visible:
http://emptyset.en
doftheinternet.org/~polzer/img/uploaded/f035a559765eb329defa
09aa939c74ba.png

And I already specified -ne 0.1 -de 2 to get a viable
result... regular
brushwork decompiles nicely with the regular values of
normalEpsilon and
distanceEpsilon.


_______________________________________________
Gtkradiant mailing list
Gtkradiantzerowing.idsoftware.com
http://zerowing.idsoftware.com/cgi-bin/mailman
/listinfo/gtkradiant

Rudolf Polzer wrote:
> - brushes get split up into multiple brushes, making
the map harder to
>   edit (the CSG Merge tool comes in handy then)

I wonder what causes this, it sounds very odd to me.

> - lighting gets lost (unless the map originally had
_keeplights in its
>   worldspawn entity)

To be honest I've always hated the fact that _keeplights
exists, because it means that the map is not properly
decompileable by default, and even more importantly the
q3map2 lights can't be loaded by
DarkPlaces engine if they're missing (it can render them in
realtime lighting mode - although I haven't put much effort
into making them the correct size/color/etc because most bsp
files don't even
have them due to lack of _keeplights).

> - some special kinds of entities break (billboards, for
example, use
>   their own surface type, but no idea what they even
are)

q3map2 does not even produce these, and quake3 does not
render them, I think openquake is the only project that
cares about them at all.

More importantly they are directly associated with light
sources and thus there is no reason to recover them from the
bsp file.

-- 
LordHavoc
Author of DarkPlaces Quake1 engine and mod
http://icculu
s.org/twilight/darkplaces/
"War does not prove who is right, it proves who is
left." - Unknown
"Any sufficiently advanced technology is
indistinguishable from a rigged demo." - James Klass




_______________________________________________
Gtkradiant mailing list
Gtkradiantzerowing.idsoftware.com
http://zerowing.idsoftware.com/cgi-bin/mailman
/listinfo/gtkradiant