DDS Texture discussion

[Springheel]

Actually, I think I goofed. I was thinking about the *models* being five layers down, but the textures should be ok.

[greebo]

So what are we heading for? Should we tighten the folder structure and move the tiling_1d/nontiling files one folder upwards?

[SneaksieDave]

Sounds like that will probably be the best solution to this conundrum. No answer from the boyz at id yet.

 

Perhaps the tiling folder status of the affected files should have that in the name, while the tiling-2D ones stay as they are?

[greebo]

The information is already in the shader name to facilitate mapper's choice, do we need it in the filename as well?

[SneaksieDave]

Good question... guess it depends on how consistent we want it. Neither way is 1:1 consistent (since now things would be in editor folders but not HD folders), but having them reflect it in the filename as well at least gives a user the information at a glance, when looking at the HD files. I'd lean toward yes, myself.

[greebo]

I'd lean towards no. We need a third opinion, I reckon.

[sparhawk]

I don't see a reason why the HD layout must reflect the editor layout. The important point is to have a strict rule how to name the textures and where to put it. And from this, if you have the name in the editor, you can easily find the texture in the directory as well, because we HAVE such a rule in place. There is no need to keep it on a 1:1 basis and in fact for browsing the textures directly, outside the editor, the falt structure is even more usefull.

[greebo]

Well, I think we already agreed to flatten the physical folder structure, but keep the virtual shader hierarchy as it is now (we did agree, didn't we, I hope I don't rush things too much here?). The question is whether we want to have the "nontiling" and "tiling_1d" strings attached to the filenames or not (for all the files we move out of the tiling1d/ and nontiling/ folders).

[sparhawk]

Sorry, I missunderstood. I think it should be kept. The information is now there, and it is usefull, so why discard it?

[Springheel]

I don't think we need to rename the files yet again, just to add the tiling designation. First of all, the names are already quite long, and adding yet another descriptor could start pushing things too far. Secondly, it's really only when you're about to use a texture *in the editor* that the tiling info matters. And that is already covered by the shader name. I'd vote against renaming.

[sparhawk]

I have no problem with that. On the other hand, when you look at textures for modelling it might be usefully, but then again, I guess modell textures will more rarely need to repeat anyway, because they usually have a smaller surface. And in worst case you can always look in the editor if you really need a tiling one. I just wanted to say that we don't neccessarily need to drop that information.

The length of the filename is mostly irrelevant, because most people will never see it anyway.

[greebo]

If we do the renaming/moving via script, I guess there will be problems, because the shader name looks currently the same as the diffusemap (e.g. "textures/darkmod/stone/flat/tiling_1d/whatever"). If the script works via find & replace, the shader name is going to be renamed along with the diffusemap, which will have to be prevented.

 

@sparhawk: What do you think is faster, writing the script catching this case and debugging it or doing it manually for all the affected shaders?

[sparhawk]

I have a lready written a simple parser which can detect the shadernames, so this is not a problem. I can adapt it to replace only lines contained within a shader. I needed this for the reorg anyway, because I needed to know which was a shadername and which was a texturename.

[greebo]

That's fine, so we can do most of the work via the script.

[sparhawk]

Yep. We only have to check for errors, but that we need to do anyway.

[greebo]

So, what's the word on the filenames? Do we want the tiling_1d or nontiling suffix attached or not? I can live with either decision.

[sparhawk]

Yup. I'm only waiting for the decision, as I can also live with it, one way or another, and for the script it doesn't really matter.

[Springheel]

I don't know. I voted for not attaching them, so it looks like we're 2v2 for the people who have spoken up.

[greebo]

Before we're stuck here, let's say we attach the information, as we can always discard it later.

[sparhawk]

Ok. I think this is the better decision.

 

I think we should mention this limitation also on the WIKI. Do we have a page for known pitfalls like this?

[greebo]

No, there's no page like this. We've got the "Serious Design Problems" in the information forum, but I think this DDS issue is of a more technical nature.

[SneaksieDave]

I'm fairly disappointed that id haven't replied. I know it was a longshot in the first place, but I used my "real" email, so it wouldn't be seen as spam or filtered, I included the topic in the subject, and this seems like a real bug. Who knows, maybe it'll be addressed in a patch. Then again, maybe my mention of TDM was the downfall... the team has collectively said many times that Doom3 sucked as a game, so I wouldn't be surprised if we're getting the blow-off.

[Springheel]

the team has collectively said many times that Doom3 sucked as a game

 

I don't think the team has ever 'collectively' said any such thing.

 

I think it's far more likely that they're too busy with new projects to respond to questions raised about a game they released three years ago than the possibility that they regularly read our public forums and were personally offended by the occasional isolated comment from individual team-members that they didn't think much of D3 as a game.

[sparhawk]

Also I doubt that Id puts that much into the opinion of individual gamers. They know what modders are worth and that not everybody will like the game, but they are more on selling the engine anyway, and the modding helps with that.

[greebo]

@sparhawk: let me know when your script is ready for takeoff. I will have time to convert the textures to DDS over the weekend, so it would be cool if we could move the files before that.