[Gtkradiant] Further GtkRadiant development?

[Nerius Landys]

> Actually, the only reason why NetRadiant exists is stabilizing Radiant 1.5, but
> keeping the map compiler up to date with current and new features. The editor
> is mostly unchanged and probably never will really get changed/improved, apart
> from minor additions and fixes.
>
> The problem simply was - I didn't want to wait for weeks to get a single bugfix
> applied, and also wanted to try new development in the map compiler even if
> this may be unstable. So the changes in NetRadiant are simply not fit for id
> software's GtkRadiant repositry, as I got told, as every single change would
> need months of evaluating whether it might break maps of other projects or not,
> and I simply wanted a fast way to provide a current, extended and bugfixed, map
> editor and compiler to Nexuiz mappers.
>
> However, I am perfectly fine if id software decides to take over NetRadiant
> changes into the official GtkRadiant 1.5 repository, and in fact, many of the
> q3map2 changes are highly recommended by me (e.g. the recent fix for lightgrid
> calculating to prevent overly dark grid points near walls). One other
> NetRadiant feature I recommend for 1.5 and also for ZeroRadiant is patch
> smoothing operation, which removes sharp edges from patch meshes:
> http://www.youtube.com/watch?v=IFxvhqJQ7G0
>
> The reason why it is based on 1.5 and not 1.6 is, simply, that 1.5 still is
> more stable, both in code and numerically. E.g. "Alternate texture projection"
> mode still has numeric instabilities in ZeroRadiant, caused by conversion of
> the texcoords back and forth, which is because the plugin interface for the
> surface dialog supports no other way of encoding the texcoords. However, I like
> working with that mode as it allows skewing and rotating without texture
> alignment trouble - which is something mathematically impossible with the
> shift-rot-scale projection mode.
>
> However, it cannot be denied that 1.4/1.6 clearly have a more efficient editing
> workflow.
>
> Also, the NetRadiant fork got mostly inactive over time - simply because it
> seems very stable and usable now.
>
> One other goal, which you probably do not agree with, in NetRadiant was
> simplifying the compile process, and reducing library dependencies. libmhash is
> no longer required. One instance that previously used MD5 now uses MD4, and MD4
> is implemented using an included .c file that is from the DarkPlaces engine,
> and came from Samba to there. Also, the dependency on scons also got removed,
> and it now can be built using a Makefile, which highly improves the process to
> cross compile NetRadiant. The only "nonstandard" dependency of NetRadiant is
> gtkglext, and that one really doesn't look like it can be easily avoided.
>
> I really wish one could combine the advantages of 1.5 and ZeroRadiant into one,
> but this probably will not happen anytime soon given the different design of
> the two editors.

It seems that Markus has graciously taken up the task of stabilizing
the 1.6 codebase.