逍遥剑客

参考https://www.artstation.com/artwork/3omYwB做一个这样的视图, 用于Debug光照亮度:需要获取当前像素的亮度(nit), 映射成一个颜色显示出来获取当前像素亮度正好在EyeAdaption Debug视图有一个nit显示:翻代码发现NIT/LUX值是在Shader中实现的(骚操作):向上查找Luminance来源自HDRSceneColorSampler:而HDRSceneColorTexture就是Toonmap前的SceneColor:

硬件配置配件型号CPUAMD 锐龙9 3950X 16核32线程主板华擎 B550M Steel Legend显卡AMD Radeon RX 5700 XT (8G GDDR6)内存美商海盗船 DDR4 3600 64GB(32G×2)SSD美商海盗船 Force MP600 2TB SSD PCI-E 4.0机箱恩杰 H510 白色 ATX机箱电源长城 额定650W G6金牌电源散热器利民 Frozen EYE 280 A.

最近在手机上尝试了一下把SceneColor改成R11G11B10, 使用FrameBufferFetch来读取深度.Android上可以使用framebuffer_fetch_depth_stencil, 但是iOS上不支持DepthFetch.所以就尝试使用MRT输出一个R16F的Depth, 需要依赖FramebufferFetchMRT的实现.4.26中UE4已经增加了延迟渲染, FramebufferFetchMRT已经实现了vk和metal的, 所以很方便地就合并了过来, 用法是这样的:

UE4如果需要在真机上测试, 通常编译+打包+安装需要很长的时间.所以UE4提供了Cook On The Fly的功能, 就是默认只编译, 资源的Cook在运行时由FileHostServer进行Cook, 这样就不用每次测试经历痛苦的打包过程.对于Android平台来说, 只需要安装apk, 资源文件(默认在obb里)仍然保存在PC机上, 通过网络进行访问.PC机做为FileHostServer, 对于请求的文件进行Cook , 如果没有请求的则不会进行Cook.但是对于公司的网络策略来说, 手机

如果是从源代码编译出来的UE4, 明明代码完全一样, 不同机器编译出来的dll却无法兼容, 这对于多分支开发非常不方便.在老版本里有个通过版本号判断的逻辑, 新版本改没了. 分析UE4源码后发现目前是通过BulidId来判断dll跟引擎是不是兼容的. 那BuildId是哪里来的呢?其实像发布的UE4版本是通过"-Formal"参数来生成固定的BuildId的, 不过我们也可以直接修改Engine/Build/Build.version来生成固定的BuildId:改完后如果代码一样, 不同机器

就是做了两层混合的材质, 采样了两TextureArray, 但是因为TextureIndex是动态计算的, 就会出现同一张纹理在不同的Texture2DArraySample里采样的情况, 然后就会出现一条一个像素宽的小缝.实验了一下, 只采样mip0或者两层纹理的UV一样的话, 就不会出现这个问题. 所以推测是采样时相邻像素是另一层纹理的UV, 导致miplevel计算错误, 然后这条线的上像素的mip是错的, 导致跟相邻像素无法连续.目前除了把纹理的UV(Tiling)改成一样的, 还没有想到.

最近疫情比较严重大家都是在家办公的, 需要远程登录公司里的开发机. 但是远程桌面无法直接启动Houdini, 会报OpenGL的错这个方法也适用于一些依赖OpenGL硬件加速的程序, 如Substance等原理就是中断当前远程登录的session, 然后再启动程序, 这时候就可以使用OpenGL加速了代价就是重新登录一次, 脚本是这样的:@echo offecho.echo Remo...

跟着教程做的一第一个模型attribute create节点uv flatten节点material编辑uv编辑

注: 文章是美术同事写的, 我只是放这里记录一下问题重点：需要将已有角色脸型模型的所有表情Blendshapes精确的重定向到另一个五官位置不一样，模型布线也不一样的角色上。首先因为两套角色五官不一样，所以单一通过Wrap变形器无法实现精确的重定向。其次，由于两个面部模型布线也不一样，也不能通过Blendshape直接实现变形。解决办法：（1）：首先将案例脸型用晶格变形来匹配我们目标角色...

http://blog.kiteandlightning.la/ue4-hlsl-shader-development-guide-notes-tips/Ctrl+Shift+.可以编译引擎Shader并重新载入, 但是对Plugins下的无效如果要在RenderDoc里看到Shader代码, 需要打开r.ShaderDevelopmentMode=1, r.Shaders.Optimize...

最近把HairWorks整合到了UE4 4.20, 整合的过程中发现了一些没法直接merge的代码, 主要集中在LightRendering.cpp和DeferredLightingPixelShader.usf中. 所以顺便简单读了一下代码, 把其中的一些关键字概念整理出来方便查阅理解.Uniform Buffer StructUE4使用了一些宏来辅助定义UniformBuffer中的结...

文章目录背景UE4的内存统计memreportMemoryProfiler2LLMAndroid进程内存DDMSMemoryAnalyzer背景UE4游戏在Android上的进程内存占用(PSS)很让人困惑, 没有一个清晰直观的方式可以统计到每一部分的内存占用. 所以在做内存分析的过程中顺手做了一个统计工具, 可以从系统底层统计UE4在Android的所有内存分配(包括Graphics部分),...

