peter_spy

Holy shit, fuck yeah! Finally! Edit: All in all, it's a balancing act. While having thousands of tiny models in your visleaf will be bad, combining everything into large models can hurt performance too. If the model is bigger than what you can see in your POV, and there are lights hitting it and casting shadows, those addidional DCs and shadows will impact your performance, even if you don't see such lights.

Why using some Urine3d when you can have an industry standard that is Disney BRDF, which is also open source, IIRC? https://github.com/wdas/brdf

Good thing that most maps run fairly well then, as this went unnoticed for quite some time, I think. Still, the easy workaround for that would be either using doors or using proximity-triggered visportals. Try to place a func_portal so it touches the visportal for the visleaf where portalsky material is located, then set up dist_check_period and portal_dist values. That should do the trick.

Views is usually set at 3, if you have a regular scene without stuff like mirrors and such. This is the scene with second visportal open: Now the second visportal is opened and "skybox" is visible. Note that number of views and texture memory used hasn't changed, so it was used by the skybox all along.

I'm still on 2.08, so maybe that has changed, but: The portalsky surface is behind the visportal that is closed, but look at the stats.

To be more precise and in terms of actual mapping scenarios: 1) If you have a portalsky surface in a current visleaf, but it's not in your field of view – it still gets rendered. 2) If you have a series of visleafs divided with portals, but with no additional setup (like doors or func_portals that force portals to close) – skybox still gets rendered, even if you see portals as marked as closed in your debug view. Only with portals that are forced to be closed by doors, func_portals and such, the portalsky skybox doesn't add to your performance stats and texture memory.

I've been meaning to recheck that some time ago but I forgot. I remember looking at the stats in older engine versions, and the additional subview + DCs and other stuff for skybox were always there. It's cool if this had been taken care of though

As long as nothing has changed on this during developement lately, the skybox is a sort of subview that is always rendered by default (or at least it uses GPU memory), even when player's inside. This is info_portal sky, which acts as a virtual 360° camera. If you want something more simple, you could just make a cubemap material and then apply in to 'ceiling' brushes for outside. Then it will be rendered only when you get outside, but its performance impact should be minimal.

FYI, speculars in Thief 3 were downright broken, that's why they weren't used. There was a specular slot in the materials, but I was never able to get a meaningful result there. That said, cubemaps were kinda broken as well. If you compare how cubemaps work here and in Thief 3, in TDM the reflection is modified by the normalmap, as it should. In Thief 3, it's sort of applied last, so it looks like a separate layer put on the top of diffuse and normalmap – unless you get rid of the diffuse texture. Then it gets modified by the normalmap, that's how they made the silver stuff for example. But anyway, Thief 3 isn't really a good example of how materials should be used, that renderer was seriously broken and it's nothing short of a miracle that two games were made on it.

That technique didn't become widespread until parallax-corrected cubemaps and then Disney's BRDF solution became available. There were custom solutions, like for UE3 there was Remember Me game, but it only around UE4 we're talking about standards. Plus I guess hardware had to catch up as well.

I can only assume the lighting setup was corrected to match textures that were adjusted for PBR. While non-pbr can use full 0-255 intensity range for diffuse (although it shouldn't), PBR base color needs to be between something like RGB 50 and 235.

Blend add mode is TDMs equivalent of emissive maps. I understood that totallytubular meant glass with cubemap reflection that is fairly bright, when put in area with ambient world only.

Interestingly enough, that was missing curly bracket in the material list section. Somehow that didn't bother DR at all. And yeah stuff like is always fun. Fortunately, that doesn't impact the model at all

Having more controls over how water looks might be interesting, but automating tile floor reflections isn't a good idea IMO. As with most materials in non-pbr setup, you have to author specularity and cubemaps per your lighting setup. E.g. cubemap reflections look very pronounced in dark areas and washed out in intensely lit places. There's no one-size-fits-all solution to that.

Don't get me wrong, it would make my model and material workflow like 10x easier I already own Substance tools, so with e.g. proper metallic-roughness workflow, I'd export all textures directly from Painter to TDM. I was just thinking, since TDM doesn't use specular workflow much at all (most surfaces have kind of chalk or powdery properties), switching to PBR makes little sense if you plan to maintain current approach, i.e. mostly no roughness maps. Otherwise, TDM will change style in a way that my custom project differs from current stock TDM assets.

Moving to PBR will require making roughness maps for all materials. All the base color textures will have to be reauthored too, as they need to use correct intensity range. Since non-pbr TDM stock assets use specular maps in like 1% of the cases, changing from non-pbr to pbr will in essence change the art style of TDM.

Seems like more trouble for Bloodlines 2: https://www.rockpapershotgun.com/vampire-the-masquerade-bloodlines-2-delayed-again-and-hardsuit-games-are-no-longer-developing-it

By the way, and maybe I'm misremembering this, but somehow you can't use .dds normalmaps at all now? I know there will be compression artifacts, but you'd expect you can use them, e.g. as a last resort, if you want to bring down the FM package size hard. I think it worked as for all other images. In 2.08 .dds normalmaps are just ignored, however compressed. Edit: yup, there are articles on the wiki that you shouldn't compress normalmaps to dds, but it was possible.

I don't work with other formats, but .ase is a plain text file and it has the material path there: IIRC, you don;t have to do that with .lwo

These artifacts also look similar to what you can get with either .dds or ingame compression. You can change these to 0 to make sure it's not that: image_useNormalCompression "0" image_useCompression "0"

I wasn't aware that SH modding community basically ripped every texture, model and other assets for every SH installment, and made it available for download. Maybe that's why they're freely available on other websites too. Konami doesn't seem to do anything about it, but obviously that's still copyright infringement.

It's not the same face.

It's not what I think. I get that having an encryption in GPL code is almost silly, but so is the stance of "every security can be broken, let's do nothing".All in all, if you want modern content creators to come and stay here, IMO you have to at least start thinking about offering something more than vague promises of community goodwill, and then blaming miscommunication, when something goes wrong. And lately it does go wrong, more and more often. Even TDM team can't be treated as role model here, as demonstrated above. I get that nobody's perfect, but people do tend to leave, or at least lose confidence after such incidents.

On one hand, you can find a big modding site where you can download like every model and every texture from every Silent Hill game, so it seems like Konami doesn't care much about that stuff, not outside Japan I'd guess. But that still is their intelectual property. In this particular case we're talking about player character from Silent Hill 3.

That was my first impression too. To be fair, I don't think I ever saw that face in TDM, maybe it's a leftover of some kind? Edit: Nope, that is Heather from SH3 available as one of the female heads: