Assimp Problem oder Layer 8 Problem?

[Top-OR]

Hallo liebe Assimp-ler!

Ich habe mir spontan gedacht, meine Toolchain auf Assimp 3.1.1 upzudaten.

Ich baue eine kleine CLI-Exe, die ein bisschen was mit Assimp macht. Mit der alten Version (3.0) war die Welt auch in Ordnung.

Festhalten, jetzt kommts:

Wie hier (https://github.com/assimp/assimp/issues/302) beschrieben, habe ich das Problem, dass die assimp.lib aus die assimp.exe anstatt die DLL referenziert.
Ich habe nichts gebaut, lediglich das Binarie-Package von Sourceforge runtergeladen.

Ich weine gerade ein bisschen und bin auch schon traurig. Mimimimimi...
Aber - ernst gemeinte Frage: Kann ich da was machen; muss/sollte ich assimp nochmal bauen; oder gibts nen anderen Rat?

Achso: Ich bin unter Windows sowohl mit MSVC2005 als auch MSVC2010 unterwegs - 32bit. Habs aber bisher nur MSVC2005 getestet...

[kimmi]

Also ich denke, die Packages müssen upgedated werden von unserer Seite.

Kimmi

[Top-OR]

Moin Kimmi,

danke für den Hinweis. Ich habe gestern mal versucht, Assimp neu zu bauen, ohne die fertigen Binaries zu benutzen:

CMake habe ich eh in Benutzung, also habe ich mal eine MSVC2005 Solution erzeugt und damit mal den Build angeworfen.
Da ich nicht mit DirectX arbeite, habe ich mir dazu auch fix das DX-SDK runtergeladen. Alles soweit schön.

Nun: Beim bauen von Assimp mit der MSVC Solution, bekomme ich EINEN Compilerfehler in der Datei FBXDocument.h um Zeile 230/231 rum:
Der Fehler sagt, dass das Symbox "max" nicht gefunden wird.

An der entsprechenden Stelle in dem File sehe ich das Makro "fbx_simple_enum_property", welche wiederum andere Macros benutzt, unter anderen (in verschiedenen Verschachtelungstiefen) auch ein so genanntes "max" - was auch immer das ist.

Ich sehe, dass ihr da sone Art Clipping/Clamping macht: "if (X < 0) || (X > max) return default;"
Aufgrund des nicht auflösbaren "max"-Wertes funtioniert das ganze eben leider nicht.
Um es nun zu kompilieren, habe ich bei mir lokal mal dieses ganze clipping auskommentiert und mache nun "immer" "return val".

Das Ende vom Lied ist:

Assimp kompiliert und meine Applikation, die Assimp konsumiert,läuft wie geschmiert - GUT GUT!

Leider habe ich nun eben den FBX-Import "kaputt-optimiert", was mir dann auch praktisch von ganz oben auffällt: Ich kann nun alles mögliche laden, nur bei FBX fällt er scheinbar immer auf die Nase.

Daher nun meine Folgefrage zum ganzen Problem:

Was ist dieses "max" bzw. wo kommt es her und wie kann ich es "her bekommen"?
Ich habe das ganze bis in ein xirgentwas.h-File verfolgen können und habe dort die Macro-Spur verloren.
Wenn ich eine Abhängigkeit nicht habe, gibt es einen einfachen Weg für mich, wie ich "max" selbst definiere?
Ich würde nämlich sehr sehr gerne auch FBXe konvertieren können. :-)


An diese Stelle wollte ich mal noch ein Lob loswerden:

Ich hatte früher auch einige einfache 3D-Formate durch "reverse engineering" und "probieren" selbst lesbar gemacht (OBJ, Quake MD5, BlitzBasic).
Obwohl ich ein großer Freund von "selbst machen" bin, habe ich nicht lange gezögert, um einen Assimp-basierten Model-Konverter für meine Toolchain zu bauen.
Der konvertiert von *."was-weiss-ich-alles" in mein eigenes Model-Format und ich kann mich nun wieder auf das Wesentliche konzentrieren.

Ich kann das nicht von vielen Libraries behaupten, weil ich gerne "selbst stricke". Aber daher, Assimp-People, umso lieber: Danke für Assimp!

