mysql存储animoji_Animoji实现方案分享

2023-10-10 02:20

本文主要是介绍mysql存储animoji_Animoji实现方案分享,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

写在前面

由于之前在申请专利,所以文章不能发出来,现在发出来帮助有需要的人。

Animoji

苹果在今年的十周年特别版iPhone X发布会上,推出了Animoji功能。该功能基于iPhone X的结构光传感器,捕捉用户的表情变化,生成相应的3D动画表情。本文介绍了基于ARKit + SceneKit的Animoji实现方案。

04dd3ec22cbf

图1 发布会上的Animoji介绍

Animoji原理

在人脸建模后,通过获取人脸追踪与表情捕捉的数据,更新到虚拟形象上,使虚拟形象与用户人脸的位置与表情相同步。

(1) 人脸建模

在高端设备上,借助红外摄像头与结构光点阵投影仪,根据获取的点云数据,结合利用泛光照明器得到的红外图像,通过随机交替获取二者数据,做3D人脸建模。

(2)人脸追踪与表情捕捉

人脸追踪:依据人脸检测算法和SLAM(同步定位与地图构建)算法,实时追踪人脸在图像中的位置变化,并计算人脸在3D空间中的位置。

表情捕捉:依据基于深度学习的表情识别算法,通过匹配用户当前人脸数据到表情库,识别出用户当前表情。

(3)虚拟形象渲染

构建与真实世界相同坐标的虚拟世界,创建虚拟形象并实时计算它与人脸之间的位置映射关系,基于表情捕捉得到的数据来更新虚拟形象的动画表情。

Animoji效果

Animoji方案

本方案使用 变形动画+骨骼动画+骨骼控制 来实现Animoji。

变形动画:使用预先制作好的表情基作为变形目标,通过变形的方式来确定模型表面每个顶点最终的位置,使用SceneKit渲染的话,可以用SCNMorpher来实现。

骨骼控制:在设计师刷好骨骼对蒙皮的权重后,就可以通过骨骼控制或者加载骨骼动画来实现非变形部分的动画。

骨骼动画

建立虚拟形象模型

(1)虚拟形象静态模型

虚拟形象分为强表情部分和弱表情部分,以头部举例:脸部为强表情部分,眼睛牙齿耳朵等为弱表情部分。强表情部分用捕捉的表情数据更新,弱表情部分则根据用户头部的运动数据与表情变化来更新。

04dd3ec22cbf

图2 强表情部分和弱表情部分

例如:用户边转头边做鬼脸,强表情部分,即脸部会更新为用户的表情形象,而弱表情部分,如耳朵骨骼会根据用户头部转动的速度变弯曲,舌头会在嘴巴长到一定幅度伸出。

(2)制作表情基

表情基分为普通表情基与混合表情基。表情基与静态模型的强表情部分的拓扑结构完全一致,且在同一个尺度空间下大小相同。不同表情基,模型的网格顶点数一样,多边形一一对应,不同的是顶点的位置不同(如大笑嘴部的顶点就会有位移)。

普通表情基是一些设计好的脸部模型,如图3。普通表情基代表一些固定的人脸表情,如张嘴、眨眼,为了缩减大小,表情基除了几何体没有其他任何信息,并且分割为若干子部分。

04dd3ec22cbf

图3 不同的表情

混合表情基是若干特定的普通表情基的非线性组合,在运行时计算得出,用以扩展表情的丰富度,理论上有混合表情基的支持,虚拟形象能够模拟无限多个表情,而不是只在普通表情基这个维度,混合表情基的计算方式如下式, B( i )表示第i 个混合表情基,E( j )表示第j个普通表情基。

04dd3ec22cbf

表情分割

本系统将表情分割成5部分,在加载表情时,只使用有效部分,(如眨眼就只加载眼部),缩小了表情的计算量。分割表情时,使用更平滑的顶点法线来避免分割后可能产生的裂缝。

04dd3ec22cbf

表情权重分配机制

本系统对不同表情分配了不同的权重,在更新时,对于高权重的表情,会先加载先更新,提高每次更新表情的用户体验,缩短关键表情的等待时间,流程图如下。

