Access by C++ class interface
The assimp library can be accessed by both a class or flat function interface. The C++ class interface is the preferred way of interaction: you create an instance of class Assimp::Importer, maybe adjust some settings of it and then call Assimp::Importer::ReadFile(). The class will read the files and process its data, handing back the imported data as a pointer to an aiScene to you. You can now extract the data you need from the file. The importer manages all the resources for itsself. If the importer is destroyed, all the data that was created/read by it will be destroyed, too. So the easiest way to use the Importer is to create an instance locally, use its results and then simply let it go out of scope.
C++ example:
bool DoTheImportThing( const std::string& pFile)
{
{
return false;
}
DoTheSceneProcessing(
scene);
return true;
}
Defines the C++-API to the Open Asset Import Library.
const struct aiScene * scene
Definition: Sample_SimpleOpenGL.c:29
CPP-API: The Importer class forms an C++ interface to the functionality of the Open Asset Import Libr...
Definition: Importer.hpp:116
const char * GetErrorString() const
Returns an error description of an error that occurred in ReadFile().
Definition: Importer.cpp:409
const aiScene * ReadFile(const char *pFile, unsigned int pFlags)
Reads the given file and returns its contents if successful.
Definition: Importer.cpp:582
Assimp::Importer importer
Definition: model_loading.cpp:75
Definitions for import post processing steps.
@ aiProcess_JoinIdenticalVertices
Definition: postprocess.h:91
@ aiProcess_CalcTangentSpace
Definition: postprocess.h:78
@ aiProcess_Triangulate
Definition: postprocess.h:123
@ aiProcess_SortByPType
Definition: postprocess.h:328
Defines the data structures in which the imported scene is returned.
The root structure of the imported data.
Definition: scene.h:278
What exactly is read from the files and how you interpret it is described at the Data Structures page. The post processing steps that the assimp library can apply to the imported data are listed at aiPostProcessSteps. See the pp Post processing page for more details.
Note that the aiScene data structure returned is declared 'const'. Yes, you can get rid of these 5 letters with a simple cast. Yes, you may do that. No, it's not recommended (and it's suicide in DLL builds if you try to use new or delete on any of the arrays in the scene).
Access by plain-c function interface
The plain function interface is just as simple, but requires you to manually call the clean-up after you're done with the imported data. To start the import process, call aiImportFile() with the filename in question and the desired postprocessing flags like above. If the call is successful, an aiScene pointer with the imported data is handed back to you. When you're done with the extraction of the data you're interested in, call aiReleaseImport() on the imported scene to clean up all resources associated with the import.
C example:
bool DoTheImportThing( const char* pFile)
{
{
return false;
}
DoTheSceneProcessing(
scene);
return true;
}
const char * aiGetErrorString()
Returns the error text of the last failed import process.
Definition: Assimp.cpp:458
const aiScene * aiImportFile(const char *pFile, unsigned int pFlags)
Reads the given file and returns its content.
Definition: Assimp.cpp:158
void aiReleaseImport(const aiScene *pScene)
Releases all resources associated with the given import process.
Definition: Assimp.cpp:272
Defines the C-API to the Open Asset Import Library.
Using custom IO logic with the C++ class interface
The assimp library needs to access files internally. This of course applies to the file you want to read, but also to additional files in the same folder for certain file formats. By default, standard C/C++ IO logic is used to access these files. If your application works in a special environment where custom logic is needed to access the specified files, you have to supply custom implementations of IOStream and IOSystem. A shortened example might look like this:
{
friend class MyIOSystem;
protected:
MyIOStream(void);
public:
~MyIOStream(void);
size_t Read(
void* pvBuffer,
size_t pSize,
size_t pCount) { ... }
size_t Write(
const void* pvBuffer,
size_t pSize,
size_t pCount) { ... }
size_t Tell()
const { ... }
};
{
MyIOSystem() { ... }
~MyIOSystem() { ... }
bool Exists(
const std::string& pFile)
const {
..
}
char GetOsSeparator() const {
return '/';
}
IOStream*
Open(
const std::string& pFile,
const std::string& pMode) {
return new MyIOStream( ... );
}
void Close( IOStream* pFile) {
delete pFile; }
};
File I/O wrappers for C++.
File system wrapper for C++.
CPP-API: Class to handle file I/O for C++.
Definition: IOStream.hpp:68
virtual size_t Tell() const =0
Get the current position of the read/write cursor.
virtual aiReturn Seek(size_t pOffset, aiOrigin pOrigin)=0
Set the read/write cursor of the file.
virtual void Flush()=0
Flush the contents of the file buffer (for writers) See fflush() for more details.
virtual size_t FileSize() const =0
Returns filesize Returns the filesize.
virtual size_t Write(const void *pvBuffer, size_t pSize, size_t pCount)=0
Write to the file.
virtual size_t Read(void *pvBuffer, size_t pSize, size_t pCount)=0
Read from the file.
CPP-API: Interface to the file system.
Definition: IOSystem.hpp:74
AI_FORCE_INLINE bool Exists(const std::string &pFile) const
For backward compatibility.
Definition: IOSystem.hpp:232
virtual void Close(IOStream *pFile)=0
Closes the given file and releases all resources associated with it.
virtual IOStream * Open(const char *pFile, const char *pMode="rb")=0
Open a new file with a given path.
aiReturn
Standard return type for some library functions.
Definition: types.h:374
aiOrigin
Seek origins (for the virtual file system API).
Definition: types.h:404
Now that your IO system is implemented, supply an instance of it to the Importer object by calling Assimp::Importer::SetIOHandler().
void DoTheImportThing( const std::string& pFile)
{
}
void SetIOHandler(IOSystem *pIOHandler)
Supplies a custom IO handler to the importer to use to open and access files.
Definition: Importer.cpp:310
Using custom IO logic with the plain-c function interface
The C interface also provides a way to override the file system. Control is not as fine-grained as for C++ although surely enough for almost any purpose. The process is simple:
-
Include cfileio.h
-
Fill an aiFileIO structure with custom file system callbacks (they're self-explanatory as they work similar to the CRT's fXXX functions)
-
.. and pass it as parameter to aiImportFileEx
Logging
The assimp library provides an easy mechanism to log messages. For instance if you want to check the state of your import and you just want to see, after which preprocessing step the import-process was aborted you can take a look into the log. Per default the assimp-library provides a default log implementation, where you can log your user specific message by calling it as a singleton with the requested logging-type. To see how this works take a look to this:
static Logger * get()
Getter for singleton instance.
Definition: DefaultLogger.cpp:230
static Logger * create(const char *name=ASSIMP_DEFAULT_LOG_NAME, LogSeverity severity=NORMAL, unsigned int defStreams=aiDefaultLogStream_DEBUGGER|aiDefaultLogStream_FILE, IOSystem *io=NULL)
Creates a logging instance.
Definition: DefaultLogger.cpp:131
static void kill()
Kills the current singleton logger and replaces it with a #NullLogger instance.
Definition: DefaultLogger.cpp:236
void info(const char *message)
Writes a info message.
Definition: DefaultLogger.cpp:179
@ VERBOSE
Debug infos will be logged, too.
Definition: Logger.hpp:73
MACHINE-GENERATED by scripts/ICFImporter/CppGenerator.py.
Definition: 3DSExporter.cpp:56
At first you have to create the default-logger-instance (create). Now you are ready to rock and can log a little bit around. After that you should kill it to release the singleton instance.
If you want to integrate the assimp-log into your own GUI it my be helpful to have a mechanism writing the logs into your own log windows. The logger interface provides this by implementing an interface called LogStream. You can attach and detach this log stream to the default-logger instance or any implementation derived from Logger. Just derivate your own logger from the abstract base class LogStream and overwrite the write-method:
class myStream :
public LogStream
{
public:
myStream()
{
}
~myStream()
{
}
void write(const char* message)
{
::printf("%s\n", message);
}
};
#define WARN
Definition: BlenderScene.h:94
virtual bool attachStream(LogStream *pStream, unsigned int severity=Debugging|Err|Warn|Info)=0
Attach a new log-stream.
int INFO
Definition: ai_regression_ui.py:50
The severity level controls the kind of message which will be written into the attached stream. If you just want to log errors and warnings set the warn and error severity flag for those severities. It is also possible to remove a self defined logstream from an error severity by detaching it with the severity flag set:
unsigned int severity = 0;
severity |= Logger::DEBUGGING;
If you want to implement your own logger just derive from the abstract base class #Logger and overwrite the methods debug, info, warn and error.
If you want to see the debug-messages in a debug-configured build, the Logger-interface provides a logging-severity. You can set it calling the following method:
LogSeverity
Defines the log severity.
Definition: OpenDDLParser.h:73
void setLogSeverity(LogSeverity log_severity)
Set a new log severity.
Definition: Logger.hpp:227
The normal logging severity supports just the basic stuff like, info, warnings and errors. In the verbose level very fine-grained debug messages will be logged, too. Note that this kind kind of logging might decrease import performance.