在DX10与OpenGL3+之前,二者都是固定管线与可编程管线的混合,其中对应Ogre1.x的版本,也是结合固定与可编程管线设计.转眼到了OpenGL3+与DX10后,固定管线都被移除了,相对应着色器的功能进一步完善与扩充,对应Ogre2.x包装DX11与OpenGL3+,完全抛弃固定管线的内容,专门针对可编程管线封装.

  Ogre1.x的渲染流程一直是大家吐槽的对象,除开用Ogre1.x本身的实例批次,才能把同材质同模型合并,但是用过的人都知道,这个局限性太大,另外就是每个Renderable结合一个Pass的渲染方法,导致一是大量的状态切换,二是大量的DrawCall.这二点应该说是Ogre1.x性能一直低的主要原因.在Ogre2.x中,我们一是得益于现有流程改进,减少状态切换,二是得益于流程改进与新API的引进,减少DrawCall.

  前面文档里有提过,不用实例批次,可以把mesh合并,以及是不同的mesh,当时看到的时候,以为文档有错,或是自己理解不对,没敢写出来,现查看相关代码,不得不说现在的渲染设计太牛了(结合最新API),同mesh合并不算啥,不同mesh合到一个DrawCall里,太牛了,并且不要你自己来写是否用实例批次,如Ogre1.x中的手动实例批次,现在是全自动的.

  举个例子,在Ogre2.1中,如下代码.

        for (int i = ; i < ; ++i)
{
for (int j = ; j < ; ++j)
{
Ogre::String meshName; if (i == j)
meshName = "Sphere1000.mesh";
else
meshName = "Cube_d.mesh"; Ogre::Item *item = sceneManager->createItem(meshName,
Ogre::ResourceGroupManager::
AUTODETECT_RESOURCE_GROUP_NAME,
Ogre::SCENE_DYNAMIC);
if (i % == )
item->setDatablock("Rocks");
else
item->setDatablock("Marble"); item->setVisibilityFlags(0x000000001); size_t idx = i * + j; mSceneNode[idx] = sceneManager->getRootSceneNode(Ogre::SCENE_DYNAMIC)->
createChildSceneNode(Ogre::SCENE_DYNAMIC); mSceneNode[idx]->setPosition((i - 1.5f) * armsLength,
2.0f,
(j - 1.5f) * armsLength);
mSceneNode[idx]->setScale(0.65f, 0.65f, 0.65f); mSceneNode[idx]->roll(Ogre::Radian((Ogre::Real)idx)); mSceneNode[idx]->attachObject(item);
}
}

二个材质应用多个模型

  

  如上图,有一个4*4个模型,其中一条对角线上全是球形,余下全是立方体,其中偶数行使用材质Rocks,奇数行使用Marble.调用glDraw…(DrawCall)的次数只需要二次或四次,看硬件支持情况,如何做到的了,在Ogre2.1中,把如上16个模型添加进渲染通道时,会根据材质,模型等生成排序ID,如上顺序大致为Rocks[sphere0-0,sphere2-2,cube0-1,cube0-2,cube0-3,cube2-1…], Marble[sphere1-1,sphere3-3,cube1-2,cube1-3…].其中Rocks中的八个模型只需要一或二次DrawCall,Marble也是一样.Ogre2.1如何做到,请看相关OpenGL3+中新的API.