04dd3ec22cbf

分包加载

本系统的加载方式采用分包加载的方式,首先将分割好的表情基分布存储在若干文件中,在需要的时候分包加载,模型开始更新的时间是之前的20%。

建立骨骼

对于弱表情部分,他们是根据头部的运动与表情变化来做更新,本系统对弱表情部分建立骨骼来控制它们。当用户向右看时,控制眼球骨骼向右旋转;当用户张嘴时,控制下巴骨骼向下旋转;当用户向右转头时,耳朵会根据转头速度向左旋转。

04dd3ec22cbf

图4 用于控制弱表情部分的骨骼

骨骼动画

除了上一点所说的更新方式,本系统还使用骨骼动画来来做更精致、可运营的表情。骨骼动画与命中逻辑可动态下发。

基于人脸追踪与表情捕捉数据更新虚拟形象

初始化之后,虚拟形象会添加到虚拟世界中,用户人脸在真实世界中的运动会同步到虚拟形象在虚拟世界的运动。同时通过表情捕捉数据,拆解用户表情为普通表情基和混合表情基的线性组合,利用此组合更新虚拟形象的强表情部分。如下式, E(user)是用户当前的表情,E是普通表情基,B是混合表情基。

04dd3ec22cbf

更新方式是:遍历表情基E的网格的每一个顶点,通过下式计算其最终的位置。其中V(i)表示第i 个顶点,V(E1)表示在表情基E1中相应的顶点,A(i)表示表情Ei的权重。

04dd3ec22cbf

对于弱表情部分,本系统根据头部的运动与表情的变化,通过骨骼控制它们。弱表情部分包括但不限于耳朵、下牙与舌头、眼球。

对于耳朵:

当头部转动时,通过判断转头的速度来控制耳朵骨骼的旋转,从而弯曲耳朵。计算公式如下式,Ear(eulerAngles)为耳朵骨骼的欧拉角,V(x), V(y) 分别为头部转动的偏航角速度、俯仰角速度,A、B分别为计算所需的补偿值,效果如图6。

04dd3ec22cbf

图6 头部转动时耳朵弯曲

1)  当用户张大嘴时,耳朵向内弯曲,弯曲幅度由云端控制。

2)  当用户闲置时,耳朵部分播放骨骼动画,动画与触发逻辑由云端下发。

对于下牙与舌头:

1)  当用户张嘴时,下牙与舌头的骨骼配合张嘴表情向下旋转。计算公式如下,Jaw为下牙与舌头骨骼的欧拉角,H 为云端控制的最大俯仰角阈值,A为当前表情的张嘴表情系数。

04dd3ec22cbf

2)  当用户张嘴且下唇特征点出现特定变化,判断用户在张嘴伸舌头,变形舌头并伸出舌头,效果如图9。

04dd3ec22cbf

图9 虚拟形象张嘴伸舌头

3)  当用户张嘴伸舌头时,移动头部,控制舌头左右变形,以符合头部的运动。

对于眼球:

1)  眼球的转动主要根据眼部表情变化来控制,计算方式如下式,Eye为眼球骨骼的欧拉角,S为计算旋转的方向值,H为云端控制的最大俯仰角与偏航角阈值,A为当前表情的眼部表情变化系数。

04dd3ec22cbf

全景背景与粒子特效

通过下发不同的360全景图片或视频作为背景。当用户做特殊表情或者特殊话语,触发全景背景的更改与粒子特效,当用户旋转手机时,能看到不同的内容,丰富了产品的应用空间,效果如下图。

04dd3ec22cbf

图 10 背景为360全景图,用户转动手机可看到不同

更进一步

目前模型的体积较大,考虑采用运行时平滑、着色的方式,实现素材包的体积减少,使用运行时加顶点的平滑方式,可以让素材包减小80%左右。

与TTS结合,让用户可以通过语音控制一些彩蛋逻辑。

结合图像处理、深度学习算法,拓宽应用场景,实现更好玩的玩法。

这篇关于mysql存储animoji_Animoji实现方案分享的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/177255

