PinkDot

This material is too complicated for Dark Radiant: tdm_tombstone_grey_1 { stone { blend diffusemap map models/darkmod/props/textures/gravestone_grey_d scale 0.25, 0.25 scroll 0.75, 0 } bumpmap addnormals(models/darkmod/props/textures/tombstone_grey_local.tga, heightmap (models/darkmod/props/textures/inscriptions_01.tga, 12)) { blend filter map models/darkmod/props/textures/inscriptions_01.tga } } Are there any chances of getting it read it properly? It shows only diffuse map, but without scaling and scrolling, what doesn't look as it should... Otherwise I would have to make editor image for each combination of tombstone and inscriptions...

Yes, separate texture for each model. Well, from artistic point of view it's the only way to go and I wouldn't mind preparing new texture for each new model. But considering the time it takes to load a large map and memory that it takes, I'm just thinking ahead of this problem. Well, ascottk was trying to make some generic textures, but so far they're not used too often... I try to make a one big common texture for set of models of the same theme. But it's really difficult to mange this issue on large scale as we are only a team of amateurs and volunteers, not an experienced in game making team, where such things are thought ahead at the beginning.

I used to use some plugin (maybe it was the one Baddcoq mentioned above) but I meant just using some image viewer (like Irfan View). ------ I'd be against any subfolders. It makes things unclear. I don't even see the reason to keep architecture and weapons textures separately except for the fact that they're already separate and it's better not too mess to much. That's good idea. My ship textures are all tileable so they can be used with brushes and patches. That will encourage modelers (including me... ) to reuse more our existing textures instead of creating new ones, where the benefit of unique texture is very small. Somehow I'm worried that we're going too easy with models textures.

I don't know which model uses such a material and looks good, but the best way around it is to make double sided polygonsin 3d app with tiny offset. Doublesided keyword is OK only for nonshadowacasting surfaces.

Some models from diffrent folders (will) share the same texture - where would they go? I think it takes more time to figure out what texture particular model uses (looking through material files...) than just to find that texture. You sort them by name and that's it. You don't search them by looking at thumbnails, do you?

Yeah, that's what I though as well. Looks like distance from low to high poly model is bigger at that spot than at other places and maybe rays miss high poly model (they never go too far to speed up projecting process). And you can see there's a mess on the normal map for the corresponding polygons. Just try to fit low poly mesh as much as you can to high poly mesh. And if you want to keep that shape of handle, you can revert it later, after baking the normals.

Spring - could you post an image of UV layout? and image of low and hipoly models overlapping each other (with mesh visible)? Maybe this could tell us more...

