hkpMoppCompilerInput.h
上传用户:yisoukefu
上传日期:2020-08-09
资源大小:39506k
文件大小:13k
源码类别:

其他游戏

开发平台:

Visual C++

  1. /* 
  2.  * 
  3.  * Confidential Information of Telekinesys Research Limited (t/a Havok). Not for disclosure or distribution without Havok's
  4.  * prior written consent. This software contains code, techniques and know-how which is confidential and proprietary to Havok.
  5.  * Level 2 and Level 3 source code contains trade secrets of Havok. Havok Software (C) Copyright 1999-2009 Telekinesys Research Limited t/a Havok. All Rights Reserved. Use of this software is subject to the terms of an end user license agreement.
  6.  * 
  7.  */
  8. #ifndef HK_COLLIDE2_MOPP_COMPILER_INPUT_H
  9. #define HK_COLLIDE2_MOPP_COMPILER_INPUT_H
  10. #include <Common/Base/hkBase.h>
  11. /// This class holds the parameters that affect the building of an hkpMoppCode. See the following long description for details.
  12. /// The hkpMoppCompilerInput will be 
  13. /// initialised with default values that may be sub-optimal
  14. /// for a particular geometry. Because of this, the values should be set
  15. /// with the appropriate methods before the hkpMoppCode is built. The following
  16. /// description explains these values and how to set them:
  17. ///
  18. /// <br><br><b>What does a bounding volume tree do?</b><br>
  19. ///
  20. /// In order to quickly find collisions between a moving object and a large static geometry,
  21. /// the triangles of the static geometry are hierarchically grouped in
  22. /// a binary bounding volume tree.<br>
  23. ///
  24. /// To do collision detection between a
  25. /// moving body and a static geometry (for instance, a landscape), the bounding box of the body
  26. /// is checked against the bounding volume tree. A list of possibly colliding triangles
  27. /// is then passed to the narrowphase collision detection. You can view
  28. /// the bounding volume tree as a filter to the narrowphase collision
  29. /// detection system.<br>
  30. /// This bounding volume tree is also used when performing raycasts and linear casts.
  31. /// At every node in the tree there exists a bounding polytope, which encapsulates all 
  32. /// of its children.
  33. /// The nodes on the leaf levels encapsulate one hkpShape, normally a
  34. /// triangle. (The rest of this explanation uses triangles as an example of a leaf node).
  35. /// The fit of this bounding volume can be perfect (as in some AABB trees), or can 
  36. /// have an extra margin/tolerance built in (e.g. MOPP):nnn
  37. /// <center><img src="pix/twoTriangles.gif"></center>n
  38. ///
  39. ///
  40. /// <b>Why is the MOPP so memory efficient?</b><br>
  41. ///
  42. /// The MOPP-tree is an optimised polytope tree, based on the same principles as KDOP
  43. /// trees. In order to keep the memory down, the MOPP data structures:
  44. /// <ul>
  45. ///    <li>use a reduced floating point resolution to store the extents of each MOPP node.
  46. ///    <li>store the minimum number of extents for each node.
  47. ///    <li>implement various compression techniques to reduce the overall size.
  48. /// </ul>
  49. ///
  50. /// <b>How do the parameters affect the building process?</b><br>
  51. ///
  52. /// There is a tolerance (called the fit tolerance) for the MOPP that describes 
  53. /// how closely the bounding volumes at the leaf nodes approximate the ideal bounding volume. 
  54. /// The MOPP building process uses the hkpMoppCompilerInput to allow you to specify which is 
  55. /// more highly optimised - the size of the tree, or how closely the leaf nodes bound the triangles. 
  56. /// This means that:
  57. /// <ul><li>The smaller the fit tolerance of the bounding volumes, the more memory is needed
  58. /// to store the bounding volume information.
  59. /// <li>The smaller the fit tolerance, the less triangles are passed to the narrow
  60. /// phase collision detector and the less CPU is needed.
  61. /// </ul>
  62. ///
  63. /// <b>How can I get the best trade off between speed and memory usage?</b><br>
  64. ///
  65. /// Fit tolerance has the largest influence on speed and memory size.
  66. /// There are two fit tolerance settings, one scalar for the general case
  67. /// <b>m_absoluteFitToleranceOfTriangles</b> and one hkVector4 specifically for axis aligned triangles.
  68. /// <b>m_absoluteFitToleranceOfAxisAlignedTriangles</b>
  69. /// The fit tolerance defines how accurately the MOPP bounding
  70. /// volumes approximates perfect bounding volumes. You can define a fit
  71. /// tolerance for triangle level nodes and internal nodes. Normally only the triangle
  72. /// level fit tolerance is important for the overall performance - the internal
  73. /// fit tolerance has only a limited effect on the tree and you should use the
  74. /// default values.
  75. /// If your game can afford a loose fit of the bounding volumes, your memory consumption decreases.
  76. /// The following are some simple guidelines to calculate the necessary fit of the MOPP tree:
  77. ///
  78. /// <ul><li>If your application is a flight simulator, the player's avatar will spend most of the time 
  79. /// away from the landscape. Assuming that you have an average triangle edge length of 10 meters,
  80. /// a pretty loose m_absoluteFitToleranceOfTriangles of 2-5 meters (which is 20%-50% of the triangle edge length)
  81. /// should suffice.
  82. ///
  83. /// <li>In a quake level environment with lots of triangles of all sizes, the player's avatar will 
  84. /// almost always be in contact with the landscape. This means that the narrowphase will always 
  85. /// have some possible collisions to resolve. As any narrowphase check is far more expensive than 
  86. /// the MOPP check, decreasing m_absoluteFitToleranceOfTriangles to ~10% of the triangle edge length
  87. /// will keep the CPU time to a minimum. In a level with an average triangle edge length of 1 meter, this is
  88. /// approximately 0.1 meters.
  89. ///
  90. /// <li>For a racing game on a mostly flat terrain (triangle edge length ~5 meters),
  91. /// you should ensure that the flat triangles on the course 
  92. /// get a very tight fit in direction of the up axis (e.g. 'y-axis'). 
  93. /// A general m_absoluteFitToleranceOfTriangles of ~0.5 meters (~10% of the triangle edge length) and a
  94. /// m_absoluteFitToleranceOfAxisAlignedTriangles.y = 0.02 meters (~0.4% of the triangle edge length)
  95. /// should give optimal results. You should try to ensure that the distance of the car to the 
  96. /// ground does not get too small, unless the game does not allow for this (Formula 1 and
  97. /// Nascar racing cars have very low suspension).
  98. ///
  99. /// <li>For a game in a city with tall straight buildings, it is useful to set the axis aligned
  100. /// fit tolerance to a small value for collision detection with the walls. This means decreasing
  101. /// the x and z components of m_absoluteFitToleranceOfAxisAlignedTriangles to roughly the same
  102. /// as the y component, at ~4% (or slightly more as collision detection between the street and the users
  103. /// avatar will be more common than with the buildings, depending on game logic).
  104. ///
  105. /// <li>In a hilly terrain motorbike/offroad vehicle game with an average triangle edge length of 5 meters,
  106. /// most of the triangles normals are not parallel to the main major axes. Therefore, the fit
  107. /// of an AABB or a KDOP node is already suboptimal and setting a very tight fit for the MOPP 
  108. /// will not improve the overall performance.
  109. /// In this case m_absoluteFitToleranceOfTriangles = 0.5f and m_absoluteFitToleranceOfAxisAlignedTriangles = hkVector4(0.1f, 0.1f, 0.1f)
  110. /// should give a good result.
  111. /// </ul>
  112. /// 
  113. /// In Havok 4.5 hkMoppFitToleranceRequirements was renamed to hkpMoppCompilerInput to more adeqautely reflect the data contained in the structure
  114. class hkpMoppCompilerInput
  115. {
  116. public:
  117. HK_DECLARE_NONVIRTUAL_CLASS_ALLOCATOR(HK_MEMORY_CLASS_CDINFO, hkpMoppCompilerInput);
  118. /// The default constructor. This sets default values
  119. /// that should produce good results. However, to get the best
  120. /// performance and size metrics from your MOPP tree, you may need to change these values.
  121. hkpMoppCompilerInput();
  122. /// Sets the fit tightness of the bounding volume leaf nodes for each triangle.
  123. /// This scalar value represents the maximum distance between the extents of a 
  124. /// MOPP bounding volume node for a triangle and the extents of a 
  125. /// perfectly fitting bounding volume node for the same triangle.
  126. /// Good values range from 1% * average triangle size (near-perfect fit)
  127. /// to 50% * average triangle size (loose fit).
  128. void setAbsoluteFitToleranceOfTriangles(float inTight);
  129. /// Returns the current value for this MOPP parameter.
  130. /// Returns the fit tightness of the bounding volume leaf nodes for each triangle.
  131. float getAbsoluteFitToleranceOfTriangles() const;
  132. /// Sets this MOPP parameter.
  133. /// Sets the fit tightness of the bounding volume leaf nodes for axis aligned triangles.
  134. /// If a triangle is coplanar to one of the major axes, this fit 
  135. /// tolerance is used instead of the scalar parameter. There is one value for each axis.
  136. /// Normally only the axis which is parallel to the gravity should get a very low value.
  137. /// This parameter is very important for racing games over a flat racing course.
  138. /// NOTE: if this parameter is uninteresting, each component should be set equal 
  139. /// to the scalar absoluteFitToleranceOfTriangles
  140. void setAbsoluteFitToleranceOfAxisAlignedTriangles(const hkVector4& inTight);
  141. /// Returns the current value for this MOPP parameter.
  142. /// Returns the fit tightness of the bounding volume leaf nodes for axis aligned triangles.
  143. hkVector4 getAbsoluteFitToleranceOfAxisAlignedTriangles() const;
  144. /// Sets this MOPP parameter.
  145. /// Sets the minimum fit tolerance for internal nodes as
  146. /// a value relative to the size of the node. 
  147. /// This parameter has a subtle effect on the MOPP performance
  148. /// a default range of [0.3f,0.7f] works well.
  149. void setRelativeFitToleranceOfInternalNodes(float inUnused);
  150. /// Returns the current value for this MOPP parameter.
  151. /// Returns the minimum fit tolerance for internal nodes as
  152. /// a value relative to the size of the node. 
  153. float getRelativeFitToleranceOfInternalNodes() const;
  154. /// Sets this MOPP parameter.
  155. /// Sets the minimum fit tolerance of internal nodes.
  156. /// This parameter has a subtle effect on the MOPP performance.
  157. /// A good value is about 1/5 of your small object diameter.
  158. void setAbsoluteFitToleranceOfInternalNodes(float inMin);
  159. /// Returns the current value for this MOPP parameter.
  160. /// Returns the minimum fit tolerance of internal nodes.
  161. float getAbsoluteFitToleranceOfInternalNodes() const;
  162. public:
  163. hkVector4 m_absoluteFitToleranceOfAxisAlignedTriangles;
  164. float m_relativeFitToleranceOfInternalNodes;
  165. float m_absoluteFitToleranceOfInternalNodes;
  166. float m_absoluteFitToleranceOfTriangles;
  167. /// By default the mopp compiler tries to group similar shapekeys into 
  168. /// one node. This helps reducing the code size. However sometimes you want
  169. /// to reorder your input without changing the tree. In this case you can set
  170. /// this parameter to false;
  171. hkBool  m_useShapeKeys;
  172. /// In typical landscapes, a single very big triangle can cause the tree to become pretty bad.
  173. /// Therefore by default, the compiler can decide to split a triangle and put in triangle
  174. /// twice into the tree. If you don't want this behavior, set m_enablePrimitiveSplitting to false
  175. hkBool  m_enablePrimitiveSplitting;
  176. /// This tells the mopp compiler to organize the mopp code into smaller chunks so it can be processed on the PLAYSTATION(R)3 spu
  177. hkBool m_enableChunkSubdivision;
  178. /// By default (m_enableInterleavedBuilding=true)
  179. /// the mopp compiler uses a fixed-sized 2 megabyte buffer for triangle storage. This works well for
  180. /// large sets of triangles as memory consumption is kept limited. Yet for small sets of triangles
  181. /// (<4000) it is better to only allocate the actually needed memory size (which is smaller than
  182. /// the fixed-sized buffer). Set this member to false to disable interleaved building and to make
  183. /// the compiler allocate the correct memory block needed for all triangles.
  184. hkBool  m_enableInterleavedBuilding;
  185. /// Enable faster but more memory-consuming version of the mopp shape mediator.
  186. ///
  187. /// By default the mopp shape mediator recalculates a primitive's maximum/minimum extent on each axis
  188. /// during each access. By enabling this flag a 20% faster version of the shape mediator will be used
  189. /// that only calculates the extents once for all axes upfront and caches the results. Note that this
  190. /// mediator version has an increased memory consumption: for each of the shape's primitive an additional
  191. /// 108 bytes block is allocated.
  192. hkBool m_cachePrimitiveExtents;
  193. };
  194. #endif // HK_COLLIDE2_MOPP_COMPILER_INPUT_H
  195. /*
  196. * Havok SDK - NO SOURCE PC DOWNLOAD, BUILD(#20090216)
  197. * Confidential Information of Havok.  (C) Copyright 1999-2009
  198. * Telekinesys Research Limited t/a Havok. All Rights Reserved. The Havok
  199. * Logo, and the Havok buzzsaw logo are trademarks of Havok.  Title, ownership
  200. * rights, and intellectual property rights in the Havok software remain in
  201. * Havok and/or its suppliers.
  202. * Use of this software for evaluation purposes is subject to and indicates
  203. * acceptance of the End User licence Agreement for this product. A copy of
  204. * the license is included with this software and is also available at www.havok.com/tryhavok.
  205. */