Difference between revisions of "Direct3D Compatibility"

From OpenGL.org
Jump to: navigation, search
(Stub for D3D compatibility features)
 
(BGRA vertex format)
Line 8: Line 8:
 
{{main|Vertex Specification#D3D compatibility}}
 
{{main|Vertex Specification#D3D compatibility}}
  
OpenGL always assumes that the components of [[vertex attribute data from vertex arrays]] is formatted in RGBA order (or XYZW/STPQ order). So the first component always goes to R, the second to G, etc.
+
OpenGL always assumes that the components of vertex attribute data from vertex arrays is formatted in RGBA order (or XYZW/STPQ order). So the first component always goes to R, the second to G, etc.
  
 
D3D has a special mode, primarily used due to the little endian nature of Intel CPUs. Colors are often stored normalized, with 8 bits per component. So the entire color fits in a 32-bit unsigned integer. The problem is the order.
 
D3D has a special mode, primarily used due to the little endian nature of Intel CPUs. Colors are often stored normalized, with 8 bits per component. So the entire color fits in a 32-bit unsigned integer. The problem is the order.
  
D3D has a special, and commonly used in D3D applications, component ordering for such colors: ARGB. When stored in that ordering in a little endian 32-bit integer, it therefore becomes BGRA.
+
D3D has a special component ordering for such colors, commonly used in D3D applications: ARGB. When stored in that ordering in a little endian 32-bit integer, it therefore becomes BGRA.
  
 
Native OpenGL applications would normally simply use what is available on OpenGL: ABGR ordering (32-bit little-endian, thus a reversed RGBA order). But if you want to read meshes that were natively built for D3D, this becomes a problem. And while one could employ a swizzle mask in GLSL, this is not entirely reasonable.
 
Native OpenGL applications would normally simply use what is available on OpenGL: ABGR ordering (32-bit little-endian, thus a reversed RGBA order). But if you want to read meshes that were natively built for D3D, this becomes a problem. And while one could employ a swizzle mask in GLSL, this is not entirely reasonable.

Revision as of 19:15, 28 July 2013

There are a number of features in OpenGL that exist mainly to provide Direct3D Compatibility in some way. These features are intended to make it easier to port applications from D3D to OpenGL. They are primarily focused on data areas: shaders and meshes. That is, they mainly make it easier to use the same mesh data between OpenGL and D3D.

In general, unless you are actually doing such a port, you should avoid these features.

BGRA vertex format

OpenGL always assumes that the components of vertex attribute data from vertex arrays is formatted in RGBA order (or XYZW/STPQ order). So the first component always goes to R, the second to G, etc.

D3D has a special mode, primarily used due to the little endian nature of Intel CPUs. Colors are often stored normalized, with 8 bits per component. So the entire color fits in a 32-bit unsigned integer. The problem is the order.

D3D has a special component ordering for such colors, commonly used in D3D applications: ARGB. When stored in that ordering in a little endian 32-bit integer, it therefore becomes BGRA.

Native OpenGL applications would normally simply use what is available on OpenGL: ABGR ordering (32-bit little-endian, thus a reversed RGBA order). But if you want to read meshes that were natively built for D3D, this becomes a problem. And while one could employ a swizzle mask in GLSL, this is not entirely reasonable.

Therefore, the size​ parameter of glVertexAttribPointer (and glVertexAttribFormat, in GL 4.3/ARB_vertex_attrib_binding) can be replaced with GL_BGRA. There are a lot of restrictions on doing this. So you should only ever use it if you need to load native D3D meshes. If your application is 100% OpenGL, don't bother.

Point coord conventions

Provoking vertex conventions

Not compatibility features

These are features that look like D3D compatibility features, but are not. They are features that work like D3D does, but are still things you should use even if you aren't doing a D3D port.

Incompatibilities

There are a number of incompatibilities left between OpenGL and D3D.