Moar textures:

[Bikerdude]

I'll send them to you this weekend if you like!

Sliptip has kindly offered to share a bunch of textures with us that he will be using in his Thief 1.19 wip project' date='

 

Download link - Its dosen't contain all the textures, as a lot of them were too low res for use in TDM, I will update the demo map as I get better replacements.

 

[AluminumHaste]

Very nice, I'm assuming they will need spec and normal maps though.

[Bikerdude]

Yup, I will process them for use in TDM. Here are screenshots of the textures, some of the smaller ones(256*256) I will quad up and make tile-able in gimp.

 

 

[grayman]

Well, I think I just found the color palette for my Builders' mission.

 

Good job, Biker, as usual.

[grayman]

Is it reasonable to provide these with a theme name, so they stay near each other when looking them up in DR?

 

f.i., ST_this, ST_that. (ST for Sliptip.)

[STiFU]

Hmn, that basically goes against our long used naming conventions for textures. We are supposed to start the texturename with the term describing the material, for instance "plaster", which makes sense if you search for plaster...

[ungoliant]

is the rust used for the gears in the other shot anywhere in this package?? I can definitely think of some uses for that.

[grayman]

Hmn, that basically goes against our long used naming conventions for textures. We are supposed to start the texturename with the term describing the material, for instance "plaster", which makes sense if you search for plaster...

 

Rats. So these textures will end up getting scattered across the texture tree.

 

So much better to have tonal groups of textures that go well together--or were even designed to be used together--easily found in one place, next to each other.

[Bikerdude]

is the rust used for the gears in the other shot anywhere in this package?? I can definitely think of some uses for that.

no idea, as I haven't seen Sliptips t2 mission that uses them.

 

Rats. So these textures will end up getting scattered across the texture tree.

I can make a material file just for you if you like..?

[ungoliant]

I think both ways can be accommodated. A new "theme" tree could be added that points to the exact same source material as the existing textures, but groups like-themed textures together.

for example, all red-brick, all grime, all foliage, and then the stuff like "abandoned factory" type themes

Edited October 6, 2012 by ungoliant

[STiFU]

Rats. So these textures will end up getting scattered across the texture tree.

 

So much better to have tonal groups of textures that go well together--or were even designed to be used together--easily found in one place, next to each other.

I totally agree, but still, we shouldn't mess with the system at this point or we'd have to do it somehow for all textures. Taging materials would be a compatible solution and also very flexible. But for that, we need the code-support first.

[Springheel]

So much better to have tonal groups of textures that go well together--or were even designed to be used together--easily found in one place, next to each other.

 

It would be nice if we could somehow categorize things by theme. Not sure how to do that at this point, however.

[Bikerdude]

It would be nice if we could somehow categorize things by theme. Not sure how to do that at this point, however.

AS Stifu is having a look at some of DR's bugs maybe he could look at this..?

[Melan]

It would be nice if we could somehow categorize things by theme. Not sure how to do that at this point, however.

Theoretically, it could be done. We can change the place textures are found in DarkRadiant without changing their physical location in the PK4 files. It is a question of editing material files. The issue is that TDM established a standard in its early versions, and has so far stuck to it. Will mappers be annoyed if someone goes through the texture tree and rebuilds it according to a new scheme?

 

Personally, I would have preferred something better divided from the beginning, since it takes time to scroll through stone/brick to find just what you are looking for, and the problem increases with more textures. But changing it now is a pretty big thing. I don't think we have to emulate Thief's texture families either, but if there is enough will for a massive change, increasing the depth of the texture tree by one increment may be a project for a later version.

[STiFU]

That's highly problematic as far as compatibility to existing FMs is concerned, Melan. We'd have to ensure that the old virtual paths to textures are still in place, while also creating a new virtual path structure that makes somehow more sense. After all, D3 / TDM also uses the paths specified in the material definitions and not their absolute paths, as far as I know. I guess the best way would really be to have meta information in the form of tags stored in the material definition files. Those tags could be further childs in the texture tree then, rather than actually expanding the texture tree.

 

