羊羊的博客

顺便提示一下，如果Unity6000打包apk不成功，可以优先考虑删除library+logs+temps缓存重启试试。已经老了，现在是Unity6000+AS panda3版本，顺便记录一下，免得每次用AI的时候细节问题总是错的。然后继续按照Unity2019的流程导入Unity6000并编写代码调用。最近又要整理unity和android交互功能了，以前的。手动新增MainActivity。新建No Activity。我喜欢在AS里提前操作。好了，完成交互过程。的第4步开始，到第9步结束。

因为我需要在arm linux国产系统上运行，目前wine+arm windows build才能满足条件，必须使用2023 or 6000，所以记录一下。同时在internation unityhub里下载模块导致部分成功部分失败，可以在temp文件夹中根据时间查找自己下载成功的模块。因为团结引擎的各种骚操作，导致unityhub下载安装新版本很麻烦，但是也有办法，记录一下。点击see all就能离线下载各个模块了。必须保证使用vpn的通道非亚洲区才行。再手动解压到Unity安装目录中。

这一步很坑爹，我刚开始死活找不到MyEditorUtilityWidget选项，后面直接创建MyEditorUtilityWidget的蓝图类MyEUWBlueprint后，选项就出现了，这不纯搞笑呢？以前在unity框架中开发了非常多实用且高频使用的编辑器工具，现在准备把目前用得上工具移植到ue4中。2.在控件中创建一个Button和一个EditableText，用于测试。最后，移植功能最方便的还是AI翻译，足以完成70%移植工作量。6.右键选择运行编辑器工具控件，则打开了编辑器窗口。

一种x轴朝前、y轴朝右、z轴朝上的坐标系。这就麻烦了，不论是左右手坐标系，我仅需少量修改就能自适应，避免改变美术输出资源的标准。我得在建模工具里预先把坐标系转换成左右手坐标系后，进ue4才能正常做几何运算，现在都搞不懂怎么跟美术同事一起定建模规范了。我个人还是比较喜欢标准左右手坐标系的三维引擎，几何算法匹配起来方便。网络模块通用性很高，毕竟协议都是通用网络协议，改造后没啥问题。然后按照左手坐标系的标准导出到ue4才能应用标准左手几何算法。同时自己的几何算法都是基于左手坐标系计算的。

可以看出TransparentObjectsDepth并没有被采样，我首先用deepseek重温了一下渲染管线工作流，盲猜因为TransparentObjects没有启用depth write导致depth采样无效的，只改了一下Lit.shader启用了zwrite on就好了。原理并不复杂，就是通过Pass采样TransparentObjects到齐次裁剪空间计算depth，输出一张TransparentDepthTexture。后面就是将我buildin和hdrp框架中的功能改造到urp就行。

希望pico后续尽快开放VST功能到消费端，毕竟现在全民短视频/直播时代，什么手机、无人机、运动相机都是大大方方摄像直播，不差一个头盔考虑隐私问题。最近用ffmpeg做了一个picoxr直播功能，发现在seethrough模式下，获取不了VST摄像头硬件的画面。还得买企业版联系官方给绑定，也就是说只能小规模定制性开发VST直播功能，闹呢？原来VST画面是后期合成的，也就是说开发阶段获取不到摄像头画面。背景画面是黑色的，采样不到VST的环境画面。上pico开发官网看了下文档，发现。

言归正传，这段时间基于urp14把开发框架整了一个分支（以前整过一份hdrp分支，因为我工作大部分是pc端），但是今年部门转型ar类项目，运行设备基于pico quest ipad hwpad等设备，所以上urp14了。博客也不想写了，因为被deepseek降维打击的感觉犹如我在田里面朝黄土背朝天一根一根插秧，突然旁边开来一辆自动插秧机~PS：虽然之前一直挂vpn用免费的gpt3.5，但是gpt3.5只能说just so so。我以为AI就那样了，看来还是我自己level low了几个级别。

一般我们开发都是基于一套完善的unity框架进行的，完全建一个new project就是干，这样开发不仅慢而且乱。我们组框架代码都有现成的，而且组员都熟练使用了，现在的问题就是怎么在一个new project或者years ago project项目上用起来。1.把框架整理到一个文件夹内，使用unitypackage或者copy/paste到其他工程使用，为此我写了一个cs脚本namespace批量添加/修改工具，避免类名冲突。就能按照以前的开发模式写功能了，非常适合临时小demo的开发。

常见的缩放功能是鼠标滚轮缩放物体，但是并非基于RayHitPoint，所以视觉上会偏移，为了修正偏移，实现基于RayHitPoint的缩放。原理是在缩放的同时，根据RayHitPoint相对坐标计算物体中心坐标，依据视椎平面相对位移*相对缩放即可。PS:其中有一些依赖函数是我框架代码内的，只标注意义，因为以前都有讲解过原理，所以节省篇幅。这次基于Camera视口（二维屏幕）+屏幕坐标（鼠标光标）来实现一套全新的物体RTS操作。这样就实现了一套Camera（用户）视角下，精准的RTS操作。

