The Texture Chopping Block

[SneaksieDave]

Recent discussion on texture submissions has me wanting to put this out there, something I've been meaning to post for a short while. I have a proposal intended to increase the quality ratio of the texture library, one of the two big problems facing this department at this time (the other being the reorg). I spoke with Gildoran about weeding the repository a bit some months ago, but we didn't get down to it yet. Also, this way it's more of a team process. I am suggesting the following system:

 

1. Any person finds a texture in the repository they think does not belong there. They nominate it for the Chopping Block. They present reasons for why they think it should go. Reasons can be many and varied, for example:

 

- it's just plain ugly

- it's very low in quality / resolution

- wrong dimensions / violates guidelines

- it's useless or has little to no practical use

- it doesn't add anything new to the repository / textureXX already does this better / waste of mod size

- etc

 

2. The team considers the texture and decides its fate. If anyone (other than the author(s)) raises an objection, the texture stays.

 

- A texture could stay, but still need fixing. If a person raises an objection to retain the texture, they should probably be prepared (or at least willing) to have the responsibility of fixing it.

 

 

So basically, it isn't a powerplay type of game where we can mass eliminate a hated enemy's textures. It is a simple system whereby we can get rid of stuff that everyone agrees doesn't really belong, while disagreement sides in favor of retaining the asset.

 

You ask, why not just have one person / some lead decide all of this? Should any one person make such far reaching aesthetic decisions? I'd personally say definitely not. You ask, is all of this really necessary? Again, in my opinion, most definitely. Take a look at some of the (especially very old) materials in the repository and use them in maps, examine the normalmaps, etc., and compare/contrast with high quality texture games - Doom, Half-Life, FarCry - even some of today's Thief2 FMs.

 

Thoughts on this? Remember this can also be used as a deciding process on what goes into the mod in the first place (when there is contention; though perhaps additions (as opposed to removals) should require more than one vote). I think this will be an effective way to remove slag from the repository, add true quality to it, and let everyone's eye play a role in doing so.

[SneaksieDave]

In the merging mayhem today, it seems some of the posts actually pertaining to this thread were moved as well. If they could be move back, it would be great, but if not or in the meantime:

 

First nomination (for example as well) - stone/floor/blocks_005:

http://forums.thedarkmod.com/index.php?s=&am...st&p=109547

Please respond here only, so as not to derail the other thread.

 

1. It is very strongly lit from the top. This is to be expected sometimes in textures, but this one is over the top. Note where the light in the picture is located, yet the shadow is on the bottom - that's because the shadow is in the diffuse.

2. It has a very poor, almost non-existant normalmap. The image on the right has r_skipbump 1. See the big difference?

3. Ugly and technically poor. It its current state, it no-way, no-how belongs in the TDM texture library. Of course no offense to any author(s) (unknown) but it is not up to date or standard.

 

At this point, whoever (other than the author of course) objects to deletion simply says so, and the texture stays... but it needs fixing badly, and that person should be prepared to do so.

 

