Spooks

How about a filtered search option? Instead of searching and scrolling through the search matches inside the entire list of entities/textures/etc. the windows would filter the folder tree to just show the entries in the list that match your typed search.

I've reopened #4686. Lest you forget, I had already provided a test map in there. r_fboseperatestencil plainly disables r_useFBO and prevents it from being on. In-game AA is the only way for the heathaze materials to appear correct with FBO on.

Hopping in to say parallel lights still borked on shadow maps.

I disagree. Billie Lurk is a good character (a bit superfluous in Dishonored 1 but good in 2) and if you couldn't connect with her that is perhaps on you, and moreover on the fact that you couldn't look past the qualities you described. Furthermore, DH2 gave you two character choices at the start, not two gender choices. The genders are incidental to the characterisation and everyone knows Emily's the correct choice to play as, as far as narrative coherence is concerned. Don't extrapolate to "most games do this" either, because you have to follow through with why you think they do this, and don't follow through here as this is still the DH2 thread. --- I am on Duke Luca Abelle's mansion mission as well, can't believe I bought DH2 at release and we've reached the patch where they have unlocked the pre-order bonuses I had and I still haven't finished the game. Waiting 10 minutes every time to start the game has definitely killed it for me, but if you say the DRM has been removed... it's going to be a fun experiment to see how fast it loads now, just because Denuvo is out... I'll have to pay extra attention next time I start the game.

Cesvaine Palace, Latvia. Very chunky exterior, reminiscent of a lot of our older textures.

That looks like an old bug not related to the BFG vertex cache beta, it's the same with glare particles and fog. Blend add on blend add or something, bleh, I don't remember. It is annoying to look at for sure. Duzenko actually added the afterfog sorting material keyword for 2.06 per my bug report of it, but 1) relevant glare particles haven't been updated with it (and it is not clear whether or not to change their behaviour now, to begin with) and 2) even if you put afterfog on that particle, I doubt it will solve the issue. Fwiw the keyword more or less does its job, it makes particles sort properly with foglights... last time I tested it, which was not on this beta. I may well be misunderstanding, but you're making it sound like it's purely for diagnostics. If so, why was it made on by default? I'll make my implicit point in my previous posts explicit: it looks broken, so the singlepass mode should either be fixed or be set back to 0 as default (if that's how it's meant to work).

That is not a decal-specific bug, every alpha surface goes opaque, including brushwork and models.

Double post, here's something else. I think we all tacitly know that the current state of the ambient lights is just a proof of concept and they will only be usable once development comes around to implementing automatic envshot taking and some sort of probing entity in the editor. Then, the irradiance maps would be generated by the engine. Related to this, and for right now, I've a problem with makeIrradiance. I don't know how it works (and if it was posted here I have forgotten about it) but really looks like there is no directionality to the lights (which is to say they don't get affected by the normals), it's like the cubemaps are reduced to 2x2 or something when using the keyword. It's functionally indistinguishable from an ambient light in that regard. Conversely, even a 64x64 envmap with gradients from photoshop looks better without the makeIrradiance keyword although, yes, it seems to blow up the specularity for no apparent reason. e: skipspecular 0 on the light or r_skipspecular in the console don't seem to remove the ambientcubemap's glossiness at all. e2: the texture being made glossy doesn't even have a specular map, so yeah. definitely something wrong with the implementation. edit 3: here have some screenshots An ambientCubeLight on a test normalmap, no specularmap without makeIrradiance and with, respectively. Note the differences. At places where the normal map is flat, you can see banding, which MIGHT be the banding VanishedOne is seeing.

I don't have a lot to add, I have not downloaded the test map, but I tested with my own: I can see very glossy results with the industrial cubemap. No banding, tested with GLSL on and off. Here is the kicker though, it's very much like you said, nbhor1more, you need the makeIrradiance keyword for the current version of the ambient cubic lights. It's just that seemingly none of the stock cubelights on offer have that keyword in their materials. While I can't say whether or not the banding VanishedOne shows in the bugtracker is not indicative of a bug, first order of business is fixing our materials to match the purpose of the lights, methinks. On the flipside, here's something nice. I used envshot in the process of testing and it works fine! No need to resize the window and it doesn't capture the console anymore. I don't have a skybox in the map so I don't know if that's still a problem, but if it is, it's one for another thread and not this one.

