mesh

实现思路步骤： 1.对原图像gamma校正，img=sqrt(img); 2.求图像竖直边缘，水平边缘，边缘强度，边缘斜率。 3.将图像每16*16（取其他也可以）个像素分到一个cell中。对于256*256的lena来说，就分成了16*16个cell了。 4.对于每个cell求其梯度方向直方图。通常取9（取其他也可以）个方向（特征），也就是每360/9=40度分到一个方向，方向大小按像素边缘强度加权。 5.每2*2（取其他也可以）个cell合成一个block，所以这里就有（16-1）*（16-1）=225个block。最后归一化直方图。 6.所以每个block中都有2*2*9个特征，一共有225个block，所以总的特征有225*36个。 当然一般HOG特征都不是对整幅图像取的，而是对图像中的一个滑动窗口取的。 形象化的用一个流程图显示： matlab实现代码：参考别人的修改的 clear;clc; img =imread( ' E:\mat\lena.jpg ' );% 图片位置 % 获取图像，尺寸，并将图像resize成step的最近整数倍 img = double (img); figure;imshow(img,[]); % 显示图像 step = 8 ; %step* step个像素作为一个cell [m1 ,n1] =size(img);% 获取图像尺寸 img

　　之前一直渲染箱子，显得有点单调。这一次我们绘制一个用艺术家事先用建模工具创建的模型。 　　本次实践参考： https://learnopengl-cn.github.io/03%20Model%20Loading/01%20Assimp/ 　　在之前我们的OpenGL实践中，绘制图形的过程是先定义顶点的位置、法线、纹理坐标（UV）等信息，按一定的规则组织后传给着色器处理，最终绘制到屏幕上。现在使用艺术家构建的模型，绘制的过程并没有变，只不过顶点和使用的贴图信息从原来我们自己定义变为从已构建好的模型中提取，所以导入模型的重点是解析模型文件中的顶点、贴图等信息，然后按照OpenGL的规则组织读取的数据。 　　艺术家构建模型时使用率高的几个构建工具有：blender,3ds max, maya。这些工具提供良好的界面和操作方式，艺术家可以非常方便顺畅的构建想要的模型，同时也屏蔽了模型文件保存的细节，使得他们并不需要关心他们构建的模型数据如何保存。但如果你想把这些文件中的数据导入到OpenGL中就必须了解这些文件的格式。然而，现在模型文件的格式有很多中，每一种的结构并不相同。比如比较简单的Wevefront 的.obj格式和基于xml的比较复杂的collada文件格式，我们如果想支持他们的导入，就需要为它们都写一个导入模块，幸运的是现在有一个叫 Assimp 的库专门处理这个问题

在做项目过程中需要使用 Assimp 这个3D模型读取库来读取obj格式的模型，因为项目是基于Android平台，采用NDK开发，所以就打算编译Assimp库并生成.so文件。本文使用Assimp-v.5.0.0.rc1（ https://github.com/assimp/assimp/releases/tag/v.5.0.0.rc1 ），此版本已经支持在导入FBX的同时导入blendshape。网上的资料大多比较老，针对assimp-3.3的比较多，新版本的编译还是有些不同，特记录下。 首先我们看下Assimp中blenshape导入的代码：以FBX为例 在FBXConverter.cpp中，也就是说blendshape以顶点动画的形式 保存在了aiAnimMesh这个数据结构中，后续对bs的操作只需要操作对应的aiAnimMesh即可。 /** @brief An AnimMesh is an attachment to an #aiMesh stores per-vertex * animations for a particular frame. std::vector<aiAnimMesh*> animMeshes; for (const BlendShape* blendShape : mesh.GetBlendShapes()) { for (const

  Assimp ：全称为Open Asset Import Library，这是一个模型加载库，可以导入几十种不同格式的模型文件（同样也可以导出部分模型格式）。只要Assimp加载完了模型文件，我们就可以从Assimp上获取所有我们需要的模型数据。Assimp把不同的模型文件都转换为一个统一的数据结构，所有无论我们导入何种格式的模型文件，都可以用同一个方式去访问我们需要的模型数据。 官网地址： https://www.assimp.org 安装及使用 环境：win7 VS2015 1. 下载Assimp： 地址： https://github.com/assimp/assimp 2. 下载安装assimp源码编译需要用到的其他库directx sdk、boost库 a. 安装 DirectX SDK：assimp view依赖directx sdk DirectX下载地址： DirectX官方下载   安装DirectX SDK时，可能遇到一个错误码为s1023的错误，这种情况下，请在安装SDK之前根据这个先卸载C++ Redistributable package(s) 卸载： Visual C++ 2010 Redistributable Package version 10.0.40219 在控制面板里像卸游戏一样卸，注意看清楚一定要把x86和x64两个都卸载了

