安装 Steam
登录
|
语言
繁體中文（繁体中文）
日本語（日语）
한국어（韩语）
ไทย（泰语）
български（保加利亚语）
Čeština（捷克语）
Dansk（丹麦语）
Deutsch（德语）
English（英语）
Español-España（西班牙语 - 西班牙）
Español - Latinoamérica（西班牙语 - 拉丁美洲）
Ελληνικά（希腊语）
Français（法语）
Italiano（意大利语）
Bahasa Indonesia（印度尼西亚语）
Magyar（匈牙利语）
Nederlands（荷兰语）
Norsk（挪威语）
Polski（波兰语）
Português（葡萄牙语 - 葡萄牙）
Português-Brasil（葡萄牙语 - 巴西）
Română（罗马尼亚语）
Русский（俄语）
Suomi（芬兰语）
Svenska（瑞典语）
Türkçe（土耳其语）
Tiếng Việt（越南语）
Українська（乌克兰语）
报告翻译问题
Thank you for the Great Mod.
I use the Mod with BMCE and other mod´s , no problem so far.
And is unsubscribe deactivating it ?
I've also read the blog before! Very insightful stuff, and has helped with the dev of Black Mesa: Blue Shift. Actually it's inspired me to look into DirectX programming one of these days. All super interesting but I've not touched C in a few years.
Sounds like a bug that slipped through.We will look into this.
I would just like to clarify that Newlights implementation was based on ver4 of my hobby engine called https://chetanjags.wordpress.com/just-another-game-engine/
Ones that change the material, which is the underlying physical properties of a surface and chooses which textures are selected for that surface
Ones that ONLY change out the texture files.
There's not really an easy way for anyone to check without looking through the mod files to see if any VMTs are included, AND if they differ from the default.
Depending on which mod overwrites which, and if the texture mod edits the texture paths or not, you'll either: Get the textures you want but be missing the lambert fix, get the lambert fix but the surface won't be shaded the way the other mod intended, or, get the lambert fix but the default textures will be used.
One final question: Is this an exclusive thing to Black Mesa, or did it originate in the Source build where it was built from? Could it potentially be ported back into other Source builds, even if it required the SDK?
Were that the case, I can see why they appear to be mostly used in the Xen observatory labs, which are relatively cramped and small compared to bigger sections. Still, its an intriguing concept that could be ported to other sections of the game.
Newlights are rendered per pixel, which means the more space on your monitor a newlight takes up the more it costs. The more the lights overlap, the more pixels that need to be rendered to twice or more, costing more.
Shadow costs also vary depending on if the shadows are static, dynamic, or stationary. If dynamic or stationary, the more meshes that are casting shadows the more it cost. With static, shadows are rendered once and then never updated.
How expensive are they? Clearly, they seem to be mainly used to cast realistic shadows. I presume they may work similar to uberlights in SFM? In that case, perhaps they would work well in scenes like the beginning of Unforeseen Consequences, or most of On A Rail?
If you want, you can use this hotkey to toggle the gbuffer on and off, which will hide newlights so you can see better where they're used.
bind "=" "incrementvar r_gbuffer_disable 0 1 1"
And yea. I'm planning on making a newlight tutorial series because there's a lot of misconceptions and techniques people haven't figured out.
You can see the effects above as well, in the comparison screenshots. Notice how the back side of the crate is being lit despite there only being one source of light in the scene which is in front of it. Same for the scientist.