[Gtkradiant] [1.5] obj/mtl support, SnapPlane bug (causing collision brushes to?disappear )

[Rudolf Polzer]

On Tue, Dec 18, 2007 at 03:54:08PM -0800, Forest Hale wrote:
> Timothee Besset wrote:
> > Yes, we still need to add q3map2 compile to the scons build for 
> > ZeroRadiant. That should be pretty trivial with the architecture already 
> > in place.
> 
> On IRC Rudolf was asking why ZeroRadiant doesn't use autotools, I
> explained our previous conversation on the subject, but he does have a
> point - Radiant is pretty much the only project using scons, which
> makes it by definition weird/hard to compile/etc :P

Especially editing the scons files is hard for someone like me who has
never used scons... OTOH, editing Makefiles is - unfortunately - a very
common task, especially when cross compiling to OS X or mingw32, I often
had to fix the mess autotools left behind (most common lately: libtool
claiming that it can't do dynamic libraries, and building me a .a
instead of the .dll I wanted - had to edit the libtool script to be able
to make a libmodplug-0.dll).

Let's see when I get my q3map2 Makefile done so that it also can cross
compile - might be a nice addition for GtkRadiant, so people are able to
build q3map2 easier... and gcc's dependency output could be used to find
all the files that are needed by q3map2, with the goal of making a
q3map2-only distribution.

What is XML used for in q3map2? There is this XMLDump.xml file - does
GtkRadiant use it? If not, I could try getting rid of the libxml
dependency... glib can't be gotten rid of... and libmhash is a very
unusual library (it's used by GtkRadiant only on my system, which has
lots of packages installed), does q3map2 use it for any cryptographic
purposes or would any other hash function do too? My final goal would be
a q3map2-only distribution that's easy to compile and set up, so you can
delegate map building to other computers easily, and so that you can
just compile a new q3map2 to put it into an existing Radiant without
much hassle. The purposes I see it using mhash for is to build long
unique IDs... and to put a MD4 checksum into the AAS file. Maybe I'll
take some freely licensed MD4 and MD5 routine and put them in my
"standalone q3map2" project, should I ever get to it.

> On a separate note, maybe Rudolf could make his changes optional using
> a commandline option, which would ensure that any maps relying on the
> old (buggy) behaviors can still use the old mode.
> 
> However from discussions on IRC it sounds like his patch is a
> universal improvement.

Could do this, but it actually consists of three things:

- the additional normal generation methods: they use the previous
  way when no special spawnflags are set (that is, just 6).
- the "find best normal" bug fix: very rarely happens (only when a
  triangle is exactly symmetrical to a 45 degrees plane, and has an
  angle of more than 45 degrees against the coordinate plane
  perpendicular to the 45 degrees plane); even roundoff errors make this
  bug not happen. I see no need to "optionalize" this part of the fix,
  as the bug it fixes probably never happens due to roundoff errors in
  the preceding calculations - I only noticed it when reading the code.
- the snap planes fix - could easily make this into an option, like a
  command line option that basically says "don't fix plane distances
  when normal snapping" so when someone gets problems, he can just set
  -ne_nofixdist and go back to the old behaviour. On the same note, I'd
  also make an additional option "don't snap planes generated by
  autoclipped models at all". I am not convinced that the latter is
  always a good idea - even if it doesn't cause any bugs, it will make
  the bsp file larger than it needs to be.

As for the change in -ne behaviour - although it would be logical, I
don't think it should be done any more. Maybe some mappers already use
-ne 0.00000000001 (smaller number) to lessen the SnapPlane bug. When
-ne gets changed the way I proposed, this will cause MUCH LESS snapping
for these users, and the bugs that happened when SnapPlane got
completely disabled could happen again until they readjust their -ne.
Also, there could be an issue with roundoff-errored normals, like
'0.00001 0.00001 1.00000000' that would not get snapped (while
currently, they would even get snapped with -ne 0).

Still, the patch may require much testing - I can see one case where it
could cause additional problems: assume a map with lots of complex
models... that could just compile because of the SnapPlane bug. Trying
to compile it without the bug would bail out because of some limits of
static structs in q3map2. There may be maps that are currently at the
very edge of these limits...

Best regards

Rudolf Polzer