Posts by kpedersen

Quote from blackdog

1 hour ago, blackdog said: While I imagine that, with the talk about file formats, you could use your tool for any game (granted coding an importer that reads these files), are there games you can map for, out of the box? Can you use it as an alternative to Trenchbroom and make Q1 maps?

Pretty much any game engine that can import .obj files. UE4, Unity, Irrlicht, Ogre3D etc... it should be good for.

As for actual games (i.e modding existing games), most of them that allow for loading custom maps interestingly enough are usually based on Quake or Unreal engines. In which case there are better alternatives suited specifically for Quake (ironically OpenRadiant is not the best for Quake since it is now too generic!) some are:

• TrenchBroom (a modern recreation)
• NetRadiant / NetRadiant custom https://github.com/Garux/netradiant-custom
• Valve's Hammer Editor

My personal recommendation would be NetRadiant Custom. It is pretty much the most modern of the "Radiant" level editors and is well suited for Quake. Interestingly it does also have .obj export but it still can only read textures from the Quake engine folder (pak, pk3 files). However it uses the classic Quake tools (q3map2, etc) to build a .bsp and do lightmap baking, etc before it can be loaded by the game.

Both TrenchBroom and NetRadiant-custom are actually starting to see more "per-vertex" tools, making them really flexible and bringing them more inline with how 3D modelling tools can be used. Makes sense so quake maps can finally move away from their traditional "boxy look"

You could pass the .map file from OpenRadiant directly through q3map2 .bsp compiler for use in Quake. You could even export to .obj and then use Blender for a few touchups and re-export to .map. It won't be quite as fun though.

Quote from AlexM

On 1/8/2021 at 7:58 PM, AlexM said: By any chance have you looked at gltf?

I certainly like the idea of it. I do admire the efforts of Khronos trying to push a new open standard. I suppose what remains to be seen is if people accept it or not. One thing I have learnt so far is that often the most annoying file formats to deal with seem to become the ones that everyone wants!

As it stands, OpenRadiant -> .obj -> Blender -> gltf might have to suffice. I suppose with a decent script for Blender to also add useful metadata (lights, entities), it isn't a bad workflow. OpenRadiant does also write out a .ent file along with the .obj providing that information so it wouldn't be too bad.

Quote from AlexM

On 1/6/2021 at 5:58 PM, AlexM said: Ah I was going to ask about FBX but I know it's a pretty rough format to work with as a programmer so I didn't want to push it

Heh, absolutely rough! So I have it working with the "text" fbx format but the binary format is horrendously undocumented. For the binary format (i.e the one people generally want) in the past I have used Autodesks FBX SDK for a few previous projects but it seems a shame for it to only support a couple of platforms.

I was looking at this: https://github.com/jskorepa/fbx which looks fairly good but it is one of those things that will permanently be playing catchup with the vendors latest format. That said, backwards compatibility is pretty good for 3D modellers so it might not be a problem.

Quote from AlexM

On 1/6/2021 at 5:58 PM, AlexM said: I've often thought about writing a plugin but I have too many projects

Haha yes, I know that feeling. I am just glad I have finally managed to make progress on one of mine that can finally be ticked off the "to do at some point" list

Quote from blackdog

On 1/6/2021 at 10:30 PM, blackdog said: So to fully understand, you also have your own renderer?

Yes. Traditionally, when making maps with id Software's Q3Radiant, you typically place a few things about and then can test it in a single mouse click which will start up Quake III Arena (or derivative) and load the map you have been working on to test out "in-game".

Because OpenRadiant is now completely separate from Quake, it seemed a shame to lose that ability to quickly test it. So I wrote a very simple renderer to run the map and move around to explore. The renderer is written in OpenGL and isn't anything too special. Later on I plan to export it as a single file WebGL website so you can dump it on web servers. I am also thinking about making a few menu items to launch the map in Maya or Blender to make for easy workflows (and they can then export to .fbx or any of the hundreds of different formats you might need).

Edit: The lighting is baked using a bespoke (but fairly primitive) ray tracing tool. Mostly because quite a lot has moved on since the old Quake III mapping tools that used to do this and I needed a few extra features so I thought I would just re-implement my own.

Many thanks

I have been working on and off with it for a good number of years. Mostly just hacking in features as and when they are needed. I (and a few of my colleagues) actually use it for a number of projects we work on commercially (even though most of us are programmers by trade). However up until recently it has been very rough and almost every second button we would click on would cause it to crash.

That is why I thought I would finally clean it up before it would be anywhere near worth sharing

I have some quite cool plans for it in the future, ranging from the obvious ones such as fbx support, all the way to exporting a single .html file complete with the exported map and basic webgl engine embedded in to quickly whack on preview pages to show off to clients.

Hi all,

Level editors for Quake era games such as Worldcraft and QERadiant originally got me interested in game development and even to this day, as a programmer I find Blender and others a little less fun to use than those original tools were. ProBuilder and UE4 brushes got close but I don't find it generic enough to be able to use the same tool for a number of different game engines I typically use for many of my projects.

So I decided to dive in and start considerably hacking at the GtkRadiant level editor source code. As just one example, rather than read Quake 3 data files, instead it reads from a standard filesystem (as you would expect a normal 3D modeller to do). I have also added a "standard" .obj (wavefront) exporter making it easy to read directly into other modelling tools as part of your build pipeline. That format is fairly minimal but widely supported.

Finally I have replaced the older Q3 lightmap baking stuff (the q3map2 compiler) with my own called "Raptor Bakery" (Or you can use Blender's, Maya's, etc anyway because they can all import .obj). I have optionally extended the .obj format to provide lightmap coordinates. A bit hacky; my next step is to just provide an fbx exporter

Familiarizing myself with the original GtkRadiant codebase has been difficult but I really enjoy using the tool. Being able to knock up test scenes in a matter of minutes is really great. Perhaps this tool could help you migrate any cool levels you created for Quake or Half-Life (perhaps back in the day or even now!) to other engines. I have been a long time lurker on these forums and have seen some great stuff. Yes, some of it is probably a bit too much for this tool to handle but nonetheless

So if you are interested, please check it out. It is free and I thought others might enjoy it.

http://thamessoftware.co.uk/openradiant/

Karsten