[Schrompf]

Wovon genau redest Du? Ich finde in dem Dokument kein "max", in der dazugehörigen .cpp auch nicht. Ich bin auf dem aktuellen Stand von GitHub.

Und nebenbei: es ist keine gute Idee, einen 10 Jahre alten Compiler verwenden zu wollen. C++11 bietet ne Menge schöner neuer Sachen - wechsel mal auf das aktuellste Visual Studio.

[Top-OR]

Wovon genau redest Du? Ich finde in dem Dokument kein "max", in der dazugehörigen .cpp auch nicht. Ich bin auf dem aktuellen Stand von GitHub.

Na davon (FBXDocument.h):

Code: Alles auswählen

#define fbx_simple_enum_property(name, type, default_value) \
type name() const { \
const int ival = PropertyGet<int>(Props(), fbx_stringize(name), static_cast<int>(default_value)); \
if (ival < 0 || ival >= AI_CONCAT(type, _MAX)) { \
ai_assert(static_cast<int>(default_value) >= 0 && static_cast<int>(default_value) < AI_CONCAT(type, _MAX)); \
return static_cast<type>(default_value); \
} \
return static_cast<type>(ival); \
}

Das _MAX z.B. in Zeile 4 hier ist mein Macro, welches vorher irgendwo (weiß gerade nicht genau wo, bin nicht daheim), auf ein anderes Macro "max" auflöst. bzw. meine IDE/Konfiguration versucht es so aufzulösen und scheitert dann...

Und nebenbei: es ist keine gute Idee, einen 10 Jahre alten Compiler verwenden zu wollen. C++11 bietet ne Menge schöner neuer Sachen - wechsel mal auf das aktuellste Visual Studio.

Ich ahne auch, dass hier das Problem verortet sein könnte. :roll:
MSVC2005 nutze ich auf dem einen Rechner (weil ich noch sone wunderbare Studi-Lizenz con "damals" habe *hust*), 2010 Express auf meinem Laptop.

Ich werds mal mit MSVC 2010 versuchen.

Die Migration auf eine neue MSVC-Version und neuen Sprachstandard habe ich bisher etwas gescheut, steht aber relativ weit oben auf meiner Nicht-Funktionalen-ToDo-Liste...

[xq]

Vielleicht ein Grund an dem es liegen könnte: MSVC hat ein Makro "max" welches eben std::max durch den Preprozessor nachbaut. Eventuell hilft ein #undef max wie ich es hier in meinen Projekten ständig drin habe (sonst könnte man keine variable "max" nennen)

[Schrompf]

Ahja. Das _MAX dort wird per Präprozessor-Aktion mit dem Typen zu einem Token verbunden. Alle enums, die da eingesetzt werden, haben als letzten Wert einen Eintrag "Blabla_MAX", der damit angesprochen wird. Die enums sind allerdings im gleichen File darüber definiert, die sind also auf jeden Fall bekannt. Eigentlich bleibt als Erklärung nur noch übrig, dass Visual Studio das Makro falsch auflöst. Das wäre doch reichlich seltsam. Aber nuja... Dein Compiler ist 10 Jahre alt. Eine gewisse Menge Seltsames ist damit unvermeidlich :-)

und @MasterQ: die min/max-Makros in <windows.h> sind ein großer Hass. Die schaltet man die üblicherweise einfach per #define NOMINMAX vor dem Include aus. Hier sind die aber nicht die Quelle des Problems, glaube ich. Zumal der Import/Export-Teil von Assimp ja gar nix mit Windows am Hut hat. Nur der Viewer braucht DirectX.

[Top-OR]

... Das wäre doch reichlich seltsam. Aber nuja... Dein Compiler ist 10 Jahre alt. Eine gewisse Menge Seltsames ist damit unvermeidlich :-)

Ja, das dachte ich auch. Schön gesagt. Gerade im Bereich "Templates + Preprozessor" finden da manchmal "seltsame Dinge" statt. Okay ... ich werde zwei Dinge versuchen:

1) kurze Lösung: Vielleicht bekomme ich das Problem mit den Präprozessor-Makros hingefrickelt
2) mittelfristige Lösung: Migration auf nen neuen Compiler