实例与间接绘制API

  void glDrawArraysInstancedBaseInstance(GLenum mode, GLint first, Glsizei count, GLsizei instanceCount, GLuint baseInstance); 非索引直接绘制

  • 对于通过 mode、 first 和 count 所构成的几何体图元集(相当于 glDrawArrays() 函数所需的独立参数),绘制它的 primCount 个实例。对于每个实例,内置变量 gl_InstanceID都会依次递增,新的数值会被传递到顶点着色器,以区分不同实例的顶点属性。此外,baseInstance 的值用来对实例化的顶点属性设置一个索引的偏移值,从而改变 OpenGL 取出的索引位置。

  void glDrawElementsInstancedBaseVertexBaseInstance(GLenum mode, GLsizei count,GLenum type, const GLvoid* indices, GLsizei instanceCount, GLuint baseVertex, GLuint baseInstance); 索引直接绘制

  • 对于通过mode、 count、 indices 和 baseVertex所构成的几何体图元集(相当于glDrawElementsBaseVertex() 函数所需的独立参数),绘制它的 primCount 个实例。与glDrawArraysInstanced() 类似,对于每个实例,内置变量 gl_InstanceID 都会依次递增,新的数值会被传递到顶点着色器,以区分不同实例的顶点属性。此外, baseInstance 的值用来对实例化的顶点属性设置一个索引的偏移值,从而改变 OpenGL 取出的索引位置。

  void glMultiDrawArraysIndirect(GLenum mode, const void* indirect, Glsizei drawcount, GLsizei stride); 非索引间接绘制

  • 绘制多组图元集,相关参数全部保存到缓存对象中。在 glMultiDrawArraysIndirect()的一次调用当中,可以分发总共 drawcount 个独立的绘制命令,命令中的参数与glDrawArraysIndirect() 所用的参数是一致的。每个 DrawArraysIndirectCommand 结构体之间的间隔都是 stride 个字节。如果 stride 是 0 的话,那么所有的数据结构体将构成一个紧密排列的数组。

  void glMultiDrawElementsIndirect(GLenum mode, GLenum type, const void* indirect, GLsizei drawcount, GLsizei stride); 索引间接绘制

  • 绘制多组图元集,相关参数全部保存到缓存对象中。在 glMultiDrawElementsIndirect()的一次调用当中,可以分发总共drawcount个 独立的绘制命令,命令中的参数与glDrawElementsIndirect() 所用的参数是一致的。每个 DrawElementsIndirectCommand结构体之间的间隔都是 stride 个字节。如果 stride 是 0 的话,那么所有的数据结构体将构成一个紧密排列的数组。

  其中链接可以看到Opengl官网中的SDK里的讲解,下面的讲解是红宝书第八版中的.二者对比的看可以更容易理解.第1,2二个是直接绘制版本,3,4是对应1,2的间接绘制版本,如果当前环境支持间接绘制,其中前面所说的就只需要二次DrawCall,一次材质一次DrawCall,不同mesh也可一次DrawCall.而直接绘制版本需要4次,每次材质二次DrawCall(对应二个类型mesh,每个类型mesh自动合并).

  具体来说下,渲染时,通道中的模型顺序为Rocks[sphere,sphere,cube,cube…], Marble[sphere,sphere,cube,cube…].应用材质Rocks(就是绑定对应着色器代码)后,绑定VBO,第一个sphere时,生成一次DrawCall,第二次sphere时,只需要DrawCall的实例参数instanceCount加1,到第一个cube时,增加一次DrawCall参数(非索引版本1,3为DrawArraysIndirectCommand结构,索引版本2,4为DrawElementsIndirectCommand结构),在这注意下baseInstance的更改(在相同材质下,模型不同这个值就会变),在这为2(对应上面函数参数中的baseInstace这个参数,这个和后面的drawID有关).在直接版本中,几次DrawCall参数对应几次DrawCall(上面1,2二个API). 间接绘制直接一次DrawCall(上面3,4二个API)搞定.然后是应用材质Marble,如上步骤一样.

