[Assimp] Visual C++-Projektkonfiguration

[Krishty]

Kurze Fragen zu Assimp:

1. In der Visual C++-Konfiguration ist Whole Program Optimization deaktiviert. Ist das beim Hochkonvertieren versehentlich passiert oder hat es Gründe? Ich erinnere mich, dass einige Post-Processing-Schritte damals 4× schneller wurden, wenn es an war …
2. Es gibt keine dll-noboost-Konfiguration (nur noboost-st). Da ebenfalls: Beabsichtigt? Falls ja, warum?
3. code/MD4FileData.h wird bei mir nicht benutzt – in Arbeit?
4. code/OgreXMLHelper.h wurde offensichtlich zu .hpp umbenannt, wird aber noch von der Projektdatei als .h referenziert, oder?

Gruß

[Schrompf]

CMake kann wohl kein LTCG. Einer der vielen Gründe, warum ich das gemieden habe. Scheiß auf die Build Configs, bau Dir was. MD4... keine Ahnung. OgreXmlHelper... sollte gepflegt sein. Woher checkst Du aus?

[Krishty]

CMake kann wohl kein LTCG. Einer der vielen Gründe, warum ich das gemieden habe. Scheiß auf die Build Configs, bau Dir was.

Danke sehr; auf diese Freigabe hatte ich gewartet :-)

MD4... keine Ahnung. OgreXmlHelper... sollte gepflegt sein. Woher checkst Du aus?

SourceForge-Download von vor zwei oder drei Wochen.

[kimmi]

LTCG-support fehlt in der CMake-Umgebung: https://github.com/assimp/assimp/issues/247 .
Schau mal lieber im Github-Repo nach, das ist aktueller. Wenn mich der aktuelle Krankenstand meiner Tochter mal was machen lässt, haben wir hald eine Version Asst Importer Lib 3.1 :).

Gruß Kimmi

[Krishty]

Welche Header muss ich #includen, damit ich NUR eure C-Datenstrukturdeklarationen erhalte, und keine STL-#includes?

  #include "assimp/postprocess.h"
  #include "assimp/Importer.hpp"
  #include "assimp/scene.h"
  #include "assimp/mesh.h"
  #include "assimp/cimport.h"

resultiert in den nutzlosen Laufzeitinitialisierungen

  utility (65): std::`dynamic initializer for 'piecewise_construct''
  xutility (3644): std::`dynamic initializer for 'allocator_arg''
  xmemory0 (627): `dynamic initializer for 'std::_Error_objects<int>::_Generic_object''
  xmemory0 (627): `dynamic initializer for 'std::_Error_objects<int>::_Iostream_object''
  xmemory0 (627): `dynamic initializer for 'std::_Error_objects<int>::_System_object''
  xlocnum (155): `dynamic initializer for 'std::num_put<char,std::back_insert_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >::id''
  xlocnum (155): `dynamic initializer for 'std::num_put<wchar_t,std::back_insert_iterator<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >::id''

… und die will ich nicht in meinem Programm haben weil ich sie garnicht benutze.

(Könnte ja sein, dass ich hier die falschen Header einbinde. Ich will bloß eure C-Schnittstelle!)

[kimmi]

IMporter.hpp ist definitiv c++. cimport sollte da reichen. Versuch dein Glück :).

Gruß Kimmi

[Schrompf]

Evtl. kriegst Du über aiString.h den Kram rein, weil der Konvertierungen von und nach std::string anbietet.

[Krishty]

IMporter.hpp ist definitiv c++. cimport sollte da reichen. Versuch dein Glück :).

Stimmt; wie blöd von mir. Ich hatte die Import-Flags schnell reingehackt.

Evtl. kriegst Du über aiString.h den Kram rein, weil der Konvertierungen von und nach std::string anbietet.

Sieht eher so aus als ob jeder der Header <types.h> einbindet und falls __cplusplus definiert ist, werden <new> und <string> mit reingesaugt, und damit die ganze STL. #undef __cplusplus bringt nichts :(

[kimmi]

Wir könnten die aiString Konvertierungen in einen separaten Header parken, der nur bei Bedarf sprich #ifdef __cplusplus inkludiert wird.

Gruß Kimmi

[Krishty]

#ifdef __cplusplus ist jetzt auch schon drum. Ich weiß ehrlich gesagt nicht wie ich Visual C++ verklickern soll, den Header zu behandeln, als wäre er pures C :( Vielleicht muss ich mir eine C-Datei schreiben, die eute C-Header einbindet, und deren Funktionen ich von meinem C++-Quelltext aus aufrufe.

[kimmi]

Man kann zumindest für C-Files explizit angeben, dass sie als C-Code kompiliert werden sollen. Das würde alle Header ja mit einbeziehen.

Gruß Kim

[Schrompf]

Wenn Dir das so wichtig ist, dann ändere den Code doch. Ist doch alles unter einer "echten" OpenSource-Lizenz und selbst wenn nicht - privat ändern und fertig, kümmert doch keinen.

[Krishty]

Ich will mich nicht in ein paar Monaten, wenn (Version 3.1 steht und) ich meine Dateien aktualisiere, wieder um dieses Problem kümmern müssen – darum kommt Ändern des Assimp-Quelltexts nicht in Frage.

Ich sinniere weiter über eine Lösung meinerseits, und halte euch auf dem Laufenden. Vielleicht hilft sie ja irgendwann jemandem.

[kimmi]

Wir wären hocherfreut, wenn du dich da mit einbringen würdest ;).

Gruß Kimmi