unity 5.4webgl教程
- 作者: 达?矢抾哆拉?
- 来源: 51数据库
- 2020-10-02
一：js效率
这个是我之前最担心的。我们的产品得益于PhysX的超强效率，实现了动态场景的快速烘焙（间接光预运算），编码成js之后，PhysX的效率究竟如何？实验结果如下：
两个场景在不同平台下的烘焙时间。单位（秒）
两个场景的烘焙结果
Firefox的运行效率还算令人满意。我们知道Unity使用的是Mozilla提出的asm.js来提升js的运行效率，而目前其他浏览器还未针对asm.js进行优化，不过这是迟早的事。而且除了烘焙功能之外，其他功能在不同的浏览器上看不到太大的性能差距。
二：js程序包尺寸
这个我也比较担心。如果内容无法在页面载入之后立刻呈现，用户会失掉耐心从而关闭页面。把所有优化选项设置好之后，我们的产品导出的程序包尺寸如下（压缩后）：
主程序（项目名.jsgz）：5.1M
内存初始化包（项目名.html.memgz）：2.7M
内置资源（项目名.datagz）：1M
不得不说还是很大。内置资源中字体占了很大的比重，将来可以把全部界面做到网页里，这样就可以使用浏览器字体，这个还好说，主程序包是把Unity的整个Runtime加上我们自己的代码全部编译到一起所以才那么大。关于这个我给Unity团队写了好几封信，问他们有没有可能不要把一些从未用到的模块编进去，他们表示会考虑但由于耦合度等原因难度应该不小。内存初始化包我不是很了7a686964616fe4b893e5b19e31333365663431解，可能是asm.js必备的东西，希望Unity推出WebGL正式版的时候这个问题能得到改善吧。
输出的项目包含Release和Compressed两个文件夹，只需保留Compressed就可以了，生成的.htaccess文件会将地址自动转向到这个压缩版本的程序包，并为HTTP请求加上一个压缩Header，浏览器下载完成后会自动解压。
三：移动平台
这是很多人关心的问题。作为HTML5的一部分，WebGL理应可以运行在所有平台不是吗？不过事实就是目前WebGL在移动平台被支持的并不好，想进微信就更是难上加难。对此我们的方案是为用户创建的每一个样板间保存一系列360度全景图，分享到微信之后可以漫游，但不能编辑。想想这样的方案似乎也很合理，手机那么小的屏幕实在不适合做复杂的三维编辑工作。等移动平台完全支持WebGL之后，会有更适合手机的3D应用出来。
四：图形接口适配
Unity5终于支持了DeferredShading，之前的只能叫DeferredLighting。不过在目前的WebGL 1.0上还是不能用，还是只能用Deferred Lighting。我们知道WebGL 1.0对应的是OpenGL ES 2.0，而WebGL2.0对应的是OpenGL ES 3.0，所以项目适配到WebGL平台，与适配到移动平台基本上是一样的。WebGL2.0的标准刚刚制定完成，支持的浏览器不知何时能推出，所以目前的适配工作，是以WebGL1.0为目标平台的。除了不能用MRT之外，我们需要把3D Texture以2D切片拼接的方式实现，还有DepthTexture要手动Encode到RGBA格式，这些工作太熟悉了，好像10年前就在做，不禁感叹实时3D这些年发展得真慢，除了游戏之外好像真的没有什么太好的应用。
一：js效率
这个是我之前最担心的。我们的产品得益于physx的超强效率，实现了动态场景的快速烘焙（间接光预运算），编码成js之后，physx的效率究竟如何？实验结果如下：
两个场景在不同平台下的烘焙时间。单位（秒）
两个场景的烘焙结果
firefox的运行效率还算令人满意。我们知道unity使用的是mozilla提出的asm.js来提升js的运行效率，而目前其他浏览器还未针对asm.js进行优化，不过这是迟早的事。而且除了烘焙功能之外，其他功能在不同的浏览器上看不到太大的性能差距。
二：js程序包尺寸
这个我也比较担心。如果内容无法在页面载入之后立刻呈现，用户会失掉耐心从而关闭页面。把所有优化选项设置好之后，我们的产品导出的程序包尺寸如下（压缩后）：
主程序（项目名.jsgz）：5.1m
内存初始化包（项目名.html.memgz）：2.7m
内置资源（项目名.datagz）：1m
不得不说还是很大。内置资源中字体占了很大的比重，将来可以把全部界面做到网页里，这样就可以使用浏览器字体，这个还好说，主程序包是把unity的整个runtime加上我们自己的代码全部编译到一起所以才那么大。关于这个我给unity团队写了好几封信，问他们有没有可能不要把一些从未用到的模块编进去，他们表示会考虑但由于耦合度等原因难度应该不小。内存初始化包我不是很了解，可能是asm.js必备的东西，希望unity推出webgl正式版的时候这个问题能得到改善吧。
输出的项目包含release和compressed两个文件夹，只需保留compressed就可以了，生成的.htaccess文件会将地址自动转向到这个压缩版本的程序包，并为http请求加上一个压缩header，浏览器下载完成后会自动解压。
三：移动平台
这是很多人关心的问题。作为html5的一部分，webgl理应可以运行在所有平台不是吗？不过事实就是目前webgl在移动平台被支持的并不好，想进微信就更是难上加难。对此我们的方案是为用户创建的每一个样板间保存一系列360度全景图，分享到微信之后可以漫游，但不能编辑。想想这样的方案似乎也很合理，手机那么小的屏幕实在不适合做复杂的三维编辑工作。等移动平台完全支持webgl之后，会有更适合手机的3d应用出来。
四：图形接口适配
unity5终于支持了deferredshading，之前的只能叫deferredlighting。不过在目前的webgl 1.0上还是不能用，还是只能用deferred lighting。我们知道webgl 1.0对应的是opengl es 2.0，而webgl2.0对应的是opengl es 3.0，所以项目适配到webgl平台，与适配到移动平台基本上是一样的。webgl2.0的标准刚刚制定完成，支持的浏览器不知何时能推出，所以目前的适配工作，是以webgl1.0为目标平台的。除了不能用mrt之外，我们需要把3d texture以2d切片拼接的方式实现，还有depthtexture要手动encode到rgba格式，这些工作太熟悉了，好像10年前就在做，不禁感叹实时3d这些年发展得真慢，除了游戏之外好像真的没有什么太好的应用。
基于 WEBGL 的 3D: three.js , osgjs 其中 three.js 最火爆，是纯JS包 osg 还有对应的 C++ 跟 .NET 包，e69da5e887aa7a6431333339656466 OSGJS 并不是 OSG 的重点 专注于 WEB 3D GIS 的 WEBGL: osmstreet openwebglobe readymap 这个是做 3D 城市规划的 基于 IE ACTIVEX OCX 的..
一：js效率
这个是我之前最担心的。我们的产品得益于PhysX的超强效率，实现了动态场景的快速烘焙（间接光预运算），编码成js之后，PhysX的效率究竟如何？实验结果如下：
两个场景在不同平台下的烘焙时间。单位（秒）
两个场景的烘焙结果
Firefox的运行效率还算令人满意。我们知道Unity使用的是Mozilla提出的asm.js来提升js的运行效率，而目前其他浏览器还未针对asm.js进行优化，不过这是迟早的事。而且除了烘焙功能之外，其他功能在不同的浏览器上看不到太大的性能差距。
二：js程序包尺寸
这个我也比较担心。如果内容无法在页面载入之后立刻呈现，用户会失掉耐心从而关闭页面。把所有优化选项设置好之后，我们的产品导出的程序包尺寸如下（压缩后）：
主程序（项目名.jsgz）：5.1M
内存初始化包（项目名.html.memgz）：2.7M
内置资源（项目名.datagz）：1M
不得不说还是很大。内置资源中字体占了很大的比重，将来可以把全部界面做到网页里，这样就可以使用浏览器字体，这个还好说，主程序包是把Unity的整个Runtime加上我们自己的代码全部编译到一起所以才那么大。关于这个我给Unity团队写了好几封信，问他们有没有可能不要把一些从未用到的模块编进去，他们表示会考虑但由于耦合度等原因难度应该不小。内存初始化包我不是很了解，可能是asm.js必备的东西，希望Unity推出WebGL正式版的时候这个问题能得到改善吧。
输出的项目包含Release和Compressed两个文件夹，只需保留Compressed就可以了，生成的.htaccess文件会将地址自动转向到这个压缩版本的程序包，并为HTTP请求加上一个压缩Header，浏览器下载完成后会自动解压。.
这个是我之前最担心的。我们的产品得益于PhysX的超强效率，实现了动态场景的快速烘焙（间接光预运算），编码成js之后，PhysX的效率究竟如何？实验结果如下：
两个场景在不同平台下的烘焙时间。单位（秒）
两个场景的烘焙结果
Firefox的运行效率还算令人满意。我们知道Unity使用的是Mozilla提出的asm.js来提升js的运行效率，而目前其他浏览器还未针对asm.js进行优化，不过这是迟早的事。而且除了烘焙功能之外，其他功能在不同的浏览器上看不到太大的性能差距。
二：js程序包尺寸
这个我也比较担心。如果内容无法在页面载入之后立刻呈现，用户会失掉耐心从而关闭页面。把所有优化选项设置好之后，我们的产品导出的程序包尺寸如下（压缩后）：
主程序（项目名.jsgz）：5.1M
内存初始化包（项目名.html.memgz）：2.7M
内置资源（项目名.datagz）：1M
不得不说还是很大。内置资源中字体占了很大的比重，将来可以把全部界面做到网页里，这样就可以使用浏览器字体，这个还好说，主程序包是把Unity的整个Runtime加上我们自己的代码全部编译到一起所以才那么大。关于这个我给Unity团队写了好几封信，问他们有没有可能不要把一些从未用到的模块编进去，他们表示会考虑但由于耦合度等原因难度应该不小。内存初始化包我不是很了7a686964616fe4b893e5b19e31333365663431解，可能是asm.js必备的东西，希望Unity推出WebGL正式版的时候这个问题能得到改善吧。
输出的项目包含Release和Compressed两个文件夹，只需保留Compressed就可以了，生成的.htaccess文件会将地址自动转向到这个压缩版本的程序包，并为HTTP请求加上一个压缩Header，浏览器下载完成后会自动解压。
三：移动平台
这是很多人关心的问题。作为HTML5的一部分，WebGL理应可以运行在所有平台不是吗？不过事实就是目前WebGL在移动平台被支持的并不好，想进微信就更是难上加难。对此我们的方案是为用户创建的每一个样板间保存一系列360度全景图，分享到微信之后可以漫游，但不能编辑。想想这样的方案似乎也很合理，手机那么小的屏幕实在不适合做复杂的三维编辑工作。等移动平台完全支持WebGL之后，会有更适合手机的3D应用出来。
四：图形接口适配
Unity5终于支持了DeferredShading，之前的只能叫DeferredLighting。不过在目前的WebGL 1.0上还是不能用，还是只能用Deferred Lighting。我们知道WebGL 1.0对应的是OpenGL ES 2.0，而WebGL2.0对应的是OpenGL ES 3.0，所以项目适配到WebGL平台，与适配到移动平台基本上是一样的。WebGL2.0的标准刚刚制定完成，支持的浏览器不知何时能推出，所以目前的适配工作，是以WebGL1.0为目标平台的。除了不能用MRT之外，我们需要把3D Texture以2D切片拼接的方式实现，还有DepthTexture要手动Encode到RGBA格式，这些工作太熟悉了，好像10年前就在做，不禁感叹实时3D这些年发展得真慢，除了游戏之外好像真的没有什么太好的应用。
一：js效率
这个是我之前最担心的。我们的产品得益于physx的超强效率，实现了动态场景的快速烘焙（间接光预运算），编码成js之后，physx的效率究竟如何？实验结果如下：
两个场景在不同平台下的烘焙时间。单位（秒）
两个场景的烘焙结果
firefox的运行效率还算令人满意。我们知道unity使用的是mozilla提出的asm.js来提升js的运行效率，而目前其他浏览器还未针对asm.js进行优化，不过这是迟早的事。而且除了烘焙功能之外，其他功能在不同的浏览器上看不到太大的性能差距。
二：js程序包尺寸
这个我也比较担心。如果内容无法在页面载入之后立刻呈现，用户会失掉耐心从而关闭页面。把所有优化选项设置好之后，我们的产品导出的程序包尺寸如下（压缩后）：
主程序（项目名.jsgz）：5.1m
内存初始化包（项目名.html.memgz）：2.7m
内置资源（项目名.datagz）：1m
不得不说还是很大。内置资源中字体占了很大的比重，将来可以把全部界面做到网页里，这样就可以使用浏览器字体，这个还好说，主程序包是把unity的整个runtime加上我们自己的代码全部编译到一起所以才那么大。关于这个我给unity团队写了好几封信，问他们有没有可能不要把一些从未用到的模块编进去，他们表示会考虑但由于耦合度等原因难度应该不小。内存初始化包我不是很了解，可能是asm.js必备的东西，希望unity推出webgl正式版的时候这个问题能得到改善吧。
输出的项目包含release和compressed两个文件夹，只需保留compressed就可以了，生成的.htaccess文件会将地址自动转向到这个压缩版本的程序包，并为http请求加上一个压缩header，浏览器下载完成后会自动解压。
三：移动平台
这是很多人关心的问题。作为html5的一部分，webgl理应可以运行在所有平台不是吗？不过事实就是目前webgl在移动平台被支持的并不好，想进微信就更是难上加难。对此我们的方案是为用户创建的每一个样板间保存一系列360度全景图，分享到微信之后可以漫游，但不能编辑。想想这样的方案似乎也很合理，手机那么小的屏幕实在不适合做复杂的三维编辑工作。等移动平台完全支持webgl之后，会有更适合手机的3d应用出来。
四：图形接口适配
unity5终于支持了deferredshading，之前的只能叫deferredlighting。不过在目前的webgl 1.0上还是不能用，还是只能用deferred lighting。我们知道webgl 1.0对应的是opengl es 2.0，而webgl2.0对应的是opengl es 3.0，所以项目适配到webgl平台，与适配到移动平台基本上是一样的。webgl2.0的标准刚刚制定完成，支持的浏览器不知何时能推出，所以目前的适配工作，是以webgl1.0为目标平台的。除了不能用mrt之外，我们需要把3d texture以2d切片拼接的方式实现，还有depthtexture要手动encode到rgba格式，这些工作太熟悉了，好像10年前就在做，不禁感叹实时3d这些年发展得真慢，除了游戏之外好像真的没有什么太好的应用。
基于 WEBGL 的 3D: three.js , osgjs 其中 three.js 最火爆，是纯JS包 osg 还有对应的 C++ 跟 .NET 包，e69da5e887aa7a6431333339656466 OSGJS 并不是 OSG 的重点 专注于 WEB 3D GIS 的 WEBGL: osmstreet openwebglobe readymap 这个是做 3D 城市规划的 基于 IE ACTIVEX OCX 的..
一：js效率
这个是我之前最担心的。我们的产品得益于PhysX的超强效率，实现了动态场景的快速烘焙（间接光预运算），编码成js之后，PhysX的效率究竟如何？实验结果如下：
两个场景在不同平台下的烘焙时间。单位（秒）
两个场景的烘焙结果
Firefox的运行效率还算令人满意。我们知道Unity使用的是Mozilla提出的asm.js来提升js的运行效率，而目前其他浏览器还未针对asm.js进行优化，不过这是迟早的事。而且除了烘焙功能之外，其他功能在不同的浏览器上看不到太大的性能差距。
二：js程序包尺寸
这个我也比较担心。如果内容无法在页面载入之后立刻呈现，用户会失掉耐心从而关闭页面。把所有优化选项设置好之后，我们的产品导出的程序包尺寸如下（压缩后）：
主程序（项目名.jsgz）：5.1M
内存初始化包（项目名.html.memgz）：2.7M
内置资源（项目名.datagz）：1M
不得不说还是很大。内置资源中字体占了很大的比重，将来可以把全部界面做到网页里，这样就可以使用浏览器字体，这个还好说，主程序包是把Unity的整个Runtime加上我们自己的代码全部编译到一起所以才那么大。关于这个我给Unity团队写了好几封信，问他们有没有可能不要把一些从未用到的模块编进去，他们表示会考虑但由于耦合度等原因难度应该不小。内存初始化包我不是很了解，可能是asm.js必备的东西，希望Unity推出WebGL正式版的时候这个问题能得到改善吧。
输出的项目包含Release和Compressed两个文件夹，只需保留Compressed就可以了，生成的.htaccess文件会将地址自动转向到这个压缩版本的程序包，并为HTTP请求加上一个压缩Header，浏览器下载完成后会自动解压。.
推荐阅读