新的Buffer操作

  在OpenGL3+,VBO,IBO,UBO,TBO都可以放入同一Buffer里.所以不同于Ogre1.x中,使用HardwareBuffer,自己生成Buffer.在Ogre2.1中,使用BufferPacked,本身不使用glGenBuffer,只是记录在一块大Buffer中的位置,GPU-CPU数据交互通过BufferInterface.因为VBO,IBO,UBO,TBO现在数据统一管理,所以对应的VertexBufferPacked,IndexBufferPacked, ConstBufferPacked, TexBufferPacked对比原来的HarderwareVertexBuffer, HarderwareIndexBuffer, HardwareUniformBuffer, HardwarePixelBuffer的处理简单太多,生成Buffer交给VaoManager完成,GPU-CPU交互通过BufferInterface完成,而原来HardwareBuffer每个都自己处理生成Buffer,GPU-CPU数据交互.原来把Buffer分成GL_ARRAY_BUFFER, GL_ELEMENT_ARRAY_BUFFER, GL_UNIFORM_BUFFER, GL_TEXTURE_BUFFER等分开处理.在OpenGl3+中,Buffer就是一块存数据的地方,不管类型,你想放啥就放啥.其中UBO与TBO因为要针对不同着色器中的不同binding索引,实现与VBO和IBO有点区别,看下ConstBufferPacked,TexBufferPacked相关代码就明白了.

  BufferType 对应GPU与CPU的操作权限,不同的权限对于不同的实现,简单说下.

  • BT_IMMUTABLE GPU只有读的权限,CPU没权限.一般纹理与模型数据使用.
  • BT_DEFAULT GPU有读写的权限,CPU没有任何权限,RTT(FBO等技术), Transform Feedback使用.
  • BT_DYNAMIC_DEFAULT GPU可读,CPU可写.一般用于粒子系统,时常更新BUFFER块(如UBO)等使用.
  • BT_DYNAMIC_PERSISTENT 同BT_DYNAMIC_DEFAULT,不同的是当Buffer 处理Mapped状态时,还能进行客户端的读写操作,如glDrawElements.
  • BT_DYNAMIC_PERSISTENT_COHERENT 同BT_DYNAMIC_PERSISTENT,不同的是当CPU修改数据后,GPU能立即得到最新数据.

  其中3,4,5具体可参见博友提升先进OpenGL(三):Persistent-mapped Buffer 中的Buffer Storage,Ogre2.1也使用Buffer Storage来提升效率. Buffer Storage一是只需要一次Map,保留相关指针,无需多次Map和UnMap,提高效率(所以也称持续映射缓冲区).二是提供更多控制,如上BufferType各枚举.

  在Ogre2.1中GL3+的VaoManager中,在初始化中,默认BT_IMMUTABLE与BT_DEFAULT加起来大小为128M,余下BT_DYNAMIC_DEFAULT, BT_DYNAMIC_PERSISTENT, BT_DYNAMIC_PERSISTENT_COHERENT每块分32M,因 BT_IMMUTABLE与BT_DEFAULT其中CPU都没权限,所以统一处理.

  在这先假设当前环境支持Buffer Storage,后面VBO,IBO,UBO,TBO都是GL3PlusVaoManager::allocatVbo来分配的,简单说下这个函数,最开始如上给BT_IMMUTABLE与BT_DEFAULT一起分配最小128M,余下每种BufferType最小32M.根据不同的BufferType对应glBufferStorage使用不同的flags.后面每次不同BufferType进来时,就找对应块是否还有分配的空间.如果有,分出一块Block,然后对应的BufferPacked记录分配起点. 对应的BufferInterface中的mVboPoolIdx记录在128M Buffer里的Block块的索引,而mVboName就是128M那块Buferr的ID.

  当使用CPU端数据更新GPU时,调用BufferInterface::map.其中BT_IMMUTABLE与BT_DEFAULT没有flag-GL_MAP_WRITE_BIT,不能直接Map,使用类StagingBuffer间接完成CPU->GPU->GPU这个转换.通过StagingBuffer::map把数据从CPU->GPU,然后又通过StagingBuffer::unmap,把当前GPU中数据移到最终GPU位置上, 对于缓存之间的复制数据为 GL_COPY_READ_BUFFER 和 GL_COPY_WRITE_BUFFER,如想了解更具体的搜索这二个关键字,从GL3PlusStagingBuffer这个类也可以了解具体用法.从上面得知,这个步骤轻过较多传输,最好不要轻易的去修改BT_IMMUTABLE与BT_DEFAULT类型的Buffer,一般只初始化时传入数据.

  余下BufferType类型如BT_DYNAMIC_DEFAULT,如上面所说,采用则使用Buffer Storage,只需Map一次保留指针到mMappedPtr.生面的Map直接使用这个mMappedPtr更新数据,相关更新过程借助类GL3PlusDynamicBuffer,这个类有注释,因为GL3+不能同时mapping(就是没有unmap,都在map)一个buffer.从上面得知,反复更新的BUFFER块应使用这种方式,更新数据非常快速.

  如果当前环境不支持Buffer Storage,则相应处理如Ogre1.x.使用glBufferData,当BT_IMMUTABLE与BT_DEFAULT时,对应flag为GL_STATIC_DRAW,否则为GL_DYNAMIC_DRAW.当CPU数据更新GPU时, BT_IMMUTABLE与BT_DEFAULT的处理同上,余下的BufferType因为没有Buffer Storage,每次更新数据需要再次调用glMapBufferRange.

