*goodness* Or Gen Textures

[New Horizon]

I trust your judgment ascottk. There were a lot of things that TDS did right when it came to assets. The TDS approach is very user friendly. My only concern is integrating it with the current system, might it require another slight modification to our current texture/ model systems?

[ascottk]

I trust your judgment ascottk. There were a lot of things that TDS did right when it came to assets. The TDS approach is very user friendly. My only concern is integrating it with the current system, might it require another slight modification to our current texture/ model systems?

 

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.

[ascottk]

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

[New Horizon]

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

 

Nope, it shouldn't. You have to set an object as being frobbable in the entity inspector. The frob code just allows an object that has been set as frobbable to use that code.

[ascottk]

Nope, it shouldn't. You have to set an object as being frobbable in the entity inspector. The frob code just allows an object that has been set as frobbable to use that code.

 

Whew. I wasn't too sure about that

[ascottk]

Do they need to be put in a separate folder from other textures? It seems like it would be intuitive to just use the same folder structure that we are currently, but call them gen_* to indicate that they're generic.

 

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

[Springheel]

do not have the skills to have a clean uvw map... I was astonished on how messy the textures looked, especially the characters.

 

I highly doubt Oddity didn't have the skills to have a clean uv map. More likely he just wasn't interested in going out of his way to make it easy for someone else to modify them.

 

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.

 

I didn't know a thing about models or textures before starting this mod, and I've made about 100 skins since then without much problem. Yes, you'd gain more flexibility with the TDS method, but then you're also encouraging the use of the same textures over and over again, aren't you?

 

The problem with a community mod is the skill levels of each person vary so the quality of the work varies.

 

Yes, that's true. You can either increase your standards and have less people able to contribute, or you can accept less than perfection and get more done. The longer the project drags on, the more we're leaning towards the latter.

 

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.

 

Perhaps it would have been, if we had anyone working on the mod at the time who knew anything about animating. Nobody here is a professional game designer, so everyone is learning as they go. Unfortunately, that does mean some backtracking. Desirable? No. But if people had to spend time learning everything that we might need to know down the road before starting anything, the mod would never have gotten off the ground, period.

 

I went against the design documents for the noisemaker because I didn't look that the design documents (I

 

Huh? All that was in the design docs about the appearance was:

The noise arrow has a little clockwork device on the end that is wound up before firing. When it impacts something, it releases the trigger and unwinds, causing strange wirring and clicking noises.

...which you captured quite nicely.

 

Sure were not going to please everyone but when any "pros" take a look behind the scenes, then we'll definately hear about it.

 

Quite frankly, I'm sure I'm not the only one who feels that any "pros" that have the nerve to complain after doing nothing to help along the way can stick their opinions way, way up their ass.

 

textures/darkmod/gen/wood/wood1_framed

 

These path names aren't necessary and can be very confusing if the textures are ever moved for whatever reason (as has happened twice already). I'm not sure what Gil is doing for the 2d textures, but for models we're just using "tdm_[name]"

[ascottk]

These path names aren't necessary and can be very confusing if the textures are ever moved for whatever reason (as has happened twice already). I'm not sure what Gil is doing for the 2d textures, but for models we're just using "tdm_[name]"

 

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.

[Springheel]

I'm not sure I understand. Are you saying the entity window organizes textures by material name, not file location?? For models it's by file name--the name of the material has no meaning at all.

[SneaksieDave]

Yep that's how it works. I guess the analog for the models would be the popup menu hierarchy thingy which we don't make much use of.

[Springheel]

Ah, didn't know that. So I guess anything that could be used as a brush texture would also need to have the entire pathname in the material. With the models that just got extremely frustrating, since the material name would be something like "models/props/darkmod/pot" but the textures were actually in "models/darkmod/props/textures" and the model was in "models/darkmod/props/kitchen". Too much room for confusion and error.

[Gildoran]

I must've missed this post. What I'm doing is a texture set. I'm not sure where you got the idea about sub-textures but all textures in this set will have the same layout.

In the example texture you posted above, it contains multiple textures in a single image: a tiling wall/floor, a couple of edge trims, and a couple of decorative trims. I'm saying it would be better to split that up into multiple images rather than a single one, so that it's easier for mappers to use. It'd still be possible to switch out entire gen texture sets in a single skin declaration.

 

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.

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.

This should have been brought to the table in the first place.

I felt the same way when I came onto this mod for both art assets and programming. I don't like the fact that the materials used by a model don't contain the model name as their path; it makes it a pain to find out what materials a model uses, and to make skins for that model. (I had to use a hex editor to find out what materials were used by the models for the frobhighlight testmap! ) It drives me absolutely bonkers that we still can't save/load without a crash. Pointer errors are a pain to debug, and the longer we go without being able to test saving/loading, the more bugs pile up. I'm very worried that when it comes time to fix those errors, it'll be a painful ordeal. Also, this is part of why I expect all new textures to be submitted to me; a lot of our older textures had/have a wide range of severe problems, and at least for the new ones, I'd like to be able to make sure they're of higher quality - of course, when I suggest that we shouldn't add a texture that has problems, people complain that we're in dire need of textures so we shouldn't limit the textures we add.

 

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.