有这么个需求: 一堆不会动的SkinnedMesh, 通过物理模拟出死亡姿势后, 需要优化性能, 不然才10FPS首先想到的做法是转成StaticMesh. 试了一下直接超出了Unity的顶点Index数量限制, 所以放弃, 再说转换完后也不方便编辑. 另一个思路就是使用Instanced Skinned Mesh Rendering, 找到两个参考:https://github.com/Unit...

基本原理都差不多, 通过在VertexShader种更改顶点的位置实现, 各种做法的差别主要是偏移量的计算. 第一种做法: 根据顶点的UV来计算顶点偏移的权重, 因为草叶一般是沿纹理的一个轴方向分布的. 偏移的远近是根据顶点位置和玩家位置(寄存器传入)计算距离后得出. 第二种做法: 根据草的Pivot来计算旋转, 这种做法比直接拉伸顶点的效果要好一些, 不会出现草被拉长的情况. ...

共享代码进程间通信通信协议其它共享代码首先要做的, 是需要编辑器和Unity共享一部部分代码, 至少协议定义和解析我不想写两遍. 虽然有protobuf这样的工具库, 但是如果不是跨语言的话, 我觉得没必要引入另一套流程. 所以我就想能不能让一个C# dll库可以同时被Winforms的编辑器和Unity脚本引用呢? 考查了一下还是可以的:Unity的.Net默...

需求背景技术挑战GUI框架技术Unity渲染窗口GUIDockingProperty Editor小结需求背景用Unity开发的游戏, 需要做个关卡编辑器. 如果只是内部用用, 其实直接扩展Unity就够了; 但问题是需要发布给外部的用户使用, 那么总不能把全套资源和Unity发给他们, 所以就诞生了这么个奇葩需求. 技术挑战既然用了Unit...

参考: Networked Physics in Virtual Reality: Networking a stack of cubes with Unity and PhysX之前做VR游戏时也是尝试了几种物理的同步方案, 最近看到Oculus Blog上也分享了一些, 经验, 做个笔记.多人VR游戏中的物理交互, 有这么几个要求:玩家对物体交互不能有延迟物体能静止后稳定, 不...

UE4每次升级个版本总是要提交大量文件到Perforce, 是件很麻烦的事. 我们的引擎编译好了会连同Binaries一起上传, 这样美术和策划都可以直接使用跟程序一样的版本. 这样的话, Perforce上的引擎就需要有这些注意事项:引擎目录完全包含所有代码和引擎依赖资源引擎编译输出的dll, exe等也都需要提交, 保证策划和美术能够直接拉取引擎版本引擎编译过程中会写入的文件, 需要改成w

游戏中衣服换色是个很普遍的需求, 除直接替换贴图外, 还有使用程序参数来控制颜色的做法. 原理就是使用一张灰白Mask图, 乘一个颜色, 替换原Diffuse贴图上的颜色 效果如下: 这种制作方式有两个缺点: 一是换色区域只能换一个固定颜色, 只有明亮不一样; 二是如果让玩家来自定义颜色, 总会出现一些亮瞎眼的配色, 影响整个游戏的画面美感. 那有没有一种方法可以同时更换多

破CSDN的文章编辑器太难用了, 传个图要累死. 以后在知乎写完再转过来: https://zhuanlan.zhihu.com/p/28471808关于游戏中的捏人系统, 很少有资料提到怎么做, 印象中只有《天涯明月刀》分享过. 前段时间关注了个VR资源分享的公众号, 经常推送HS的捏人作品, 所以才引发了我的好奇心, 决定一探究竟.HS之所以能够有这么强的定制能力, 是因为第三方MOD工具的存...

以往做游戏换装什么的, 大多是使用骨骼来调整体型/脸型什么的, 这算是比较成熟的技术了. 最近的项目里尝试了使用MorphTarget(BlendShape)来做个事情, 好处是能够做到逐顶点的调节, 可以做出比较细腻的效果, 但是与此同时来带了制作成本的上升. 不过看目前AAA级的游戏这种做法已经比较普遍了, 所以还有必要把制作流程理一下. 常见的问题: 比如我们人的身体通过Morph做了胖瘦

去年在Oculus Connect 3体验过《Lone Echo》的多人竞技玩法, 品质很高, 算是VR游戏中的一线大作了. 正好今年GDC上他们分享了一些关于VR中角色动画的一些经验, 还是比较有借鉴意义的, 毕竟Avatar做了全身的VR游戏少之又少. 这是一个太空失重背景下的游戏, 可以用手抓住环境物体或者推墙进行反向的漂浮. 一开始他们是通过手部射线了检测是不是抓住静态几何体, 通过让身

很多游戏中都有, 就是角色转头+眼镜转动盯着一个目标看, 通常是盯着镜头看用的比较多 UE4里实现这个功能很容易, 直接在AnimGraph里使用LookAt结点就可以了 4个LookAt分别控制脖子, 头, 左眼, 右眼的朝向, 脖子和头的角度比眼睛小, 转动速度也比眼睛慢. 实际项目中用的时候, 有个需求是NPC播放一段动画师做的全身动画后, 再盯住玩家, 然后再播, 再盯, 如此循环.