Hey hey, it's about The Timeless Way of Building! Melan recommended A Pattern Language, and this reminds me I should report back here now and say that I made it through most of that book over the summer. At about a thousand pages, it's encyclopaedic (in volume, and arguably in content as it goes down the checklist of the largest superstructures of government to the minute details of building), but I appreciate the recommendation. It's very good in making you think in terms of context as to what you are building, which would ideally be human habitats and all that this fact entails. Only some of its information is applicable to (TDM) level design however, due to engine and game ruleset limitations. I have been reading the Ecological Approach to Visual Perception by J.J. Gibson (while waiting on another visual literacy book, "Visual Intelligence: Perception, Image, and Manipulation in Visual Communication", to arrive) and I very much recommend Gibson if you hope to understand why and how we perceive our environment the way we do. It's a landmark work in optics (reading it I am fairly certain, though not for a fact, that he strongly influenced how PBR in CG is structured) and his concept of affordances is in wide use today and it is something you should familiarize yourself with. On the topic of less contemporary authors, I have good old John Ruskin waiting on the e-shelf here: http://www.gutenberg.org/files/17774/17774-h/17774-h.htm and am planning on going through these essays soon.

Yes, they do. Do remember r_maxShadowMapLight when testing! I blew up the parallel light volume during tests and it got sent to stencil shadows because it was too large, In Remembrance of Him's parallel lights may well go over your r_maxShadowMapLight value.

I tested the same location on the newest update. This is the SinglePass mode now defaulting to 1, it renders all apha materials opaque for the purposes of shadow casting. I already reported this, if you turn the cvar to 0 it fixes itself. @nbhor, I don't know about the size of the light volume, my test was on a very conventionally sized one (~5123) and the shadows were straight up busted rather than over-softened - they just weren't there. With soft shadows on they disappear, with them off there are thin streaks of shadow that dis/appear as you move and look around. Parallel lights with (soft) stencil shadows don't look wrong from what I can tell. I can also confirm the opaque blotches are now fixed but I can feel the optimization being gone, FPS dips to 40 now (down from, I don't remember ~50?), in my test scene with a bunch of alpha texture grates, with softshadow quality 16.

Further experimenting with lights. It seems parallel lights with shadow maps also have problems, the shadows do not display, or do only in part. This one's a bit harder to pin, no soft shadows are glitchy in a different way than with soft shadows, and it seems the higher the soft shadow quality the more diffused and weak the parallel light is.

In 2.06 it used to be positive values would just work with r_shadows 1 (the only shadow mode). I was going to say this extends to here and only shadow maps have a problem, but... On further testing positive values also break soft shadows for r_shadows 1! The shadows are there, they're just not softened. Again, it is specifically in spotlights, omni lights look fine. Setting the cvar to a negative value softens the shadows properly. I had to comb through the FM list for a while before I found a pre-existing place where the opaque blotches show up. You can see it in Sir Tallbot's Collateral: map kiss.map, g_showPlayerShadow 1 and notarget just so the guard doesn't bother you. The getviewpos is: -53.56 1057.18 172.25 40.4 179.3 0.0 Strafe left to right and look at the kitchen grate to see the blotches appear as your shadow intersects with the grate shadows. At SoftShadowsRadius -1 it's kind of minimal, but put it to something like -5 and it really shows. The SoftShadowsQuality can be conservative values, something between 16 and 32. My ShadowMapSize is 1024 as well. edit: Here's a screenshot of what it looks like and where the place is exactly in the map. It's in the kitchen area, ground floor, the unlit one of two pairs of fireplaces.

Hi. I just started Dark Mod today and all of a sudden shadow maps work with spotlights?? ¯\_(ツ)_/¯¯\_(ツ)_/¯¯\_(ツ)_/¯¯\_(ツ)_/¯¯\_(ツ)_/¯¯\_(ツ)_/¯¯\_(ツ)_/¯¯\_(ツ)_/¯¯\_(ツ)_/¯ I have no idea why it's working now, I changed no settings whatsoever. I'll point out that the fog flickering is still present and I'll be keeping an eye out for the spotlight issue reappearing in later updates, but for now... I guess we're cool? No! Wait! I literally just found out why this happens! Agh. OK, check this out: If r_softShadowsRadius is equal or greater than 0 the bug as I've described it appears. If r_softShadowsRadius is less than 0 - a negative value - the bug disappears. It doesn't matter if r_softShadowsQuality is at 0 or not (!), although the bug manifests differently when it's at 0, like I described in my original post. I must also report that at negative values of the r_softShadowsQuality cvar the shadows also disappear - but this happens with both r_shadows 1 and 2 and I don't think you're supposed to be inputting negative values for this one anyway. OK! With this mystery being solved I want to complain about these now: This is shadow maps with soft shadows on. The opaque splotches appear near thin shadows close together, like grates, or around the player's shadow and they're worse the lower the soft shadow quality value is. Having it higher, then, does help but I don't think it eliminates them entirely. I'm wondering if there's any way to lessen the issue, or if it's just a kink of the soft shadow implementation. Some scenes are bound to have these if a player has soft shadow quality on low settings, around 16 or so.

