Shapeworks: Optimierung auf Maschen mit Schnittebenen

Ausgezeichneter Fehlerbericht @ jadie1 , kleiner Datensatz enthalten und Anweisungen zur Reproduktion.

@HeavenlyBerserker , als Referenz, es steckt hier fest:

Call graph:
    5 Thread_5215217   DispatchQueue_1: com.apple.main-thread  (serial)
    + 5 start  (in libdyld.dylib) + 1  [0x7fff69ef2cc9]
    +   5 main  (in shapeworks) + 2606  [0x102bfb9fe]  shapeworks.cpp:88
    +     5 shapeworks::Executable::run(int, char const* const*)  (in shapeworks) + 188  [0x102c0ad7c]  Executable.cpp:128
    +       5 shapeworks::Executable::run(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >, shapeworks::SharedCommandData&)  (in shapeworks) + 308  [0x102c0a6f4]  Executable.cpp:94
    +         5 shapeworks::Command::run(shapeworks::SharedCommandData&)  (in shapeworks) + 20  [0x102c14e64]  Command.cpp:27
    +           5 shapeworks::OptimizeCommand::execute(optparse::Values const&, shapeworks::SharedCommandData&)  (in shapeworks) + 921  [0x102c16889]  Commands.cpp:92
    +             5 shapeworks::Optimize::Run()  (in shapeworks) + 1938  [0x102ea5d52]  Optimize.cpp:120
    +               5 shapeworks::Optimize::Initialize()  (in shapeworks) + 1770  [0x102ea7d3a]  Optimize.cpp:733
    +                 1 itk::ParticleSystem<3u>::AdvancedAllParticleSplitting(double)  (in shapeworks) + 2133  [0x102eb46f5]  itkParticleSystem.txx:330
    +                 1 itk::ParticleSystem<3u>::AdvancedAllParticleSplitting(double)  (in shapeworks) + 2542  [0x102eb488e]  itkParticleSystem.txx:344
    +                 ! 1 itk::Constraints::IsAnyViolated(itk::Point<double, 3u> const&)  (in shapeworks) + 71  [0x102ecce67]  Constraints.h:61
    +                 1 itk::ParticleSystem<3u>::AdvancedAllParticleSplitting(double)  (in shapeworks) + 2530  [0x102eb4882]  itkParticleSystem.txx:344
    +                 1 itk::ParticleSystem<3u>::AdvancedAllParticleSplitting(double)  (in shapeworks) + 3010  [0x102eb4a62]  itkParticleSystem.txx:349
    +                 1 itk::ParticleSystem<3u>::AdvancedAllParticleSplitting(double)  (in shapeworks) + 1655  [0x102eb4517]  vector:0

Ich unterstütze die Qualität dieses Fehlerberichts. Ich habe mir das Problem angesehen. Danke, dass du das überprüft hast, Alan.

Die AdvancedAllParticleSplitting-Funktion bleibt hängen, wenn keines der Partikel, die in eine Richtung mit einem bestimmten Radius (Abstand vom geteilten Partikel zum ursprünglichen Partikel) gehen, die Einschränkungen erfüllt. Ich dachte darüber nach, die Anzahl der versuchten Richtungen zu begrenzen, entschied mich aber dagegen, da es abhängig von den Schnittebenen sein kann, dass ein Treffer äußerst selten ist, sodass eine konstante Anzahl möglicherweise ungeeignet ist. Ich bin offen für Vorschläge, um damit umzugehen. Wenn die aktuelle Arbeit, die ich mache, ausfällt, ist AdvancedAllParticleSplitting nicht unbedingt erforderlich, sodass wir völlig unterschiedliche Strategien zur Partikelaufteilung diskutieren können.

Der Test selbst geschieht aufgrund der Positionierung der Maschen. Die Schnittebenen schneiden bei z = -40,5 bis -42,5, aber die Maschen sind bei z = -737,593 bis -609,55, -1217,76 bis -1114,47 und 1079,93 bis 1206,3 (siehe unten) positioniert. Dies verursacht zwei Probleme. Erstens gibt es unabhängig davon, in welche Richtung die Normalen zeigen (nach oben / unten), mindestens einen Femur, der die Einschränkungen vollständig verletzt. Zweitens wird der Teilchenspaltungsradius durch eine Größe epsilon bestimmt, die vom Abstand der Eingabe abhängt; In diesem Fall liegt der Abstand in den 1000ern, sodass jede Aufteilung wahrscheinlich die Einschränkungen verletzt.

Hinweis: Die von Ihnen verwendete Femora wurde bereits mit der Clipping-Methode geschnitten. Ich denke nicht, dass dies in einem realen Szenario geschehen würde. Erinnern Sie sich daran, wie ich ClipBinaryVolumes und applyCropping für femur_cut.py entfernt habe.

Bitte weisen Sie mich zukünftigen Problemen im Zusammenhang mit Schnittebenen zu (innerhalb von C ++). Ich habe den Code der Schnittebene nicht mit Maschen getestet. Es gibt keinen Grund, warum es nicht funktionieren sollte, aber es wäre gut, es auf Fehler zu testen. Danke euch allen!

@HeavenlyBerserker oh okay, theoretisch würde der Fehler nicht existieren, wenn die Maschen und Schnittebenen sinnvoll wären? Joe muss mit Schnittebenen auf nicht abgeschnittenen Femurnetzen optimieren. Ich habe versucht, ihm ein Beispiel-XML zur Verfügung zu stellen. Also habe ich mir nur Schnittebenen ausgedacht und Femurnetze verwendet, aber wenn ich vorsichtiger bin, sollte es funktionieren?

Ja, ich habe versucht, Flugzeuge zu schneiden, die nicht verletzt werden, aber auf das Abstandsproblem gestoßen sind, aber es funktioniert. Wenn Sie alle Femoren in den gleichen allgemeinen Bereich bringen und die Schnittebenen so einstellen können, dass sie angemessen sind, sehe ich keinen Grund, warum dies nicht funktionieren sollte, insbesondere wenn Sie nur eine Schnittebene verwenden.

Okay, ja, ich habe keinen Fehler bestätigt, als ich diese Daten verwendet habe: test.zip

Vielen Dank, dass Sie mir geholfen haben, @HeavenlyBerserker zu verstehen
Schließen Sie dies jetzt

Ich habe den Code der Schnittebene nicht mit Maschen getestet. Es gibt keinen Grund, warum es nicht funktionieren sollte, aber es wäre gut, es auf Fehler zu testen.

Wir haben einige Netze erfolgreich zerlegt und es gibt Unit-Tests dafür (MeshTests, PythonTests und ShapeworksTests).

Bitte weisen Sie mich zukünftigen Problemen in C ++ zu.

Absolut! Vielen Dank!!

@HeavenlyBerserker , gibt es eine Möglichkeit, diesen Zustand zu erkennen und eine Ausnahme oder eine Fehlermeldung auszulösen? Ich würde das wirklich dem Hängen oder Abstürzen vorziehen. Gibt es auch eine Möglichkeit, die wir vor dem Ausführen überprüfen können? Siehe # 910.

Hmm, es sollte möglich sein zu überprüfen, ob mindestens einer der Netz- / Bildpunkte einer Eingabe die Bedingung erfüllt. Nicht narrensicher, sollte aber in 99,9% der Fälle funktionieren.