相关文章

Ilya-AI分享的他在OpenAI学习到的15个提示工程技巧

Ilya(不是本人,claude AI)在社交媒体上分享了他在OpenAI学习到的15个Prompt撰写技巧。 以下是详细的内容: 提示精确化:在编写提示时,力求表达清晰准确。清楚地阐述任务需求和概念定义至关重要。例:不用"分析文本",而用"判断这段话的情感倾向:积极、消极还是中性"。 快速迭代:善于快速连续调整提示。熟练的提示工程师能够灵活地进行多轮优化。例:从"总结文章"到"用

SQL中的外键约束

外键约束用于表示两张表中的指标连接关系。外键约束的作用主要有以下三点: 1.确保子表中的某个字段(外键)只能引用父表中的有效记录2.主表中的列被删除时,子表中的关联列也会被删除3.主表中的列更新时,子表中的关联元素也会被更新 子表中的元素指向主表 以下是一个外键约束的实例展示

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

如何去写一手好SQL

MySQL性能 最大数据量 抛开数据量和并发数,谈性能都是耍流氓。MySQL没有限制单表最大记录数,它取决于操作系统对文件大小的限制。 《阿里巴巴Java开发手册》提出单表行数超过500万行或者单表容量超过2GB,才推荐分库分表。性能由综合因素决定,抛开业务复杂度,影响程度依次是硬件配置、MySQL配置、数据表设计、索引优化。500万这个值仅供参考,并非铁律。 博主曾经操作过超过4亿行数据

无人叉车3d激光slam多房间建图定位异常处理方案-墙体画线地图切分方案

墙体画线地图切分方案 针对问题:墙体两侧特征混淆误匹配,导致建图和定位偏差,表现为过门跳变、外月台走歪等 ·解决思路:预期的根治方案IGICP需要较长时间完成上线,先使用切分地图的工程化方案,即墙体两侧切分为不同地图,在某一侧只使用该侧地图进行定位 方案思路 切分原理:切分地图基于关键帧位置,而非点云。 理论基础:光照是直线的,一帧点云必定只能照射到墙的一侧,无法同时照到两侧实践考虑:关

异构存储(冷热数据分离)

异构存储主要解决不同的数据,存储在不同类型的硬盘中,达到最佳性能的问题。 异构存储Shell操作 (1)查看当前有哪些存储策略可以用 [lytfly@hadoop102 hadoop-3.1.4]$ hdfs storagepolicies -listPolicies (2)为指定路径(数据存储目录)设置指定的存储策略 hdfs storagepolicies -setStoragePo

HDFS—存储优化(纠删码)

纠删码原理 HDFS 默认情况下,一个文件有3个副本,这样提高了数据的可靠性,但也带来了2倍的冗余开销。 Hadoop3.x 引入了纠删码,采用计算的方式,可以节省约50%左右的存储空间。 此种方式节约了空间,但是会增加 cpu 的计算。 纠删码策略是给具体一个路径设置。所有往此路径下存储的文件,都会执行此策略。 默认只开启对 RS-6-3-1024k

hdu1043(八数码问题,广搜 + hash(实现状态压缩) )

利用康拓展开将一个排列映射成一个自然数,然后就变成了普通的广搜题。 #include<iostream>#include<algorithm>#include<string>#include<stack>#include<queue>#include<map>#include<stdio.h>#include<stdlib.h>#include<ctype.h>#inclu

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题,本文将一起从代码层去分析为什么没有建立索引? 开源ERP项目地址:https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置

MySQL数据库宕机,启动不起来,教你一招搞定!

作者介绍:老苏,10余年DBA工作运维经验,擅长Oracle、MySQL、PG、Mongodb数据库运维(如安装迁移,性能优化、故障应急处理等)公众号:老苏畅谈运维欢迎关注本人公众号,更多精彩与您分享。 MySQL数据库宕机,数据页损坏问题,启动不起来,该如何排查和解决,本文将为你说明具体的排查过程。 查看MySQL error日志 查看 MySQL error日志,排查哪个表(表空间