XCode 插件自动签名
0 条评论最近用XCode写一些C++的测试,遇到一个问题,我升级过XCode所以现在看不到所有的旧插件了,网上找了一圈,需要手动创建证书然后重新对之前的插件进行签名。最后我找到一个插件可以很方便的对之前插件进行恢复。
最近用XCode写一些C++的测试,遇到一个问题,我升级过XCode所以现在看不到所有的旧插件了,网上找了一圈,需要手动创建证书然后重新对之前的插件进行签名。最后我找到一个插件可以很方便的对之前插件进行恢复。
本篇总结一些 C# 4.0 - 7.0的语法特性。 如今都是距离5.xUnity盛行的时代都过去两年多了,该看一看新语法不然要落伍啦。
UNITY版本与C#版本关系
Unity 5.5.4 自带的Mono也可以支持C# 6,在mcs.rsp文件中添加一行:-langversion:6即可。
Unity 2017.1 C# 6.0 试验性地支持新脚本运行时。This includes Mono 4.8 and IL2CPP with support for C# 6 and .NET 4.6
Unity 2018.1 C# 7.2
总的来说新特性还是在2018的运行环境下比较稳定,所以建议在2018下再去放开使用。下面列出的特性基本上都可以在2018中使用。不能使用的部分已经做了标注,下面是正文:
如果您想动手尝试可以在AssetStore中获取到🔗 示例源码,在 Default Playables 包中展示了大量的Playable API案例。在这里我们会挑比较有代表性的进行讲解。在案例中全部都是结合 Timeline 使用,由此可窥 “Playables API” 真是香饽饽,堪称万金油的存在。既能单独作为树型动画播放器使用又能够被 Timeline 所结合,不写代码也能做出复杂的游戏逻辑。当然 Timeline 同样适合处理各种动画需求等 如过场剧情,封面动画,甚至可以制作电影。本篇将会带大家从零开始使用Timeline进行剧情的编写,并且对相关 概念 以及 api 进行讲解。
之前输入数学公式的一直用截图 自觉用户体验很差,最近发现用的这个主题带了好用的数学函数辅助,便一发不可收拾。顺便推荐一下我用的主题是maupassant-hexo github ,这里记录一下数学符的用法。
上篇给大家介绍了 “Playables API” 的使用方法与背后的意义,本篇将会进一步带大家深入其中。 本篇重点还是会放到 “Playables API” 上,不会对 Timeline 进行集中讲解,但是搞明白了 “Playables API” 也就意味着理解了 Timeline 最复杂的部分,到时候学起来也会非常的快。
GPUSkinning 教程大纲(UNITY3D)
节一. 原理
节二. 实践
Playables API 推出已经一年有余(2017–07–04 New in Unity 2017.1)。即使你没时间其他的新功能, 也应该看看这个 Playable API
.做过大型游戏的同学无论你是做过 2D或3D 只要使用过 Animaiton Controller,或多或少体会过被 蜘蛛网(复杂状态机过渡) 支配的恐惧。当下有了 Playable API
可供使用,我们能轻易的向 Legacy animation API 的使用习惯靠拢 — 高效及易于定制。
在我看来 Playable API 的目的就是为了替换掉Legacy动画系统,并且兼容Timeline(本篇不介绍timeline 感兴趣的可以自己去看看)。总的一个词概括就是 【dynamically】,如同使用组件一般的灵活。
目前我在测试中使用了 UNITY2018.1+ 编辑器。如果不使用该可视化插件您在 UNITY5.x 版本就能使用
Playable API
。 使用5.x版本的Playable API 时请注意后续的代码API变更,某些函数名或调用方式可能已经更改,如果从未使用过 建议从 UNITY2017+ 开始入手。
这周会计划研究LipSync方向,会写一些资料记录过程。本篇并不讲详细使用步骤,只讨论其功能实现。
本篇评测的工具实现方式都相近,插件列表如下:
LipSync Pro【U3D】
EasyTalk【U3D】Lipsync Tool【美术用】Face and lips
评测的方向: 1. 嘴型同步 2.面部表情
评测角度: 1. 实现方式 2. 可用性
这周会计划研究LipSync方向,会写一些资料记录过程。本篇并不讲详细使用步骤,只讨论其功能实现。
本篇评测的插件列表如下:
** SALSA With RandomEyes **
** UniLip **
评测的方向: 1. 嘴型同步
评测角度: 1. 实现方式 2. 可用性
前两天有一个问题一直困扰我。使用protobuf .net版本的时候序列化类,基类的字段会丢失。随后我问了下朋友无一例外他们都使用的是组合而非继承。我也在反思是否这个做法本身就有问题。我昨天Google的时候发现有人遇到相同的问题,遂在本篇中记录。
可拖动分割条在 Unity3D 的编辑器结构中一般都属于最外层结构,因为它是基于 GUI 组件,计算位置的时候必须要很精确,所以跟Layout 流式布局混编会比较乱。这里也推荐作为最外层结构使用。
下面是我给项目组的一些参考。其中也包含各种各样的标准,与优化建议。项目优化并不是一件事,它是点点滴滴串联起来的(勿以恶小而为之),我见过很多项目只是图一时之方便就导致后期很难做 比如 前期未规划好图集,模型贴图材质目录混用,UI制作未按照 复用/特殊 的标准制作,动画导出帧率不统一高高低低 等等。如果一开始没有定制良好的规范,后面想要补救只能靠程序写一些工具批量处理,当然这工具也不一定好写。