渲染后期相关类与流程

  知道了新的Buffer的操作方式,我们就可以先看如下相关类,然后说明如何通过这些类来渲染.

  VertexArraObject(封装VAO):VAO不同VBO是一块BUFFER,VAO应该说是保存的相应VBO,IBO的绑定信息,以及相应顶点glVertexAttribPointer的状态.在Ogre2.1中,如上面所说VBO,IBO,UBO,TBO都保存在一个BUFFER中,所以一般来说,创建模型(模型可以有多个SubMesh,一个SubMesh对应一个VAO)对应的VAO时,其中相同的多个SubMesh,一般来说mVaoName与mRenderQuereID都相同.而不同的多个SubMesh,一般来说mVaoName相同,而mRenderQuereID不同,参见GL3与DX11中的VaoManager实现的createVertexArrayObjectImpl相关renderQueueId的计算.

  • mVaoName VAO的ID,对应一个顶点布局,布局是在OpenGL中指渲染类型(点,线,三角形带等),VBO与IBO中的BufferID,索引类型(16bit-32bit),顶点属性(glVertexAttribPointer).如果多个SubMesh用的是相同的顶点布局(在Ogre2.1中,这是很常见的,因为多个VBO,IBO一般共用一个Buffer,那么只要顶点格式一样就是相同的布局),那么可以共用一个VAO,并且这种情况很常见.
  • mRenderQuereID 一个uint32的分段数,在这分成二段,前一段是0-511(占8位), 表示当前VaoManager的ID(一个调用createVertexArrayObject后自增ID),后一段是512-uint32.maxValue(占24位),表示对应mVaoName. 这种设计一是能根据段数来排序,如在这,mVaoName不同,二个数值就会相差非常大,而mVaoName相同,创建VertexArraObject 的ID不同,值相差不大,二是这样在创建一个Mesh多SubMesh下(VaoManager的ID加1),同一SubMesh一般排在一起.

  Renderable:和Ogre1.x一样的是,在渲染通道中关联材质与数据.不同的是材质不再是Material(对应固定管线中属性设置),而是HlmsDatablock(主要用于生成对应着色器代码),数据不再是直接关联对应VBO与IBO对象,而是绑定VAO.其中 mHlmsHash 和上面的mRenderQuereID一样,是个分段数,也是分成二段,前一段是0-8191(占12位),表示在当前HLMS类型的渲染属性组合列表中的索引,其中渲染属性包含如是否骨骼动画,纹理个数,是否启用Alpha测试,是否启用模型,视图,透视矩阵等.后面一段是HLMS的类型,如PBS(基于物理渲染,),Unlit(无光照,用于GUI,粒子,自发光),TOON(卡通着色),Low_level(Ogre1.9材质渲染模式).

  QueuedRenderable:原Ogre1.x中,渲染通道中是Renderable和对应pass,现在渲染通道中保存的是QueuedRenderable.其中QueuedRenderable 中的Hash 主要用来在通道中排序,是一个unit64的分段数,在非透明的情况下分成七段,其中纹理占15-25位,meshHash占26-39位, hlmsHash(对应Renderable的mHlmsHash)占到40-49位,是否透明占60-60位(bool类型只用一位),通道ID占用61-64位,更多详情请看RenderQueue::addRenderable这个方法.这样我们排序后,按照通道ID,然后是透明,材质,模型,纹理排序,这个很重要,后面渲染时,这个顺序能保证模型能正确的组合渲染,并且保证最小的状态切换,提升效率.

  HlmsCache:hlms根据Renderable中的mHlmsHash(HLMS中渲染属性组合在列表中的索引)生成对应的各种着色器,详情请看Hlms::createShaderCacheEntry.

  • Hash 和前面一样,分段,unit32,前面15位表示当前特定的Hlms类型的HlmsCache中的hash,后面17位表示对应Renderable中的mHlmsHash.
  • Type 表示Hlms的类型,如PBS(基于物理渲染,),Unlit(无光照,用于GUI,粒子,自发光),TOON(卡通着色),Low_level(Ogre1.9材质渲染模式)
  • Shader:根据特定Hlms类型生成的各种着色器,有顶点,几何,细分曲面,片断.

  通过这几个类,我们来回顾最初那16个球的问题,如何排序,如何合并,简单说明下渲染流程.

  当前摄像机检索场景,检索所有可见的Renderable.根据Renderable的材质(在这是HlmsDatablock,非Ogre1.x中的pass)生成分段数hash(用于排序,其中先材质,再mesh),并把相关Renderable,分段数hash,对应的MovableObject包装成QueuedRenderable添加到线程渲染通道中,合并所有当前线程渲染通道到当前通道中.

  然后开始渲染通道中的模型,根据当前Renderable生成HlmsCache,根据Renderable的材质mHlmsHash,找到对应材质所有属性,结合当前类型的HLMS填充HlmsCache里的着色器代码.只需生成一次,相应HlmsCache会缓存起来.

  然后如前面所说,vao不同,一般来说,材质不同,需要重新绑定VAO(注释说是DX11/12需要),然后生成一次DrawCall.一个材质下有多个模型,在同材质下(mVaoName相同),如果后来的模型与前面的模型是同一个(mRenderQuereID相同),就只把当前DrawCall的参数中的实例个数加1,如果与前一个不同(mRenderQuereID不同),则增加对应DrawCall的参数结构,在这如果环境支持间接绘制,则所有的参数合并成一个结构数组渲染,这样可以多个不同实例和多个不同模型一次渲染,否则,还是每次一个实例多个模型一起渲染.

  我们知道,实例中多个模型,他们的局部坐标一般都不同,这个如何解决?在最开始对应VaoManager初始化时,会生成一块4096个drawID(uint32,存放0,1…4095)的Buffer,通过glVertexAttribDivisor(drawID)与baseInstance(参看前面1,2二个API).我们把多个实例中的每个模型参数如局部坐标放入TBO中(我们假定在PBS材质格式下),这样多个DrawCall都用到这个TBO,所以要用baseInstance来定位每个模型参数位置,先设置对应顶点属性drawID的glVertexAttribDivisor为1,这样每个实例中对应每个DrawID,每个实例中darwID因里面存放的是从0每个自加1的数组Buferr,达到和gl_InstanceID类似的效果, baseInstance用来正确产生每次DrawCall的drawID(因为DrawCall都共用TBO,不同实例的drawID需要增加baseInstance个位移),这样就能通过drawID当索引取得存入在TBO中的模型矩阵,同样也能根据drawID来取共享的TBO中的其他内容(gl_InstanceID类似,但是baseInstance不会影响gl_InstanceID的值),一些下面是一份HlmsPbs产生的顶点着色器代码.

