nbohr1more

The ai_see spawnarg for lights allows mappers to attach a light to the player without affecting the lightgem. I don't recall seeing mention of that in the video.

Change to a higher soft shadow quality after starting your mission. For some reason switching missions breaks soft shadows. ( r_softShadowsQuality )

@Spooks Are you using single pass shadow maps? Disabling the single pass cvar should fix the missing AI and movable shadows.

As I recall, RGTC is just another name for Microsoft's BC4 or 5 This seems to confirm it: RGTC1_RED = BC4U, RGTC1_SIGNED_RED = BC4S, RGTC2_RG = BC5U, RGTC2_SIGNED_RG = BC5S

I set all TDM 2.07 settings to default and enabled postprocess then tried to eyeball the equivalent look in 2.08 With windowed mode and screens side by side. Here is what I currently have set: r_ssao_edgesharpness = "1" r_ssao_base = "0.1" r_ssao_intensity = "0.82" (tame darkening effect transition a little so ssao to non-ssao looks smoother) r_ssao_bias = "0.05" r_ssao_radius = "72" ( bigger radius has a richer effect but ssao=3 doubles this so if you use that mode set radius=36 ) r_ssao = "2" (less samples than 3 so less quality but better performance than 3) r_postprocess_desaturation = "0.05" r_postprocess_colorCorrectBias = "0.1" r_postprocess_colorCorrection = "5" r_postprocess_colorCurveBias = "0.95" (a little more contrast and brighter brights) r_postprocess_brightness = "1.0" r_postprocess_gamma = "1.22" r_ambientGamma="1.11" (compensate for gamma loss from color curve)

Yes, that is exactly what "SA" \ Share Alike means. You must "share" in the "exact same way" (alike).

This is how it works: NC == sell (we don't sell or do make any money from TDM) SA == or distribute any Content (modified or not) by themselves or in a texture pack, material, shader, scale modelling papers (pre-printed or digital), scrapbooking pack; The license from textures.com says you are allowed to share (distribute) within the context of a "full game asset with attribution" (model, map, etc). TDM distributes (shares) textures in the form of a full game package with attribution. Share Alike means that other projects can use TDM "game assets" and share them too as long as they also "follow these rules" (Alike).

The SSAO levels determine how far the effect spreads from the occlusion zones. They are presets that internally affect the base levels of the cvars so your cvar adjustments are relative to them. case 1: uniforms->maxMipLevel.Set(0); uniforms->numSpiralTurns.Set(5); uniforms->numSamples.Set(7); sampleRadius = 0.5f * r_ssao_radius.GetFloat(); break; case 2: uniforms->maxMipLevel.Set(MAX_DEPTH_MIPS); uniforms->numSpiralTurns.Set(7); uniforms->numSamples.Set(12); sampleRadius = r_ssao_radius.GetFloat(); break; case 3: default: uniforms->maxMipLevel.Set(MAX_DEPTH_MIPS); uniforms->numSpiralTurns.Set(7); uniforms->numSamples.Set(24); sampleRadius = 2.0f * r_ssao_radius.GetFloat();

Please experiment and compare to 2.07 You can also raise the r_ambientGamma to compensate for some of the darkening. Find a sweet spot with r_postprocess_brightness r_postprocess_gamma r_ambientGamma r_postprocess_colorCurveBias r_postprocess_desaturation

"Scalable Ambient Obscurence" Try lowering the r_ssao_base value to 0.3 or 0.4 (higher numbers are the cutoff to how dark it can be).

Bump. This is public now!!! Please engage with feedback

Now that I think of it, the major issue with our shipped shaders using makeIrradiance is that it wasn't quite compatible with the ARB shader. In 2.08 all ARB shaders are replaced by GLSL so that issue is gone. The only other concern is that makeIrradiance falls short in quality of a true irradiance image per the first post in this thread but mappers are free to create their own materials that don't use the keyword and bake their own irradiance textures per Spooks's recommendations. (I indicated to Duzenko that mappers would probably prefer that we simply make our shaders match quality to the external tool output but beggars can't be choosers and makeIrradiance still results in pretty nice ambient lighting.)

I hate to join the chorus of negativity but I honestly feel like Vulkan itself is a bad move. It pretends to be a modernized "clean slate" OpenGL but it really just encourages vendor lock-in since it is so closely tied to the hardware. It is mostly big industry players getting together and going "why do we need a flexible open standard when we are the only players left?" then collaborating on a standard that will only work for big industry players. The only thing I can say for it's defence is that OpenGL has been tainted by Nvidia's overwhelming ARB voting influence which has caused AMD to always be crippled in OpenGL performance. With Vulkan, AMD can equal or best Nvidia because they can force developers to write to their hardware directly. AMD is mostly behind this Vulkan push. They started things with their "Close to Metal" GPGPU initiative then developed Mantle then co-developed DX12. All these moves are addressing two issues at AMD. The aforementioned Nvidia control of the OpenGL standard and the fact that their driver teams are short staffed and less capable than Nvidia's. Why hire more OpenGL driver devs when you can get engine developers to write their own drivers via the Vukan or DX12 API? I can't fault it as a "strategy" but I'm not a fan of it as a standard. I guess PowerVR is pretty glad to see it too though. They also were living in the shadow of Nvidia's voting power in the OpenGL ARB and were happy to have a way to bypass that too (and even happier to offload driver development to engine devs).

Did you disable High DPI in Windows: https://wiki.thedarkmod.com/index.php?title=FAQ#Screen_is_Oversized_in_Fullscreen_Mode_.28Image_is_too_large_to_fit_the_screen_area_available.29 ?

Yes, that makes sense. We create a player entity flag then mappers can toggle the flag state with their script. And yes, I am well aware that using scripts to play with cvar settings is a bad practice but since the setcvar script event exists we should either make harmless by preventing it from archiving or remove it (presuming no mission uses it). So something like this wouldn't work? if ( LiveArchiveState ) { cvarSystem->ClearModifiedFlags( CVAR_ARCHIVE ); } LiveArchiveState=true then provoke the "LiveArchiveState=false" during the Setcvar script event ? Of course, I guess there is that funny little issue of "thread safe..."?