之前对实时渲染(RealTimeRendering)的殿堂就十分向往,也有简单了解过实时渲染中的光,无奈一直没能系统学习。鉴于笔者已经有一点 CesiumJS 源码基础,所以就抽了一个周末跟了跟 CesiumJS 中的光照初步,在简单的代码追踪后,发现想系统学习光照材质,仍然是需要 RTR 知识的,这次仅仅了解了光在 CesiumJS 底层中是如何从 API 传递到 WebGL 着色器中去的,为之后深入研究打下基础。
CesiumJS 支持的光的类型比较少,默认场景光就一个太阳光:
// Scene 类构造函数中
this.light = new SunLight();
从上面这代码可知,CesiumJS 目前场景中只支持加入一个光源。
查阅 API,可得知除了 SubLight 之外,还有一个 DirectionalLight,即方向光。
官方示例代码《Lighting》中就使用了方向光来模拟手电筒效果(flashLight)、月光效果(moonLight)、自定义光效果。
方向光比太阳光多出来一个必选的方向属性:
const flashLight = new DirectionalLight({
direction: scene.camera.directionWC // 每帧都不一样,手电筒一直沿着相机视线照射
})
这个 direction 属性是一个单位向量即可(模长是 1)。
说起来归一化、规范化、标准化好像都能在网上找到与单位向量类似的意思,都是向量除以模长。
可见,CesiumJS 并没有内置点光源、聚光灯,需要自己写着色过程(请参考 Primitive API 或 CustomShader API)。
既然 CesiumJS 支持的光只有一个,那么调查起来就简单了。先给结论:
光是作为 Uniform 值传递到着色器中的。 先查清楚光是如何从 Scene.light 转至 Renderer 中的 uniform 的。
在 Scene 渲染一帧的过程中,几乎就在最顶部,Scene.js 模块内的函数 render 就每帧更新着 Context 对象的 uniformState 属性:
function render(scene) {
const frameState = scene._frameState;
const context = scene.context;
const us = context.uniformState;
// ...
us.update(frameState);
// ...
}
这个 uniformState 对象就是 CesiumJS 绝大多数统一值(Uniform)的封装集合,它的更新方法就会更新来自帧状态对象(FrameState)的光参数:
UniformState.prototype.update = function (frameState) {
// ...
const light = defaultValue(frameState.light, defaultLight);
if (light instanceof SunLight) { /**/ }
else { /**/ }
const lightColor = light.color;
// 计算 HDR 光到 this._lightColor 上
// ...
}
那么,这个挂在 Context 上的 uniformState 对象包含的光状态信息,是什么时候被使用的呢?下一小节 2.2 就会介绍。
在 Scene 的更新过程中,最后 DrawCommand 对象被 Context 对象执行:
function continueDraw(context, drawCommand, shaderProgram, uniformMap) {
// ...
shaderProgram._setUniforms(
uniformMap,
context._us,
context.validateShaderProgram
)
// ...
}
Context.prototype.draw = function (/* ... */) {
// ...
shaderProgram = defaultValue(shaderProgram, drawCommand._shaderProgram);
uniformMap = defaultValue(uniformMap, drawCommand._uniformMap);
beginDraw(this, framebuffer, passState, shaderProgram, renderState);
continueDraw(this, drawCommand, shaderProgram, uniformMap);
}
就在 continueDraw 函数中,调用了 ShaderProgram 对象的 _setUniforms 方法,所有 Uniform 值在此将传入 WebGL 状态机中。
ShaderProgram.prototype._setUniforms = function (/**/) {
// ...
const uniforms = this._uniforms;
len = uniforms.length;
for (i = 0; i < len; ++i) {
uniforms[i].set();
}
// ...
}
而这每一个 uniforms[i],都是一个没有公开在 API 文档中的私有类,也就是接下来 2.3 小节中要介绍的 WebGL Uniform 值封装对象。
进入 createUniforms.js 模块:
// createUniforms.js
UniformFloat.prototype.set = function () { /* ... */ }
UniformFloatVec2.prototype.set = function () { /* ... */ }
UniformFloatVec3.prototype.set = function () { /* ... */ }
UniformFloatVec4.prototype.set = function () { /* ... */ }
UniformSampler.prototype.set = function () { /* ... */ }
UniformInt.prototype.set = function () { /* ... */ }
UniformIntVec2.prototype.set = function () { /* ... */ }
UniformIntVec3.prototype.set = function () { /* ... */ }
UniformIntVec4.prototype.set = function () { /* ... */ }
UniformMat2.prototype.set = function () { /* ... */ }
UniformMat3.prototype.set = function () { /* ... */ }
UniformMat4.prototype.set = function () { /* ... */ }
可以说把 WebGL uniform 的类型都封装了一个私有类。
以表示光方向的 UniformFloatVec3 类为例,看看它的 WebGL 调用:
function UniformFloatVec3(gl, activeUniform, uniformName, location) {
this.name = uniformName
this.value = undefined
this._value = undefined
this._gl = gl
this._location = location
}
UniformFloatVec3.prototype.set = function () {
const v = this.value
if (defined(v.red)) {
if (!Color.equals(v, this._value)) {
this._value = Color.clone(v, this._value)
this._gl.uniform3f(this._location, v.red, v.green, v.blue)
}
} else if (defined(v.x)) {
if (!Cartesian3.equals(v, this._value)) {
this._value = Cartesian3.clone(v, this._value)
this._gl.uniform3f(this._location, v.x, v.y, v.z)
}
} else {
throw new DeveloperError(`Invalid vec3 value for uniform "${this.name}".`);
}
}
在 2.2 小节中有一个细节没有详细说明,即 ShaderProgram 的 _setUniforms 方法中为什么可以直接调用每一个 uniforms[i] 的 set()?
回顾一下:
Scene.js 的 render 函数内,光的信息被 us.update(frameState) 更新至 UniformState 对象中;
ShaderProgram 的 _setUniforms 方法,调用 uniforms[i].set() 方法, 更新每一个私有 Uniform 对象上的值到 WebGL 状态机中
是不是缺少了点什么?
是的,UniformState 的值是如何赋予给 uniforms[i] 的?
这就不得不提及 ShaderProgram.js 模块中为当前着色器对象的 Uniform 分类过程了,查找模块中的 reinitialize 函数:
function reinitialize(shader) {
// ...
const uniforms = findUniforms(gl, program)
const partitionedUniforms = partitionUniforms(
shader,
uniforms.uniformsByName
)
// ...
shader._uniformsByName = uniforms.uniformsByName
shader._uniforms = uniforms.uniform
shader._automaticUniforms = partitionedUniforms.automaticUniforms
shader._manualUniforms = partitionedUniforms.manualUniforms
// ...
}
它把着色器对象上的 Uniform 全部找了出来,并分类为:
_uniformsByName - 一个字典对象,键名是着色器中 uniform 的变量名,值是 Uniform 的封装对象,例如 UniformFloatVec3 等
_uniforms - 一个数组,每个元素都是 Uniform 的封装对象,例如 UniformFloatVec3 等,若同名,则与 _uniformsByName 中的值是同一个引用
_manualUniforms - 一个数组,每个元素都是 Uniform 的封装对象,例如 UniformFloatVec3 等,若同名,则与 _uniformsByName 中的值是同一个引用
_automaticUniforms - 一个数组,每个元素是一个 object 对象,表示要 CesiumJS 自动更新的 Uniform 的映射关联关系
举例,_automaticUniforms[i] 用 TypeScript 来描述,是这么一个对象:
type AutomaticUniformElement = {
automaticUniform: AutomaticUniform
uniform: UniformFloatVec3
}
而这个 _automaticUniforms 就拥有自动更新 CesiumJS 内部状态的 Uniform 值的功能,例如我们所需的光状态信息。
来看 AutomaticUniforms.js 模块的默认导出对象:
// AutomaticUniforms.js
const AutomaticUniforms = {
// ...
czm_sunDirectionEC: new AutomaticUniform({ /**/ }),
czm_sunDirectionWC: new AutomaticUniform({ /**/ }),
czm_lightDirectionEC: new AutomaticUniform({ /**/ }),
czm_lightDirectionWC: new AutomaticUniform({ /**/ }),
czm_lightColor: new AutomaticUniform({
size: 1,
datatype: WebGLConstants.FLOAT_VEC3,
getValue: function (uniformState) {
return uniformState.lightColor;
},
}),
czm_lightColorHdr: new AutomaticUniform({ /**/ }),
// ...
}
export default AutomaticUniforms
所以,在 ShaderProgram.prototype._setUniforms 执行的时候,其实是对自动统一值有一个赋值的过程,然后才到各个 uniforms[i] 的 set() 过程:
ShaderProgram.prototype._setUniforms = function (
uniformMap,
uniformState,
validate
) {
let len;
let i;
// ...
const automaticUniforms = this._automaticUniforms;
len = automaticUniforms.length;
for (i = 0; i < len; ++i) {
const au = automaticUniforms[i];
au.uniform.value = au.automaticUniform.getValue(uniformState);
}
// 译者注:au.uniform 实际上也在 this._uniforms 中
// 是同一个引用在不同的位置,所以上面调用 au.automaticUniform.getValue
// 之后,下面 uniforms[i].set() 就会使用的是 “自动更新” 的 uniform 值
const uniforms = this._uniforms;
len = uniforms.length;
for (i = 0; i < len; ++i) {
uniforms[i].set();
}
// ...
}
也许这个过程有些乱七八糟,那就再简单梳理一次:
Scene 的 render 过程中,更新了 uniformState
Context 执行 DrawCommand 过程中,ShaderProgram 的 _setUniforms 执行所有 uniforms 的 WebGL 设置,这其中就会对 CesiumJS 内部不需要手动更新的 Uniform 状态信息进行自动刷新
而在 ShaderProgram 绑定前,早就会把这个着色器中的 uniform 进行分组,一组是常规的 uniform 值,另一组则是需要根据 AutomaticUniform(自动统一值)更新的 uniform 值
说到底,光状态信息也不过是一种 Uniform,在最原始的 WebGL 学习教材中也是如此,只不过 CesiumJS 是一个更复杂的状态机器,需要更多逻辑划分就是了。
上面介绍完光的类型、在 CesiumJS 源码中如何转化成 Uniform 并刷入 WebGL,那么这一节就简单看看光的状态 Uniform 在着色器代码中都有哪些使用之处。
PointCloud.js 使用了 czm_lightColor。
找到 createShaders 函数下面这个分支:
// Version 1.104
function createShaders(pointCloud, frameState, style) {
// ...
if (usesNormals && normalShading) {
vs +=
" float diffuseStrength = czm_getLambertDiffuse(czm_lightDirectionEC, normalEC); \n" +
" diffuseStrength = max(diffuseStrength, 0.4); \n" + // Apply some ambient lighting
" color.xyz *= diffuseStrength * czm_lightColor; \n";
}
// ...
}
显然,这段代码在拼凑顶点着色器代码,在 1.104 版本官方并没有改变这种拼接着色器代码的模式。
着色代码的含义也很简单,将漫反射强度值乘上 czm_lightColor,把结果交给 color 的 xyz 分量。漫反射强度在这里限制了最大值 0.4。
漫反射强度来自内置 GLSL 函数 czm_getLambertDiffuse(参考 packages/engine/Source/Shaders/Builtin/Functions/getLambertDiffuse.glsl)
Primitive API 材质对象的默认着色方法是 冯氏着色法(Phong),这个在 LearnOpenGL 网站上有详细介绍。
调用链:
MaterialAppearance.js
┗ TexturedMaterialAppearanceFS.js ← TexturedMaterialAppearanceFS.glsl
┗ phong.glsl → vec4 czm_phong()
除了 TexturedMaterialAppearanceFS 外,MaterialAppearance.js 还用了 BasicMaterialAppearanceFS、AllMaterialAppearanceFS 两个片元着色器,这俩也用到了 czm_phong 函数。
看看 czm_phong 函数本体:
// phong.glsl
vec4 czm_phong(vec3 toEye, czm_material material, vec3 lightDirectionEC)
{
// Diffuse from directional light sources at eye (for top-down)
float diffuse = czm_private_getLambertDiffuseOfMaterial(vec3(0.0, 0.0, 1.0), material);
if (czm_sceneMode == czm_sceneMode3D) {
// (and horizon views in 3D)
diffuse += czm_private_getLambertDiffuseOfMaterial(vec3(0.0, 1.0, 0.0), material);
}
float specular = czm_private_getSpecularOfMaterial(lightDirectionEC, toEye, material);
// Temporary workaround for adding ambient.
vec3 materialDiffuse = material.diffuse * 0.5;
vec3 ambient = materialDiffuse;
vec3 color = ambient + material.emission;
color += materialDiffuse * diffuse * czm_lightColor;
color += material.specular * specular * czm_lightColor;
return vec4(color, material.alpha);
}
函数内前面的计算步骤是获取漫反射、高光值,走的是辅助函数,在这个文件内也能看到。
最后灯光 czm_lightColor 和材质的漫反射、兰伯特漫反射、材质辉光等因子一起相乘累加,得到最终的颜色值。
除了 phong.glsl 外,参与半透明计算的 czm_translucentPhong 函数(在 translucentPhong.glsl 文件中)在 OIT.js 模块中用于替换 czm_phong 函数。
在 Globe.js 中使用的 GlobeFS 片元着色器代码中使用到了 czm_lightColor,主要是 main 函数中:
void main() {
// ...
#ifdef ENABLE_VERTEX_LIGHTING
float diffuseIntensity = clamp(czm_getLambertDiffuse(czm_lightDirectionEC, normalize(v_normalEC)) * u_lambertDiffuseMultiplier + u_vertexShadowDarkness, 0.0, 1.0);
vec4 finalColor = vec4(color.rgb * czm_lightColor * diffuseIntensity, color.a);
#elif defined(ENABLE_DAYNIGHT_SHADING)
float diffuseIntensity = clamp(czm_getLambertDiffuse(czm_lightDirectionEC, normalEC) * 5.0 + 0.3, 0.0, 1.0);
diffuseIntensity = mix(1.0, diffuseIntensity, fade);
vec4 finalColor = vec4(color.rgb * czm_lightColor * diffuseIntensity, color.a);
#else
vec4 finalColor = color;
#endif
// ...
}
同样是先获取兰伯特漫反射值(使用 clamp 函数钉死在 [0, 1] 区间内),然后将颜色、czm_lightColor、漫反射值和透明度一起计算出 finalColor,把最终颜色值交给下一步计算。
这里区分了两个宏分支,受 TerrainProvider 影响,有兴趣可以追一下 GlobeSurfaceTileProvider.js 模块中 addDrawCommandsForTile 函数中 hasVertexNormals 参数的获取。
在 1.97 大改的 Model API 中,PBR 着色法使用了 czm_lightColorHdr 变量。czm_lightColorHdr 也是自动统一值(AutomaticUniforms)的一个。
在 Model 的更新过程中,有一个 buildDrawCommands 的步骤,其中有一个函数 ModelRuntimePrimitive.prototype.configurePipeline 会增减 ModelRuntimePrimitive 上的着色阶段:
ModelRuntimePrimitive.prototype.configurePipeline = function (frameState) {
// ...
pipelineStages.push(LightingPipelineStage);
// ...
}
上面是其中一个阶段 —— LightingPipelineStage,最后在 ModelSceneGraph.prototype.buildDrawCommands 方法内会调用每一个 stage 的 process 方法,调用 shaderBuilder 构建出着色器对象所需的材料,进而构建出着色器对象。过程比较复杂,直接看其中 LightingPipelineStage.glsl 提供的阶段函数:
void lightingStage(inout czm_modelMaterial material, ProcessedAttributes attributes)
{
// Even though the lighting will only set the diffuse color,
// pass all other properties so further stages have access to them.
vec3 color = vec3(0.0);
#ifdef LIGHTING_PBR
color = computePbrLighting(material, attributes);
#else // unlit
color = material.diffuse;
#endif
#ifdef HAS_POINT_CLOUD_COLOR_STYLE
// The colors resulting from point cloud styles are adjusted differently.
color = czm_gammaCorrect(color);
#elif !defined(HDR)
// If HDR is not enabled, the frame buffer stores sRGB colors rather than
// linear colors so the linear value must be converted.
color = czm_linearToSrgb(color);
#endif
material.diffuse = color;
}
进入 computePbrLighting 函数(同一个文件内):
#ifdef LIGHTING_PBR
vec3 computePbrLighting(czm_modelMaterial inputMaterial, ProcessedAttributes attributes)
{
// ...
#ifdef USE_CUSTOM_LIGHT_COLOR
vec3 lightColorHdr = model_lightColorHdr;
#else
vec3 lightColorHdr = czm_lightColorHdr;
#endif
vec3 color = inputMaterial.diffuse;
#ifdef HAS_NORMALS
color = czm_pbrLighting(
attributes.positionEC,
inputMaterial.normalEC,
czm_lightDirectionEC,
lightColorHdr,
pbrParameters
);
#ifdef USE_IBL_LIGHTING
color += imageBasedLightingStage(
attributes.positionEC,
inputMaterial.normalEC,
czm_lightDirectionEC,
lightColorHdr,
pbrParameters
);
#endif
#endif
// ...
}
#endif
故,存在 USE_CUSTOM_LIGHT_COLOR 宏时才会使用 czm_lightColorHdr 变量作为灯光颜色,参与函数 czm_pbrLighting 计算出颜色值。
除了光颜色本身,我在着色器代码中看到被应用的还有光线的方向,主要是 czm_lightDirectionEC 等变量,光照材质仍需一个漫长的学习过程。
一、引擎主循环UE版本:4.27一、引擎主循环的位置:Launch.cpp:GuardedMain函数二、、GuardedMain函数执行逻辑:1、EnginePreInit:加载大多数模块int32ErrorLevel=EnginePreInit(CmdLine);PreInit模块加载顺序:模块加载过程:(1)注册模块中定义的UObject,同时为每个类构造一个类默认对象(CDO,记录类的默认状态,作为模板用于子类实例创建)(2)调用模块的StartUpModule方法2、FEngineLoop::Init()1、检查Engine的配置文件找出使用了哪一个GameEngine类(UGame
1.回顾.TransportServicepublicclassTransportServiceextendsAbstractLifecycleComponentTransportService:方法:1publicfinalTextendsTransportResponse>voidsendRequest(finalTransport.Connectionconnection,finalStringaction,finalTransportRequestrequest,finalTransportRequestOptionsoptions,TransportResponseHandlerT>
参考文章搭建文章gitte源码在线体验可以注册两个号来测试演示图:一.整体介绍 介绍SignalR一种通讯模型Hub(中心模型,或者叫集线器模型),调用这个模型写好的方法,去发送消息。 内容有: ①:Hub模型的方法介绍 ②:服务器端代码介绍 ③:前端vue3安装并调用后端方法 ④:聊天室样例整体流程:1、进入网站->调用连接SignalR的方法2、与好友发送消息->调用SignalR的自定义方法 前端通过,signalR内置方法.invoke() 去请求接口3、监听接受方法(渲染消息)通过new signalR.HubConnectionBuilder().on
快速导航(持续更新中…)Cesium源码解析一(terrain文件的加载、解析与渲染全过程梳理)Cesium源码解析二(metadataAvailability的含义)Cesium源码解析三(metadata元数据拓展中行列号的分块规则解析)Cesium源码解析四(Quantized-Mesh(.terrain)格式文件在CesiumJS和UE中加载情况的对比)目录1.前言2.本篇的由来3.terrain文件的加载3.1更新环境3.2更新和执行渲染命令3.3数据优化3.4结束当前帧4.总结1.前言 目前市场上三维比较火的实现方案主要有两种,b/s的方案主要是Cesium,c/s的方案主要是u
Iparking停车收费管理系统-可商用介绍Iparking是一款基于springBoot的停车收费管理系统,支持封闭车场和路边车场,支持微信支付宝多种支付渠道,支持多种硬件,涵盖了停车场管理系统的所有基础功能。技术栈Springboot,MybatisPlus,Beetl,Mysql,Redis,RabbitMQ,UniApp功能云端功能序号模块功能描述1系统管理菜单管理配置系统菜单2系统管理组织管理管理组织机构3系统管理角色管理配置系统角色,包含数据权限和功能权限配置4系统管理用户管理管理后台用户5系统管理租户管理多租户管理6系统管理公众号配置租户公众号配置7系统管理操作日志审计日志8系统
大家好,我叫胡飞虎,花名虎仔,目前负责云效旗下产品Codeup代码托管的设计与开发。代码作为企业最核心的数据资产,除了被构建、部署之外还有更大的价值。为了帮助企业和团队挖掘更多源代码价值以赋能日常代码研发、运维等工作,云效代码团队在大数据和智能化方向进行了一系列的探索和实践(例如代码搜索与推荐),本文主要介绍我们如何通过直接打通源代码来提高研发与运维效率。随着微服务架构的流行,一个业务流程需要多个微服务共同完成。一旦出现问题,运维人员在面对数量多、调用链路复杂的情况下,很难快速锁定导致问题发生的罪魁祸首:代码。为了提高排查效率,目前常见的解决方案是:链路跟踪+日志分析工具相结合。即通过链路跟踪
运行有问题或需要源码请点赞关注收藏后评论区留言一、利用ContentResolver读写联系人在实际开发中,普通App很少会开放数据接口给其他应用访问。内容组件能够派上用场的情况往往是App想要访问系统应用的通讯数据,比如查看联系人,短信,通话记录等等,以及对这些通讯数据及逆行增删改查。首先要给AndroidMaifest.xml中添加响应的权限配置 下面是往手机通讯录添加联系人信息的例子效果如下分成三个步骤先查出联系人的基本信息,然后查询联系人号码,再查询联系人邮箱代码 ContactAddActivity类packagecom.example.chapter07;importandroid
信息数智化招采系统服务框架:SpringCloud、SpringBoot2、Mybatis、OAuth2、Security前端架构:VUE、Uniapp、Layui、Bootstrap、H5、CSS3涉及技术:Eureka、Config、Zuul、OAuth2、Security、OSS、Turbine、Zipkin、Feign、Monitor、Stream、ElasticSearch等企业电子化采购系统企业电子化采购系统是明理公司在多家大、中、小型企业采购需求的分析与实际应用的基础上,结合企业采购流程优化再造理念开发的一体化电子招标采购平台,对于招标项目提供交易过程的全流程电子化、规范化管
有符号距离场(SDF:SignedDistanceField)是距离场的一种变体,它在3D(2D)空间中将位置映射到其到最近平面(边缘)的距离。距离场在图像处理、物理学和计算机图形学等许多研究中都有应用。在计算机图形的上下文中,距离场通常是有符号的,表示某个位置是否在网格内。在计算机图形学和游戏开发中,SDF显示出极大的通用性,它可以用于碰撞测试、网格表示、光线追踪等。此外,人们发现它在使用光线追踪渲染场景时也有一些好处(即,ray-marching)算法——几乎不需要额外成本就可以产生像软阴影和环境光遮蔽这样的阴影效果。这个项目是关于实时光线行进渲染器的从零开始的C++实现,它包括一个SDF
目录springSecurity授权权限管理策略基于url的权限管理基于方法的权限管理将url权限管理设为动态会话管理会话并发管理会话失效处理禁止再次登录会话共享源码分析CSRF跨站请求伪造开启CSRF防御传统web开发前后端分离开启CSRF防护csrf防御过程CORS跨域问题springBoot解决跨域的三种方式springSecurity解决跨域springSecurity授权认证与授权解耦授权:据系统提前设置好的规则,给用户分配可以访问某一个资源的权限,用户根据自己所具有权限,去执行相应操作。GrantedAuthority应该如何理解呢?是角色还是权限?权限是具体一些操作,角色是一些权