You can't have overlapping polygons only at the moment of baking normal maps. So when you want to have your model with overlapping polygons on texture, just save that UV coordinates set, then take all overlapping polygons out of the UV space (out of 0,0 to 1,1 range), so no polygons are overlapping. Export that model and use it for renderbump. When you're happy with the result you can load the previous UV set. I use Max, so I can't tell you where are Save UV and Load UV commands but I'm pretty sure Lightwave can do that as well. BTW: not everything looks fine after renderbump. For instance that strip at the bottom of your baked texture. It could be corrected in 3D application, which gives you control over the projecting rays direction (again, I don't know how to do that in Lightwave). Or you can do it also in Photoshop (Gimp) - just make a simple height map simulating those round edges and run nVIdia filter.

origins the same, one overlapping the other, but exported in separate files. That might be the cause - grey (=blank) normal map means that rays did not reach hipoly model (it was too far from hipoly).

I had been using renderbump before I learnt how to do it in Max (it gives some better control). I remember that it took me some time to figure out what was wrong. Are you working with LWO or ASE files? Few questions: - does your low poly model have UV applied? - do LP and HP occupy the same space? (they should overlap each other in 3D app before exporting) - are paths correct? where did you place your models? Separate folder is a good idea (f.e.models/renderbump or whatever). - does low poly model points to existing material shader? - what are your renderbump parameters? (those in material declaration)

Very nice concepts, Redface. Are they based on photos or drawn from scratch?

It will probably have some performance impact since it adds some extra calculations. The only way to brighten something is to add a BLEND ADD stage. { blend add map _white.tga rgb 0.1 } Just change the value of RGB or use COLOR (or RED, GREEN, BLUE) to brighten changing the HUE of texture. @Springheel - thanks, I'll try that. BTW: is there somewhere a full list with all console commands explained?

Fidcal: just words red, green or blue , f.e. red 0.7 etc... But color combines them all in one line as parametres - also good solution. You mean reloading entire map to test a change in material declaration? Jeez no! Type in console: reloaddecls for any txt files modified (materials, defs etc.), reloadimages for changed textures or reloadmodels for changedmodels. Doom is not a Dromed! Actually type only reload and press TAB to see other possibilities Could you elaborate on this one a little bit more please? Doom crashed after I typed reloadsurface...

You're right. I actually meant red, green and blue keywords but having them in one command may be even better. I've learnt something new...

Fidcal - can't you just use rgb instead of color? You don't want to change alpha value, do you..?

Must be something on your end, cause it's fine on my system. That shader doesn't have any specular, BTW.

I didn't notice those pixels when testing that texture yesterday, so it's OK. I like those wavy bumps on it, which the right one lacks. By flat I meant global bumps, not just those tiny ones. My "smooth" snow has subtle uneven surfaces which looks more natural IMO. But as I said already - we're not at the stage of having too many snow textures yet. And if we're going to support snow fanmission we should do it properly - not with just two textures. BTW: are there any new texture guidelines? where should I upload them? Who's going to look after them? (give proper name, material shader etc., convert to DDS, etc.) Or should I do those things on my own? Soon I'll have a bunch of new tileable textures, not only snowy ones.

I don't have anything like "guard room" reference. And I don't think there's anything special about this. I'd see it rather austere room with some table, chairs, maybe desk, shelves and couple props like books or bottles. It usually has kind of window open to the guarded space... OK, I'll do that.

At this moment it definitely looks very artificial but before you throw this idea try to make material overlayed with detail texture. Since you can scale images you can have one big texture for colour variety and one much smaller for details. Of course that large texture shouldn't be random as it is at this moment. This is part of snow material, so you can take a look at it: textures/darkmod/nature/snow/plain_snow01 { surftype15 description "snow" { blend diffusemap map textures/darkmod/nature/snow/plain_snow01 rgb 0.75 scale 0.5, 0.5 } { blend bumpmap map textures/darkmod/nature/snow/plain_snow01_local scale 0.5, 0.5 } // Detail layers { blend gl_zero, gl_one_minus_src_color map textures/darkmod/nature/snow/plain_detail rgb 0.1 scale 6, 6 rotate 0.3 } { blend gl_zero, gl_one_minus_src_color map textures/darkmod/nature/snow/plain_detail rgb 0.2 scale 36, 36 rotate 0.8 }

All those three textures share specular map and two of them has the same diffuse map. I didn't see our snow textures before - all I've seen before was snow texture on jdude's screenshots which looked flat. Now, after I took a look at our existing snow textures I think one of them has quite nice normal map (snow_plain) but it lacks specular. The other one (ice_something...) didn't convince me (it's completely flat). Indeed we don't need more clean snow textures and if we want to reduce repository size we could choose the best textures of our existing ones and mine and combine them into 2 or 3 materials instead of 5. But I wouldn't panic anyway - variety is necessary - snow textures in Thief FMs tend to look monotonous casue people never bothered to use more than 1-2 textures per whole mission...

I'm not sure why you want to make the background transparent. What's the purpose of this texture? If you want to make tileable texture for brushes and models, you would normally just crop the middle part of the texture - triming out the background. When I do tree trunk textures I also resize the side parts, so the pattern gets flat instead of round. This makes it more blurry of course, so I have to sharpen it using filters and some other tools (cloning stamp for example). It's always better to make photos of wider trees or/and several photos of one and the same tree from diffrent angles and then joining them into one long and relatively flat texture. It's not an easy task for the beggining- brick wall would be much easier...

really nice

Thanks, I'm glad you like it I found a very cool page - torture museum gallery, where's plenty of reference photos for our dungeon folder. Next one will be that Iron Maiden @sparhawk - no problem, but what exactly do you need? Do you want two parts of padlock to be separate entities, openable like chest?

Couple new models I've made as a break from docks environment. That chain uses slightly improved chain_d texture (it wasn't tiling exactly). I added local map for it. Looks like it doesn't need specular map cause highlights are in diffuse map and shines enough.

It would be great to make it a gameplay feature. But I haven't seen any engine keeping footprints on snow for more than 30 sec. or more than 20-30 of them... With strong snowfalss footprints could dissapear gradually, which would help the performance (and player as well ) but not all snowy mission have strong snowfalls..