#version  core
#extension GL_ARB_shading_language_420pack: require out gl_PerVertex
{
vec4 gl_Position;
}; layout(std140) uniform; mat4 UNPACK_MAT4( samplerBuffer matrixBuf, uint pixelIdx )
{
vec4 row0 = texelFetch( matrixBuf, int((pixelIdx) << 2u) );
vec4 row1 = texelFetch( matrixBuf, int(((pixelIdx) << 2u) + 1u) );
vec4 row2 = texelFetch( matrixBuf, int(((pixelIdx) << 2u) + 2u) );
vec4 row3 = texelFetch( matrixBuf, int(((pixelIdx) << 2u) + 3u) );
return mat4( row0.x, row1.x, row2.x, row3.x,
row0.y, row1.y, row2.y, row3.y,
row0.z, row1.z, row2.z, row3.z,
row0.w, row1.w, row2.w, row3.w );
} mat4x3 UNPACK_MAT4x3( samplerBuffer matrixBuf, uint pixelIdx )
{
vec4 row0 = texelFetch( matrixBuf, int((pixelIdx) << 2u) );
vec4 row1 = texelFetch( matrixBuf, int(((pixelIdx) << 2u) + 1u) );
vec4 row2 = texelFetch( matrixBuf, int(((pixelIdx) << 2u) + 2u) );
return mat4x3( row0.x, row1.x, row2.x,
row0.y, row1.y, row2.y,
row0.z, row1.z, row2.z,
row0.w, row1.w, row2.w );
} in vec4 vertex;
in vec4 qtangent;
in vec2 uv0;
in uint drawId;
out block
{
flat uint drawId;
vec3 pos;
vec3 normal; vec2 uv0; } outVs; struct ShadowReceiverData
{
mat4 texViewProj;
vec2 shadowDepthRange;
vec4 invShadowMapSize;
}; struct Light
{
vec3 position;
vec3 diffuse;
vec3 specular;
}; layout(binding = ) uniform PassBuffer
{ mat4 viewProj;
mat4 view;
mat3 invViewMatCubemap;
Light lights[]; } pass; layout(binding = ) uniform samplerBuffer worldMatBuf;
vec3 xAxis( vec4 qQuat )
{
float fTy = 2.0 * qQuat.y;
float fTz = 2.0 * qQuat.z;
float fTwy = fTy * qQuat.w;
float fTwz = fTz * qQuat.w;
float fTxy = fTy * qQuat.x;
float fTxz = fTz * qQuat.x;
float fTyy = fTy * qQuat.y;
float fTzz = fTz * qQuat.z; return vec3( 1.0-(fTyy+fTzz), fTxy+fTwz, fTxz-fTwy );
} void main()
{ mat4x3 worldMat = UNPACK_MAT4x3( worldMatBuf, drawId << 1u); mat4 worldView = UNPACK_MAT4( worldMatBuf, (drawId << 1u) + 1u ); vec4 worldPos = vec4( (worldMat * vertex).xyz, 1.0f );
vec3 normal = xAxis( normalize( qtangent ) );
outVs.pos = (worldView * vertex).xyz;
outVs.normal = mat3(worldView) * normal;
gl_Position = pass.viewProj * worldPos;
outVs.uv0 = uv0; outVs.drawId = drawId; }