介绍了一种很trick的优化方法: Stencil Mask 这里他们称之为Resolution Gradient 主要的思想跟NVIDIA的MultiRes Shading差不多, 但是不用依赖硬件的特性才能实现. 简单一点说就是, 因为VR显示器透镜变形的原因, 边缘的渲染分辨率用不着那么高, 中心区域是全分辨率就好了. 这个优化思路来自于GDC2016上”Fast and Flex

Eagle Flight是我认为目前品质达到”优秀”的VR游戏, 所以关于它的一些分享是非常有参考价值的 这个游戏有几点挑战: * 怎么让高速的飞行尽可能的舒适? 因为VR中的移动非常难保证不会晕 * 规模非常庞大的场景, 还有非常多的植被 * PC上要达到90FPS, PS4上要达到60FPS, 性能优化是一个挑战 第一个关键点: 飞行的方向就是你面向的方向, 没有漂移, 这样可以极

又是新的一年, 2016总体不错, 前两年的坚持和积累开始产生效果, 2017不忘初心, 继续前行. 从做PC网游开始, 到2014年做主机游戏, 2015年做单机VR游戏, 2016年做多人VR游戏, 我们一直在走一条非主流的路. 不过现在回头看看, 冒似绕了一条路走在了前面, 做为一名技术人员来说, 还是挺有成就感的. 看看目前绝大数的VR游戏, 其实就是美术做个场景, 程序实现一下交互,

LowPloy风格是一种小清新风格, 在美术设计上很有独特性. 典型的游戏作品有《纪念碑谷》《劳拉Go》等 2016上半年我们也进行过尝试, 从程序的角度来说, 这种风格是一种利好, 因为可以大大减少资源量, 对于性能的压力就小得多了, 所以在移动平台上会有比较好的性能表现. 这种风格在实际制作过程中, 反而不如传统的风格简单. 首先需要好的概念设计, 但是对于原画来说, 一般

看了一下UKismetProceduralMeshLibrary::SliceProceduralMesh的代码实现, 发现也没想像中的复杂, 只要把网格/三角形/顶点/边的关系理清楚, 逐步分解问题就可以把复杂问题给简化成一个个的小问题, 然后各个击破. 把注释和代码的步骤整理了一下, 变成了人话:把切割面从World转换到Local空间对于每个Section(SubMesh), 计算包围盒

很早之前玩过两个小众的潜入游戏, 分别是《Warp》和《Mark of the Ninja》, 就喜欢上了这类游戏, 不过对我口味的不多, MGS5算一个. 最近又玩了另外两个潜入游戏: 《Aragami》和《Dishonored》, 发现这两个游戏有一个共同点: 游戏中的移动频繁依赖传送. 因为自己正在做VR游戏项目, 所以自然而然地就联想到了VR上. 体验过VR的人都知道, 一动就容易晕. 对于

