Shapeworks: Optimisation sur les maillages avec des plans de coupe

Créé le 15 févr. 2021  ·  8Commentaires  ·  Source: SCIInstitute/ShapeWorks

Lorsque vous optimisez des maillages avec des plans de coupe, l'optimisation se fige apparemment après l'initialisation. Aucune erreur n'est générée mais elle reste bloquée.

Tester:

  • décompressez test.zip
  • cd en test
  • exécuter: shapeworks optimize --name correspondence_1024.xml

Notez que si le plan de coupe est supprimé du xml, l'optimisation s'exécute comme prévu.

bug

Tous les 8 commentaires

Excellent rapport de bogue @ jadie1 , petit jeu de données inclus et instructions à reproduire.

@HeavenlyBerserker , pour référence, c'est coincé ici:

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

J'appuie la qualité de ce rapport de bogue. J'ai regardé le problème. Merci de vérifier cela, Alan.

La fonction AdvancedAllParticleSplitting se bloquera si aucune des particules allant dans une direction quelconque d'un certain rayon (distance entre la particule scindée et la particule d'origine) ne satisfait les contraintes. J'ai pensé à limiter le nombre de directions tentées, mais j'ai décidé de ne pas le faire car selon les plans de coupe, il se peut qu'un coup soit extrêmement rare, donc tout nombre constant peut être mal adapté. Je suis ouvert aux suggestions pour gérer cela, bien que si le travail actuel que je fais tourne, AdvancedAllParticleSplitting ne sera pas strictement nécessaire afin que nous puissions discuter de stratégies de division de particules complètement différentes.

Quant au test lui-même, cela se produit à cause du positionnement des mailles. Les plans de coupe coupent à z = -40,5 à -42,5, mais les mailles sont positionnées à z = -737,593 à -609,55, -1217,76 à -1114,47 et 1079,93 à 1206,3 (illustré ci-dessous). Cela pose deux problèmes. Tout d'abord, quelle que soit la direction de la normale (haut / bas), il y aura au moins un fémur qui viole complètement les contraintes. Deuxièmement, le rayon de division des particules est déterminé par une quantité epsilon, dépendant de l'espacement de l'entrée; dans ce cas, l'espacement est de l'ordre de 1000, ce qui rend toute scission susceptible de violer les contraintes.
Screenshot from 2021-02-17 13-48-13

À noter, les fémurs que vous utilisez ont déjà été coupés en utilisant la méthode de découpage. Je ne pense pas que cela se ferait dans un scénario réel. Rappelez-vous comment j'ai supprimé ClipBinaryVolumes et applyCropping pour femur_cut.py.
Screenshot from 2021-02-17 14-01-22

Veuillez m'attribuer à tout problème futur concernant les plans de coupe (dans C ++). Je n'ai pas testé le code du plan de coupe avec des maillages. Il n'y a aucune raison pour laquelle cela ne devrait pas fonctionner, mais ce serait bien de le tester pour les bogues. Merci à tous!

@HeavenlyBerserker oh d'accord, donc en théorie, si les maillages et les plans de coupe avaient un sens, le bogue n'existerait pas? Joe a besoin d'optimiser avec des plans de coupe sur des mailles de fémur non clipsées, j'essayais de lui fournir un exemple xml. Donc, j'ai juste inventé des plans de coupe et utilisé des mailles de fémur, mais si je fais plus attention à ce sujet, cela devrait fonctionner?

Oui, j'ai essayé des plans de coupe qui ne sont pas violés mais qui ont rencontré un problème d'espacement, mais cela fonctionne. Si vous pouvez placer toutes les fémurs dans la même zone générale et ajuster les plans de coupe pour qu'ils soient raisonnables, je ne vois aucune raison pour laquelle cela ne devrait pas fonctionner, d'autant plus que vous n'utilisez qu'un seul plan de coupe.

Ok ouais confirmé aucun bug lorsque j'ai utilisé ces données: test.zip

Merci de m'aider à comprendre @HeavenlyBerserker
Fermer ça maintenant

Je n'ai pas testé le code du plan de coupe avec des maillages. Il n'y a aucune raison pour laquelle cela ne devrait pas fonctionner, mais ce serait bien de le tester pour les bogues.

Nous avons découpé certains maillages avec succès et il existe des tests unitaires pour cela (MeshTests, PythonTests et shapeworksTests).

Veuillez m'attribuer à tout problème futur dans C ++.

Absolument! Merci!!

@HeavenlyBerserker , existe-t-il un moyen de détecter cette condition et de

Hmm, il devrait être possible de vérifier si au moins un des points de maillage / image de n'importe quelle entrée satisfait la contrainte. Pas infaillible, mais devrait fonctionner 99,9% du temps.

Cette page vous a été utile?
0 / 5 - 0 notes