Can DR be used with engines like Godot?

[Skaruts]

I'm trying to get DR to work with my Godot projects, to replace TrenchBroom, but my first attempts haven't been fruitful. I need DR to see my project's textures, 3D models and entity definitions. I told DR where to find my game in the Game Setup window, but I'm having some issues.

As far as entities go, I think I'm probably fine. I unpacked a few of TDM's .pk4 files and found the folder def with many .def files. I tried placing misc.def and tdm_base.def in there, to see if DR would load those entities after restarting, and it does but only if the game type is TDM. I'm probably fine with that, as it makes no difference, as far as I can tell. The Godot importer only cares about the contents of the .map file, which I know I can export in a few formats, so that should be fine (Q3 at least should work fine).

However, DR is not seeing my project's textures. I don't know if DR can work with .png files, but I brought in some .tga files from TDM for testing and DR doesn't see them either. So something is missing, but I don't know what it is.

I tried placing the textures in a textures folder at the project's root, but nothing happened. Although ideally I'd like to have the textures in root/assets/textures.

I haven't tried to use 3D models at all yet, so I'm in complete darkness about that. I wonder what formats DR supports, though. I usually work with .obj, which bypasses Godot's import weirdness.

Edited October 16, 2023 by Skaruts

[Skaruts]

Ok, so I remembered that TDM textures are declared in mtr files in the materials folder, so I copied over `tdm_internal_engine.mtr` and it works. DR sees textures, but... only .tga files. The console has quite a few lines like: "[shaders] Unable to load texture: textures/tool/clip.png", referring to my own textures.

Can DR not work with png files?

 

EDIT: I presume it can, and maybe it has to be set in the game config file, but I have a very feeble understanding of those files, and I can't find any information anywhere on how to set them up. I've used NRC a bit, which uses the same kind of game config files, and I also had trouble detecting textures. But the only way I could get it to work was... the NRC developer gave me a working config that could see my textures.

So... I'm not very confident that I'm gonna get this working on my own.

I tested the NRC game config in DR, but nothing seemed to change.

Edited October 17, 2023 by Skaruts

[datiswous]

13 hours ago, Skaruts said:

So... I'm not very confident that I'm gonna get this working on my own.

Is the png issue your only problem?

 

15 hours ago, Skaruts said:

I haven't tried to use 3D models at all yet, so I'm in complete darkness about that. I wonder what formats DR supports, though. I usually work with .obj, which bypasses Godot's import weirdness.

afaik DR suports lwo and ase. obj is supported by tdm, but afaik not by DR yet.

[Skaruts]

3 hours ago, datiswous said:

Is the png issue your only problem?

So far yes. But I haven't moved past that, so I don't know what other problems might come up, if any. 

I don't know if model formats are going to be a problem.

[Skaruts]

Yea, it seems models are going to be a problem. DR doesn't detect gltf or dae. It does detect obj, but crashes as soon as I click the model. 

I don't know if I can work with lwo or ase in Godot, but I don't even have plugins for that in blender. I've only made one model for TDM once, and it was back in Blender 2.79. 

 

As far as textures go, I suppose it's not much of a problem. I could work with tga. It's just that free textures are usually distributed in jpg or png, so working with .tga requires going through the trouble of converting each of them (base texture plus normal map, ao map, rough map, etc).

[datiswous]

Yeah DR should definitely support more formats, especially at least one that is supported by other open source engines like Godot.

Quote

Godot supports the following 3D scene file fomats:

• DAE (COLLADA), which is currently the most mature workflow.
• GLTF 2.0. Both text and binary formats are supported. Godot has full support for it, but the format is new and gaining traction.
• OBJ (Wavefront) formats. It is also fully supported, but pretty limited (no support for pivots, skeletons, etc).

 

 

Edited October 20, 2023 by datiswous

[OrbWeaver]

DarkRadiant does not care about engines at all, it only cares about file formats. Whether you can use DR with your Godot-based game will therefore depend on whether your game's assets are arranged in the same way as TDM.

More specifically:

• Your game will need to read map data from the Doom 3 .map format. If it does not, there will be no way to save your map from DarkRadiant in a form that your game can access. Export to OBJ is available but if all you want to do is produce OBJ models then DarkRadiant isn't the right tool for the job (you should use a proper 3D modelling app like Blender/Max/Maya/LightWave etc).
• Your game assets will need a tree of .def files defining important entities to be placed in your map, including certain "fixed" entity types which are used directly by DarkRadiant itself. There will need to be a light entity defining light volumes, a func_static entity defining a static model, an info_player_start entity to define the starting position, a speaker entity to define sound sources, and probably several others. If these entity types are not defined, then built-in features like "Create light" and "Place player start here" will not work correctly.
• Your game will need a tree of .mtr files defining material shaders, referring to image paths which will be resolved to either uncompressed .tga files in a textures/ hierarchy, or compressed DDS files in a dds/ hierarchy. If these material shaders are not defined, no materials will appear in DarkRadiant. DR does not make any attempt to load "raw" image file hierarchies which are not referred to by material shaders.
• Your game will need to define a hierarchy of 3D models in ASE or LWO format. No other formats will show up in the model selector. These models can be stored directly on disk (there is no "model shader" tree required like with materials).

[datiswous]

55 minutes ago, OrbWeaver said:

Your game will need to define a hierarchy of 3D models in ASE or LWO format. No other formats will show up in the model selector. These models can be stored directly on disk (there is no "model shader" tree required like with materials).

I read @greebo stated obj is also possible, but it has to be specified in a config file..

Edited January 8, 2024 by datiswous

[HMart]

I agree with @OrbWeaver, IMO DR is not the right tool to make models for Godot or any other engine using triangle mesh's only, if anyone wants a simple and relatively easy 3D tool (but still very powerful in the right hands) to make models, I personally recommend Wings3D instead, is free as Blender, way less complex (no animation/bones support) and it supports obj, collada, and other formats.

Edited January 18, 2024 by HMart

[Skaruts]

Oh my, I completely forgot about this.

@OrbWeaver I actually got DR to work fine with png images and obj models.  Seems like it supports them fine, as long as the mtr files are correct. Greebo helped me out on discord.

Also got it to be compatible with Godot's importer plugins by exporting as Quake 3 format (as long as there's no complex geometry, like patches, etc, it seems to work).

 

The only reason I didn't keep using DR, is because DR doesn't seem to store the game's path properly. When you switch game setup, the path remains the same, so you have to manually set the path every time you switch project. 

I tried having separate portable DR installations for each project, but it seems DR isn't properly portable either, as the game setups are also stored globally. So that didn't work either.

Edited January 18, 2024 by Skaruts

[datiswous]

I wonder if you could use a sandbox for 2 portable editions.

Edit: I tried this with sandboxie and that works. But I read below it isn't necessary.

Edited January 19, 2024 by datiswous

[greebo]

16 hours ago, Skaruts said:

I tried having separate portable DR installations for each project, but it seems DR isn't properly portable either, as the game setups are also stored globally. So that didn't work either.

You can create shortcuts to DR, passing an fs_game=your_fm parameters to DarkRadiant.exe, e.g.

DarkRadiant.exe fs_game=fms/yourmission

It will override the setting saved to the user.xml file in your settings folder. Works with fs_game_base as well.

[Skaruts]

On 1/19/2024 at 10:00 AM, greebo said:

Works with fs_game_base as well.

I was just giving this another go, and it seems neither fs_game nor fs_game_base set the actual engine's path. This is the problem I was having before.

Looking at other game types in the drop down menu (in the Game Setup window), some of them show that fs_game sets the "Mod" (Mission ) and fs_game_base sets the "Mod Base", and not the "Engine Path".

(fs_game is actually useful for Dark Mod mapping, though, for working on multiple projects. Thanks a lot for that. )

 

What I really need is to launch DR with an engine path (and no Mod or Mod Base at all). 

Is there a parameter to do that? 

Edited February 20, 2024 by Skaruts

[Skaruts]

I took a look at DR 3.8 source code (not latest), and it seems to me it only ever checks for the fs_game and fs_game_base command line parameters.

[Skaruts]

So..., texture issues are being the only road block I'm having so far in trying to use DR with Godot, but I'm not exactly sure why yet. 

However, I've noticed when exporting maps in quake3 format, that the texture values don't match the ones in the editor.

This is the door face in the map file:

                                                                                 hs  vs  rot  hscale vscale
( 24 64 0 ) ( -24 64 96 ) ( 24 64 96 ) darkmod/door/wood/board_brown_nails_hinge 64 256 -180 -0.375 -0.375 0 0 0

The horizontal shift is the only correct value.

Is this a bug?

 

 

Edited April 11, 2024 by Skaruts

[OrbWeaver]

When you say the value is not correct, do you mean it actually gives wrong results in the Q3 engine, or it just "looks wrong" when examining the text file?

