vrshoot
diff libs/assimp/assimp/postprocess.h @ 0:b2f14e535253
initial commit
author | John Tsiombikas <nuclear@member.fsf.org> |
---|---|
date | Sat, 01 Feb 2014 19:58:19 +0200 |
parents | |
children |
line diff
1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000 1.2 +++ b/libs/assimp/assimp/postprocess.h Sat Feb 01 19:58:19 2014 +0200 1.3 @@ -0,0 +1,630 @@ 1.4 +/* 1.5 +Open Asset Import Library (assimp) 1.6 +---------------------------------------------------------------------- 1.7 + 1.8 +Copyright (c) 2006-2012, assimp team 1.9 +All rights reserved. 1.10 + 1.11 +Redistribution and use of this software in source and binary forms, 1.12 +with or without modification, are permitted provided that the 1.13 +following conditions are met: 1.14 + 1.15 +* Redistributions of source code must retain the above 1.16 + copyright notice, this list of conditions and the 1.17 + following disclaimer. 1.18 + 1.19 +* Redistributions in binary form must reproduce the above 1.20 + copyright notice, this list of conditions and the 1.21 + following disclaimer in the documentation and/or other 1.22 + materials provided with the distribution. 1.23 + 1.24 +* Neither the name of the assimp team, nor the names of its 1.25 + contributors may be used to endorse or promote products 1.26 + derived from this software without specific prior 1.27 + written permission of the assimp team. 1.28 + 1.29 +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1.30 +"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1.31 +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1.32 +A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1.33 +OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1.34 +SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1.35 +LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1.36 +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1.37 +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1.38 +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1.39 +OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1.40 + 1.41 +---------------------------------------------------------------------- 1.42 +*/ 1.43 + 1.44 +/** @file postprocess.h 1.45 + * @brief Definitions for import post processing steps 1.46 + */ 1.47 +#ifndef AI_POSTPROCESS_H_INC 1.48 +#define AI_POSTPROCESS_H_INC 1.49 + 1.50 +#include "types.h" 1.51 + 1.52 +#ifdef __cplusplus 1.53 +extern "C" { 1.54 +#endif 1.55 + 1.56 +// ----------------------------------------------------------------------------------- 1.57 +/** @enum aiPostProcessSteps 1.58 + * @brief Defines the flags for all possible post processing steps. 1.59 + * 1.60 + * @see Importer::ReadFile 1.61 + * @see aiImportFile 1.62 + * @see aiImportFileEx 1.63 + */ 1.64 +// ----------------------------------------------------------------------------------- 1.65 +enum aiPostProcessSteps 1.66 +{ 1.67 + 1.68 + // ------------------------------------------------------------------------- 1.69 + /** <hr>Calculates the tangents and bitangents for the imported meshes. 1.70 + * 1.71 + * Does nothing if a mesh does not have normals. You might want this post 1.72 + * processing step to be executed if you plan to use tangent space calculations 1.73 + * such as normal mapping applied to the meshes. There's a config setting, 1.74 + * <tt>#AI_CONFIG_PP_CT_MAX_SMOOTHING_ANGLE</tt>, which allows you to specify 1.75 + * a maximum smoothing angle for the algorithm. However, usually you'll 1.76 + * want to leave it at the default value. 1.77 + */ 1.78 + aiProcess_CalcTangentSpace = 0x1, 1.79 + 1.80 + // ------------------------------------------------------------------------- 1.81 + /** <hr>Identifies and joins identical vertex data sets within all 1.82 + * imported meshes. 1.83 + * 1.84 + * After this step is run, each mesh contains unique vertices, 1.85 + * so a vertex may be used by multiple faces. You usually want 1.86 + * to use this post processing step. If your application deals with 1.87 + * indexed geometry, this step is compulsory or you'll just waste rendering 1.88 + * time. <b>If this flag is not specified</b>, no vertices are referenced by 1.89 + * more than one face and <b>no index buffer is required</b> for rendering. 1.90 + */ 1.91 + aiProcess_JoinIdenticalVertices = 0x2, 1.92 + 1.93 + // ------------------------------------------------------------------------- 1.94 + /** <hr>Converts all the imported data to a left-handed coordinate space. 1.95 + * 1.96 + * By default the data is returned in a right-handed coordinate space (which 1.97 + * OpenGL prefers). In this space, +X points to the right, 1.98 + * +Z points towards the viewer, and +Y points upwards. In the DirectX 1.99 + * coordinate space +X points to the right, +Y points upwards, and +Z points 1.100 + * away from the viewer. 1.101 + * 1.102 + * You'll probably want to consider this flag if you use Direct3D for 1.103 + * rendering. The #aiProcess_ConvertToLeftHanded flag supersedes this 1.104 + * setting and bundles all conversions typically required for D3D-based 1.105 + * applications. 1.106 + */ 1.107 + aiProcess_MakeLeftHanded = 0x4, 1.108 + 1.109 + // ------------------------------------------------------------------------- 1.110 + /** <hr>Triangulates all faces of all meshes. 1.111 + * 1.112 + * By default the imported mesh data might contain faces with more than 3 1.113 + * indices. For rendering you'll usually want all faces to be triangles. 1.114 + * This post processing step splits up faces with more than 3 indices into 1.115 + * triangles. Line and point primitives are *not* modified! If you want 1.116 + * 'triangles only' with no other kinds of primitives, try the following 1.117 + * solution: 1.118 + * <ul> 1.119 + * <li>Specify both #aiProcess_Triangulate and #aiProcess_SortByPType </li> 1.120 + * </li>Ignore all point and line meshes when you process assimp's output</li> 1.121 + * </ul> 1.122 + */ 1.123 + aiProcess_Triangulate = 0x8, 1.124 + 1.125 + // ------------------------------------------------------------------------- 1.126 + /** <hr>Removes some parts of the data structure (animations, materials, 1.127 + * light sources, cameras, textures, vertex components). 1.128 + * 1.129 + * The components to be removed are specified in a separate 1.130 + * configuration option, <tt>#AI_CONFIG_PP_RVC_FLAGS</tt>. This is quite useful 1.131 + * if you don't need all parts of the output structure. Vertex colors 1.132 + * are rarely used today for example... Calling this step to remove unneeded 1.133 + * data from the pipeline as early as possible results in increased 1.134 + * performance and a more optimized output data structure. 1.135 + * This step is also useful if you want to force Assimp to recompute 1.136 + * normals or tangents. The corresponding steps don't recompute them if 1.137 + * they're already there (loaded from the source asset). By using this 1.138 + * step you can make sure they are NOT there. 1.139 + * 1.140 + * This flag is a poor one, mainly because its purpose is usually 1.141 + * misunderstood. Consider the following case: a 3D model has been exported 1.142 + * from a CAD app, and it has per-face vertex colors. Vertex positions can't be 1.143 + * shared, thus the #aiProcess_JoinIdenticalVertices step fails to 1.144 + * optimize the data because of these nasty little vertex colors. 1.145 + * Most apps don't even process them, so it's all for nothing. By using 1.146 + * this step, unneeded components are excluded as early as possible 1.147 + * thus opening more room for internal optimizations. 1.148 + */ 1.149 + aiProcess_RemoveComponent = 0x10, 1.150 + 1.151 + // ------------------------------------------------------------------------- 1.152 + /** <hr>Generates normals for all faces of all meshes. 1.153 + * 1.154 + * This is ignored if normals are already there at the time this flag 1.155 + * is evaluated. Model importers try to load them from the source file, so 1.156 + * they're usually already there. Face normals are shared between all points 1.157 + * of a single face, so a single point can have multiple normals, which 1.158 + * forces the library to duplicate vertices in some cases. 1.159 + * #aiProcess_JoinIdenticalVertices is *senseless* then. 1.160 + * 1.161 + * This flag may not be specified together with #aiProcess_GenSmoothNormals. 1.162 + */ 1.163 + aiProcess_GenNormals = 0x20, 1.164 + 1.165 + // ------------------------------------------------------------------------- 1.166 + /** <hr>Generates smooth normals for all vertices in the mesh. 1.167 + * 1.168 + * This is ignored if normals are already there at the time this flag 1.169 + * is evaluated. Model importers try to load them from the source file, so 1.170 + * they're usually already there. 1.171 + * 1.172 + * This flag may not be specified together with 1.173 + * #aiProcess_GenNormals. There's a configuration option, 1.174 + * <tt>#AI_CONFIG_PP_GSN_MAX_SMOOTHING_ANGLE</tt> which allows you to specify 1.175 + * an angle maximum for the normal smoothing algorithm. Normals exceeding 1.176 + * this limit are not smoothed, resulting in a 'hard' seam between two faces. 1.177 + * Using a decent angle here (e.g. 80 degrees) results in very good visual 1.178 + * appearance. 1.179 + */ 1.180 + aiProcess_GenSmoothNormals = 0x40, 1.181 + 1.182 + // ------------------------------------------------------------------------- 1.183 + /** <hr>Splits large meshes into smaller sub-meshes. 1.184 + * 1.185 + * This is quite useful for real-time rendering, where the number of triangles 1.186 + * which can be maximally processed in a single draw-call is limited 1.187 + * by the video driver/hardware. The maximum vertex buffer is usually limited 1.188 + * too. Both requirements can be met with this step: you may specify both a 1.189 + * triangle and vertex limit for a single mesh. 1.190 + * 1.191 + * The split limits can (and should!) be set through the 1.192 + * <tt>#AI_CONFIG_PP_SLM_VERTEX_LIMIT</tt> and <tt>#AI_CONFIG_PP_SLM_TRIANGLE_LIMIT</tt> 1.193 + * settings. The default values are <tt>#AI_SLM_DEFAULT_MAX_VERTICES</tt> and 1.194 + * <tt>#AI_SLM_DEFAULT_MAX_TRIANGLES</tt>. 1.195 + * 1.196 + * Note that splitting is generally a time-consuming task, but only if there's 1.197 + * something to split. The use of this step is recommended for most users. 1.198 + */ 1.199 + aiProcess_SplitLargeMeshes = 0x80, 1.200 + 1.201 + // ------------------------------------------------------------------------- 1.202 + /** <hr>Removes the node graph and pre-transforms all vertices with 1.203 + * the local transformation matrices of their nodes. 1.204 + * 1.205 + * The output scene still contains nodes, however there is only a 1.206 + * root node with children, each one referencing only one mesh, 1.207 + * and each mesh referencing one material. For rendering, you can 1.208 + * simply render all meshes in order - you don't need to pay 1.209 + * attention to local transformations and the node hierarchy. 1.210 + * Animations are removed during this step. 1.211 + * This step is intended for applications without a scenegraph. 1.212 + * The step CAN cause some problems: if e.g. a mesh of the asset 1.213 + * contains normals and another, using the same material index, does not, 1.214 + * they will be brought together, but the first meshes's part of 1.215 + * the normal list is zeroed. However, these artifacts are rare. 1.216 + * @note The <tt>#AI_CONFIG_PP_PTV_NORMALIZE</tt> configuration property 1.217 + * can be set to normalize the scene's spatial dimension to the -1...1 1.218 + * range. 1.219 + */ 1.220 + aiProcess_PreTransformVertices = 0x100, 1.221 + 1.222 + // ------------------------------------------------------------------------- 1.223 + /** <hr>Limits the number of bones simultaneously affecting a single vertex 1.224 + * to a maximum value. 1.225 + * 1.226 + * If any vertex is affected by more than the maximum number of bones, the least 1.227 + * important vertex weights are removed and the remaining vertex weights are 1.228 + * renormalized so that the weights still sum up to 1. 1.229 + * The default bone weight limit is 4 (defined as <tt>#AI_LMW_MAX_WEIGHTS</tt> in 1.230 + * config.h), but you can use the <tt>#AI_CONFIG_PP_LBW_MAX_WEIGHTS</tt> setting to 1.231 + * supply your own limit to the post processing step. 1.232 + * 1.233 + * If you intend to perform the skinning in hardware, this post processing 1.234 + * step might be of interest to you. 1.235 + */ 1.236 + aiProcess_LimitBoneWeights = 0x200, 1.237 + 1.238 + // ------------------------------------------------------------------------- 1.239 + /** <hr>Validates the imported scene data structure. 1.240 + * This makes sure that all indices are valid, all animations and 1.241 + * bones are linked correctly, all material references are correct .. etc. 1.242 + * 1.243 + * It is recommended that you capture Assimp's log output if you use this flag, 1.244 + * so you can easily find out what's wrong if a file fails the 1.245 + * validation. The validator is quite strict and will find *all* 1.246 + * inconsistencies in the data structure... It is recommended that plugin 1.247 + * developers use it to debug their loaders. There are two types of 1.248 + * validation failures: 1.249 + * <ul> 1.250 + * <li>Error: There's something wrong with the imported data. Further 1.251 + * postprocessing is not possible and the data is not usable at all. 1.252 + * The import fails. #Importer::GetErrorString() or #aiGetErrorString() 1.253 + * carry the error message around.</li> 1.254 + * <li>Warning: There are some minor issues (e.g. 1000000 animation 1.255 + * keyframes with the same time), but further postprocessing and use 1.256 + * of the data structure is still safe. Warning details are written 1.257 + * to the log file, <tt>#AI_SCENE_FLAGS_VALIDATION_WARNING</tt> is set 1.258 + * in #aiScene::mFlags</li> 1.259 + * </ul> 1.260 + * 1.261 + * This post-processing step is not time-consuming. Its use is not 1.262 + * compulsory, but recommended. 1.263 + */ 1.264 + aiProcess_ValidateDataStructure = 0x400, 1.265 + 1.266 + // ------------------------------------------------------------------------- 1.267 + /** <hr>Reorders triangles for better vertex cache locality. 1.268 + * 1.269 + * The step tries to improve the ACMR (average post-transform vertex cache 1.270 + * miss ratio) for all meshes. The implementation runs in O(n) and is 1.271 + * roughly based on the 'tipsify' algorithm (see <a href=" 1.272 + * http://www.cs.princeton.edu/gfx/pubs/Sander_2007_%3ETR/tipsy.pdf">this 1.273 + * paper</a>). 1.274 + * 1.275 + * If you intend to render huge models in hardware, this step might 1.276 + * be of interest to you. The <tt>#AI_CONFIG_PP_ICL_PTCACHE_SIZE</tt>config 1.277 + * setting can be used to fine-tune the cache optimization. 1.278 + */ 1.279 + aiProcess_ImproveCacheLocality = 0x800, 1.280 + 1.281 + // ------------------------------------------------------------------------- 1.282 + /** <hr>Searches for redundant/unreferenced materials and removes them. 1.283 + * 1.284 + * This is especially useful in combination with the 1.285 + * #aiProcess_PretransformVertices and #aiProcess_OptimizeMeshes flags. 1.286 + * Both join small meshes with equal characteristics, but they can't do 1.287 + * their work if two meshes have different materials. Because several 1.288 + * material settings are lost during Assimp's import filters, 1.289 + * (and because many exporters don't check for redundant materials), huge 1.290 + * models often have materials which are are defined several times with 1.291 + * exactly the same settings. 1.292 + * 1.293 + * Several material settings not contributing to the final appearance of 1.294 + * a surface are ignored in all comparisons (e.g. the material name). 1.295 + * So, if you're passing additional information through the 1.296 + * content pipeline (probably using *magic* material names), don't 1.297 + * specify this flag. Alternatively take a look at the 1.298 + * <tt>#AI_CONFIG_PP_RRM_EXCLUDE_LIST</tt> setting. 1.299 + */ 1.300 + aiProcess_RemoveRedundantMaterials = 0x1000, 1.301 + 1.302 + // ------------------------------------------------------------------------- 1.303 + /** <hr>This step tries to determine which meshes have normal vectors 1.304 + * that are facing inwards and inverts them. 1.305 + * 1.306 + * The algorithm is simple but effective: 1.307 + * the bounding box of all vertices + their normals is compared against 1.308 + * the volume of the bounding box of all vertices without their normals. 1.309 + * This works well for most objects, problems might occur with planar 1.310 + * surfaces. However, the step tries to filter such cases. 1.311 + * The step inverts all in-facing normals. Generally it is recommended 1.312 + * to enable this step, although the result is not always correct. 1.313 + */ 1.314 + aiProcess_FixInfacingNormals = 0x2000, 1.315 + 1.316 + // ------------------------------------------------------------------------- 1.317 + /** <hr>This step splits meshes with more than one primitive type in 1.318 + * homogeneous sub-meshes. 1.319 + * 1.320 + * The step is executed after the triangulation step. After the step 1.321 + * returns, just one bit is set in aiMesh::mPrimitiveTypes. This is 1.322 + * especially useful for real-time rendering where point and line 1.323 + * primitives are often ignored or rendered separately. 1.324 + * You can use the <tt>#AI_CONFIG_PP_SBP_REMOVE</tt> option to specify which 1.325 + * primitive types you need. This can be used to easily exclude 1.326 + * lines and points, which are rarely used, from the import. 1.327 + */ 1.328 + aiProcess_SortByPType = 0x8000, 1.329 + 1.330 + // ------------------------------------------------------------------------- 1.331 + /** <hr>This step searches all meshes for degenerate primitives and 1.332 + * converts them to proper lines or points. 1.333 + * 1.334 + * A face is 'degenerate' if one or more of its points are identical. 1.335 + * To have the degenerate stuff not only detected and collapsed but 1.336 + * removed, try one of the following procedures: 1.337 + * <br><b>1.</b> (if you support lines and points for rendering but don't 1.338 + * want the degenerates)</br> 1.339 + * <ul> 1.340 + * <li>Specify the #aiProcess_FindDegenerates flag. 1.341 + * </li> 1.342 + * <li>Set the <tt>AI_CONFIG_PP_FD_REMOVE</tt> option to 1. This will 1.343 + * cause the step to remove degenerate triangles from the import 1.344 + * as soon as they're detected. They won't pass any further 1.345 + * pipeline steps. 1.346 + * </li> 1.347 + * </ul> 1.348 + * <br><b>2.</b>(if you don't support lines and points at all)</br> 1.349 + * <ul> 1.350 + * <li>Specify the #aiProcess_FindDegenerates flag. 1.351 + * </li> 1.352 + * <li>Specify the #aiProcess_SortByPType flag. This moves line and 1.353 + * point primitives to separate meshes. 1.354 + * </li> 1.355 + * <li>Set the <tt>AI_CONFIG_PP_SBP_REMOVE</tt> option to 1.356 + * @code aiPrimitiveType_POINTS | aiPrimitiveType_LINES 1.357 + * @endcode to cause SortByPType to reject point 1.358 + * and line meshes from the scene. 1.359 + * </li> 1.360 + * </ul> 1.361 + * @note Degenerate polygons are not necessarily evil and that's why 1.362 + * they're not removed by default. There are several file formats which 1.363 + * don't support lines or points, and some exporters bypass the 1.364 + * format specification and write them as degenerate triangles instead. 1.365 + */ 1.366 + aiProcess_FindDegenerates = 0x10000, 1.367 + 1.368 + // ------------------------------------------------------------------------- 1.369 + /** <hr>This step searches all meshes for invalid data, such as zeroed 1.370 + * normal vectors or invalid UV coords and removes/fixes them. This is 1.371 + * intended to get rid of some common exporter errors. 1.372 + * 1.373 + * This is especially useful for normals. If they are invalid, and 1.374 + * the step recognizes this, they will be removed and can later 1.375 + * be recomputed, i.e. by the #aiProcess_GenSmoothNormals flag.<br> 1.376 + * The step will also remove meshes that are infinitely small and reduce 1.377 + * animation tracks consisting of hundreds if redundant keys to a single 1.378 + * key. The <tt>AI_CONFIG_PP_FID_ANIM_ACCURACY</tt> config property decides 1.379 + * the accuracy of the check for duplicate animation tracks. 1.380 + */ 1.381 + aiProcess_FindInvalidData = 0x20000, 1.382 + 1.383 + // ------------------------------------------------------------------------- 1.384 + /** <hr>This step converts non-UV mappings (such as spherical or 1.385 + * cylindrical mapping) to proper texture coordinate channels. 1.386 + * 1.387 + * Most applications will support UV mapping only, so you will 1.388 + * probably want to specify this step in every case. Note that Assimp is not 1.389 + * always able to match the original mapping implementation of the 1.390 + * 3D app which produced a model perfectly. It's always better to let the 1.391 + * modelling app compute the UV channels - 3ds max, Maya, Blender, 1.392 + * LightWave, and Modo do this for example. 1.393 + * 1.394 + * @note If this step is not requested, you'll need to process the 1.395 + * <tt>#AI_MATKEY_MAPPING</tt> material property in order to display all assets 1.396 + * properly. 1.397 + */ 1.398 + aiProcess_GenUVCoords = 0x40000, 1.399 + 1.400 + // ------------------------------------------------------------------------- 1.401 + /** <hr>This step applies per-texture UV transformations and bakes 1.402 + * them into stand-alone vtexture coordinate channels. 1.403 + * 1.404 + * UV transformations are specified per-texture - see the 1.405 + * <tt>#AI_MATKEY_UVTRANSFORM</tt> material key for more information. 1.406 + * This step processes all textures with 1.407 + * transformed input UV coordinates and generates a new (pre-transformed) UV channel 1.408 + * which replaces the old channel. Most applications won't support UV 1.409 + * transformations, so you will probably want to specify this step. 1.410 + * 1.411 + * @note UV transformations are usually implemented in real-time apps by 1.412 + * transforming texture coordinates at vertex shader stage with a 3x3 1.413 + * (homogenous) transformation matrix. 1.414 + */ 1.415 + aiProcess_TransformUVCoords = 0x80000, 1.416 + 1.417 + // ------------------------------------------------------------------------- 1.418 + /** <hr>This step searches for duplicate meshes and replaces them 1.419 + * with references to the first mesh. 1.420 + * 1.421 + * This step takes a while, so don't use it if speed is a concern. 1.422 + * Its main purpose is to workaround the fact that many export 1.423 + * file formats don't support instanced meshes, so exporters need to 1.424 + * duplicate meshes. This step removes the duplicates again. Please 1.425 + * note that Assimp does not currently support per-node material 1.426 + * assignment to meshes, which means that identical meshes with 1.427 + * different materials are currently *not* joined, although this is 1.428 + * planned for future versions. 1.429 + */ 1.430 + aiProcess_FindInstances = 0x100000, 1.431 + 1.432 + // ------------------------------------------------------------------------- 1.433 + /** <hr>A postprocessing step to reduce the number of meshes. 1.434 + * 1.435 + * This will, in fact, reduce the number of draw calls. 1.436 + * 1.437 + * This is a very effective optimization and is recommended to be used 1.438 + * together with #aiProcess_OptimizeGraph, if possible. The flag is fully 1.439 + * compatible with both #aiProcess_SplitLargeMeshes and #aiProcess_SortByPType. 1.440 + */ 1.441 + aiProcess_OptimizeMeshes = 0x200000, 1.442 + 1.443 + 1.444 + // ------------------------------------------------------------------------- 1.445 + /** <hr>A postprocessing step to optimize the scene hierarchy. 1.446 + * 1.447 + * Nodes without animations, bones, lights or cameras assigned are 1.448 + * collapsed and joined. 1.449 + * 1.450 + * Node names can be lost during this step. If you use special 'tag nodes' 1.451 + * to pass additional information through your content pipeline, use the 1.452 + * <tt>#AI_CONFIG_PP_OG_EXCLUDE_LIST</tt> setting to specify a list of node 1.453 + * names you want to be kept. Nodes matching one of the names in this list won't 1.454 + * be touched or modified. 1.455 + * 1.456 + * Use this flag with caution. Most simple files will be collapsed to a 1.457 + * single node, so complex hierarchies are usually completely lost. This is not 1.458 + * useful for editor environments, but probably a very effective 1.459 + * optimization if you just want to get the model data, convert it to your 1.460 + * own format, and render it as fast as possible. 1.461 + * 1.462 + * This flag is designed to be used with #aiProcess_OptimizeMeshes for best 1.463 + * results. 1.464 + * 1.465 + * @note 'Crappy' scenes with thousands of extremely small meshes packed 1.466 + * in deeply nested nodes exist for almost all file formats. 1.467 + * #aiProcess_OptimizeMeshes in combination with #aiProcess_OptimizeGraph 1.468 + * usually fixes them all and makes them renderable. 1.469 + */ 1.470 + aiProcess_OptimizeGraph = 0x400000, 1.471 + 1.472 + // ------------------------------------------------------------------------- 1.473 + /** <hr>This step flips all UV coordinates along the y-axis and adjusts 1.474 + * material settings and bitangents accordingly. 1.475 + * 1.476 + * <b>Output UV coordinate system:</b> 1.477 + * @code 1.478 + * 0y|0y ---------- 1x|0y 1.479 + * | | 1.480 + * | | 1.481 + * | | 1.482 + * 0x|1y ---------- 1x|1y 1.483 + * @endcode 1.484 + * 1.485 + * You'll probably want to consider this flag if you use Direct3D for 1.486 + * rendering. The #aiProcess_ConvertToLeftHanded flag supersedes this 1.487 + * setting and bundles all conversions typically required for D3D-based 1.488 + * applications. 1.489 + */ 1.490 + aiProcess_FlipUVs = 0x800000, 1.491 + 1.492 + // ------------------------------------------------------------------------- 1.493 + /** <hr>This step adjusts the output face winding order to be CW. 1.494 + * 1.495 + * The default face winding order is counter clockwise (CCW). 1.496 + * 1.497 + * <b>Output face order:</b> 1.498 + * @code 1.499 + * x2 1.500 + * 1.501 + * x0 1.502 + * x1 1.503 + * @endcode 1.504 + */ 1.505 + aiProcess_FlipWindingOrder = 0x1000000, 1.506 + 1.507 + // ------------------------------------------------------------------------- 1.508 + /** <hr>This step splits meshes with many bones into sub-meshes so that each 1.509 + * su-bmesh has fewer or as many bones as a given limit. 1.510 + */ 1.511 + aiProcess_SplitByBoneCount = 0x2000000, 1.512 + 1.513 + // ------------------------------------------------------------------------- 1.514 + /** <hr>This step removes bones losslessly or according to some threshold. 1.515 + * 1.516 + * In some cases (i.e. formats that require it) exporters are forced to 1.517 + * assign dummy bone weights to otherwise static meshes assigned to 1.518 + * animated meshes. Full, weight-based skinning is expensive while 1.519 + * animating nodes is extremely cheap, so this step is offered to clean up 1.520 + * the data in that regard. 1.521 + * 1.522 + * Use <tt>#AI_CONFIG_PP_DB_THRESHOLD</tt> to control this. 1.523 + * Use <tt>#AI_CONFIG_PP_DB_ALL_OR_NONE</tt> if you want bones removed if and 1.524 + * only if all bones within the scene qualify for removal. 1.525 + */ 1.526 + aiProcess_Debone = 0x4000000 1.527 + 1.528 + // aiProcess_GenEntityMeshes = 0x100000, 1.529 + // aiProcess_OptimizeAnimations = 0x200000 1.530 + // aiProcess_FixTexturePaths = 0x200000 1.531 +}; 1.532 + 1.533 + 1.534 +// --------------------------------------------------------------------------------------- 1.535 +/** @def aiProcess_ConvertToLeftHanded 1.536 + * @brief Shortcut flag for Direct3D-based applications. 1.537 + * 1.538 + * Supersedes the #aiProcess_MakeLeftHanded and #aiProcess_FlipUVs and 1.539 + * #aiProcess_FlipWindingOrder flags. 1.540 + * The output data matches Direct3D's conventions: left-handed geometry, upper-left 1.541 + * origin for UV coordinates and finally clockwise face order, suitable for CCW culling. 1.542 + * 1.543 + * @deprecated 1.544 + */ 1.545 +#define aiProcess_ConvertToLeftHanded ( \ 1.546 + aiProcess_MakeLeftHanded | \ 1.547 + aiProcess_FlipUVs | \ 1.548 + aiProcess_FlipWindingOrder | \ 1.549 + 0 ) 1.550 + 1.551 + 1.552 +// --------------------------------------------------------------------------------------- 1.553 +/** @def aiProcessPreset_TargetRealtimeUse_Fast 1.554 + * @brief Default postprocess configuration optimizing the data for real-time rendering. 1.555 + * 1.556 + * Applications would want to use this preset to load models on end-user PCs, 1.557 + * maybe for direct use in game. 1.558 + * 1.559 + * If you're using DirectX, don't forget to combine this value with 1.560 + * the #aiProcess_ConvertToLeftHanded step. If you don't support UV transformations 1.561 + * in your application apply the #aiProcess_TransformUVCoords step, too. 1.562 + * @note Please take the time to read the docs for the steps enabled by this preset. 1.563 + * Some of them offer further configurable properties, while some of them might not be of 1.564 + * use for you so it might be better to not specify them. 1.565 + */ 1.566 +#define aiProcessPreset_TargetRealtime_Fast ( \ 1.567 + aiProcess_CalcTangentSpace | \ 1.568 + aiProcess_GenNormals | \ 1.569 + aiProcess_JoinIdenticalVertices | \ 1.570 + aiProcess_Triangulate | \ 1.571 + aiProcess_GenUVCoords | \ 1.572 + aiProcess_SortByPType | \ 1.573 + 0 ) 1.574 + 1.575 + // --------------------------------------------------------------------------------------- 1.576 + /** @def aiProcessPreset_TargetRealtime_Quality 1.577 + * @brief Default postprocess configuration optimizing the data for real-time rendering. 1.578 + * 1.579 + * Unlike #aiProcessPreset_TargetRealtime_Fast, this configuration 1.580 + * performs some extra optimizations to improve rendering speed and 1.581 + * to minimize memory usage. It could be a good choice for a level editor 1.582 + * environment where import speed is not so important. 1.583 + * 1.584 + * If you're using DirectX, don't forget to combine this value with 1.585 + * the #aiProcess_ConvertToLeftHanded step. If you don't support UV transformations 1.586 + * in your application apply the #aiProcess_TransformUVCoords step, too. 1.587 + * @note Please take the time to read the docs for the steps enabled by this preset. 1.588 + * Some of them offer further configurable properties, while some of them might not be 1.589 + * of use for you so it might be better to not specify them. 1.590 + */ 1.591 +#define aiProcessPreset_TargetRealtime_Quality ( \ 1.592 + aiProcess_CalcTangentSpace | \ 1.593 + aiProcess_GenSmoothNormals | \ 1.594 + aiProcess_JoinIdenticalVertices | \ 1.595 + aiProcess_ImproveCacheLocality | \ 1.596 + aiProcess_LimitBoneWeights | \ 1.597 + aiProcess_RemoveRedundantMaterials | \ 1.598 + aiProcess_SplitLargeMeshes | \ 1.599 + aiProcess_Triangulate | \ 1.600 + aiProcess_GenUVCoords | \ 1.601 + aiProcess_SortByPType | \ 1.602 + aiProcess_FindDegenerates | \ 1.603 + aiProcess_FindInvalidData | \ 1.604 + 0 ) 1.605 + 1.606 + // --------------------------------------------------------------------------------------- 1.607 + /** @def aiProcessPreset_TargetRealtime_MaxQuality 1.608 + * @brief Default postprocess configuration optimizing the data for real-time rendering. 1.609 + * 1.610 + * This preset enables almost every optimization step to achieve perfectly 1.611 + * optimized data. It's your choice for level editor environments where import speed 1.612 + * is not important. 1.613 + * 1.614 + * If you're using DirectX, don't forget to combine this value with 1.615 + * the #aiProcess_ConvertToLeftHanded step. If you don't support UV transformations 1.616 + * in your application, apply the #aiProcess_TransformUVCoords step, too. 1.617 + * @note Please take the time to read the docs for the steps enabled by this preset. 1.618 + * Some of them offer further configurable properties, while some of them might not be 1.619 + * of use for you so it might be better to not specify them. 1.620 + */ 1.621 +#define aiProcessPreset_TargetRealtime_MaxQuality ( \ 1.622 + aiProcessPreset_TargetRealtime_Quality | \ 1.623 + aiProcess_FindInstances | \ 1.624 + aiProcess_ValidateDataStructure | \ 1.625 + aiProcess_OptimizeMeshes | \ 1.626 + 0 ) 1.627 + 1.628 + 1.629 +#ifdef __cplusplus 1.630 +} // end of extern "C" 1.631 +#endif 1.632 + 1.633 +#endif // AI_POSTPROCESS_H_INC 1.634 \ No newline at end of file