作者 | 王夕宁 阿里云高级技术专家 参与阿里巴巴云原生公众号文末留言互动，即有机会获得赠书福利！ **导读：**本文摘自于由阿里云高级技术专家王夕宁撰写的《Istio 服务网格技术解析与实践》一书，在展望服务网格未来的同时，讲述了如何使用 Istio 进行多集群部署管理，来阐述服务网格对多云环境、多集群即混合部署的支持能力。 你只需开心参与阿里巴巴云原生公众号文末互动，我们负责买单！技术人必备书籍《Istio 服务网格技术解析与实践》免费领~ 服务网格作为一个改善服务到服务通信的专用基础设施层，是云原生范畴中最热门的话题。随着容器愈加流行，服务拓扑也频繁变动，这就需要更好的网络性能。服务网格能够通过服务发现、路由、负载均衡、心跳检测和支持可观测性，帮助我们管理网络流量。服务网格试图为无规则的复杂的容器问题提供规范化的解决方案。 服务网格也可以用于混沌工程 —— “一门在分布式系统上进行实验的学科，目的是构建能够应对极端条件的可靠系统”。服务网格能够将延迟和错误注入到环境中，而不需要在每个主机上安装一个守护进程。 容器是云原生应用的基石，通过应用容器化，使得应用开发部署更加敏捷、迁移更加灵活，并且这些实现都是基于标准化的。而容器编排则是更近一步，能够更加有效地编排资源、更加高效地调度利用这些资源。而到了云原生时代，在 Kubernetes 基础架构之上，结合 Istio 服务网格

函数计算（Function Compute） ： 函数计算 是事件驱动的全tuoguan计算服务。使用函数计算，您无需采购与管理服务器等基础设施，只需编写并上传代码。函数计算为您准备好计算资源，弹性地可靠地运行任务，并提供日志查询、性能监控和报警等功能。借助函数计算，您可以快速构建任何类型的应用和服务，并且只需为任务实际消耗的资源付费。 访问 PostgreSQL 数据库是指在函数计算中通过编写代码调用数据库驱动库通过 TCP 协议实现对数据库进行的插入、查询等操作。通常函数计算中运行的不同函数实例之间是不共享状态的，对于结构化的数据可以通过数据库的形式进行持久化以实现状态共享。由于用户函数运行在函数计算的 VPC 中，而用户的数据库运行在用户所属的 VPC 中，所以在函数计算平台访问数据库会涉及到跨 VPC 访问的场景，下面我们先来介绍一下其工作机制。 工作机制 访问 PostgreSQL 的原理、工作机制与访问 Mysql 数据库完全相同，本文不再重复阐述，更详细的内容请参考 访问 Mysql 数据库 中的工作机制章节。 配置与函数编写 公共配置 创建专有网络VPC 登录 VPC控制台 。 参阅 VPC 搭建专有网络 创建VPC和交换机。 创建安全组 在 安全组控制台 新建安全组，点击 创建安全组 ，设置安全组名称，网络类型选择 专有网络 ，并选择刚才创建的专有网络。 注意

