For all who are interested in the language ports of Asset-Importer-Lib: I opened a poll which language binding will be preferred.
So if you want to vote as well, feel free to participate our poll at: The Assimp language binding Poll
For all who are interested in the language ports of Asset-Importer-Lib: I opened a poll which language binding will be preferred.
So if you want to vote as well, feel free to participate our poll at: The Assimp language binding Poll
If you want to support my Asset-Importer-Work: here is my Patreon-Profile for the assimp-library: https://www.patreon.com/assimp
I cannot promise that I will be able to work on Assimp all day. But for funding will help me to improve the underlying infrastructure like the webspace or some new hardware.
Think of the following situation: you want to import a model using Asset-Importer-Lib and store some values like the version of the current asset or the author / company. Or when you want to manage the models using modules for a much more efficient way for your SCM you need to store grouping information. How can you do that using the Asset-Importer-Lib?
Asset-Importer-Lib provides a meta-data API to offer a solution for these kind of use-cases. It is straight-forward to use:
// to allocated two entries aiMetadata *data = aiMetadata::Alloc( 2 ); unsigned int index( 0 ); bool success( false ); const std::string key_int = "test_int"; // to store an int-key success = data->Set( index, key_int, 1 ); // to store a string key index = 1; const std::string key = "test"; success = data->Set( index, key, aiString( std::string( "test" ) ) ); // Deallocate the data afterwards aiMetaData::dealloc( data );
You can store an arbitrary number of items, supported datatypes are
int float double aiString
The intermediate data-structure aiNode can store this data.
After struggeling with bugs in assimp for more than 10 years until now I have to accept the fact: I need to improve our unittests + regression-test-strategy:
Yes, these are all signs of legacy code :-)…
So I started to review our old testing-strategy:
So I started to redesign this kind of strategy. A lot of people are spending hours and hours to support us and a lot of software is using Asset-Importer-Lib. So for me as a software-engineer it is my duty to guaratee that we are not breaking all your code with every change we are doing.
So I will change some things …
class AbstractImportExportBase : public ::testing::Test { public: virtual ~AbstractImportExportBase(); virtual bool importerTest() = 0; };
All Importer tests will be derived from this class. As you can see the importerTest-method must be implemented for each new importer test. So we will get a starting point when you want to look into a special importer issue: look for the right unittest: if you can find one: start your investigations. If not: build you own test fixure, derive it from AbstractImportExportBase and make sure, that there is an importer test. At the moment this is just a simple Assimp::Importer::ReadFile()-call. But to make sure that the results will not change there is another new class.
I already started to implements the unit-tests and the SceneDiffer-class. And I am using our unittests to reproduce new issues. When fixing them the test to reproduce the underlying issue is checked in as well.
Hopefully these things will help you Assimp-users to get a better User-Experience with Asset-Importer-Lib.
Feel free to give me any kind of feedback …
When you are working on Github with your project there are a lot really handy services which you can use. This kind of software-usage is called “Software-As-A-Service”. Why? You can use it via a nice Web-API without having all the maintain-work.
For instance when you want to use a Continuous-Integration-Service for your project you can setup a new PC, install Jenkins. Or you just use Travis on Github instead.
So I just started to use some more services on GitHub for my projects, in special for Asset-Importer-Lib ( see https://github.com/assimp/assimp and its dependency https://github.com/kimkulling/openddl-parser.git ) of course:
If you want to generate a 64bit-build for Asset-Importer-Lib by using the Visual Studio project files generated by CMake please follow these instructions:
Make sure that you are using a supported cmake ( 2.8 or higher at the moment )- and Visual-Studio-Version ( on the current master VS2010 is deprecated )
Clone the latest master Asset-Importer-Lib from github
Generate the project files with the command:
cmake -G”Visual Studio 14 Win64"
Open the project and build the whole project and enjoy the 64-bit-version of your famous Asset-Importer-Lib.
This should help you if you a struggeling with this feature. We just learned that just switching to code
generation for 64bit does not work.
Feel free to report any issues if you observed one.
If you are looking for the latest Asset Importer Lib build: we are using appveyor
( check their web-site https://ci.appveyor.com, its free for OpenSource projects ).
as the Continuous Integration service for windows. If the build was successful it
will create an archive containing the dll’s, all executables and the export
libraries for Windows. At the moment we are supporting the following versions:
– Visual Studio 2015
– Visual Studio 2013
– Visual Studio 2012
I am planning to support the MinGW version as well. Unfortunately first I have to
update one file which is much too long for the MinGW-compiler ( thanks to the
guy’s from the Qt-framework ).