Double-post for another bug report: With r_shadowMapSinglePass 1, the shadow maps on alpha tested materials don't work anymore (it's back to solid shadows, like with stencils).

The file signature is ‎Saturday, ‎September ‎22, ‎2018, ‏‎6:50:07 PM, so yes, I agree it's too old I really can't think of an FM with a spotlight off the top of my head... Just a minute... Okay, King of the Mountain by Spoonman has a corridor with a bunch of spotlights. Here is the save file: https://drive.google.com/file/d/14U4pyOk8tMwIhpngLd0_vj1DGfnJdpiX/view?usp=sharing noshadowshere.txt (if you need to create it) says: "noshadowshere""kotm""" This was saved with TheDarkModx64.exe from update 15, in case that's important. I recommend g_showPlayerShadow 1 because there aren't any shadowcasting objects besides the patrolling guard.

Excuse me, could you be more specific? r_shadows 1 vs 2? The output from DarkModNoTools.exe vs regular DarkMod.exe? edit: looking over the condump, perhaps this is the salient point here: OpenGL vendor: NVIDIA Corporation OpenGL renderer: GeForce GTX 950/PCIe/SSE2 OpenGL version: 4.6.0 NVIDIA 390.77 [yadda yadda yadda] ---------- R_ReloadGLSLPrograms_f ----------- interaction VF ambientInteraction VF interactionN VF stencilShadow VF shadowMap VGFWARNING:shaderCompileFromFile(glprogs/shadowMap.fs) validation 0(9) : error C7566: in blocks require #version 150 or later 0(9) : error C0000: ... or #extension GL_ARB_gpu_shader5 : enable 0(17) : warning C7533: global variable gl_FragColor is deprecated after version 120 with DarkModNoTools.exe, which has somewhat working shadow maps. No such warning with the DarkMod.exe from update 15: ---------- R_ReloadGLSLPrograms_f ----------- interactionA VF ambientInteraction VF stencilShadow VF shadowMapA VGF oldStage VF depthAlpha VF fog VF blend VF cubeMap VF interactionN VF shadowMapN VGF

No dice, I'm afraid. Still flickering, still no lights when SoftShadows=0 and lights w/o shadows when SoftShadows=/=0. quick edit: Ah, check this one out, though. On a lark, I launched DarkModNoTools.exe, the executable duzenko provided in the GLSL skybox testing thread. With it, shadows on spotlights show, but they are very low-res (I can't quantify how it looks, but let's say a magnitude lower than whatever the MapSize is set to). Shadow maps from omni lights seem fine, but both omni and spotlights are unaffected by SoftShadows. Fog flickering still persists.

Yes, I mean the 1D+2D spotlights. Tried the single pass mode and some misc settings like FBO but it didn't change anything.

Both problems I listed persist under update 15.

Off-topic being that and all, I still linked it because it's a great example of IRL kitbashing

Hi, I decided to download beta 14 to try out the shadow maps. Regarding them, I have two things to report. 1) Projected lights. Projected lights (as opposed to Omni ones, in DR) don't seem to work properly with shadow maps. The behaviour is weird. If r_softShadowsQuality = 0, a projected light doesn't show up at all. If r_softShadowsQuality ≠ 0, projected lights will appear but they won't cast any shadows. In both cases, shadow maps for omni-directional lights work for me. 2) Z-fighting with shadow textures when foglight present. I happened to be testing this on a WIP map that has sealing brushwork with the shadowcaulk texture. On top of those, I have architectural modules with normal textures, with some of the faces being coplanar with the shadowcaulk brushes. I also have a map-wide foglight. with r_shadows 2, there is z-fighting between the shadowcaulk texture and the normal one. r_skipfoglights removes the z-fighting, meaning the problem is with the foglights. I tested in a more controlled setting. I made a brush with a regular texture, duplicated it in place and textured the second brush with the "shadow" devtexture. This time, instead of z-fighting, it looked like the entire regular-textured brush was getting double-fogged because of the "shadow" duplicate brush. When I changed the dimensions of the shadow brush while still keeping one side of it flush to the original brush, I got the z-fighting. Shadow volumes don't have this issue.

Alt+Shift+LMB for single select. Shift+LMB for multi-select.