ascottk

Due to a strange twist in the space/time continuum, the Kate Moss arrow was created . . .

I'm pretty happy with the way the copper and bronze is turning out. I have issues with the rest, especially the silver and gold. Maybe a cubemap would work for loot? I'll have to experiment with those.

I made one for Gil with an example map. I was waiting for some feedback or potential problems but he hasn't been on for a few days. I was thing about putting in some info in the document section or the wiki. Anything with gen_* has an associated directory. How-tos & guidlines would be helpful too but I'm waiting to see if Gil has any problems. Another approach is to have some predefined entities, especially loot objects. Or just have a list of skins with a list of models: GEN SKINS: gen/tdm_gen_bronze gen/tdm_gen_brushedmetal gen/tdm_gen_copper . . . GEN MODELS models/darkmod/props/gen/.. ..gen_bucket.lwo ..gen_goblet1.lwo ..gen_squarestreetlamp.lwo

For the gen_texture project I'm working on, I'm creating a set of textures and materials for general use that can be used in models or walls. I'm finding that the trickier sets are the metallic ones (which would look rather silly as walls). Feedback is appreciated. But first guess which metal goes with which model. The choices are bronze, brushed metal, copper, gold, and silver: Some of them are fairly obvious, some are tricky, and one material desperately needs help.

Based on a previous reaction he didn't seem aware material path names were taken from the files, not the directory. Which seems kind of odd since he's at this stuff longer than I have. Although it did take me a while to catch on to Gildoran's reorganization. I was used to thinking in directory structures too. I do apologize though, I'm just having trouble getting the idea across that adding all gen-enabled models to the skin file is not necessary & it's more trouble than it's worth.

Okay, Spring, if you want to play that way: The same idea for the media browser applies to the skin browser. They are not defined by the directory but by the skin file. All the skins are easily found in the gen "folder".

If you recall: The skin's are easily found in the editor. Also I'd have to copy & paste all the models into every skin entry. If any gen-enabled models are made afterwards, then we'd have to copy that entry in every every skin entry again. That makes for a poor work flow. It'd be nice to be able to have a gen_models.skin file & have all the gen_skins.skin with an #include "gen_models.skin" entry at the top. Then only one file needs to edited in order to have gen-enabled models added.

If I didn't list the models then the mappers would only have to look in the gen directory in the skin browser. Is there a way to have a central list of models the skin files can reference? Similar to the #include definition (or whatever it's called) for scripts?

As I said, this is a work in progress, wip, in the process of generating content/ideas, trying to balance art with the technical side, in the long haul of creating/realizing an idea, trying to silence the nay-sayers, etc.

I ended up revising the template: Here's an example of what you could do with the layout: I think it'll be more flexible & subtle.

I already have quite a few skin files & entries already. One tricky thing about this though it that every "gen-enabled" model has to use the same default material unless a better idea comes along. If the models don't have the same starting material, then the skins won't work. If a model has gen_copper, for example, then there has to be a a gen_copper entry as the original skin. Here's the metal skin file I came up with: skin gen/tdm_gen_bronze { textures/darkmod/gen/default_framed textures/darkmod/gen/metal/bronze_framed } skin gen/tdm_gen_brushedmetal { textures/darkmod/gen/default_framed textures/darkmod/gen/metal/brushedmetal_framed } skin gen/tdm_gen_copper { textures/darkmod/gen/default_framed textures/darkmod/gen/metal/copper_framed } So if the model has gen_copper as the default, d3 will scan the skin file for gen_copper as the original. D3 won't find gen_copper as an original so the skin won't work. Either come up with all possible combinations of defaults & their material replacements or just have one default material. I'd rather go with the latter.

I think it would be wise to keep the originals. The authors of the originals wouldn't be too happy with me messing up their stuff It would probably be a few chosen models like cups, vases, pillars, loot objects, light posts and stuff like that.

Just keep in mind that the textures/uvw maps in that shot are either wips or place holders.

Here's a shot of a demo map I made for Gil. All of these objects were in the same room: It runs fine in-game & the editor as long as I do not have the skin browser loaded.

In the editor, when I load the skins, I keep getting an over 90% physical memory utilized warning. But when I don't have the skins loaded I don't get that warning. "gen" textures don't need to be "generic". With some creative uvw mapping you can get some pretty good results. Consistancy & versatility are the main reasons of going this route. I don't plan on having every model done like this but loot, buckets, light poles, and the stuff you mention work work well with this. Besides, a lot of models won't look well with gen textures. I started to name them "gen-enabled" models btw.

Will do.

I was replying when you were So yeah, it would be copies of existing textures. I was planning on uploading a pk4 before anything went to cvs. I'm far away from doing that though.

