Unvanquished mapping with DarkRadiant

[illwieckz]

So the current status of DarkRadiant compatibility with Unvanquished:

• The mkeditorpacks tool now produces a compatible DarkRadiant gamepack (I mean compatible with DarkRadiant);

• an entity definition file written with Doom 3 def syntax compatible with DarkRadiant is now generated by mkeditorpacks and it works;

• a game file written with DarkRadiant syntax is now generated by mkeditorpacks and it works;

• Quake 3 brush format is read and now texture size is properly scaled but rotation/orientation is correct;

• Quake 3 brush format is written, it is now implemented;

• the IQM patch for the picomodel library was submitted to DarkRadiant (same code as in GtkRadiant and NetRadiant). Animations aren't supported;

• the dpk/dpkdir format works in a basic way (like a pk3/pk3dir: everything is loaded);

• DEPS is not supported in dpk/dpkdir (loaded like a pk3/pk3dir like GtkRadiant), this if NOT a problem is your mapping environment is clean;

• some models are not properly scaled, it only affects DarkRadiant display (they are correctly displayed in game).

Note that .map files written by DarkRadiant, NetRadiant or GtkRadiant may differ because of minor difference in writing floats, so switching between tools may produce a lot of diff noise in git repositories.

Initial post:

I've done some experiments with DarkRadiant. DarkRadiant is the radiant editor maintained by people who make The Dark Mod game, which is based on idTech4 (Doom 3) engine. Forked of GtkRadiant, its current usage is Doom3 derivated games, and primarily The Dark Mod. By the way, Quake3 map and shader support look to be there, there is just a proper missing game pack and some bugfixes are probably needed. The DarkRadiant game pack format extends the NetRadiant one, they probably forked the 1.5 version of GtkRadiant instead of the 1.4/1.6 one [Edit: it's now verified], so the code base is probably closer to NetRadiant than GtkRadiant.

I wrote a Quick&Dirty gamepack without reading any documentation, I probably made many mistakes and there is still Doom 3 references in that game pack, by the way, all the things you will see in screenshots below were obtained without writing and compiling any custom DarkRadiant code. There is no need to hardcode game support like you have to do with GtkRadiant 1.6. Just put the game file in the right folder to add your own game supported, the same way you would do with NetRadiant.

They ported the GUI from GTK to WxWidgets, it works as well on Linux and that other OS named Windows. It also means it runs on Mac OS with a native Cocoa interface without needing XQuartz at all. In fact, I had some talks with @cu-kai trying first to compile GtkRadiant and NetRadiant on his Mac, then DarkRadiant. I copy/paste there some quotes from the talk:

<illwieckz> I don't know how well done the mac support is
<cu-kai> lol yeah i just noticed
<cu-kai> no build instructions for mac os
<illwieckz> there is no mac reference on their website
<cu-kai> huh
<cu-kai> this is too easy
<cu-kai> something will go wrong
<illwieckz> ^_^
<cu-kai> ummm
<cu-kai> it works
<cu-kai> shit, it works

Yes, it works, and there is an extra candy for you: the pk3dir support is already in and it works too, that's something that is not yet merged in both GtkRadiant and NetRadiant but is there since years in DarkRadiant.

Here, you see a preview of the Metro map, the map and its textures sit in map-metro_src.pk3dir, while the ads textures sit in tex-metro-ads_src.pk3dir. Everything load. There is some issues with some textures, not all of them, sometime they are not correctly scaled, I guess it's a minor issue that would not be hard to fix. As you see, there is a texture browser (not like in GtkRadiant 1.6).

There is native md5 model support (I wonder if it would be easy to merge iqm model support from aaradiant). This is how looks md5 models in DarkRadiant. There is also an md5 animation preview interface, but I haven't figured out yet how to get a model in it.

This is how you add map models with DarkRadiant (right click on orthogonal view, “Create model…”).

There is a built-in particle editor but I haven't figured out yet how to use it and if it's usable for idTech 3 related stuff.

I said there is a texture scaling issue. I hope it's minor and easy to fix. This is how look the Boil and Dark Zone maps for the upcoming Xonotic 0.8.2 release. Boil's textures look OK, Dark Zone's not.

We can see similar things with Unvanquished maps. As seen on the screnshot of Metro map above, some look OK, some not. On this Parpax screenshot, the textures are obviously not correctly scalled. Same problem with the Forlorn map, but you still recognize the map easily, and you can notice updates are coming in Forlorn!

Not only textures has issues, some models are not correctly scaled too: some are ok, some are not, as you can obviously notice it on these Vega screenshots. Do not be fooled by that vehicule, it's a matter of point of view, it's obviously wrong !

