DDS Texture discussion

[Springheel]

I tried it with a texture in textures/darkmod/stone/flat/smooth/tiling1d and got the same results.

[greebo]

I get a bad feeling about this.

 

If this is actually related to the folder depth we can either change our folder structure (again!) or don't use DDS textures (at least not for the "deeper" textures).

[Springheel]

I'm not excited by reorganizing the textures yet again....

[greebo]

Me neither, believe me.

 

We could go with a compromise and convert those textures to DDS that are working properly (which implies they must not be moved to deeper folders in the future).

 

Or we could skip the DDS conversion, which would be a bit of a shame, because they only use a third of the disk space.

 

How much chance is there to get support (or at least an answer) from iD software about this?

[Ishtvan]

Argh, we might have to if this is something we can't change. People are definitely going to want to use DDS textures, and it's not that difficult in principle to come up with an organization scheme that doesn't require 5 layers of folder. It's stupid on D3's part, but what can you do.

[sparhawk]

Seems it was not such a bad idea from me, to keep the hierarchy flat, and use the filenames instead.

[greebo]

Five levels is not very much, given that textures and darkmod already takes two.

 

I'm wondering what might be the cause for this, as it works fine for TGA textures. I'll have a try and add a really "deep" TGA texture, maybe the dds/ prefix counts as well.

edit: Nope, I could load a TGA texture with 7 levels fine.

 

Or maybe I'm (we're) doing something wrong?

[Springheel]

So that would mean all the tiling1d and nontiling folders would have to be moved/renamed, among others. I'm not sure how you could move those up a level and still have a meaningful folder structure. And restructuring things in a different way at this point is a project I won't be signing up for.

[greebo]

The "darkmod/" is not droppable, I reckon?

[sparhawk]

If we want to get rid of the tiling directories, that should be much easier, because it can be done completely by scripting. No need for manual renaming. Also, I have explained this before. The directory strcuture does NOT need to match the DR hierarchy, so we can still have tiling as part of the name and make it a branch in the tree in DR, because they are unrelated.

[Ishtvan]

It would be a bit weird to have D3Ed and DR treat texture names completely differently though. If you had to briefly go into D3Ed to do something that DR couldn't do, and had to work with textures, all of a sudden the names and organization would be different.

[greebo]

I think there's a misunderstanding. DarkRadiant and D3Ed treat the shadernames equivalently, no worries.

[Ishtvan]

I was responding to what Sparhawk was just suggesting:

I have explained this before. The directory strcuture does NOT need to match the DR hierarchy, so we can still have tiling as part of the name and make it a branch in the tree in DR, because they are unrelated.

 

As I understood it, the suggestion was to change the DR system so that it could parse part of the filename into a different branch in the browser directory structure. That is fine for DR, but would confuse people IMO if they switched to D3Ed to do something and saw a different texture structure because it wasn't parsing the filenames like DR.

[SneaksieDave]

Or maybe I'm (we're) doing something wrong?

To reiterate that: before doing anything rash, are we sure there isn't something else going on? Case, punctuation, explicit extension? I've gotta try some things. This is a really stupid bug/limitation on id's part if it's really that.

[OrbWeaver]

I was responding to what Sparhawk was just suggesting:

As I understood it, the suggestion was to change the DR system so that it could parse part of the filename into a different branch in the browser directory structure. That is fine for DR, but would confuse people IMO if they switched to D3Ed to do something and saw a different texture structure because it wasn't parsing the filenames like DR.

 

I think he is suggesting that the material names could retain their folder structure even if the actual image paths on disk were changed to get around this limitation, not that DR should do something special here.

[sparhawk]

I was responding to what Sparhawk was just suggesting:

As I understood it, the suggestion was to change the DR system so that it could parse part of the filename into a different branch in the browser directory structure. That is fine for DR, but would confuse people IMO if they switched to D3Ed to do something and saw a different texture structure because it wasn't parsing the filenames like DR.

 

That was not what I said. I said that the shadernames and directory paths are totally unrelated. Thus we don't need to put tiling into the path AND the shadername for a given texture.

[sparhawk]

I think he is suggesting that the material names could retain their folder structure even if the actual image paths on disk were changed to get around this limitation, not that DR should do something special here.

 

Correct. I was already proposing this before the reorg, but was turned down, because some felt that the directory should match the shadername, which I don't see any reason for.

[greebo]

@SneaksieDave: Please have a try and see if you can reproduce that and confirm this issue, this would be appreciated.

[SneaksieDave]

greebo: Unfortunately, I also was able to confirm your findings.

 

So is the assumption that Doom3 does not handle DDS files nested 5 or more folders beneath /dds ? WTF. Is there any logic behind that at all, why this would or could be the case? I also tried length and it didn't help.

 

If worse comes to worse, the best option is probably to go with flattened structure for the files themselves (e.g., we get rid of /tiling_1d, /nontiling file folders) and keep the in-editor structure the same, to get the nice sorting and the slimming benefit of the DDS files over TGAs. It's not the end of the world, but damn it sure would be nicer to have 1:1 relationship between filename and material definition.

 

I still really want to know what's behind this though... I believe a letter to id might get a reply, especially if/because this is a rather significant and arbitrary bug/limitation.

[greebo]

Has anybody ever had contact with iD support? Is it likely that they would still answer regarding D3 issues (the game is 3 years old after all).

[SneaksieDave]

Just sent an email to brian@ and johnc@. I've gotten an email reply from johnc one time, but it was 10+ years ago. I remember I was asking him about the fact that quaketest had nonsolid skies (rockets would just keep going) but the 1.0 release had solid skies. His response?

 

"Yeah, I fucked that up..."

[greebo]

 

Regardless of what the answer to the mail will be (if there is one), we should agree upon an alternative strategy. Even if we get an answer, a fix is not very likely to arrive in a matter of weeks or months.

 

Is the flattening of the folder structure an acceptable way to go? Sparhawk could do it with a script and I'd be willing to go through the repository to fix any weirdness that may come afterwards.

[Springheel]

Just to throw it out there, this will also keep us from using .dds textures for the majority of our models. I don't know if we were planning on doing that or not, but about half of them are 5+ folders down.

 

I don't have a problem with moving the separate tiling folders up one level (and just keep them separate with the material entry name). How many other folders is this a problem for?

[SneaksieDave]

Oh crap. Are they though? I thought they were basically all (maybe exceptions... not sure)

 

/dds/models/darkmod/props/textures

 

Which is 4-deep below /dds. I have the bell textured with DDS in there, and it works.

 

 

Edit: Ah, you mean characters for instance? I believe they might be 5+. ARGH.

[greebo]

From what I see these folders are affected:

 

all nontiling and tiling_1d folder under...

 

.../dds/textures/darkmod/metal/detailed/*

.../dds/textures/darkmod/metal/flat/*

.../dds/textures/darkmod/metal/grate/*

 

.../dds/textures/darkmod/nature/dirt/*

.../dds/textures/darkmod/nature/foliage/*

.../dds/textures/darkmod/nature/grass/*

.../dds/textures/darkmod/nature/snow/*

 

.../dds/textures/darkmod/stone/whatever/*

 

.../dds/textures/darkmod/wood/boards/*

.../dds/textures/darkmod/wood/panels/*

 

This is for the regular non-model textures only. The models/darkmod/props/textures folder is ok, so the heavy part can be converted without problems (460 MB in one folder!).

 

I'd say we don't care too much about the other model textures, because it doesn't weigh as much as the textures/ and models/darkmod/props/textures.