需要注意的是，因为我们是基于物体计算的，所以不存在物体时，先设定一个默认PlaneDistance，随后再根据平面Plane的Distance重载。原理就是计算摄像机到物体所在平面Plane（平行于视椎体）的距离，然后根据屏幕坐标计算在Plane上的移动坐标，用于摄像机的反向移动计算。我的CameraFps脚本用了很多年了，基本所有项目调整下参数拿着就用，没啥大问题。这样的Drag效果在精准微操的竞技游戏或者软件中比较常用。最近根据需求优化摄像机飞行操作，优化操作的精准性。

为了方便自测，需要用unity将一个工程打开多次，分别是Win/IOS/Android版本，进行多角色联调。），接下来用unity打开_android目录并切换到Android版本，即可完成同一工程打开Standalone/Android双版，只需开发Standalone版本会自动同步。，以Windows版本为主版本，使用mklink操作将工程文件链接到不同目录，然后就可以使用unity打开多次。会自动在父目录下创建_android目录，然后链接_standalone中关键的四个目录（

今天整理自己的框架代码，将Matrix2x2和Matrix3x3给扩展了一下，发现网上unity数学计算相关挺少的，所以记录一下。关于Matrix2x2，我设计了构造、转置、余子式（2x2矩阵的余子式为标量，或称1x1矩阵）、余子式标量矩阵、伴随矩阵和逆矩阵。OK，洗了睡，这里吐槽一下：这些矩阵计算unity应该直接提供，写起来眼睛都要看瞎了。基本上数学运算开发够用了，每个函数的意义只在代码注释上简单说明。

需要注意视点和起始终止相对坐标和texture3d采样配参一致，同时注意因为texture3d的储存方式从0号纹理开始已经有0.5的插值预留，所以我们进行zdimension计算的时候，用0.5的偏移做精准采样，避免模糊。我早期工作，在小作坊全栈的时候，做过一段时间web开发，做了一个古董藏品的h5展示，做法是360度拍摄各个角度的照片，然后在js中通过用户滑动屏幕切换不同角度的古董照片，模拟3d渲染的功能。缺点：采样纹理过大，所以想要达到正向效果，必须采样的对象是超精细场景或模型，不然得不偿失。

原理：获取中心点（centeruv）到当前像素（pixeluv）的朝向法向量（ndir），pixeluv沿着ndir进行向前向后的像素颜色采样，并叠加到当前像素颜色（pixelcolor）以pixeluv为起点，ndir为朝向，向外、向内、或两端同时采样颜色进行叠加，为了保证叠加后亮度的统一，除以采样次数进行衰减即可。和以前聊过的高斯滤器模糊有点类似，核心都是将其他像素颜色叠加到当前像素颜色，无非叠加的计算规则不同。径向模糊（也叫辐射模糊）：一种由内向外发散的模糊的效果。后处理着色器，原理就是叠加颜色。

dnf手游操作里，按两下后跳，就会朝着操作方向快速闪现，同时出现滞留残影，有时候会发生一个残影一直滞留的bug，满屏幕到处跑会产生满屏幕残影，可见dnf开发人员加班挺凶的，很多bug估计来不及修。dnf手游在作死的道路上越行越远，困难罗特斯完全打不动，提前在抖音上细看攻略，基本能躲过机制不死，但是伤害不够，全时打满也还剩3000+管血，组团半天+炸团半天=完全浪费一天。个人觉得策划完全没必要这么逼氪，毕竟才开服四个月，就马不停蹄的想逼玩家氪金，可见游戏后续发展基本玩不下去，最后记录一下用得上的功能就退游。

最近一个工程切换了最新的unity和packages，在外网开发没什么问题，切换到内网接入保密开发后，发现不论是操作编辑器还是编译代码，巨卡无比。以上是仅仅写了一句int a = 1;后，编译代码的速度。经过分析觉得，应该是某些库在联网直到TimeOut。重启电脑后，unity正常操作和编译代码。

画完之后我自己顺便把交互系统模块开发完成了，按照unity插件的制作方式，开发过程中，只要迷茫了或者卡壳了，看看构架图，一下就知道怎么往下继续开发了，挺方便的。如果遇到对编码质量有一定要求的项目（非一把梭撸完代码打包丢出去不管了），需要有一定可维护性，我觉得不妨做每个模块开发之前花一两个小时设计下构架图，事半功倍。再站在开发的角度，构建一份详细的模块构架设计图就更好了，这样不仅可以给开发提供编码的思路和规范，也可以保证最终交付的代码大差不差，所以返工会减低很多。

项目管理和工作分配

所以当UI策划和UI设计师完成UI模块的设计后，UI程序根据实际的UI界面业务功能，将一个UI模块划分为永远不动的静态元素（如各个背景）+一直在动的活动元素（如动态生成的物品），配合UI对象池的使用。当然已经生成生成好的复杂UI界面，在退出时也可根据UI管理器的调度策略，并不销毁，而是移动坐标到视口外，再次使用则可快速加载。地下城战斗系统这块，则是我的知识盲区了，虽然我做过卡牌战斗系统，但是和dnf这种手感的格斗游戏比起来，简直小巫见大巫，我一直觉得就手感这一块，没有超越dnf的格斗游戏。