peter_spy

One minor thing that I just noticed: texture scale in surface inspector is limited to 3 digits after the decimal point. With big textures like 2048 you need precise scale values like 0.125 or 0.0625, and the latter gets rounded to 0.063.

Adding optimised assets will help a lot too, but that will take time. Or maybe someone will make VR-focused missions, that would be interesting to see.

The idea is great, but many missions aren't optimised to run in high FPS. And it's not as much a GPU problem, but CPU -> GPU bottleneck, so you cant just offset that by buying a modern card.

What about Sneaky Upgrade? I managed to run Thief 3 on Win7 with it.

I admit, I don't have refined taste in whiskey. I like JD or Jameson for my weekly needs, I also tried a few finer brands like Greenspot or Yellowspot. But even my plebeian nose and taste buds can sense ethanol in red label. It almost reeks of it. Maybe that's a regional thing, and this is one of the cheapest whiskeys on the market, so I shouldn't be that surprised.

Right now, our fog uses light to define its area in the map, we also have "fog end" parameter (shaderparm3), so we can extend the fog range beyond the light area. This very useful, if yo want to use subtle fog to show depth in your map or simulate a little haze in the air, that is always present to some extent in the real world. There are a few problems here though. You need a gradient image to simulate fog, and by limits of 8 bits per channel in images, we can only have 256 steps in any gradient, which causes banding. To simulate haze, you need to use high values for shaderparm, and that increases banding even more. It's less obvious when you have many objects in your scene, but you can easily see this with caulk: My question is: can we have additional "fog start" parameter, so the fog would start further away from the player? Is it possible to decrease banding this way, by having shorter distance between fog start and fog end?

Thief 1-2 should be on both GoG and Steam, so it's not that hard to find. And with NewDark, hardware compatibility issues are minimal these days. As for the whiskey comparison: to me, Thief 4 is like Johnny Walker Red Label. Some people call that whiskey, sure. I think no human being with minimum amount of self-respect should ever go below Jack Daniels

I just found out that Fraps includes both gamma settings and con_noprint data while capturing screenshots, awesome.

Yeah, sceenshots are taken with gamma 1.0. Not sure why that would ruin anything though. If anything, you should get more contrasty look, but that's all. I just add gamma in IrfanView before saving the image for web.

Just make what you want to make, and post ingame screenshots when you're done with textures and materials. That will speak more than walls of text.

Dammit, it looks like the problem still persists. I fired up TDM today and the old path still shows up during loading. I deleted all the files, saved the map in DR and then dmapped it, and that old path is still there. Maybe I should delete the .ase model and export it again. My mistake, I pasted old code in my material file, it still had the previous texture name in // TDM Ambient Method Related section. It's all good now

Good find! That did it. I opened all map files with notepad and searched for the old path, but it wasn't there. Looks like it's a good idea to delete files generated with dmap and gnerate them again, if you changed texture path or model name. Thanks again!

This is an unwrapped texture, so it can't be used on brushes or other meshes. I searched the map files, but there are no traces of the old name here. Same for the model. Actually you can see many errors like that during loading, for many FMs, while everything is fine, so paths must have been replaced correctly. Wonder where game keeps getting that information from.

I had con_noprint set to 0 for quite some time now, both for use with r_showprimitives command, and because it displays helpful info during loading. It also displays many path errors, both while TDM main menu is loading and during FM loading. Lately I’ve changed a name and textures/material names for one of my meshes. Everything updated correctly, I but still see a warning about textures with previous name missing. Looks like that information is still stored somewhere. Is it possible to get rid of it? I’d like to keep my log clean so I don’t miss anything important.

Well that more complicated actually. Let's take a look at example that works. This is a wooden + metal surface, diffuse texture: If you use B&W spec, it will look like something between plastic and metal. But if you use something like this: It will look like this ingame: The light source is white, reflection on wooden panels is white, and metal reflection is a bit colored, as it should.

Frob bias should do, or maybe making things unfrobabble until the lid is open, which I saw in a few maps already. I also saw cases where you could frob chests in addition to chest lids, and I bet that causes a lot of trouble as well. IMO as a rule of thumb, only lids should be made frobbable.

I don't know the specifics, but TDS used frob_bias parameter do sort out what is frobbed in the first place, when you had several objects in a chest or just placed next to each other. Another, a bit more arbitrary solution that comes to my mind is a script that would temporarily disable frob on a container, right after player opens it, until he/she gets all the content, so there's no frob conflict.

You actually don't need that in UE 3 (they correctly assumed that most surfaces out there are not metals and default specular color is white), but if you did, that's how it would probably look like, maybe with some minor tweaks here and there: If you can achieve something like that in TDM, that would be great.

It's more pronounced in motion, but while the original material looks like a plaster wall, the colored version behaves like metallic surface. It's a wrong material. To make it right, you'll need to get the the value from colored and invert it, and then properly blend it with specular (add, blend?). Not sure how to do this though.

Fog light is actually cheaper than ambient light. It can be a bit difficult to use, as Obs said, and it doesn't have a minumum range, it always starts at player POV.

Much greater speed of work and ability to experiment. You can stare at empty notepad all you want, but when you have all types of nodes listed and ready to use, at least you can try to combine them

In graphical interfaces for materials you have nodes to link. Nodes can contain samplers (texture sources), math functions, single or combined channels (R, G, B or A), etc. You chain them and then you link them to proper slot (diffuse, specular etc.).

Using solid colors with textures or stuff like storing multiple masks in one texture are pretty old technique. Thing is, in other engines you just set up a node or two and link them. Meanwhile here...

Here are the textures, you should probably scale them down by to 1024 to fit to TDM assets. It works well with colored modifier, although this needs further refinement IMO. Basic problem with isolator materials is that they need the base color to be inverted in specular to look right, while other parts of the texture need to be brighter or lighter, as needed. This specular is useful only for the base texture. When you use colors, the whole surface looks more like a metal (the light source gets color from the texture instead of being white). I'm not sure whether it's possible to have an automatic inverted value for diffuse color in specular, and even if so, it probably won't be enough. Still, it's always good to try https://www.dropbox.com/s/urwdmftdpnmvrng/plaster01.zip?dl=1

I have a 2048 plaster texture set that might be a good base for _colored parameters. Will check it tonight and post it here. Btw. parm11 > 0 section is responsible for frob, not for texture color.