Texture Organization

[Dram]

Done.

 

Thanks

[New Horizon]

That would mean we'd have to open up -every- model and change the material name that it uses

 

But I guess it'll look more clean

 

LOL I've already done it twice in the last year and a half. It doesn't take that long. I'll get to it shortly.

[Dram]

LOL I've already done it twice in the last year and a half. It doesn't take that long. I'll get to it shortly.

 

Ok, as long as I don't have to do materials again lol. I litteraly spent 9 hours straight changing them lol.

[SneaksieDave]

Probably unnecessary, but I'll say it anyway (especially since I posted it wrong in my first post): no caps, either. 'tdm' instead of 'TDM' (as I accidentally wrote).

[Gildoran]

(these quotes are out of order)

I don't know if this is a good idea. It would mean everyone has to rely on you keeping them up to date. If something comes up for you and you can't do it then it means we're in a deadlock.

 

I think if we leave permissions open but tell everyone not to edit them then in the case of you being away we can change it.

Assuming it's even possible to restrict access, and something happens and I can't come back for a while, Sparhawk could just give everybody write access to the affected files.

 

We all have to keep in mind that this is for helping us along, not hinder us, so if we make it too hard to add new materials and the like then it would slow progress.

Following my suggestions wouldn't prevent mapping teams and coders and such from adding their own materials to CVS - they would just have to name them differently. For example, if you're making a material file for your map, you might name it mymapname.mtr, and its materials might be in the textures/mymapname/ directory. (of course you could use any naming conventions you wanted as long as the textures weren't in textures/darkmod/) You could play around with them as much as you want, having placeholder textures, etc, all without having to wait for me. When you felt like specific textures were ready to be added to the standard TDM set, you could just drop me a line, and the textures would probably be added next Friday (or sooner during the summer).

 

If people end up finding this system inconvenient, then I'll definitely be willing to scrap it and just check on changes as they come in. However, at least while I'm busy reorganizing textures, I'd like other people to hold off on adding new textures/darkmod/ textures.

 

Plus I don't really see how everyone could'nt copy/paste the current material layout, preserving the clean configuration.

At least for the source code on CVS, there have been problems with some people's machines not using unix-style newlines. This results in each line edited by the person getting double-spaced without them realizing it.

 

Lastly, about uploading to ftp each material - it's a waste of time with ascii formatts, we can just post it here on the forum, that way we all know what materials exist etc.

I don't have a problem with people posting the material code to the forum. I just figured uploading pk4 files to CVS or FTP might be an easier way to store all the image files and such in one place.

 

Do you know what I mean Gild? Mind, I'm not trying to offend you, just raising the important and relevant points.

Don't worry, I'm not offended by differences of opinion. The reason I post my plans to the board is to give people a chance to voice their concerns before anything goes into action.

[Gildoran]

Probably unnecessary, but I'll say it anyway (especially since I posted it wrong in my first post): no caps, either. 'tdm' instead of 'TDM' (as I accidentally wrote).

Agreed... D3 doesn't like caps in filenames.

[Dram]

Ahh! Now I see what you're trying to achieve

 

Very well, I'm not against it, as long as people can still easily pop their textures on cvs without a problem then we can still have everything playable etc.

 

Well if it makes the job easier for you and does'nt slow us down (which your idea does'nt) then I'm all for it

 

I think it might be easier for you if there was a specific sticky topic which people could post that they want this and this material added and either give a link to ftp or just say what it is on cvs. That way you wo'nt be flooded with pm's

 

Anyways, good luck

[Gildoran]

@NewHorizon & Dram: I don't like the fact that every single material used by models is in the root material directory... that seems like very bad design to me.

 

I haven't yet fully thought this through, so take this with a grain of salt (and don't act on it yet), but: If it's possible, I'd eventually like to request that materials used by a model use the same naming scheme as the model. For example, if we have something like models/readables/book1.lwo and it uses cover1 and parchment1, I'd probably like cover1 and parchment1 to be renamed to models/readables/book1/cover1 and models/readables/book1/parchment1 respectively. (note that as material names, they aren't actual files, and are obviously materials from the context they're used in) Image files for those materials would be in textures/models/readables/book1/. Any external materials referenced by the model would be listed in a text file for easy reference by mappers/texture-artists who want to create new skins.

 

The purpose of this is so that it's easy to find all materials used by a model, just by browsing the declarations editor, and it keeps the root material directory from being flooded with hundreds of materials.

[Dram]

@NewHorizon & Dram: I don't like the fact that every single material used by models is in the root material directory... that seems like very bad design to me.

 

I haven't yet fully thought this through, so take this with a grain of salt (and don't act on it yet), but: If it's possible, I'd eventually like to request that materials used by a model use the same naming scheme as the model. For example, if we have something like models/readables/book1.lwo and it uses cover1 and parchment1, I'd probably like cover1 and parchment1 to be renamed to models/readables/book1/cover1 and models/readables/book1/parchment1 respectively. Image files for those materials would be in textures/models/readables/book1/. Any external materials referenced by the model would be listed in a text file for easy reference by mappers/texture-artists who want to create new skins.

 

The purpose of this is so that it's easy to find all materials used by the model, just by browsing the declarations editor.

 

Yeah I know Gild, but the only problem for me is that useless milkshape has a limit to how long that name can be. I myself wanted them to be in the darkmod directory, but the problem is milkshape. So if we change it then I can't really put long names there

 

Of course, I could ask someone else to chuck those names there in full but that's just an extra hassle.

 

I'm planning to learn lightwave within the next year but that's not any time soon, so I still use milkshape.

[sparhawk]

