Jump to content
The Dark Mod Forums


  • Content Count

  • Joined

  • Last visited

  • Days Won


peter_spy last won the day on February 18

peter_spy had the most liked content!

Community Reputation

1603 Deity

About peter_spy

  • Rank
    Uber member
  • Birthday 01/01/1981

Profile Information

  • Gender
  • Location
    Central Europe
  • Interests
    Photography, 3d modeling, level design

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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
  6. 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.
  7. 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. B
  8. 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.
  9. 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.
  10. 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.
  11. 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
  12. 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.
  13. 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.
  14. 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.
  15. 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
  • Create New...