DarkRadiant does not ship any map compiler since id Tech 4 features a built-in map compiler, but we can just use q3map2 from netradiant for that task.

This is very promising and at first glances there is only minor issues to fix. If we need to merge something, the gap between NetRadiant and DarkRadiant looks to be far far far smaller than the one between NetRadiant and GtkRadiant 1.6. Also, DarkRadiant is well maintained, probably more maintained than GtkRadiant, enough to get packaged in Debian and Ubuntu ! That's impressive ! On the features, it looks like GtkRadiant < NetRadiant < DarkRadiant. I don't know yes what is missing from NetRadiant but I hope it would not be too hard to merge them in DarkRadiant. That looks very promising!

The DarkRadiant souce code is hosted on GitHub and bug tracker sits in The Dark Mod bug tracker.

Thing you need to know: It just loads the map with quake3 format, currently I haven't managed to save it as quake3 one. It looks like to be an issue in DarkRadiant itself, perhaps it's not wired correctly or it's just my quick&dirty gamepack that is malformed. So, if you want to try out, only test on copied files, do not overwrite your precious maps!!!! Edit: it looks like it's even not the doom3 format I got when I write quake3 maps in DarkRadiant, probably bugs somewhere…

[illwieckz]

Very good stuff I discovered: there is quake3 brush read support, quake3 patch read support and quake3 patch write support, quake3 brush write is missing, and that texture issue probably comes from bugs in that quake3 brush read support.

But you know what? These formats were only introduced in DarkRadiant 10 month ago, so these issues are just bugs because the work was started 10 month ago and just has to be polished and finished! It also means they are ok to merge Quake3 related stuff since they started to implement it themselves, and they probably will not refuse fixes on what they started to implement!

[illwieckz]

• proof they forked GtkRadiant 1.5.0

• commit adding initial quake3 brush support 10 month ago

[illwieckz]

Except that texture scaling issue, that looks very good:

As you see, the decorative turrets are rendered in DarkRadiant, something that is missing in-game.

[Viech]

This does look really promising. We strongly want an editor that's maintained and DarkRadiant also offers features that can come in handy later, such as proper support for Doom 3-Era entity/dynamic lights. Would be really nice if we could get it fully working by contributing to the root repository.

[greebo]

Hey there folks,

by chance I noticed your fork and bumped into this thread. Just wanted to pop in and say hello, it's nice to see that DarkRadiant is used for different projects as well. I'm the person behind the https://github.com/codereader/DarkRadiant repository and as it seems I'm the only personl left working on the project. But that's not a complaint, it's just how things are. :)

While DR doesn't really follow the "we-want-to-support-all-games-under-the-sun" approach of the original GtkRadiant, I'm happily accepting contributions that are compatible with the codebase. :) So if there are small things that might improve compatibility with your game (i.e. game packs or map format plugins or Python scripts), I'm happy to include this in upstream development. If you rather want to go ahead with your fork, that's fine with me of course as well. I can try to offer advice or answer questions, if that helps.

Also nice to read about the confirmation that it compilesin OSX, it was only recently when started to fool around using an old MacBook, setting up the Xcode project such that it compiles and generates a portable app package. Nice to see that effort led to something.

I'm not the person with a lot of online time on my hands, but I'm usually reachable through the DarkRadiant forums over at forums.thedarkmod.com. If this board is sending out mails for private messages or thread subscriptions, I might monitor this thread as well.

[illwieckz]

Hi @greebo! Welcome there!

My fork is just a place for me to experiment stuff and to share what I'm experimenting with. For sure if one day I wrote something releasable I will submit a PR, I'm not planing to maintain any fork outside the tree. I wrote a tool to compare radiant trees to look for stuff that can be interesting and I really don't want to add a new tree . I'm already contributing to NetRadiant and GtkRadiant trees for Unvanquished purpose so there is no reason I wouldn't contribute to DarkRadiant if we manage to get something with it! In fact we are all bored of all radiant forks. We currently use NetRadiant but it's not because we love it, we use it today because we used it yesterday, and yesterday because we were already using it the day before etc. It looks like Xonotic guys get bored of NetRadiant too. We had some talks recently, looking for a more maintained project to merge in. We first thought about GtkRadiant but it would be an hard work to merge in and would be a huge regression. I was aware of Darkradiant since a long time but never tried it for id Tech 3 related stuff, because I was not aware it was somewhat compatible with pre id Tech 4 stuff. I was very impressed by the experience and this thread is the result of my experiment. It looks like not so many things are missing at first glance.

For some fun facts, the Dæmon engine used by Unvanquished shares much code with the old XreaL/ET:XreaL project, and since this old ET:XreaL was experimenting with DarkRadiant back in the days, there is already some DarkRadiant references in our current source tree (like an entities.def with explicit DarkRadiant wording):

Code: Select all

$ grep -r Radiant *
daemon/src/engine/qcommon/q_math.cpp:// helper functions for MatrixInverse from GtkRadiant C mathlib
daemon/src/engine/renderer/tr_bsp.cpp:		// check for deluxe mapping provided by NetRadiant's q3map2
main/def/entities.def: ET-XreaL/etmain/ entity definition file for the XreaLRadiant
main/def/entities.def:	"spawnclass"					"idLight"  // this is required for DarkRadiant

(Yes our current code base references at least four Radiant trees )

So, for sure I will continue my experiments, and I will probably have some questions to ask.

My first priority would be to get proper brush reading and writing. We use this Legacy Brush format and currently DarkRadiant reads this brush format but textures are misaligned, and DarkRadiant writes this other BrushDef format instead at saving, which means our maps can't be compiled after saving in DarkRadiant. On the Patch format, everything looks already OK by the way.

About the OSX compile, well, your project is probably the only radiant that compiles and runs nicely on Mac today. And since this Mac support looks to not be a first priority for you, I think the fact it builds and runs so easily means something about the quality of the project itself and about good design choices. Having a radiant that works on Mac makes @cu-kai very happy, if DarkRadiant becomes usable for Unvanquished, expect some feedback if that Mac support breaks. ;-)

You can subscribe on that thread (just tick “Notify me when a reply is posted” when replying, you can also be notified on highlight like I just did. Of course this needs the mail system to be working. By the way if I produces something useful to contribute or if I have to talk about some bugs I find, I will write some PR or issues on GitHub.

[greebo]

My first priority would be to get proper brush reading and writing. We use this Legacy Brush format and currently DarkRadiant reads this brush format but textures are not misaligned, and DarkRadiant writes this other BrushDef format instead of saving, which means our maps can't be compiled after saving in DarkRadiant. On the Patch format, everything looks already OK by the way.

If upgrading your engine's map parser is not an option, I can try to assist you in setting up a .game and extend the brush exporter code to write a format you folks need. As far as the textures go, I can try to look at this stuff, I haven't had any valid maps to work with when writing the importer. I'd need a small test map plus texture/material files, with a screenshot to compare against.

About the OSX compile, well, your project is probably the only radiant that compiles and runs nicely on Mac today. And since this Mac support looks to not be a first priority for you, I think the fact it builds and runs so easily means something about the quality of the project itself and about good design choices. Having a radiant that works on Mac makes @cu-kai very happy, if DarkRadiant becomes usable for Unvanquished, expect some feedback if that Mac support breaks. ;-)

That's nice to hear. There wasn't too much code to fix up for Xcode, actually, the packaging and otool/install_name_tool fiddlery was more work. The move to wxWidgets a few years back was an important decision, and it seems it was the right one (I chewed on that migration for more than eight monhts, I think).

[cu-kai]

That's nice to hear. There wasn't too much code to fix up for Xcode, actually, the packaging and otool/install_name_tool fiddlery was more work. The move to wxWidgets a few years back was an important decision, and it seems it was the right one (I chewed on that migration for more than eight monhts, I think).

If it helps, I simply followed the linux compilation instructions while using brew to install the deps.

I'm very glad it compiles on OSX though, and has a native(!) interface rather than GTK+ garbage found in net/gtkradiant (neither of which work properly on osx)

Thank you for continuing to maintain your project!

[greebo]

If it helps, I simply followed the linux compilation instructions while using brew to install the deps.

Ah, yes, that's the way I got it to work first time around as well (I've been using MacPorts to get the dependencies though). In the meantime I've set up an Xcode project to compile DR, if you feel like it you can check out if it works on your end as well.

I'm very glad it compiles on OSX though, and has a native(!) interface rather than GTK+ garbage found in net/gtkradiant (neither of which work properly on osx)

Same for the Windows platform, GTK+ support for Windows (especially x64) was getting more and more outdated over the years and I felt it was getting worse after GTK+3 came out. At first, I went with compiling the entire GTK+ stack myself for Windows x64, but I was stuck with GTK+2, so after looking around a bit and some rough tests I bit the bullet and made the move to wx. The wxWidgets folks are doing a great job keeping up the support for all of the three platforms, and having native controls is a nice advantage.

But even with wxWidgets there will be some hurdles to overcome, since the GL widget doesn't work in Wayland. Right now DR just crashes in Fedora 25, for example.