Texture tree depth - avoiding clutter?

[Melan]

Here is an issue I have been thinking about for a while, and on which I would like to solicit input from the team and others. Unlike Thief, where textures were stored in the form of pallettised families in discrete folders, TDM sorts them by material categories and more specific subcategories. For example, the stone category looks like this:

>stone/cobblestones (for rough, uneven blocks or flagstone textures)

>stone/brick (for regular, rectangular bricks of any size)

>stone/natural (rock walls, cave surfaces, gravel)

>stone/flat (cement, marble, ceramic tiles, anything basically flat). Polished surfaces get the prefix smooth_.

>stone/sculpted (for tiles or surfaces that have been intentionally sculpted or carved)

 

...and there are also editor-exclusive virtual categories such as >>nontiling and >>tiling_1d.

 

As long as we are working with the core TDM package, which mostly includes textures for general use (such as generic walls and a few trims), this setup works nicely. However, as the mod expands, and more textures are incorporated into both the core and added by individual users, this structure might become overloaded -- as is, I am already scrolling a bit too much in the "brick" and "sculpted" category to find a specific thing I am looking for. There are textures which are always good to have on hand; others are probably used judiciously in some maps and not so much in others (e.g. a nice geometric trim), while some could be so specific that you would only use them in every fifth or tenth map, and then only once or twice (e.g. the bas-relief below - looks great in game at a higher resolution, but you wouldn't plaster every mansion with it - in the texture pack I am working on, there is also a collection of shields that's pretty cool for variety, but it's already 8 textures with probably more to come).

 

I am thinking that it would not be a bad idea to eventually introduce some further subdivisions for textures that are good to have on hand (and I certainly think these give a map much of its soul) but if your editor were a worbench, you would keep them on a top shelf and only reach for them every so often. For example, staying with >stone/sculpted , >>trims and >>panels might be an obvious addition, but could "overflow" just as easily as any other shader category. Adding special categories such as >>shields, >>reliefs or >>architecture, although the team might believe these to be too narrow or maybe even confusing.

 

I would like to hear what people think of this -- it is not an immediately pressing issue, but could have some important repercussions on the future state of TDM editing. Remember that it is possible to store textures just fine in the base folders -- it is the arrangement of the shaders in the Media Browser that matters most, and they can be placed under virtual categories.

[Tels]

There is a technical limitation of 5 folders depth in Doom3 that is because D3 won't load DDS if they are deeper than that. I don't know what they were smoking at id when they came up with that idea, but we have to live with it...

[Melan]

Does that mean physical folders or virtual (Media Browser) folders as well? What I meant to point out was a matter of organisation; the "real" location of textures may or may not be relevant for this.

Edited May 17, 2010 by Melan

[Tels]

Does that mean physical folders or virtual (Media Browser) folders as well? What I meant to point out was a matter of organisation; the "real" location of textures may or may not be relevant for this.

 

Hm, interesting. D3's limit is physical. I am note sure if it is possible to have a different virtual folder sep. from the physical. It is possible for entities, so maybe it is also possible for material shaders. "editor_displayFolder" "foo/bar" is the keyword to be added in the definition if you want to try it

[OrbWeaver]

The paths used in material shaders are purely virtual and do not need to correspond in any way to the physical paths of image files (although they often do for organisation reasons). I do not know if there is any limit on the depth of virtual folders though.

 

The editor_displayFolder key is only used to categorisation of entities, not material shaders which have the path specified as part of their name. There should not be any limit on the depth allowed with editor_displayFolder.

[rich_is_bored]

It's also possible to add a description to each material. This field could be populated with tags and the editor could be made to search or filter the list based on those tags.

[OrbWeaver]

Yes, that description string is used by the mod code to set the material impact sound, IIRC. Of course the format could always be changed to support a list of delimited tags as you suggest, including some for the editor.

 

I've also wondered whether it is possible to add arbitrary "qer_blah" global keywords to material files, and have Doom 3 ignore them. Provided the game doesn't choke these keywords could be used to set editor properties as well.

[Melan]

I have just tested using a different path in my material file, and it works - the only thing that needs to be added is a subfolder in the line before the curly bracket, and DarkRadiant automatically creates the appropriate subcategory (in the case below, "shield"). It also works in game, as attested by the included screenshot (note, the textures represent fairly degraded stonework).

 

The main question that remains is what people in the team think the subcategories ought to be - material files are easy to change, but it would be nice to hear something official.

 

 

textures/darkmod/stone/sculpted/ shields/ornament_shield_white_lionsalient

{

stone

 

qer_editorimage textures/darkmod/stone/sculpted/ornament_shield_white_lionsalient_ed

diffusemap textures/darkmod/stone/sculpted/ornament_shield_white_lionsalient

bumpmap textures/darkmod/stone/sculpted/ornament_shield_white_lionsalient_local

 

{

if ( parm11 > 0 )

blend gl_dst_color, gl_one

map _white

rgb 0.40 * parm11

}

{

if ( parm11 > 0 )

blend add

map textures/darkmod/stone/sculpted/ornament_shield_white_lionsalient

rgb 0.15 * parm11

}

 

// TDM Ambient Method Related

{

blend add

map textures/darkmod/stone/sculpted/ornament_shield_white_lionsalient

red global2

green global3

blue global4

}

}

 

 

[Fidcal]

It's important to realize that although you can add new materials like this, we cannot change existing ones without breaking existing maps. So we cannot for example, re-organize say, all rusty metals into their own folder but you could put new rusty metals into a rusty folder which is possibly more confusing to have some there and some in the main folder. What can be done is to copy some existing ones so they are present in both.

[OrbWeaver]

As a mapper you can use whatever organisation scheme appeals to you for your custom textures, without regard to any default schemes used by the core mod. If the textures are incorporated into the main mod this would obviously have to change, but given the size of the mod already I think it would be better for mappers to use custom textures that are required by their maps, rather than expand the core distribution to a huge "everything anybody might want" set of assets.

 

Another options would be to distribute asset expansion packs that were suitable for certain settings, such as the "mansion pack" or the "caves pack". Mappers could then specify these expansion packs as a pre-requisite and rely on all their contained assets being available without having to have a huge core mod.

[Melan]

Fidcal: Sure. That's why I brought the issue up now.

 

OrbWeaver: The problem in this case is that CGTextures doesn't normally allow the distribution of their assets in the form of texture packs, but has a permission for levels and full mods. To distribute new textures, I can either make everybody wait until I can build a level that uses them all (in which case everyone who uses my textures will have to incorporate that extra 10-15 MB they need to use at a time), or submit them to the team and let them select. I am on the opinion that the mod library could use more assets, and more specific ones in addition to basic materials.

Edited May 17, 2010 by Melan