At least for the source code on CVS, there have been problems with some people's machines not using unix-style newlines. This results in each line edited by the person getting double-spaced without them realizing it.

 

Which is as hard as clicking the appropriate checkbox to do everything in unix style linefeeds.

 

 

I don't have a problem with people posting the material code to the forum. I just figured uploading pk4 files to CVS or FTP might be an easier way to store all the image files and such in one place.

 

CVS is not suitable for binary files, so uploading a lot of pk4 files is not a very good idea.

[Gildoran]

What about image and wave files?

[sparhawk]

Of course these files should be stored on CVS, but it should be limited to the neccessary. For ASCII files there is no problem if you upload a version and then change on byte and commit it again. For binaries, it would be better to fix it and upload it only once (ideally). I know that this is not possible always, but we should try to limit the number of changes on binary files as each file will be stored completely. So if you upload a PK4 with 4MB, and then change one byte of it, it costs 8MB + small overhead to maintain it, instead of 4MB + 1b + small overhead to maintain it.

[Gildoran]

Ah, ok. That makes perfect sense.

[Dram]

So we'll have to upload our textures as a pk4 to the ftp, or we could upload to cvs but not into the darkmod ones. That way you get a cvs update notification and can organize it. either of these ways is fine imo.

[Gildoran]

From what Sparhawk just said, it sounds like it'd be best to send as few different versions of binary files as possible to CVS, so I'll probably suggest only uploading image and/or pk4 files to the FTP, so there's only one copy of them on CVS.

[Dram]

Basically you mean its best to limit cvs to just *official* tdm textures, not WIP textures right?

 

If so, then it makes sense.

[sparhawk]

Basically you mean its best to limit cvs to just *official* tdm textures, not WIP textures right?

 

If so, then it makes sense.

 

Exactly. It also doesn't make sense from the workflow point of view. If it is on CVS, people are bound to sync with it. BUt nobody really wants to spend his downloadtime to get a bunch of WIP textures, that he can't use anyway.

[New Horizon]

I haven't yet fully thought this through, so take this with a grain of salt (and don't act on it yet), but: If it's possible, I'd eventually like to request that materials used by a model use the same naming scheme as the model. For example, if we have something like models/readables/book1.lwo and it uses cover1 and parchment1, I'd probably like cover1 and parchment1 to be renamed to models/readables/book1/cover1 and models/readables/book1/parchment1 respectively. (note that as material names, they aren't actual files, and are obviously materials from the context they're used in) Image files for those materials would be in textures/models/readables/book1/. Any external materials referenced by the model would be listed in a text file for easy reference by mappers/texture-artists who want to create new skins.

 

This was the naming scheme that we started out using in the beginning, but it turned out to be very confusing and messy. I had planned to do one last reorg of the models where the material names would be tdm_cover1 and tdm_parchment1. We were getting too many incorrect variations using the previous method. In addition, using a simplified tdm_material naming scheme is less confusing to new comers. When I first started messing around with this stuff, I thought that the material name actually required the correct path to the texture. It's just more misleading.

[Springheel]

I don't think a new model organization is in the cards right now. We already finished one (and a half) within the last six months.

 

The material files for models are supposed to follow the same naming conventions as the model folders. So the furniture model materials are in furniture.mtr, etc.

 

Would it help if the model material filenames had "model" added to them? So we would have "model_furniture.mtr" for example.

[New Horizon]

I don't think a new model organization is in the cards right now. We already finished one (and a half) within the last six months.

 

The material files for models are supposed to follow the same naming conventions as the model folders. So the furniture model materials are in furniture.mtr, etc.

 

Would it help if the model material filenames had "model" added to them? So we would have "model_furniture.mtr" for example.

 

Oh, I wasn't referring to the material files themselves, I was talking about the 'material names' within the files. The material names within the models don't need to be /model/is/stored/here/tdm_materialname, they only need to be tdm_materialname. As long as tdm_materialname is written in any of the material files, it will find it. This doesn't break any maps since the maps reference the models and then the models reference the materials.

[Springheel]

I hear you, NH. I've been a fan of short material names for a while as you know. I was just wondering if Gil might like a way to try and keep his material -files- separate from the model ones. Maybe I misunderstood his concern.

[Gildoran]

I dunno... I found our current scheme very confusing when I tried to make new skins for the models in my frob highlight testmap. I ended up having to open up the models in a hex editor and make guesses as to which ascii strings were used materials. Then I had to search for the correct material names in the large list of materials used by models.

 

It would have been much more convenient if I could have just pasted the model path into the declaration browser and seen a list of all materials used by the model, and be able to easily browse the code for each one just by clicking on it.

 

Anyway, I'm not asking for a model texture reorg right now... Currently I'm more interested in doing a nice reorg for mapper textures first.

[Dram]

I dunno... I found our current scheme very confusing when I tried to make new skins for the models in my frob highlight testmap. I ended up having to open up the models in a hex editor and make guesses as to which ascii strings were used materials. Then I had to search for the correct material names in the large list of materials used by models.

 

The solution: use a modelling program

[Gildoran]

Surely you don't seriously expect a mapper to have to DL and learn an entire modelling program just to create a skin that merely swaps a couple of images?

 

D3 already has a nice, simple declaration browser that could be very convenient for mappers (and it doesn't even require them to open up an external program), if we set up materials properly.

[Dram]

Surely you don't seriously expect a mapper to have to DL and learn an entire modelling program just to create a skin that merely swaps a couple of images?

 

D3 already has a nice, simple declaration browser that could be very convenient for mappers (and it doesn't even require them to open up an external program), if we set up materials properly.

 

I was kidding lol.

 

Yeah we should eventually fix up the materials of models too, but perhaps we can do that later. I guess the main priority is textures for maps.