As a full stack Developer, if you have been spending a lot of time in developing apps recently, you already understand a whole new set of challenges related to Microservice architecture. Although there has been a shift from bloated monolithic apps to compact, focused Microservices for faster implementation and improved resiliency but the fact is developers have to really worry about the challenges in integrating these services in distributed systems which includes accountability for service discovery, load balancing, registration, fault tolerance, monitoring, routing, compliance, and security.

点击返回自学华为IoT物流网 自学华为IoT物联网_11 物联网操作系统介绍 1.1 物联网面临的困难 物联网终端发展面临的困难：开发者需要懂硬件和芯片的差异，自行适配硬件接口 物联网开发面临的困难：物联网通信协议多，通信模块更新换代快，彼此是多对多的关系，开发者需要自行选型和对接适配 物联网操作系统面临的困难： 　　　多传感器系统管理复杂 　　　视频场景下性能、功耗要求高 　　　开发语言编程效率低、上手难度大（大而复杂；实现相同的功能耗时长；同时需要更多行代码，开发效率低；编译脚本难编写，问题难发现） 1.2 物联网操作系统需求 连接需求：不同类型通信协议的互通互联 组网需求：自发现、自连接、自组网，网络可快速自愈 管理要求：不同类型传感器接入和算法开发的统一管理 2. Huawei LiteOS介绍 2.1 Huawei LiteOS特点 华为　“１＋２＋１”　ＩｏＴ架构 以轻量级、低功耗，快速启动等特性为基础 Ｗｉｆｉ、Ｚｉｇｂｅｅ、ＮＢ－ＩｏＴ等短距、长距协议设备的互联互通 优化的Ｍｅｓｈ自组网，组网快、组网稳、组网多 不同类型、不同接口传感器的统一管理，即插即用 端管云协同的安全管理，降低终端被攻击的风险 ＪＳ变成语言 2.２ Huawei LiteOS基础架构　　　１＋Ｎ架构 2.3 Huawei LiteOS 四大互联网解决方案 2.3.1 华为智能家居解决方案

<?php return array( 'ez' => 'application/andrew-inset', 'hqx' => 'application/mac-binhex40', 'cpt' => 'application/mac-compactpro', 'doc' => 'application/msword', 'bin' => 'application/octet-stream', 'dms' => 'application/octet-stream', 'lha' => 'application/octet-stream', 'lzh' => 'application/octet-stream', 'exe' => 'application/octet-stream', 'class' => 'application/octet-stream', 'so' => 'application/octet-stream', 'dll' => 'application/octet-stream', 'oda' => 'application/oda', 'pdf' => 'application/pdf', 'ai' => 'application/postscript', 'eps' => 'application/postscript', 'ps' =>

最初的Unity导航系统很不完善，只能静态烘焙场景图的可行走区域，而且必须在本地保存场景的NavMesh数据，难以运行时动态计算；这使得鲜有开发者愿意再尝试Unity内置的导航功能，转向了AStar寻路算法的研究。 但实际上AStar算法真的适合大多数开发情况且性能较优么？ 了解过AStar算法的都知道，它是基于格子来遍历计算行走权重的，算法复杂度其实是相对较高的，受到格子密度，地图大小和路线长度的的影响较大。 AStar更适合的是策略性寻路，该算法更有利于找出最短路径的最优解，能够达到足够的精确性。 而Unity的NavMesh是用的拐角点算法，随便找一个场景烘焙一下便可得知，例如： 烘焙出来的NavMesh区域只在障碍物边缘与平面边缘存在顶点，而不会像AStar一样均匀的布满整个平面；如果是一个无任何障碍物的平面，那就只会有平面边缘的几个顶点，算法效率是相对较高的，并不会因为地图变大而有明显算法复杂度上的变化。 相反，NavMesh的缺点也正是AStar的优点，那就是难以保证寻路的最优解，更多的时候是用于AI能够更快计算出绕过障碍物朝向目标前进的路径。 对于场景不变的静态地图来说，Unity最初的NavMesh已经能够满足需求，但如果地图随机生成或障碍物的位置随时变化，此时静态NavMesh一下子就捉襟见肘了。 好在随着Unity版本的更新，关于动态烘焙的方法也已经能有效实现