[Gtkradiant] Further GtkRadiant development?

[Rudolf Polzer]

On Sun, Dec 27, 2009 at 01:21:10PM -0600, Timothee Besset wrote:
> ailmanki wrote:
> > Hello,
> >
> > Just to mention it, there is a fork of the 1.5 
> > http://dev.alientrap.org/wiki/netradiant alive.
> >
> > Hmmm so 1.6 is they way to go, actually quite a sad thing, 3 different 
> > versions which have different abilities.
> > Maybe thats the reason, that since 1.3 none has made a new plugin..
> >
> > thanks
> > ailmanki
> >
> 
> Yeah there is NetRadiant too. It's a bit unfortunate that they went 
> their own way and never wanted to play ball with us, but that's 
> perfectly within the rules of open source software.

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.

Best regards,

Rudolf Polzer