WebGL

QuadTree 四叉树顾名思义就是树状的数据结构，其每个节点有四个孩子节点，可将二维平面递归分割子区域。QuadTree常用于空间数据库索引，3D的椎体可见区域裁剪，甚至图片分析处理，我们今天介绍的是QuadTree最常被游戏领域使用到的碰撞检测。采用QuadTree算法将大大减少需要测试碰撞的次数，从而提高游戏刷新性能，本文例子基于 HT for Web 的图形引擎，通过 GraphView 和 Graph3dView 共享同一数据模型 DataModel ，同时呈现QuadTree算法下的2D和3D碰撞视图效果： http://v.youku.com/v_show/id_XODQyNTA1NjY0.html QuadTree的实现有很多成熟的版本，我选择的是 https://github.com/timohausmann/quadtree-js/ 四叉树的算法很简单，因此这个开源库也就两百来行代码。使用也非常简单，构建一个Quadtree对象，第一个参数传入rect信息制定游戏空间范围，在每次requestAnimationFrame刷新帧时，先通过quadtree.clear()清除老数据，通过quadtree.insert(rect)插入新的节点矩形区域，这样quadtree就初始化好了，剩下就是根据需要调用quadtree.retrieve(rect)获取指定矩形区域下

前面的话 　　Cocos Creator 是一个完整的游戏开发解决方案，包括了 cocos2d-x 引擎的 JavaScript 实现，以及快速开发游戏所需要的各种图形界面工具。Cocos Creator 的编辑器完全为引擎定制打造，包含从设计、开发、预览、调试到发布的整个工作流所需的全功能，该编辑器提供面向设计和开发的两种工作流，提供简单顺畅的分工合作方式。Cocos Creator 目前支持发布游戏到 Web、Android 和 iOS，真正实现一次开发，全平台运行。Cocos Creator 是以内容创作为核心的游戏开发工具，在 Cocos2d-x 基础上实现了彻底脚本化、组件化和数据驱动等特点。本文将详细介绍cocos creator 入门知识 工作流程 　　cocos creator的流程如下所示 【创建或导入资源】 　　将图片、声音等资源拖拽到编辑器的资源管理器面板中，即可完成资源导入 　　此外，也可以在编辑器中直接创建场景、预制、动画、脚本、粒子等各类资源 【建造场景内容】 　　项目中有了一些基本资源后，就可以开始搭建场景了，场景是游戏内容最基本的组织方式，也是向玩家展示游戏的基本形态 　　通过场景编辑器将添加各类节点，负责展示游戏的美术音效资源，并作为后续交互功能的承载 【添加组件脚本，实现交互功能】 　　可以为场景中的节点挂载各种内置组件和自定义脚本组件

我们上一篇《 基于 WebSocket 实现 WebGL 3D 拓扑图 实时数据通讯同步（一） 》主要讲解了如何搭建一个实时数据通讯服务器，客户端与服务端是如何通讯的，相信通过上一篇的讲解，再配合上数据库的数据储存，我们就可以实现一个简易版的 Web 聊天工具了，有空的朋友可以自己尝试下实现，那么我们今天的主要内容真的是实现 WebGL 3D 拓扑图实时数据通讯了，请大家接着往下看。 有了前面的知识储备，我们就可以来真正实现我们 3D 拓扑图 组件上节点位置信息的实时数据同步了，毋庸置疑，节点的位置信息必须是在服务端统筹控制，才能达到实时数据同步，也就是说，我们必须在服务端创建 DataModel 来管理节点，创建 ForceLayout 弹力布局节点位置，并在节点位置改变的过程中，实时地将位置信息推送到客户端，让每个客户端都更新各自页面上面的节点位置。 在服务端我们该如何创建 HT 的 DataModel 和 ForceLayout 呢？其实也很简单，我们可以看看下面的代码： var ht = global.ht = this.ht = require('../../../build/ht-debug.js').ht, dataModel = new ht.DataModel(), reloadModel = require("../util.js").reloadModel;

感谢支持ayqy个人订阅号，每周义务推送1篇（ only unique one ）原创精品博文，话题包括但不限于前端、Node、Android、数学（WebGL）、语文（课外书读后感）、英语（文档翻译） 如果觉得弱水三千，一瓢太少，可以去 http://blog.ayqy.net 看个痛快 一.出发点 在 React 现有的组件模型下，存在很多难以解决的问题： 难以跨组件复用状态逻辑 组件复杂度高难以理解 Class 的诸多弊病 …… 而 Hooks， 肩负着破局使命 组件间逻辑复用 组件间逻辑复用一直是个问题，Render Props、Higher-Order Components等常用 套路 模式都是为了分离横切关注点（Cross-cutting concern），复用诸如： 日志 缓存/同步/持久化 数据校验 错误捕获/异常处理 的逻辑，目的是 将横切关注点与核心业务逻辑分离开 ，以便专注于业务逻辑 P.S.关于切面、关注点等 AOP 概念的更多信息，见AOP(Aspect-Oriented Programming) 然而，HOC 与 Render Props 虽然能以组件形式分离横切关注点，但也带来了一些新问题： 扩展性限制 Ref 传递问题 Wrapper Hell 之所以会出现这些问题，根本原因在于： 细粒度代码复用不应该与组件复用捆绑在一起