No, the original textures won't be touched. This would make this project a little easier & mappers could have objects that could match their architecture. Suppose someone wanted to have a location that has limited natural resources to draw on (like a cabin out in the middle of nowhere, the furniture would be the same material the cabin is made out of). That'd be a little tacky but I could put in variations of existing textures.

I plan on having textures like this too without the trim: I also plan on adding trim to existing tdm textures if that's alright. It would give this project a little consistancy.

That could get messy. Those material path names I made were to lessen that clutter and it looks a helluva lot nicer in d3ed: Unfortunately, it's not so hot looking in Dark Radiant.

Anyway, back to this question. I'm thinking it'll have to be a separate directory because I plan on having a whole bunch of these textures. Right now my gen\metal directory so far has 9 planned textures. Multiply those by 3 (diffuse, normal, and specular) & I'll end up with 27 textures that would clutter up the main texture directory. Although there is no metal directory in tdm yet Another thing is the materials. Here's what I have so far: //************TDM Gen Wood********************* textures/darkmod/gen/wood/wood1_framed { wood qer_editorimage textures/gen/stone/gen_wood1_framed_d.tga diffusemap textures/gen/stone/gen_wood1_framed_d.tga bumpmap textures/gen/stone/gen_wood1_framed_local.tga //specularmap textures/gen/stone/gen_wood1_framed_s.tga { if ( parm11 > 0 ) blend gl_dst_color, gl_one map _white.tga rgb 0.40 * parm11 } { if ( parm11 > 0 ) blend add map textures/gen/stone/gen_wood1_framed_d.tga rgb 0.15 * parm11 } } textures/darkmod/gen/wood/wood2_framed { wood qer_editorimage textures/gen/stone/gen_wood2_framed_d.tga diffusemap textures/gen/stone/gen_wood2_framed_d.tga bumpmap textures/gen/stone/gen_wood2_framed_local.tga //specularmap textures/gen/stone/gen_wood2_framed_s.tga { if ( parm11 > 0 ) blend gl_dst_color, gl_one map _white.tga rgb 0.40 * parm11 } { if ( parm11 > 0 ) blend add map textures/gen/stone/gen_wood2_framed_d.tga rgb 0.15 * parm11 } } If I want a matching texture with no trim, then they won't have the *_framed. *EDITED material definition

Whew. I wasn't too sure about that

Oh crap! I just thought of a wrinkle in my scheme: frob code . . . If I add frob code, will the walls hilight?

I wouldn't think so, I hope not anyway At any rate, I'm far from submitting anything so changes from my end will definately happen.

They do have a specific function (or nonspecific depending on your point of view). They can be used for meshes or walls which can't be said for the rest of tdm's textures, with a few exceptions. Sorry guys, but I'm going to rant . . . [rant] There's other reasons for pushing this idea though. A lot of people working on this mod do not have the skills to have a clean uvw map & this kind of urks me When I started looking at the textures for the models, I was astonished on how messy the textures looked, especially the characters. Another reason is I can't apply another skin to a model because the texture is model specific & if I don't like the look, I'd have to figure out how that modeler mapped the mesh & create a new texture and skin. With this idea, all I have to do is apply another gen* skin to it. The problem with a community mod is the skill levels of each person vary so the quality of the work varies. Some people submit textures that don't tile and others submit broken models. This causes grief down the road because someone has to take the time to fix these things which delays more important tasks. I can't imagine how much further this mod would be if things were close to being right the first time. For example, the character models are being redone so we can have facial expressions. This should have been brought to the table in the first place. Another thing that urks me are decisions that could have been made on certain features are not in the mod yet because people disagreed about it. UI design and the back story are a couple of those "features" that's been delayed due to disagreements. Either vote on it or just implement one of them until a concensus has been made.That's why most forums have voting features & I wonder why voting isn't utilized more often in this mod. I went against the design documents for the noisemaker because I didn't look that the design documents (I should have). But when I presented the new noisemaker design, the mod team liked it. That's one example of implementing something, without all the discussion/voting, that actually worked. It definately doesn't work all the time but it's something to keep in mind. *Good grief I have to stop complaining here, but here goes . . .* The Dark Mod is held in high esteem & high quality is expected by this mod. When those expectations are not met, people can be total asswipes: Sure were not going to please everyone but when any "pros" take a look behind the scenes, then we'll definately hear about it. I'm not saying GBM is a pro btw In short, I think we should be more consistant with voting proceedures because a lot of discussions so far have been counterproductive. Either that or just implement the damn thing. Don't get me wrong on community projects (or this one for that matter), I love them, but these problems rub me the wrong way. Sorry to keep being a thorn in the members' sides. [/rant]