HLMS产生的顶点着色器代码

  相关API主要是介绍OpenGL方面的,DX都有对应的API.

Ogre2.1 结合OpenGL3+高效渲染的更多相关文章

  1. 美团开源Graver框架:用“雕刻”诠释iOS端UI界面的高效渲染

    Graver 是一款高效的 UI 渲染框架,它以更低的资源消耗来构建十分流畅的 UI 界面.Graver 独创性的采用了基于绘制的视觉元素分解方式来构建界面,得益于此,该框架能让 UI 渲染过程变得更 ...

  2. 高效渲染css

    译自:http://css-tricks.com/efficiently-rendering-css/ 无可否认我并不经常考虑这个问题… 我们书写的CSS的效率如何,浏览器渲染它的速度如何? 浏览器的 ...

  3. Ogre2.1 Hlms与渲染流程

    在我前面三篇说明Ogre2.x的文章里,第一篇大致说了下Hlms,第二篇说了下和OpenGL结合比较紧的渲染,本文用来说下Hlms如何影响渲染流程中,因为有些概念已经在前面二文里说过了,本文就不再提, ...

  4. Unity场景渲染相关实现的猜想

    如下,很简单的一个场景,一个Panel,二个Cube,一个camera,一个方向光,其中为了避免灯光阴影的影响,关掉阴影,而Panel和二个Cube都是默认的材质,没做修改,我原猜,这三个模型应该都动 ...

  5. Qt移动应用开发(八):实现跨平台的QML和OpenGL混合渲染

    Qt移动应用开发(八):实现跨平台的QML和OpenGL混合渲染 上一篇文章讲到了利用C++这个桥梁,我们实现了QML和Java的交互.Qt 5大力推崇的QML/JS开发,让轻量.高速开发的QML/J ...

  6. 解锁Renderbus客户端使用新技巧----快速渲染效果图篇

    度娘说,效果图最基本的要求就是:应该符合事物的本身尺寸,不能为了美观而使用效果把相关模型的尺寸变动,那样的效果图不但不能起到表现设计的作用,反而成为影响设计的一个因素.可见高效渲染效果图是都是当下我们 ...

  7. vega prime 1.2 (视景仿真)

    Vega Prime 1.2 (视景仿真) MPI的视景仿真渲染工具Vega是世界上领先的应用于实时视景仿真.声音仿真和虚拟现实等领域的软件环境,它用来渲染战场仿真.娱乐.城市仿真.训练模拟器和计算可 ...

  8. iOS图片加载新框架 - FlyImage

    FlyImage 整合了SDWebImage,FastImageCache,AFNetworking的优点,是一个新的性能高效.接口简单的图片加载框架. 特点 高效 可将多张小图解码后存储到同一张大图 ...

  9. 关于Qt

    什么是Qt Qt是一个针对桌面.嵌入式.移动设备的一个跨平台的应用程序开发框架,支持的平台包括Linux.OS X.Windows.VxWorks.QNX.Android.iOS.BlackBerry ...