@Biker: That's quite the huge feature. At the moment I am only looking at smaller fixes, because I really don't have so much time for coding these days. However, we can discuss this here and once we found a good solution, we can add it as a feature request to the bugtracker.

[AluminumHaste]

Well seeing as how textures are already sorted by their material def, I see no reason an extra set of definitions could be added for each texture to give it an alternate layout.

For example, the texture defined at: textures/darkmod/stone/brick/blocks_brown, could have an alternate definition in the same mtr file that puts it in a category called "dark wall textures" or something like that.

And when you go to the Media browser in Dark Radiant you would have 2 buttons at the top. 1 for standard layout, and 1 for category or family layout.

 

The problem with this of course is that every single texture would have to be retagged in the various mtr files. And it would have to be done in an intelligent way so that the families or categories of textures make sense, so that means I'm out lol.

 

There are drawbacks and advantages to each approach of course. I could remember in the DromED days that I would remember seeing a carpet or wall texture in the OM, and would have a horrendous time trying to find it in the texture families. And I remember wishing that all wall textures would be listed as "wall" and floor as "floor" and carpets as "carpets" etc etc. Which is kind of what we have in Dark Radiant.

[STiFU]

Well seeing as how textures are already sorted by their material def, I see no reason an extra set of definitions could be added for each texture to give it an alternate layout.

For example, the texture defined at: textures/darkmod/stone/brick/blocks_brown, could have an alternate definition in the same mtr file that puts it in a category called "dark wall textures" or something like that.

Multiple definitions of every texture? That's bound to get messy. Everything you change something on your texture, you'll have to remember to change that on the other definition as well. That will get out of hand pretty fast, I imagine.

[Bikerdude]

I think you guys are loosing the jist...?

 

In my mind we keep the directory structure as-is, but create a custom " play list " for want of a better word, that lists all the textures in DR the way we want etc

 

@ Stifu, is this doable do you think..?

[Springheel]

that lists all the textures in DR the way we want etc

 

How do you imagine this working?

[Bikerdude]

How do you imagine this working?

The same way a playlist works..? Once the user has created thier 'playlist' which can then be exported that list etc.

[Bikerdude]

Regarding texture creation I have now learned all the basics, so am going to make a start on Stiptip's pack.

[Springheel]

The same way a playlist works..?

 

Playlists work in lots of different ways. Were you just thinking of someone manually selecting individual textures to show together in a list somewhere, or a series of pre-made categories of textures?

[STiFU]

The same way a playlist works..? Once the user has created thier 'playlist' that can export/backup that list etc.

Hmn, that's actually not a bad idea and wouldn't leave us messing around in the material files. Think about it as Themelists. We just give the theme a certain name and add our predefined materials to it. The theme name could be a virtual folder structure, just like the material definition names, e.g. "houserooms/bathroom/luxurious/dark".

[Bikerdude]

Were you just thinking of someone manually selecting individual textures to show together in a list somewhere, or a series of pre-made categories of textures?

Either, if someone sat down and made a bunch of playlists these could be added to DR as presets I imagine.

[Bikerdude]

Regarding texture creation I have now learned all the basics, so am going to make a start on Stiptip's pack.

of the two folders of textures ST gave me, one of them is unusealable as all the textures are in 256*256, so have asked him if he has higher res versions.

 

Regarding the remaining folder, the textures range from 512*512 -to- 2048*1024 and this is what I have been doing thus far:

• some of the textures were already good and needed nothing doing to them
  
• the majority needed cloning and making tile-able, which was done via gimp's offset and clone tool functions
  
• and some of them were just low res clones that needed a lot of work to get them upto usable for TDM.
  

once I have cleaned them all up, I then crack on with the next stage of creating the normal/specular maps.