[Gtkradiant] Loading shaders with non-standard names

Joseph, William WJoseph at europe.ea.com
Wed Jan 19 08:15:00 CST 2005

Hi Nathan,

Almost all of the systems in 1.5 use the full shader name when dealing
with materials and do not require the prefix. The few exceptions to this
rule are the surface-inspector enforcing the prefix when applying
textures, the texture-browser only displaying shaders that have the
prefix, and the sanity checks on material names in the brush/patch code.

I'm planning to make the 'textures/' prefix optional for shaders applied
to brushes/patches because Doom 3 does not require it. I guess it should
check for the 'textures/' prefix only in game-modes that do require it.
This requirement would be specified by a 'texture_prefix' option in the
.game file.

If you want to make this change in the 1.5 codebase and send us a patch,
that would be welcomed. Otherwise, I'll be doing it fairly soon.


-----Original Message-----
From: gtkradiant-bounces at zerowing.idsoftware.com
[mailto:gtkradiant-bounces at zerowing.idsoftware.com] On Behalf Of Nathan
Sent: 19 January 2005 13:01
To: gtkradiant at zerowing.idsoftware.com
Subject: [Gtkradiant] Loading shaders with non-standard names

Hi all,
I'm in the process of trying to get Radiant ready for a new game of
ours (new project files etc), but we're running into an issue with
material/shader loading. The game is running a different engine, and
we'd like to be able to name our materials in a different system (eg,
terrain.grassy1 instead of /textures/terrain/grassy1 ).

Radiant of course won't accept such a name because it can't find a
corresponding texture file. For namespacing reasons, we'd like to be
able to use our naming system for materials, and avoid having to go
down the /textures/whatever path (pun not intended).

So we're considering just patching Radiant in-house to load materials
(shaders) with unacceptable names if they have a valid use of the
qer_editorimage keyword.

Would this be the easiest way? Would it be an acceptable patch (we
don't particularly want to have to maintain a patch in an (what is to
us) unfamiliar codebase against new Radiant versions), or are there
good reasons that this isn't implemented?

- Nathan

Gtkradiant mailing list
Gtkradiant at zerowing.idsoftware.com

More information about the Gtkradiant mailing list