I agree, and I bet Sparhawk does too... I did the same thing for readables - I took the general idea of the design docs, but did them in my own way, and almost everybody seemed really like it. I'm sure that if I had suggested my idea before coding it, people would have shot it down as too "complicated", despite that it's really intuitive once you try it.

[Springheel]

Just be glad you two weren't here when we were trying to come up with a lightgem design.

[ascottk]

In the example texture you posted above, it contains multiple textures in a single image: a tiling wall/floor, a couple of edge trims, and a couple of decorative trims. I'm saying it would be better to split that up into multiple images rather than a single one, so that it's easier for mappers to use. It'd still be possible to switch out entire gen texture sets in a single skin declaration.

 

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.

[Springheel]

If you change existing textures, that will mess up any maps or models currently using them. And then it forces mappers to use that trim with that texture, instead of being able to mix and match as they choose. What's the benefit there?

 

edit: Ah, just read Gil's post, perhaps I misunderstood. Certainly modifying the existing texture files would not be a good idea, but adding trim textures to match them would be.

[Gildoran]

When you say "adding trim to existing tdm textures", do you mean making another trim texture that works well with an existing texture, or do you mean making another copy of the texture with trim at the top/bottom? I'd prefer the former. When the trim is part of a larger image, it's a pain for mappers to fit it to stuff.

 

Also, could you please package the trims/etc in a PK4 and send them to me instead of directly adding them to CVS?

[ascottk]

If you change existing textures, that will mess up any maps currently using them. And then it forces mappers to use that trim with that texture, instead of being able to mix and match as they choose. What's the benefit there?

 

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.

[ascottk]

When you say "adding trim to existing tdm textures", do you mean making another trim texture that works well with an existing texture, or do you mean making another copy of the texture with trim at the top/bottom? I'd prefer the former. When the trim is part of a larger image, it's a pain for mappers to fit it to stuff.

 

Also, could you please package the trims/etc in a PK4 and send them to me instead of directly adding them to CVS?

 

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.

[Gildoran]

Anyway, don't hold off uploading PK4 until the end... things are easier on me if I just have to upload a few textures at a time. Also, if you can send me a single set of textures that matches your plans, we can discuss any problems I might have before you do a hundred of them.

[New Horizon]

If you change existing textures, that will mess up any maps or models currently using them. And then it forces mappers to use that trim with that texture, instead of being able to mix and match as they choose. What's the benefit there?

 

edit: Ah, just read Gil's post, perhaps I misunderstood. Certainly modifying the existing texture files would not be a good idea, but adding trim textures to match them would be.

 

I think he just means alternate versions of the textures, with trim..so they can be used as General textures for models...etc....or I could be way off. lol

[ascottk]

Anyway, don't hold off uploading PK4 until the end... things are easier on me if I just have to upload a few textures at a time. Also, if you can send me a single set of textures that matches your plans, we can discuss any problems I might have before you do a hundred of them.

 

Will do.

[New Horizon]

This should be really cool. I can't wait to see it in action in a map.

[PinkDot]

Well, I'm very short time here, but let me just say two words...

 

From artistic point of view I'd avoid using generic textures - this can kill the uniqness of models. F.e. that fountain asckott posted looks very clean - I would make the inside more dirty but in that case this texture couldn't be used for walls or door frames...

 

The consistency in design can be achieved without gen textures. It is harder to make consistent game world made by several diffrent modelers and texture artist but that's what the Art Department Leader position is for. (that was in general, not personal, of course)

 

But idea of gen textures might be useful from performance and optimization point of view. What I'm really afraid of is that if plenty of models use their own diffrent skins then we can very easily reach the memory limit... Should I really worry about it or not? Is it really necessary to save the memory by using the gen textures?

 

My mind is more artistic than technical I think and creating models with reusing textures in mind is limiting and delaying me. Of course - if it's necessary to save the memory that textures use I'll work that wayt, but if not - I would prefer to avoid that.

[Springheel]

From artistic point of view I'd avoid using generic textures - this can kill the uniqness of models.

 

I don't think the idea is that every model should be using these--I wouldn't want to see that for the same reasons you mention. But I can see a lot of use for these kind of textures for architectural meshes, however, so that pillars, archways, etc, match the rest of your texture set.

[ascottk]

Well, I'm very short time here, but let me just say two words...

 

From artistic point of view I'd avoid using generic textures - this can kill the uniqness of models. F.e. that fountain asckott posted looks very clean - I would make the inside more dirty but in that case this texture couldn't be used for walls or door frames...

 

The consistency in design can be achieved without gen textures. It is harder to make consistent game world made by several diffrent modelers and texture artist but that's what the Art Department Leader position is for. (that was in general, not personal, of course)

 

But idea of gen textures might be useful from performance and optimization point of view. What I'm really afraid of is that if plenty of models use their own diffrent skins then we can very easily reach the memory limit... Should I really worry about it or not? Is it really necessary to save the memory by using the gen textures?

 

My mind is more artistic than technical I think and creating models with reusing textures in mind is limiting and delaying me. Of course - if it's necessary to save the memory that textures use I'll work that wayt, but if not - I would prefer to avoid that.

 

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 think the idea is that every model should be using these--I wouldn't want to see that for the same reasons you mention. But I can see a lot of use for these kind of textures for architectural meshes, however, so that pillars, archways, etc, match the rest of your texture set.

 

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.