随机推荐

  1. C#读取对象实例的值和对对象的属性自动赋值方法

    using System; using System.Data; using System.Reflection; namespace DBUtility { /// <summary> ...

  2. 【Unity】2.6 游戏视图(Game)

    分类:Unity.C#.VS2015 创建日期:2016-03-29 一.简介 游戏视图 (Game View) 从游戏的相机 ((Camera(s)) 中呈现,代表所发布游戏的最终版.你将需要一台或 ...

  3. openssl之EVP系列之13---EVP_Open系列函数介绍

    openssl之EVP系列之13---EVP_Open系列函数介绍     ---依据openssl doc/crypto/EVP_OpenInit.pod翻译和自己的理解写成     (作者:Dra ...

  4. Speech and Language Processing, NLP 处理

    https://www.amazon.com/Speech-Language-Processing-Daniel-Jurafsky/dp/0131873210 http://web.stanford. ...

  5. python-zip方法

    zip 返回一个将多个可迭代对象组合成一个元组序列的迭代器. 1.  循环多个list的数据: letters = ['a', 'b', 'c'] nums = [1, 2, 3] for lette ...

  6. ISO27001适用性-导图

    大图请戳这里

  7. [Windows Azure] Configuring and Deploying the Windows Azure Email Service application - 2 of 5

    Configuring and Deploying the Windows Azure Email Service application - 2 of 5 This is the second tu ...

  8. Android 编程下 TextView 添加链接的一种方式

    通过如下这种方式给 TextView 添加的链接支持链接样式.点击事件.href 样式,代码如下: package cn.sunzn.tlink; import android.app.Activit ...

  9. 【ActiveMQ】Spring Jms集成ActiveMQ学习记录

    Spring Jms集成ActiveMQ学习记录. 引入依赖包 无论生产者还是消费者均引入这些包: <properties> <spring.version>3.0.5.REL ...

  10. 关于go1.6使用vendor的坑

    基本命令是:$ govendor init$ govendor add +external 坑:如果在govendor之前,修改过go get的包源代码,那么必须在该包目录里git commit这个修 ...