So far only OrbWeaver has responded, and in agreement. Does anyone see saving grace in this image? (no time limit pressures, just looking for opinions - that's what this is supposed to be about afterall).

[sparhawk]

It is also usefull if you can scan our maps if we used this texture somehwere. If we are oging to delete textures, then we should know which ones are to be replaced if they were already used. That's why the mappers should also have access to this thread, because they might have already used some of the textures.

[greebo]

@SneaksieDave: I do agree that it looks not phenomenal, but it's not hopeless. It should definitely go, but I would suggest to actually moving them from the repository into some kind of "texture cemetery" where they can be resurrected from. Should we create another repository for such things?

 

As for the maps: There are quite a few garbage maps in our darkmod/maps/ folder which should be removed entirely. I don't think that it's a huge problem if a texture goes missing, as these are testmaps in the first place. Just apply any other texture, for testmaps it doesn't matter.

 

We could create some sort of "Textures Removed" thread where the deleted textures are "announced". Beta mappers who used this texture can still retrieve it from the repository and include them independently in their PK4 if they really insist in using this crappy texture.

[SneaksieDave]

Yes! Now we're talkin. I was going to make a suggestion of "unofficial" or some kind of side repository (cemetary is good ), so nothing is really destroyed, just maybe set off to the side in case we need or want to resurrect it later. Great idea.

 

Fully agreed about the maps as well. They're testmaps at this stage, some breakage is to be expected.

 

Whether or not to open the chopping process to the betamappers is up to the team I suppose... I've got mixed feelings, some good will certainly come of it, but some difficulty (argument) might as well.

[sparhawk]

Textures on SVN are not deleted anyway, so why move them to a seperate repository?

[OrbWeaver]

The advantage of moving them is that it reduces the size of the download when checking out the main mod. It would be better to move them to another branch in the same repository rather than a completely new repository however, because this would allow a lightweight "svn copy" rather than an actual data copy.

[Springheel]

There are certainly some maps that could use culling too. Several in there I don't even know where they came from (that Kanasarka (sp) one?) And others are so out-dated they're not likely to ever be used again (Aitest 1 &2, the various Hauntcity copies, old inventory test-map, etc)

[greebo]

I will take care of those maps.

[sparhawk]

There are certainly some maps that could use culling too. Several in there I don't even know where they came from (that Kanasarka (sp) one?) And others are so out-dated they're not likely to ever be used again (Aitest 1 &2, the various Hauntcity copies, old inventory test-map, etc)

 

That was my attempt at starting a real map. I don't think I will ever finish it though.

[SneaksieDave]

So any word on what we do with the removed textures? I'm not sure of the distinction, new repository, same repository/different branch, but the objective is that we can still sync to the mod without automatically grabbing these as part of the download; the user would have to purposely get them to use them (say, to work on improving them, or incorporate them into their own map - kinda like the betamapper folders).

[sparhawk]

It would be more effecient, to copy the texture to a new new branch (like cemetary) and then delete it. Not sure if this works in SVN as I think it should. Mabye Orb knows about it. Can we keep a file alive in one branch, but not in the other? Creating a new repository would mean that the textures are physically copied, thus occupying twice the space, because they will be still available in the old repository as they are not physically deleted.

[OrbWeaver]

It would be more effecient, to copy the texture to a new new branch (like cemetary) and then delete it. Not sure if this works in SVN as I think it should. Mabye Orb knows about it. Can we keep a file alive in one branch, but not in the other?

 

Yes, a copy followed by a delete is exactly what is needed, although user-friendly clients support this as a single "move" command. When you "delete" it from the main branch, nothing is actually removed, it just means that the file is no longer visible from that revision onwards and will not be checked out in future.

[greebo]

So, the solution would be to create a new branch "cemetery". How can single files be moved into an existing branch? (I obviously haven't done this before.) Given the case we have textures/darkmod/stone/floor/blocks_005.tga and we want to get rid of this?

[OrbWeaver]

So, the solution would be to create a new branch "cemetery". How can single files be moved into an existing branch? (I obviously haven't done this before.) Given the case we have textures/darkmod/stone/floor/blocks_005.tga and we want to get rid of this?

 

I don't recommend "cemetery", it looks too like a texture category.

 

The operation would be something like

 

svn copy https://darkmod.homelinux.com/svn/darkmod/trunk/textures/darkmod/stone/floor/blocks_005.tga https://darkmod.homelinux.com/svn/darkmod/branches/deprecated_textures/
svn delete https://darkmod.homelinux.com/svn/darkmod/trunk/textures/darkmod/stone/floor/blocks_005.tga

[Springheel]

Will SVN automatically delete the file from our local folders, even if we don't download the new "dead texture" repository?

 

(Also, for completeness, we should also consider moving the mtr entries for the textures to a seperate file)

[OrbWeaver]

Will SVN automatically delete the file from our local folders, even if we don't download the new "dead texture" repository?

 

It will get removed when you next do an svn update on your working copy, yes.

[sparhawk]

Ok. So this sounds a like a solution then. What I still don't get though is, if I create a branch, it is essentially a snapshot of the current revision. So I do the following steps:

• Create the branch "Texture RIP"
  
• Delete the texture A in "trunk"
  

Right? So I will have a copy of trunk in texture RIP and in trunk the texture is dead, while in the branch it will be still alive. That's understood. What I don't understand is the next step though.

 

So next we want to delete texture B. The branch already exists so what do I do now?

[*] Create the same branch "Texture RIP" again?

[*] Delete Texture B in "trunk"

 

But this souldn't work. If I create the same branch again, then it would take the snapshot form the current release, where A is already killed, so in the new branch it would also not be there anymore. Or do I simply have to put the texture in RIP and SVN will know that this texture is gone now in trunk only? But I don't see how it would know that this would be the same texture to occupy only one discspace? Of course I can add this texture to the branch, but then I would still have the same texture a second time in the repository. Once as deleted and once as active.

[OrbWeaver]

A branch is just a directory. Once you have created this directory, you never need to create it again. You just move texture B into the existing directory the same way you did with the first one.

 

Actually there might have been a missing step in my command list, you might need to start with

 

svn mkdir https://darkmod.homelinux.com/svn/darkmod/branches/deprecated_textures

 

You would only do this once, before moving anything.

[greebo]

You don't need to create a new branch, you just copy the file into the existing branch.

 

I guess SVN just keeps a single copy of each version of each file, regardless of how often it is actually referenced. If you copy it from trunk to the branch, the file would be referenced twice (delete it from the trunk to decrease the reference count). Am I right, OrbWeaver?

 

edit: Ok, OrbWeaver already answered your question.

[greebo]

Should I go ahead and create this branch or should I wait/does anybody else want to do it?

 

Regarding the branch name: do we want to have a texture-specific name (like deprecated_textures) or a more general name (if we wanted to move deprecated models there for instance)?

[sparhawk]

I guess we should wait until we agree on the reorg, and then define it there.

[Springheel]

I don't think this has to have any connection to the reorg. We'd be doing this whether we reorganized the texture folders or not.

 

Personally, I don't think the name matters all that much, as everyone who is dealing with it will be aware of what it's for, and we won't be releasing it to the public.

[sparhawk]

Yeah. I meant the moving of the textures.

[SneaksieDave]

It looks like this ran aground. Can we have this branch created now? (Well, not "NOW!" because there's nothing to put there yet, but relatively speaking.)