If it's the former, then that's arguably a bug (although supporting Q3 isn't top priority for DR). If it's the latter, then that doesn't really mean much at all — raw numbers in a map file don't necessarily correspond directly to values shown in the GUI, especially when transformations are involved (for example the -180 might be a rotation to match the default orientation in a particular engine).

[Skaruts]

I'm not using the Quake 3 engine, I'm using the Godot engine. The results seem ok, except when faces are slanted, but I'm not sure why it happens. I'm trying to find out. I don't know anything about the Q3 engine, so I'm not the one to say what's correct and what isn't about the map format. When I said "correct", I just meant that it's the same value that is displayed in the editor.

But there are differences between the Q3 format from DR and from other editors I've tested, like TrenchBroom and NetRadiant Custom. They keep the texture values as they are in the editor. One other difference is that DR exports entity brushes with coordinates relative to the `origin` spawnarg, for example. Though DR is also the only editor that enforces the `origin` spawnarg.

(I know there are two Q3 formats, and I'm using the equivalent one on all editors.)

I'm importing maps into Godot using a plugin. I've made some changes to it to accommodate for the differences in the map format and some editor specific stuff (e.g. DR uses "rotation" matrices instead of euler "angles").

Edited April 11, 2024 by Skaruts

[Skaruts]

Actually I think I found what's causing issues with my textures: DR changes the texture's Horizontal and Vertical Shift when a face gets slanted.

E.g., my test door is facing -Y and sitting flat on the ground, which is at 0 in Z, so the v-shift is 0. When I move the bottom vertices of the door 8 units forward, and then re-fit the texture, the v-shift turns to 4 (3.97241). If I do the same but backward, the v-shift turns to 90.7035. But these values depends on the distance the face is from the world origin, and sometimes if I move the top vertices instead, the values don't change. I can't make sense of it...

The other editors don't do this, so the plugin's import code doesn't account for it.

Do you think you could help me understand the logic behind this? If I could understand it, maybe I could get the plugin working with it. 

Edited April 11, 2024 by Skaruts

[datiswous]

21 hours ago, Skaruts said:

I'm importing maps into Godot using a plugin. I've made some changes to it to accommodate for the differences in the map format and some editor specific stuff (e.g. DR uses "rotation" matrices instead of euler "angles").

Could you store that somewhere? For example in Github. I'm learning Godot at the moment and might be interested in this in the future.

[OrbWeaver]

20 hours ago, Skaruts said:

Do you think you could help me understand the logic behind this? If I could understand it, maybe I could get the plugin working with it. 

I can certainly help to locate and identify the relevant code, but I didn't write it myself and I'm not really a maths guy so the help I can provide with respect to its logic might be limited.

[Skaruts]

5 hours ago, OrbWeaver said:

I can certainly help to locate and identify the relevant code, but I didn't write it myself and I'm not really a maths guy so the help I can provide with respect to its logic might be limited.

Might be worth a try.

I browsed the source code yesterday a little, but I had no idea where to even start looking for it. 

 

6 hours ago, datiswous said:

Could you store that somewhere? For example in Github. I'm learning Godot at the moment and might be interested in this in the future.

I've been building a sort of starter-project for it, but it's not public yet. But my support for DR is not ready for production or anything. Everything seems to work fine, except I'm having issues with textures, and tbh I'm not sure I'm gonna make it. I am about to make my repo public regardless of that, though, but I still need to get a lot of stuff in order. 

Meanwhile, if you'd like to move forward without DR, you could try NetRadiantCustom or TrenchBroom. Personally I recommend NRC (although TB might be a bit easier to start with).

The plugin I'm using is FuncGodot (formerly known as Qodot). It's currently the most recommendable.

 

Patches and NURBS aren't supported by any plugins yet, btw.

Edited April 12, 2024 by Skaruts

[OrbWeaver]

On 4/12/2024 at 3:29 PM, Skaruts said:

I browsed the source code yesterday a little, but I had no idea where to even start looking for it.

This appears to be the function which calculates the texture values for Q3 export:

https://gitlab.com/orbweaver/DarkRadiant/-/blob/master/radiantcore/map/format/Quake3Utils.h?ref_type=heads#L56

It's largely based on legacy GtkRadiant code and means absolutely nothing to me.

[Skaruts]

@OrbWeaverdo you think you could point me to the part of the code where vertex manipulation is handled?

Maybe by looking at it I could figure out how the texture shifting is calculated as a consequence of moving vertices around.