在VR游戏中, 使用双手(控制器)直接对虚拟世界中的对象进行交互, 已经成为一种”标准化”的设计, 一切看起来能够用手去交互的物体, 都需要附合物理规则. 简单的物理对象, 通常只是一个刚体(Rigidbody), 这种只需要模拟重力和惯性运动就可以了, 最多再调节一下摩擦力, 弹性, 空气阻力等, 所以在技术上借助物理引擎的帮助是比较简单的. 稍微复杂一点儿的物理对象, 是带有约束(Co

跟Delegate一起用FTimerDelegate TimerCallback;TimerCallback.BindLambda([]{ // callback;});FTimerHandle Handle;GetWorld()->GetTimerManager().SetTimer(Handle, TimerCallback, 5.0f, false);UI回调事件 SNew(S

OVRLipSync 是Oculus为Unity开发的一个口型同步插件, 能够实时处理语音数据转换成相应的口型, 按照它的规范, 一共有15个口型: 上面的截图是基于MorphTarget的, 这个插件也提供了基于贴图的表现形式: 通过分析插件可以知道, 核心算法封装在OVRLipSync.dll里, 这个dll经过我测试是可以独立运行的: 之前也有个人尝试把它整合进UE4:

背景Oculus的Touch, HTC Vive的Controller, PSVR的PS Move, 三家一线VR硬件都在给大家传达一个信息: VR下能够模拟双手的体感控制器是一个趋势. 在VR游戏中, 一旦有了双手, 这就意味着不光能看了…..如果说之前的VR游戏只是输出方式(显示器)发生了变化, 那现在有了个双手, 输入方式也发生了变化, 这对游戏来说是一个革命性的改变, 是完全可以改变用户体验

讲的是Gears of War 3中的Face Rig GOW3中的角色很多, 过场动画也很多, 这就带来了一些挑战:表情动画必须容易编辑在外包制作的基础可以建立良好的工作流动画数据可以共享给不同的模型 容易编辑体现在所有结点都是一条曲线, 这也保证了数据的简洁, 方便外包数据传输 灵感来自MGS4 XSI的文章 Rig分4层:Cage: 一个低面的几何体, 定义了面部的大部分

来源https://www.assetstore.unity3d.com/en/#!/content/63141 https://steamcommunity.com/games/250820/announcements/detail/604985915045842668前几天Valve放出来他们在The Lab中基于Unity做的一些渲染优化相关的东西, 对于VR开发者来说还是非常有参考价值的.

背景去年做了一个VR Demo后, 总是有各种参观啊, 演示啊, 讲座啊等, 然后很少有合格的电脑跑得动…有时又想现场演示下, 就只能把工作站抬过去了. 来回折腾几次就下定决心要装一台VR专用的演示机, 要求很明确: 小. 品牌主机如果想要GTX980级别显卡配置的, 几乎要么体积巨大, 要么价格巨贵, 排除. 那就自己DIY小机箱的PC吧, 只能选ITX规格了, 要求满足以下条件: *

物理模拟的问题物理模拟需要是确定性的吗?应该是发送物理对象的状态还是碰撞事件或者受力?使用UCP还是TCP发送数据?使用C/S还是P2P?需要一个DS吗?怎么隐藏玩家行为的延迟?怎么防止作弊?带宽同步策略帧同步只同步输入, 不同步状态优点: 带宽需求很低, 跟对象多少无关难点: 需要保证物理模拟是确定性的, 而浮点数很难保证确定性 随机数操作系统编译器硬件缺点: 需

注: 原文2016年2月发表于公司内部社区, 最近才由同事转载出来, 删去了文中引用的一些内部文章和视频. 在这里我也只是把外网版本转过来, 留做备份. 背景介绍我们组在2014年下半年尝试开发了一款 XboxOne 平台的体感游戏, 2015年上半年进行收尾工作的同时, 结合之前积累的体感交互经验, 开始进行 VR 游戏的预研工作. 在这近一年的时间里, 一方面从外界感受到了一股虚拟现实快速发展

Unity和UE4的Material Editor中都有类似VertexOffset的功能, 可以在VertexShader中驱动顶点, 做一些程序控制的顶点动画 用顶点动画的原因: 骨架是共享的, 骨骼动画是共享的等, 同时节省了骨骼数和动画师的工作量 使用cos三角函数+Time是基本的技巧, 配合顶点色控制每个部分的权重 材质参数暴露出来能够使用程序逻辑进行动态控制 顶

上篇已经能在VR中画出来了, 但是还存在两个问题: 1. 透明物体会被Native画的东西挡住 2. VR中Native画的东西透视关系有点问题, 跟Unity绘制的场景不能很好地融合在一起先来解决一个透明排序的问题, 这个问题有两个思路去解决:双Camera双Camera的思路就是, 一个Camera只画不透明物体, OnPostRender中回调Native Renderer, 另一个Cam

官方的Sample只是画了一个屏幕空间的三角形, 怎么改成世界空间的呢? 以D3D11为例:Native:struct ConstantBuffer{ DirectX::XMMATRIX World; DirectX::XMMATRIX View; DirectX::XMMATRIX Projection;} g_CB;extern "C" void UNITY_INT

跟NVIDIA的VRWorks一样, AMD也对VR进行了一些优化, 两家的各项技术基本上可以一一对应起来, 只是名字不同 Latest data latchhttps://www.youtube.com/watch?v=e_o22yJOgkg 其实就是Timewarp Affinity multi-GPU对应NVIDIA的VR SLI. 去年在UE4中整合过VR SLI, 性能提升的

这次有幸参加了GDC 2016, 终于把三大设备体验了个遍, 也试玩了很多不错的VR游戏. 之前看到很多人总是靠猜测和推测来评价这个三个VR设备, 误导了很多人, 所以在这里我就详细对比一下, 希望能让更多的人清楚的认识每个设备的优缺点, 客观地去评价它们. 分辨率/清晰度从参数上来看, Rift和Vive分辨率是一样的, PSVR略低. 但是有一个大家都忽略的因素, 那就是像素的排列方式. PSV

VR中的”延迟”, 特指”Motion-To-Photon Latency”, 指的是从用户运动开始到相应画面显示到屏幕上所花的时间. 这中间经过了大概这么几个步骤:传感器采集运动输入数据采集到的数据进行过滤并通过线缆传输到主机游戏引擎根据获取的输入数据更新逻辑和渲染视口提交到驱动并由驱动发送到显卡进行渲染把渲染的结果提交到屏幕, 像素进行颜色的切换用户在屏幕上看到相应的画面

注: 文章写于2015年8月, 目前VR游戏Demo已经完结, 所以把上一次预研的一些经验分享出来, 希望对大家有所帮助背景初接触Oculus时, 从网上下载了一大堆的Demo来体验, 但是, 操作体验大都比较差, 特别是FPS类. 这也让我们意识到, 对于VR游戏, 最大的挑战还不是显示方式的变化, 而是交互方式. 在一个沉浸式的环境中, 最自然的交互就是最完美的方式. 其中基本的需求, 就是可以

我们算是国内第一批做VR游戏的团队了, 基本上都是一路踩着坑过来的, 也从侧面说明了目前VR游戏的不成熟. 但是, 得益于大公司的资源, 机会和合作关系优势, 我们能在第一时间获得前沿的资料, 并可以体验到最新的一些硬件原型. 所以, 对于整个行业的发展趋势, 相对于其他人会了解的更深入一些. 不过最近我们发现, 大众(甚至是做游戏开发的同事)对于VR的了解还是相当有限的, 甚至还有一些误解, 我觉

原文: http://blogs.valvesoftware.com/abrash/latency-the-sine-qua-non-of-ar-and-vr/ 译者注: 原文发表于2012年, 虽然当时的一些硬件条件限制现在已经没有了, 但我们可以从中学习到AR/VR的延迟解决思路. 另外, 译文略过了显示器的发展史如果没有足够低的延迟, 根本不可能带来好的体验, 也就说大脑不会把眼睛看到的虚拟

原文：http://oculusrift-blog.com/john-carmacks-message-of-latency/682/延迟是OculusVR所面对的最大挑战之一，  它不仅会分散玩家体验游戏时的注意力， 还会导致晕动症， 所以找出它背后的原因并消除它是非常重要的。整个系统保持在50ms已经很快了， 但是还是可以感觉到延迟20ms是可接受的最大延迟传感器数据的推导预测可以缓解部分的系

最近在UE4中实现了程序实时生成的Mesh顶点动画， 由于使用的顶点数目很多（几十万量级）一开始是创建Dynamic Vertex Buffer， 然后每帧去更新顶点数据，发现效率比较低效率的瓶颈在顶点坐标的计算上， 毕竟数量有点多于是改成了基于Vertex Texture(Material中的World Position Offset)的实现，那VB就不用更新了， 只需要每帧更新Texture这

VR渲染需要左右眼两幅不同的画面，现在的大部分引擎都是暴力的直接渲染两遍，这样做想想性能也很难达到75FPS（或90FPS）以Oculus DK2为例，1920x1080@75FPS，加上Super Sampling就变成了（UE4默认135%）2592x1458@75FPS如果是Oculus的消费者版本和HTC Vive，分辨率和刷新率更是提升到了2160x1200@90FPS， 推荐配置是GT

Wiimote最早在玩Wii的模拟器游戏时候, 就发现其中有关于Wiimote的一些设置, 了解到其实Wii的控制器可以连接到PC上使用. 去年做了Kinect的体感游戏后, 也想了解下Wii的, 所以就淘宝买了Wiimote Plus. 完整的Wiimote有三部分: - Wii手柄(这个集成了motion plus) - Nunchunk(外号”鸡腿”) - IR感应条 跟PC

最近停止更新了一段时间, 不是我不想写, 而是处于一种迷茫状态上一次的年终总结中有提到, 2014是我参与的项目的面世的一年可谁想到公司冻结了这个项目, 全部转去做手游了当时也纠结过是不是转手游, 最终因为手游的技术和玩法都没法让我"激动", 仍然走了一条小路, 只为自己心中的那份坚持我们尝试做了国内第一款XboxOne的体感游戏, 虽然比较小众, 但至少对得起自己的心在此过程中也认识到, 游戏的

LG官方的固件更新从来不加什么更新日志, 如果手贱更新了发现少了什么功能就只能认栽虽然也可以通过USB进行更新, 但是只会识别更高的固件版本号经过搜索, 发现已经有大神破解出了LG固件的在线更新流程, 大概是这样的:请求snu.lge.com, 提交电视机产品代号根据型号返回对应的固件更新版本数据(XML格式)根据返回的版本数据里的版本号和下载链接下载固件进行系统固件的更新, 重启生效所以, 想强

Actors客户端复制actor被spawn出来时, 只有Location和Rotation在PreBeginPlay()和PostBeginPlay()时是全法的被复制的Actor只有在服务器关闭他们的复制通道时才被销毁Actor的属性复制是可靠的. 只会从服务器往客户端同步FReplicationFlags属性描述bNetOwner在目标机器上被PlayerController控制bNetIn

跟Class一样, 类成员变量也可以像C#那样加一堆的描述UPROPERTY([specifier, specifier, ...], [meta(key=value, key=value, ...)])Type VariableName;主要有4种基础类型:整数浮点数布尔值除bool外, 可以使用bitfield, 如uint32 bIsHungry : 1;字符串FString: 动态字符串

函数声明UE4中有两种函数, 一种是传统的C++函数, 一种是UFunction. UFunction通过加入一些描述符来支持一些特殊功能UFUNCTION([specifier, specifier, ...], [meta(key=value, key=value, ...)])ReturnType FunctionName([Parameter, Parameter, ...])主要有几

增加类编辑器中有一个类向导, 可以生成类所需要的文件和基础宏头文件由于UE4对C++做了扩展, 实现了如序列化反射等特性, 跟Qt的做法类似: 在代码中加入一些宏关键字, 在编译期间生成相应的C++代码. 因此, 对于每个类来说, 都有会生成一个ClassName.generated.h的文件类声明UCLASS([specifier, specifier, ...], [meta(key=valu

一图流:详见: https://de45xmedrsdbp.cloudfront.net/Resources/files/GameFramework-948891729.pptx

NavMesh, 这个一个Demo看不出有什么优缺点, 编辑起来到是很方便角色控制, 与UE3一样, 还是Character+Controller的方式, Character(Pawn)负责表现, Controller负责行为. 对于AI来说, 是派生AIController来实现自定义的AI行为与UE3不同的地方, 一是Blueprint可以代替很多原来脚本所做的事情. 另外, UE3中更多的是

在GDC2014上, UE4展示了一个SOUL Mobile Tech Demo: http://www.youtube.com/watch?v=jzGRbGb-fog

UE4相对于UE3, 渲染上最大的改变就是光照

官方WIKI上面有个FPS C++ Tutorial, 照着做一遍可以体会一下UE4整

原文链接: https://forums.unrealengine.com/showthread.php?2574-Why-C-for-Unreal-4&p=16252&viewfull=1#post16252

从Havok换到Bullet后, 最大的不适应就是各种btCollisionShape都是以

自己的超级本挂了后, 一直没有电脑用正好

UE4有很多个Module, GamePlay部分也是一个或多个Module, 每个Editor也是一个Module搜索了一下, Module总数170+, 总共分三类: Runtime, Editor, DeveloperRuntime这边比较重要的是Core, UObject, EngineCore数据类型数据库容器IO/LogUObject: 所有对象的基类. UE中还有个约定是Object

很多时候, 我们想把一项操作放入后台线程去执行, 可能是为了提高操作体验(UI表现的流畅), 或者是性能(充分利用多核的计算能力)等为了方便, 我在这里先定义一个简化的线程模型:所有的操作都定义为命令(Command)后台线程监听一个命令队列, 如果有命令就执行, 没有就等待如果收到结束通知, 则结束该线程比如我们有两种操作:void PrintA(){ printf("thread[%

承接2012篇, 保持格式一样吧技术篇渲染虽说加入流行的各种技术从程序的角度来说, 并不是很难, 但是从最终效果来看往往不能让人满意, 为什么呢?我想类似的事情, 一直都在困扰着所有自研引擎的同仁吧? 想来想去, 应该还是程序员想问题太简单的问题对于多数的程序员, 包括我自己, 都是在模仿/搬动/抄袭别人的代码, 但是功能实现出来不难, 有多少人了解功能背后的动机和改善过程以及存在的各种坑呢?往往

Tiled作为一个通用的2D地图编辑器, 对于功能扩充做了一些考虑, 比例加载/输出第三方的文件格式. 不过分析下来, 能扩充的功能有限, 像UI面板之类的功能扩展就没有提供支持, 但是参考已经有的接口可以很方便地实现插件原理Qt本身就对插件机制提供了完善的支持, 对于应用程序, 插件一般是以DLL的方式存在, 在程序运行时动态加载. DLL中实现已经在主程序中定义好的抽象接口, 然后主程序这边只

就像之前说过的, 没有Undo/Redo的编辑器都是耍流氓优点不过, Qt为我们提供了Undo/Redo的完整框架, 连工具栏按钮和History控件都齐活了Command模式的核心当然是Command, 就是说所有操作都是QUndoCommand, push进一个QUndoStack就redo, pop一个就是undoTiled中比较特别是多文档编辑器, 也就意味着有多个QUndoStack,

文档模型文档对象是一个MapDocument类, 它的主要功能有:管理编辑操作的signal的派发, 保证一些UI的状态可以正确地更新管理地图的数据模型, 如layer model(Qt MVC结构中的model, 可以绑定到控件)增加删除地图对象的操作接口管理这个地图的undo堆栈(后续专门分析一下undo/redo)管理地图编辑时的选中状态然后就是DocumentManager, 是一个单件类

MFC, WinForms, WPF, Qt算是都折腾过, 就差WxWigets了比较下来, 做游戏(引擎)工具开发的话, 最重要的是易上手, 好维护, 开发快, 综合下来还是滚回C++阵营, 选择了Qt不用不知道, 其实传统的Qt Widgets用起来跟WinForms非常像, 甚至Qt Quick的特性跟WPF有的一拼想当初强烈地想用C#, 很大部分原因是WinForms那个可视化GUI编辑器

最近业余玩玩了cocos2d-x, 在做地图部分时发现了Tiled这个开源的地图编辑器深入了解之后, 发现这个编辑十分强大, 好用到其他2D引擎都支持其地图格式, 几乎成为了一种标准在使用过程中, 有时会有对其编辑功能进行扩充的需要, 所以顺便看了一下它的代码读过之后, 越看越喜欢, 做为开源的编辑器, 代码能写这么漂亮很不简单想想自己用Qt写的几个工具, 总是感觉有点耦合, 所以就有了学习一下T

原文链接: http://www.qsoftz.com/mirza/?p=59简介这篇文章是关于如何将传统的STL vector作为XNAMath类型容器使用. 因为SSE/SSE2指令集要求数据必须对齐到16字节的边界, 所以vector的分配器必须替换成一个可以对齐的内存分配器(x86架构). 本文适用于想在代码中引入新鲜空气的x86 Windows开发者, 你将会看到如何把强大的XNAMat

两年前我开始实行个人时间管理, 现在看来, 的确受益匪浅虽然自己在实行过程中慢慢地"简化"这种自我管理, 但是仅剩的一点记事与思考的习惯保留了下来, 对我的工作和生活都产生了很不错的促进作用最近又感觉自己到了一定的瓶颈期, 或者说迷茫期, 回过头来想想自己之前突破瓶颈的状态, 也找不出类似的解决方法上周引擎技术中心组织了一次团建, 可以说汇集了自己所处的这个领域的精英, 从这些大神级别的人物身上,

在我使用Lua编程整整9个月后, 是时候停下来反省一下这段经历了. 过去了几年里, 我使用了各式各样的语言:Perl (soaplite.com, 还有其它的项目, 包括我现在的咨询工作), C (DHCPLite 和 ping-pong juggling robot), JavaScript (Google Maps相关经验 和 canvas), MATLAB (ping-pong juggli

说到战争迷雾(Fog of War, FOW), 其实还是非常普遍的一个游戏技术, 在RPG, RTS等游戏中得到了广泛的应用 但是关于这方面的资料非常少, 经常会有人问怎么做, 所以就有了写这篇文章从应用上来说, 有两种:探索范围: 通常在RPG游戏里, 用于标记走过的地图区域视野范围: 通常在RTS游戏里, 用于标记友方单位可以看到的区域当然, 在魔兽争霸3中, 两中迷雾都存在. 下面以第二种

最近在做动画系统的一些重构工作, 顺便就看了下成熟的引擎的动画部分. 之前做过一个动作游戏的预研, 所以对这部分感触比较大, 因为相比业界一流的厂商, 动画技术可以说是国内游戏开发最落后的的一部分了在我看来, 动画系统分成这么几个级别吧:可以把DCC中制作的动作导入播放, 有Play/Stop/Pause之类的接口. 开源或者自研的引擎多停留在这一阶段在多个动画之间可以定义混合转换方式, 可以很好

参数编辑可以说, 引擎工具在除了一些特定操作外, 80%的事情都是在进行参数的编辑与保存等. 从我接触工具开发开始, 就一直在学习如何简化这么部分的工作. 因为我见过很多业余的编辑器, 大多都是每加一个参数就在UI层写一些代码, 在IO层加一些版本兼容代码等. 而这些代码常常都是大同小异的, 很多都是Ctrl+C, Ctrl+V出来的. 说起来, 这个探索过程中我也走了不少的弯路, 顺便写出来当教

大体浏览过emscripten的那一堆demo后, 心想试试移植个游戏试试, 顺便体验下这项技术的实用程度首先尝试了Onescripter, 因为手头上有可以编译运行的FateStayNight. 在工程配置中增加新的Platform: Emscripten, 并选择编译成可以执行的html编译提示缺少bzlib.h, 增加libbz2工程(开源), 注意这个就需要编译.bc库了(相当于.lib)

在《传统3D游戏引擎的Web化》中, 当时我还说emscripten不够成熟, 可是短短几个月它就有了很大的进步, 可用性甚至超过了flascc!在GDC2013上, Unreal发布了基于emscripten的移植Demo, 据说只用了4天时间, 足以看出这个移植过程的平滑floh前几天发布了一个PPT: 《C++ on the Web: Run your big 3D game in the

最近看了OGRE2.0的一个PPT, 触动挺大的其实OGRE一直以来所为人诟病的性能问题, 何偿不也是我们引擎存在的问题虽然很多时候我们都拿OGRE和GameBryo的效率当反面教材, 但是自己也没有做到极致相对于GPU的性能优化来说, CPU的性能优化难得多就好比游戏开发的书籍, 讲API/渲染的多, 讲架构&逻辑的少可能很多人以为, 做引擎开发就是做图形开发, 对于国内的游戏来说好像没错但是如

又一次遇到瓶颈了第一次是大三时, 不甘于沦落到去做外包码农, 自学了游戏开发, 遇贵人介绍上海一实习机会, 得入游戏行业第二次是工作满一年, 想做个自己喜欢的游戏, 辞职去了北京, 做了3D引擎程序员, 算是一种磨练第三次是想追求技术, 正好遇到爱情, 南下深圳, 专业技术与个人成长都不错, 算是两全其美第四次是面临开发之外兼做一点管理沟通工作，想好好写代码都难第五次是升职级，让我意识到技术之外的

世界末日没来, 只好继续战斗技术篇渲染这部分没什么搞头了, 大家都差不多, 够用就好. 最重要的是让尽量多的机器画面好, 而不是高端机器好关键字: Deferred Lighting, SSAO, Deferred Shadow, Gamma Correction, FXAA, Screen Space Decal, Rim Light, Color Grading, HDR虽说画面是第一印象,

最近遇到个内存泄露, 查来查去竟然在FMOD模块里要不是别的组件全部定制了内存分配函数, 还真不会怀疑到它头上使用FMOD::EventSystem::getMemoryInfo()输出内存信息一看, 直接崩溃了, 100MB~200MB之前我是用XACT的, FMOD本以为是差不多的东西, 就没怎么在意, 结果摔一跟头细细的去读了一下文档, 发现有3点:FMOD::Memory_Initiali

最近业余在做一个基于结点的编辑工具玩, 遇到一个问题, 就是结点和连线多了, 经常会出现重叠交叉的问题, 导致图看不清楚:要是这个样子, 还不如不用图清楚呢, 所心就需要找一个方法来进行自动布局, 理想情况是这样的(手动整理结果):当然, 手动整理的话, 每个人弄出来的结果都不一样. 自动的算法肯定没有100%完美的, 但是总是能方便不少的在google了一会儿后, 发现这种结点-线组成的图是一有

物理引擎的抉择前面说了, 这一系列是针对c++&3D的, 所以排除Box2D之类的2D引擎.3D版的, 目前最流行的有3个:Havok: 说它是最NB的毫不为过. 但是要钱, 不给钱人家才不鸟你呢. 免费版本只有Win32, 所以排除PhysX: 目前占有率最高, 跟游戏开发商合作比较好. NaCl版本没看到有, 所以排除Bullet: 开源. 想跨平台, 还是开源的东西比较靠谱, 一切尽在掌握.

NaCl的3D渲染API使用的GLES2.0, 这也很好理解, 因为这已经是公认的跨平台标准了. 手机, 平板, 网页, PC都可以使用.就算在Windows上, 也有一些基于DX9的GLES2.0实现, 比如ANGLE. 有时候我真在想, 像M$这种升级个操作系统版本号就淘汰一种API的做法, 还不如全都使用标准库, 这样也节省了跨平台移植的成本~所以什么DX10/DX11, 还是省省吧其实从D

一些限制相对于Win32来说, NaCl相当于另一个平台, 一些操作系统相关的API需要移植. 除此之外, 参考Technical Overview, 还有一些其它的限制:不支持硬件异常不支持创建进程不支持传统的TCP/UDP sockets (有其它方式去实现, RakNet已经有个预览版本)不支持查询可用内存内联汇编必须兼容 Native Client 验证器(使用SDK中的 ncval 工具

下载 Native Client SDKhttps://developers.google.com/native-client/sdk/download需要设置两个环境变量, Python2.7.3的安装路径加到PATH里, NACL_SDK_ROOT设置为对应版本目录CHROME_PATH这个是后面VS调试用的, 如果不用VS开发, 可以不设置C++ 教程https://developers.g

老机器用了4年多了, 说实话对它还是挺有感情的, 当初光配置单就前后纠结了4个版本最后定的是E7200+P45+2x2G+320G+9800GT+22LCD(1080p), 3dmark06分数12000+用下来最满意的还是显示器了, 1920x1080的分辨率对于上网/编程/游戏在体验上都是一个质的飞越最不满意的, 就是噪音, 后悔在电源上省钱, 没弄个大风扇的, 后悔买9800GT, 费电不说

2012年6月7日19:31星际2的编辑器相对于魔兽3最大的改进就是数据编辑器了, 也正是这个改变, 让很多有兴趣自制地图的人放弃了这个想法. 为什么呢? 因为它太复杂了, 而且资料很少, 所以上手难度比较大. 但是一旦你学会了它, 你就会喜欢上这种编辑方式. 这个编辑器背后的实现原理, 也是非常值得程序员们去好好探索和借鉴的. 星际2中, 很多功能都是可以使用数据编辑器去"配置"出来的, 这就是

最近floh大神的blog又复活了, 现在n3的主要发展发向是web化其实也是跟PC和主机平台的衰落有关, 各种移动设备正在逐渐取代PC的地位而做为一个3D游戏引擎, 想要适应这个潮流却不是很容易先不考虑其它, 光技术上面临的问题就很棘手:C++目前无法直接用于web开发, 必然要面临老代码转换/移植的问题3D硬件加速的渲染在浏览器这边, 没有一个统一的标准多线程, web浏览器里对于线程的使用有

最近老是想着学习下Upsampling, 因为在做优化时这是一项非常实用的技术参考AMD的PPT: Mixed Resolution Rendering, 有这么几种情况可以应用:把半透明元素(如粒子)单独画到一个小的BlendBuffer上, 再跟原场景混合, 减小填充率的负担SSAO, 一般不会做FullSize的处理, 所以Upsampling基本上是必须的一步屏幕空间的软阴影, 同上间接光

游戏&引擎不要为了做引擎而做引擎脱离项目的引擎是一个没有经过验证的东西, 没人敢用引擎设计要以人为本, 这不是一个技术问题, 是需要项目的沉淀和积累的技术&应用技术如果不转化为生产力, 那么它的价值就是停留在程序员们YY中的自我满足只有技术能够让生产力得到提升, 或者产品品质的提高, 它才会被认可, 不管它是多么得高深, 还是多么得的简单程序们往往只喜欢去挑战有难度的部分, 反而不去推动那些简单实

Tutorial by Siretu让大多数接触星际2编辑器的人歇菜的原因, 就是这个数据编辑器(Data Editor). 不管你是个新手, 还是使用魔兽3的编辑器做过一些东西, 当你怀着满腔的热情准备做一张星际2的地图时, 数据编辑器就像挡在前面的一座大山, 让人恨不得撞死算了.这种情况同样发生在我身上. 我自信用魔兽3的对象编辑器用得炉火纯青了, 但是当我打开数据编辑器时, 连怎么做个Uni

在游戏中显示网页? 为什么要这么做呢?其实可以做不少的应用:嵌入帮助文档, 比如技能介绍, 可以做得很漂亮, 各种排版方式用传统UI做起来很费劲活动公告页面直接在游戏中查看游戏内的BBS/社区玩家的个性展示/资料等等最重要的是, 所有的这些内容都可以扔到web服务器上, 不用打包进客户端最早是用LLMozLib 实验过, 编译这玩意儿费了我老大劲儿, 最终发布时还要带一屁股的DLL和资源受不了了就

照葫芦画瓢弄了一个, 正好可以解决一下色彩不够鲜艳的问题见 http://blog.csdn.net/ccanan/article/details/6745207曝光度弄成16铁定过了, 如果是非常暗的场景, 并且是线性颜色空间才有意义(GammaCorrection)LDR其实也可以用, 我上面的没有使用HDR颜色空间

https://developer.valvesoftware.com/wiki/Particle_System_Overview文件格式PCF编辑器Particle EditorMemory Fields这里其实也是组件模式的一种应用, 否则内存和CPU的开销会很大Control Points每个粒子系统最大有64个控制点, 0号默认为粒子的原点每个控制点可以设置位置, 朝向, 实体TF中医生的