2012-06-23 01:36:55 +00:00
|
|
|
/*
|
|
|
|
Open Asset Import Library (assimp)
|
|
|
|
----------------------------------------------------------------------
|
|
|
|
|
2024-02-23 21:30:05 +00:00
|
|
|
Copyright (c) 2006-2024, assimp team
|
2018-01-28 18:42:05 +00:00
|
|
|
|
2012-06-23 01:36:55 +00:00
|
|
|
All rights reserved.
|
|
|
|
|
2015-05-19 03:52:10 +00:00
|
|
|
Redistribution and use of this software in source and binary forms,
|
|
|
|
with or without modification, are permitted provided that the
|
2012-06-23 01:36:55 +00:00
|
|
|
following conditions are met:
|
|
|
|
|
|
|
|
* Redistributions of source code must retain the above
|
|
|
|
copyright notice, this list of conditions and the
|
|
|
|
following disclaimer.
|
2016-02-29 14:57:47 +00:00
|
|
|
r
|
2012-06-23 01:36:55 +00:00
|
|
|
* Redistributions in binary form must reproduce the above
|
|
|
|
copyright notice, this list of conditions and the
|
|
|
|
following disclaimer in the documentation and/or other
|
|
|
|
materials provided with the distribution.
|
|
|
|
|
|
|
|
* Neither the name of the assimp team, nor the names of its
|
|
|
|
contributors may be used to endorse or promote products
|
|
|
|
derived from this software without specific prior
|
|
|
|
written permission of the assimp team.
|
|
|
|
|
2015-05-19 03:52:10 +00:00
|
|
|
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
|
|
|
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
2012-06-23 01:36:55 +00:00
|
|
|
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
|
2015-05-19 03:52:10 +00:00
|
|
|
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
|
2012-06-23 01:36:55 +00:00
|
|
|
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
2015-05-19 03:52:10 +00:00
|
|
|
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
|
2012-06-23 01:36:55 +00:00
|
|
|
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
2015-05-19 03:52:10 +00:00
|
|
|
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
|
|
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
2012-06-23 01:36:55 +00:00
|
|
|
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
|
|
|
|
----------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
|
|
|
/** @file FBXImporter.cpp
|
|
|
|
* @brief Implementation of the FBX importer.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef ASSIMP_BUILD_NO_FBX_IMPORTER
|
|
|
|
|
|
|
|
#include "FBXImporter.h"
|
|
|
|
|
2019-10-26 15:28:51 +00:00
|
|
|
#include "FBXConverter.h"
|
|
|
|
#include "FBXDocument.h"
|
2012-06-23 01:36:55 +00:00
|
|
|
#include "FBXParser.h"
|
2019-10-26 15:28:51 +00:00
|
|
|
#include "FBXTokenizer.h"
|
2012-06-25 21:03:06 +00:00
|
|
|
#include "FBXUtil.h"
|
2012-06-23 01:36:55 +00:00
|
|
|
|
2018-01-06 00:18:33 +00:00
|
|
|
#include <assimp/MemoryIOWrapper.h>
|
Infrastructure for reporting progress
This commit adds two classes:
* ProgressTracker
* ProgressScope
The first is for users to implement, and to instantiate when they desire
to get informed about the overall progress.
The second is to be added to all functions that may take a considerable
amount of time, such that they can report back how far along they are.
These are much more convenient to use than the existing ProgressHandler.
ProgressScope is designed such that it only requires "local knowledge"
about upcoming and finished work. Scopes are nested and combined to
form the final global progress.
The active ProgressTracker is stored in a thread_local pointer.
This is a consicius decision since in assimp there is often no 'context'
passed through. The ProgressTracker may be needed anywhere, and it would
be tedious and a huge change to pass it through to every function.
Therefore, using a thread_local variable makes it accessible everywhere,
without a major interface change. Since assimmp is single-threaded,
but may be run in parallel on multiple threads, a thread_local is a
good trade-off, in my opinion.
This change only adds few uses of ProgressScope, to generally show how
it would be used. Also for our use cases these where the most pressing
places to add progress reporting, so this already covers loading from FBX
files pretty well.
2023-07-31 16:49:28 +00:00
|
|
|
#include <assimp/ProgressTracker.h>
|
2019-10-26 15:28:51 +00:00
|
|
|
#include <assimp/StreamReader.h>
|
2017-02-22 16:20:26 +00:00
|
|
|
#include <assimp/importerdesc.h>
|
2019-10-26 15:28:51 +00:00
|
|
|
#include <assimp/Importer.hpp>
|
2016-12-02 10:32:34 +00:00
|
|
|
|
2012-06-23 01:36:55 +00:00
|
|
|
namespace Assimp {
|
2019-02-18 20:43:45 +00:00
|
|
|
|
2019-10-26 15:28:51 +00:00
|
|
|
template <>
|
|
|
|
const char *LogFunctions<FBXImporter>::Prefix() {
|
2023-01-16 07:18:36 +00:00
|
|
|
return "FBX: ";
|
2019-02-18 20:43:45 +00:00
|
|
|
}
|
|
|
|
|
2019-10-26 15:28:51 +00:00
|
|
|
} // namespace Assimp
|
2012-06-23 01:36:55 +00:00
|
|
|
|
|
|
|
using namespace Assimp;
|
|
|
|
using namespace Assimp::Formatter;
|
|
|
|
using namespace Assimp::FBX;
|
|
|
|
|
|
|
|
namespace {
|
2023-11-11 08:59:42 +00:00
|
|
|
static constexpr aiImporterDesc desc = {
|
|
|
|
"Autodesk FBX Importer",
|
|
|
|
"",
|
|
|
|
"",
|
|
|
|
"",
|
|
|
|
aiImporterFlags_SupportTextFlavour,
|
|
|
|
0,
|
|
|
|
0,
|
|
|
|
0,
|
|
|
|
0,
|
|
|
|
"fbx"
|
|
|
|
};
|
2012-06-23 01:36:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// ------------------------------------------------------------------------------------------------
|
2015-05-19 03:52:10 +00:00
|
|
|
// Returns whether the class can handle the format of the given file.
|
2021-04-23 22:17:50 +00:00
|
|
|
bool FBXImporter::CanRead(const std::string & pFile, IOSystem * pIOHandler, bool /*checkSig*/) const {
|
|
|
|
// at least ASCII-FBX files usually have a 'FBX' somewhere in their head
|
2023-11-09 21:28:15 +00:00
|
|
|
static const char *tokens[] = { " \n\r\n " };
|
2021-05-04 22:08:54 +00:00
|
|
|
return SearchFileHeaderForToken(pIOHandler, pFile, tokens, AI_COUNT_OF(tokens));
|
2012-06-23 01:36:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// ------------------------------------------------------------------------------------------------
|
|
|
|
// List all extensions handled by this loader
|
2019-10-26 15:28:51 +00:00
|
|
|
const aiImporterDesc *FBXImporter::GetInfo() const {
|
|
|
|
return &desc;
|
2012-06-23 01:36:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// ------------------------------------------------------------------------------------------------
|
|
|
|
// Setup configuration properties for the loader
|
2019-10-26 15:28:51 +00:00
|
|
|
void FBXImporter::SetupProperties(const Importer *pImp) {
|
2022-04-05 18:07:22 +00:00
|
|
|
mSettings.readAllLayers = pImp->GetPropertyBool(AI_CONFIG_IMPORT_FBX_READ_ALL_GEOMETRY_LAYERS, true);
|
|
|
|
mSettings.readAllMaterials = pImp->GetPropertyBool(AI_CONFIG_IMPORT_FBX_READ_ALL_MATERIALS, false);
|
|
|
|
mSettings.readMaterials = pImp->GetPropertyBool(AI_CONFIG_IMPORT_FBX_READ_MATERIALS, true);
|
|
|
|
mSettings.readTextures = pImp->GetPropertyBool(AI_CONFIG_IMPORT_FBX_READ_TEXTURES, true);
|
|
|
|
mSettings.readCameras = pImp->GetPropertyBool(AI_CONFIG_IMPORT_FBX_READ_CAMERAS, true);
|
|
|
|
mSettings.readLights = pImp->GetPropertyBool(AI_CONFIG_IMPORT_FBX_READ_LIGHTS, true);
|
|
|
|
mSettings.readAnimations = pImp->GetPropertyBool(AI_CONFIG_IMPORT_FBX_READ_ANIMATIONS, true);
|
|
|
|
mSettings.readWeights = pImp->GetPropertyBool(AI_CONFIG_IMPORT_FBX_READ_WEIGHTS, true);
|
|
|
|
mSettings.strictMode = pImp->GetPropertyBool(AI_CONFIG_IMPORT_FBX_STRICT_MODE, false);
|
|
|
|
mSettings.preservePivots = pImp->GetPropertyBool(AI_CONFIG_IMPORT_FBX_PRESERVE_PIVOTS, true);
|
|
|
|
mSettings.optimizeEmptyAnimationCurves = pImp->GetPropertyBool(AI_CONFIG_IMPORT_FBX_OPTIMIZE_EMPTY_ANIMATION_CURVES, true);
|
|
|
|
mSettings.useLegacyEmbeddedTextureNaming = pImp->GetPropertyBool(AI_CONFIG_IMPORT_FBX_EMBEDDED_TEXTURES_LEGACY_NAMING, false);
|
|
|
|
mSettings.removeEmptyBones = pImp->GetPropertyBool(AI_CONFIG_IMPORT_REMOVE_EMPTY_BONES, true);
|
|
|
|
mSettings.convertToMeters = pImp->GetPropertyBool(AI_CONFIG_FBX_CONVERT_TO_M, false);
|
|
|
|
mSettings.useSkeleton = pImp->GetPropertyBool(AI_CONFIG_FBX_USE_SKELETON_BONE_CONTAINER, false);
|
2012-06-23 01:36:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// ------------------------------------------------------------------------------------------------
|
2015-05-19 03:52:10 +00:00
|
|
|
// Imports the given file into the given scene structure.
|
2019-10-26 15:28:51 +00:00
|
|
|
void FBXImporter::InternReadFile(const std::string &pFile, aiScene *pScene, IOSystem *pIOHandler) {
|
2020-09-01 16:30:31 +00:00
|
|
|
auto streamCloser = [&](IOStream *pStream) {
|
|
|
|
pIOHandler->Close(pStream);
|
|
|
|
};
|
|
|
|
std::unique_ptr<IOStream, decltype(streamCloser)> stream(pIOHandler->Open(pFile, "rb"), streamCloser);
|
|
|
|
if (!stream) {
|
2019-10-26 15:28:51 +00:00
|
|
|
ThrowException("Could not open file for reading");
|
|
|
|
}
|
|
|
|
|
2020-05-14 16:46:33 +00:00
|
|
|
ASSIMP_LOG_DEBUG("Reading FBX file");
|
Infrastructure for reporting progress
This commit adds two classes:
* ProgressTracker
* ProgressScope
The first is for users to implement, and to instantiate when they desire
to get informed about the overall progress.
The second is to be added to all functions that may take a considerable
amount of time, such that they can report back how far along they are.
These are much more convenient to use than the existing ProgressHandler.
ProgressScope is designed such that it only requires "local knowledge"
about upcoming and finished work. Scopes are nested and combined to
form the final global progress.
The active ProgressTracker is stored in a thread_local pointer.
This is a consicius decision since in assimp there is often no 'context'
passed through. The ProgressTracker may be needed anywhere, and it would
be tedious and a huge change to pass it through to every function.
Therefore, using a thread_local variable makes it accessible everywhere,
without a major interface change. Since assimmp is single-threaded,
but may be run in parallel on multiple threads, a thread_local is a
good trade-off, in my opinion.
This change only adds few uses of ProgressScope, to generally show how
it would be used. Also for our use cases these where the most pressing
places to add progress reporting, so this already covers loading from FBX
files pretty well.
2023-07-31 16:49:28 +00:00
|
|
|
Assimp::ProgressScope progScope("Read FBX File");
|
|
|
|
progScope.AddStep(5); // Reading FBX File Content
|
|
|
|
progScope.AddStep(); // Tokenizing FBX
|
|
|
|
progScope.AddStep(24); // Converting FBX to aiScene
|
|
|
|
|
|
|
|
progScope.StartStep("Reading FBX File Content");
|
2020-05-14 16:43:31 +00:00
|
|
|
|
2019-10-26 15:28:51 +00:00
|
|
|
// read entire file into memory - no streaming for this, fbx
|
|
|
|
// files can grow large, but the assimp output data structure
|
|
|
|
// then becomes very large, too. Assimp doesn't support
|
|
|
|
// streaming for its output data structures so the net win with
|
|
|
|
// streaming input data would be very low.
|
|
|
|
std::vector<char> contents;
|
2020-09-01 16:30:31 +00:00
|
|
|
contents.resize(stream->FileSize() + 1);
|
|
|
|
stream->Read(&*contents.begin(), 1, contents.size() - 1);
|
2019-10-26 15:28:51 +00:00
|
|
|
contents[contents.size() - 1] = 0;
|
|
|
|
const char *const begin = &*contents.begin();
|
|
|
|
|
2022-04-05 18:07:22 +00:00
|
|
|
// broad-phase tokenized pass in which we identify the core
|
2019-10-26 15:28:51 +00:00
|
|
|
// syntax elements of FBX (brackets, commas, key:value mappings)
|
|
|
|
TokenList tokens;
|
2022-04-20 14:11:09 +00:00
|
|
|
Assimp::StackAllocator tempAllocator;
|
|
|
|
try {
|
Infrastructure for reporting progress
This commit adds two classes:
* ProgressTracker
* ProgressScope
The first is for users to implement, and to instantiate when they desire
to get informed about the overall progress.
The second is to be added to all functions that may take a considerable
amount of time, such that they can report back how far along they are.
These are much more convenient to use than the existing ProgressHandler.
ProgressScope is designed such that it only requires "local knowledge"
about upcoming and finished work. Scopes are nested and combined to
form the final global progress.
The active ProgressTracker is stored in a thread_local pointer.
This is a consicius decision since in assimp there is often no 'context'
passed through. The ProgressTracker may be needed anywhere, and it would
be tedious and a huge change to pass it through to every function.
Therefore, using a thread_local variable makes it accessible everywhere,
without a major interface change. Since assimmp is single-threaded,
but may be run in parallel on multiple threads, a thread_local is a
good trade-off, in my opinion.
This change only adds few uses of ProgressScope, to generally show how
it would be used. Also for our use cases these where the most pressing
places to add progress reporting, so this already covers loading from FBX
files pretty well.
2023-07-31 16:49:28 +00:00
|
|
|
progScope.StartStep("Tokenizing FBX");
|
|
|
|
|
2019-10-26 15:28:51 +00:00
|
|
|
bool is_binary = false;
|
|
|
|
if (!strncmp(begin, "Kaydara FBX Binary", 18)) {
|
|
|
|
is_binary = true;
|
2022-04-20 10:33:39 +00:00
|
|
|
TokenizeBinary(tokens, begin, contents.size(), tempAllocator);
|
2019-10-26 15:28:51 +00:00
|
|
|
} else {
|
2022-04-20 10:33:39 +00:00
|
|
|
Tokenize(tokens, begin, tempAllocator);
|
2019-10-26 15:28:51 +00:00
|
|
|
}
|
|
|
|
|
Infrastructure for reporting progress
This commit adds two classes:
* ProgressTracker
* ProgressScope
The first is for users to implement, and to instantiate when they desire
to get informed about the overall progress.
The second is to be added to all functions that may take a considerable
amount of time, such that they can report back how far along they are.
These are much more convenient to use than the existing ProgressHandler.
ProgressScope is designed such that it only requires "local knowledge"
about upcoming and finished work. Scopes are nested and combined to
form the final global progress.
The active ProgressTracker is stored in a thread_local pointer.
This is a consicius decision since in assimp there is often no 'context'
passed through. The ProgressTracker may be needed anywhere, and it would
be tedious and a huge change to pass it through to every function.
Therefore, using a thread_local variable makes it accessible everywhere,
without a major interface change. Since assimmp is single-threaded,
but may be run in parallel on multiple threads, a thread_local is a
good trade-off, in my opinion.
This change only adds few uses of ProgressScope, to generally show how
it would be used. Also for our use cases these where the most pressing
places to add progress reporting, so this already covers loading from FBX
files pretty well.
2023-07-31 16:49:28 +00:00
|
|
|
progScope.StartStep("Converting FBX to aiScene");
|
|
|
|
|
2019-10-26 15:28:51 +00:00
|
|
|
// use this information to construct a very rudimentary
|
|
|
|
// parse-tree representing the FBX scope structure
|
2022-04-20 10:33:39 +00:00
|
|
|
Parser parser(tokens, tempAllocator, is_binary);
|
2019-10-26 15:28:51 +00:00
|
|
|
|
|
|
|
// take the raw parse-tree and convert it to a FBX DOM
|
2022-04-05 18:07:22 +00:00
|
|
|
Document doc(parser, mSettings);
|
2019-10-26 15:28:51 +00:00
|
|
|
|
|
|
|
// convert the FBX DOM to aiScene
|
2022-04-05 18:07:22 +00:00
|
|
|
ConvertToAssimpScene(pScene, doc, mSettings.removeEmptyBones);
|
2019-10-26 15:28:51 +00:00
|
|
|
|
|
|
|
// size relative to cm
|
|
|
|
float size_relative_to_cm = doc.GlobalSettings().UnitScaleFactor();
|
2022-04-05 18:07:22 +00:00
|
|
|
if (size_relative_to_cm == 0.0) {
|
2020-10-05 13:23:42 +00:00
|
|
|
// BaseImporter later asserts that fileScale is non-zero.
|
2020-10-02 14:25:16 +00:00
|
|
|
ThrowException("The UnitScaleFactor must be non-zero");
|
|
|
|
}
|
2019-10-26 15:28:51 +00:00
|
|
|
|
|
|
|
// Set FBX file scale is relative to CM must be converted to M for
|
|
|
|
// assimp universal format (M)
|
|
|
|
SetFileScale(size_relative_to_cm * 0.01f);
|
|
|
|
|
2022-04-20 14:11:09 +00:00
|
|
|
// This collection does not own the memory for the tokens, but we need to call their d'tor
|
|
|
|
std::for_each(tokens.begin(), tokens.end(), Util::destructor_fun<Token>());
|
|
|
|
|
|
|
|
} catch (std::exception &) {
|
|
|
|
std::for_each(tokens.begin(), tokens.end(), Util::destructor_fun<Token>());
|
|
|
|
throw;
|
2019-10-26 15:28:51 +00:00
|
|
|
}
|
2012-06-23 01:36:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#endif // !ASSIMP_BUILD_NO_FBX_IMPORTER
|