*goodness* Or Gen Textures

[PinkDot]

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.

Well, Ascottk showed the model of bell with some wall textures on it but if it's only example then it's OK.

Yeah, I think that architectural models might be the best to use gen textures too.

 

* going back to my boar head model with nice brick texture on it *

 

But seriously - did anybody think about memory problems?

 

Ascottk posted just before me...

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.

So does it mean that we can't make many more skins for our mod? Or mappers could use in one map just a fraction of our final props amount?

[New Horizon]

Nah, that 90% error message is just a nonsense error with D3Ed. Shouldn't be a problem when we switch over to Dark Radiant.

[ascottk]

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.

[Springheel]

Definitely shows how it could be useful, but I agree with Gil that having the trim part right in the texture is maybe not the way to go. The trim design looks quite out of place on many of the models, especially the buckets. The more often you run into the same designs on different objects, the more you're reminded that the setting is artificial.

 

It's also worth nothing that none of those images look as good, in my opinion, as the original textures made specifically for those models.

[ascottk]

Definitely shows how it might be useful, but I agree with Gil that having the trim part right in the texture is maybe not the way to go. The trim design looks quite out of place on many of the models, especially the buckets.

 

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

[Springheel]

Just out of curiosity, what is it exactly that you're proposing here? That you make this repository of generic textures that can then be used by future models/mappers? Or that we go back and redo all the uvmaps of our existing models so that they use these instead? I'm totally on board with the first bit.

[ascottk]

Just out of curiosity, what is it exactly that you're proposing here? That you make this repository of generic textures that can then be used by future models/mappers? Or that we go back and redo all the uvmaps of our existing models so that they use these instead? I'm totally on board with the first bit.

 

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.

[SneaksieDave]

Indeed, it could have future skin application. Going backwards and 'fixing'/reskinning things is likely not an option.

[Springheel]

It would probably be a few chosen models like cups, vases, pillars, loot objects, light posts and stuff like that.

 

That makes sense. We've already been resuing textures for lamps and loot objects, so creating a more organized system for those kinds of things is not a bad idea. I'd still push for at least having the choice between a trim and trimless version though.

 

Someone's going to have to write a LOT of skin files though, unless DarkRadiant can somehow let you browse them automatically.

[ascottk]

That makes sense. We've already been resuing textures for lamps and loot objects, so creating a more organized system for those kinds of things is not a bad idea. I'd still push for at least having the choice between a trim and trimless version though.

 

Someone's going to have to write a LOT of skin files though, unless DarkRadiant can somehow let you browse them automatically.

 

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.

[OrbWeaver]

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.

 

That makes perfect sense to me -- any model that wishes to use a gen skin must have the gen_default material on its mesh, so that the standard skins can switch it.

[ascottk]

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.

[PinkDot]

To be honest with you, your buckets do not convince me. They remind me about Eastern European tradition of painting eggs at Easter. I believe that it can work with architectural models (and not only probably...), as it was said already, but your other models look more psychodelic than realistic (IMO this Mod is intended to be more realistic than psychodelic...).

I also do believe that consistency in design can be achieved in other way - when people start to think about colours, matter, age, function etc. of models and textures they create.

 

But on the other side I also see the necessity of saving some memory by sharing the same textures (skins) by diffrent models. F.e. I'm starting with graveyard theme and I'm going to make many grave models using one big texture - that will save some memory, make them consistent in look and will be easy to make another skins.

 

The art of modeling for games is to find some harmony between artistic vision and technical limitations. Your idea seems to me a bit too technical...

[ascottk]

To be honest with you, your buckets do not convince me. They remind me about Eastern European tradition of painting eggs at Easter. I believe that it can work with architectural models (and not only probably...), as it was said already, but your other models look more psychodelic than realistic (IMO this Mod is intended to be more realistic than psychodelic...).

I also do believe that consistency in design can be achieved in other way - when people start to think about colours, matter, age, function etc. of models and textures they create.

 

But on the other side I also see the necessity of saving some memory by sharing the same textures (skins) by diffrent models. F.e. I'm starting with graveyard theme and I'm going to make many grave models using one big texture - that will save some memory, make them consistent in look and will be easy to make another skins.

 

The art of modeling for games is to find some harmony between artistic vision and technical limitations. Your idea seems to me a bit too technical...

 

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.

[Springheel]

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.

 

Yep, that's a problem, unless you make separate skins for each object. That's why I'm hesitant to make this the default action for most models.

 

You also have to make sure that you list every model using the skins in the entry, otherwise they won't show up in the 'matching skins' list, and mappers will have to scroll through the entire list of every skin for every model to find the one they want (or more likely they'll just assume there aren't any skins for that model).

[New Horizon]

One thing that bugs me in D3 about skins, is that you have to 'render' the scene in order to see the skin you have applied. Leaving the render off only shows you the default skin...quite confusing. Hopefully we can avoid this in Dark Radiant.

[Springheel]

Yeah, and even rendering doesn't show you the skin when you're working with AI.

[ascottk]

You also have to make sure that you list every model using the skins in the entry, otherwise they won't show up in the 'matching skins' list, and mappers will have to scroll through the entire list of every skin for every model to find the one they want (or more likely they'll just assume there aren't any skins for that model).

 

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?

[Springheel]

If I didn't list the models then the mappers would only have to look in the gen directory in the skin browser.

 

Well, yes, but then they have to look through all the skins. It's already 100 skins long, so finding a specific one won't be convenient. Plus, I'm not sure mappers would intuitively know to look outside of the 'matching skins' folder--they'd be more likely to just assume there aren't any for that model.

 

Is there a way to have a central list of models the skin files can reference?

 

 

All you need to do is put 'model [model path&file name]' in the skin entry--you can include as many models as you want.

[ascottk]

Well, yes, but then they have to look through all the skins. It's already 100 skins long, so finding a specific one won't be convenient. Plus, I'm not sure mappers would intuitively know to look outside of the 'matching skins' folder--they'd be more likely to just assume there aren't any for that model.

All you need to do is put 'model [model path&file name]' in the skin entry--you can include as many models as you want.

 

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.

[Springheel]

The skin's are easily found in the editor.

 

Those look like textures to me, not skins. This is the skin browser I'm used to seeing:

 

[ascottk]

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".

[New Horizon]

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".

 

I think Spring was just pointing out that the skin browser takes the extra step of organizing the matching skins for a particular model for you. Don't think he was posting the huge pic to spell anything out for you.

[ascottk]

I think Spring was just pointing out that the skin browser takes the extra step of organizing the matching skins for a particular model for you. Don't think he was posting the huge pic to spell anything out for you.

 

Based on a previous reaction he didn't seem aware material path names were taken from the files, not the directory.

 

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.

 

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.

[SneaksieDave]

I'd suggest make an example PK4 of the method and put it up for download as proof of concept. If there are objections after that, we can figure 'em out after we're all on the same page (and if it's a PK4, it's easy to clean up).