Design concepts for a material/resource editor

[OrbWeaver]

One feature often requested by DarkRadiant users is a graphical material editor, that would allow easy management of Doom 3 materials and textures. I have always resisted suggestions to add such functionality into DarkRadiant itself due to its primary nature as a consumer of Doom 3 resources, rather than a producer, but I think there could be a strong case for a standalone application for this purpose.

 

Here are some of my thoughts regarding the potential scope and design of such an application:

 

1. Code from DarkRadiant could be re-used, particularly in the areas of parsing and managing the hierarchy of materials, textures and skins. Separating such code into a library would be one option, although simple copying might be easier given the fairly static nature of this code.
    
   
2. Initial functionality might be to display the tree of materials and allow their properties to be inspected via a GUI rather than as text, for example using checkboxes for global keywords, a subtree of material stages (with stage GUIs) and so on. Previews of the textures could be shown in a suitable widget.
    
   
3. A distinction would need to be made between materials in editable files, and materials inside PK4s which are not easily editable. For editing an in-PK4 material, the options would be to either save an edited copy of the material outside of the PK4, or integrate functionality to update the file within the PK4 itself using ZIP tools.
    
   
4. More advanced (but potentially extremely useful) functionality could involve allowing external tools to integrate with the material editor, perhaps by invoking it with command-line options, or some form of inter-process communication. This would allow the further development of plugins for 3D applications such as Blender to allow Doom 3 materials to be directly accessed and applied to objects inside a 3D scene without the tedious process of editing and re-writing texture paths.
    
   
5. Taking (4) further might involve adding similar support for inspecting the model tree and allowing models to be edited with a chosen 3D application (likewise for skins). In this case the "material editor" would become a more general Doom 3 resource editor.
    
   
6. If starting a new application from scratch I would probably go for the Qt framework as a toolkit; I use this extensively at work and have concluded that it is in fact a lot more powerful than GTK as well as being a native C++ library rather than requiring C++-to-C bridge techniques. Qt's inbuilt support for sockets, IPC and the like could come in useful for point (4) above.
    
   
7. None of this functionality is in any way Dark Mod-specific, so the tool would be useful to the wider Doom 3 editing community as well as TDM mappers.
   

 

Just throwing some ideas out there, in case anyone has any comments or better suggestions.

[New Horizon]

Sounds extremely useful, and flexible.

[OrbWeaver]

Well it's not much so far, but I've create a project on Google Code and pushed some preliminary application code/widgets into the Mercurial repository:

 

https://code.google.com/p/darkresource/source/checkout

 

It will be interesting to see how Google Code compares with SourceForge for project hosting. It certainly seems cleaner and faster so far.

[rebb]

Good idea, reminds me a bit of Q3ASE from Quake3 Times, it's actually kinda strange that something similar doesn't exist for Doom3 yet.