Shapeworks: Optimización de mallas con planos de corte

Creado en 15 feb. 2021  ·  8Comentarios  ·  Fuente: SCIInstitute/ShapeWorks

Cuando optimiza en mallas con planos de corte, la optimización aparentemente se congela después de la inicialización. No se produce ningún error, pero se atasca.

Probar:

  • descomprimir test.zip
  • cd en prueba
  • ejecutar: shapeworks optimize --name correspondence_1024.xml

Tenga en cuenta que si el plano de corte se elimina del xml, la optimización se ejecuta como se esperaba.

bug

Todos 8 comentarios

Excelente informe de error @ jadie1 , pequeño conjunto de datos incluido e instrucciones para reproducir.

@HeavenlyBerserker , como referencia, está atascado aquí:

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

Secundo la calidad de este informe de errores. He analizado el problema. Gracias por comprobar esto, Alan.

La función AdvancedAllParticleSplitting se bloqueará si ninguna de las partículas que van en ninguna dirección por un cierto radio (distancia desde la partícula dividida a la partícula original) satisface las restricciones. Pensé en limitar el número de direcciones intentadas, pero decidí no hacerlo porque, dependiendo de los planos de corte, puede ser que un golpe sea extremadamente raro, por lo que cualquier número constante podría no ser adecuado. Estoy abierto a sugerencias para manejar esto, aunque si el trabajo actual que estoy haciendo funciona, AdvancedAllParticleSplitting no será estrictamente necesario para que podamos discutir estrategias de división de partículas completamente diferentes.

En cuanto a la prueba en sí, esto ocurre debido al posicionamiento de las mallas. Los planos de corte cortan en z = -40.5 a -42.5, pero las mallas se colocan en z = -737.593 a -609.55, -1217.76 a -1114.47 y 1079.93 a 1206.3 (se muestra a continuación). Esto causa dos problemas. Primero, independientemente de hacia dónde apunte la normal (arriba / abajo), habrá al menos un fémur que viole completamente las restricciones. En segundo lugar, el radio de división de las partículas está determinado por una cantidad épsilon, que depende del espaciamiento de la entrada; en este caso, el espaciado está en los 1000, por lo que es probable que cualquier división infrinja las restricciones.
Screenshot from 2021-02-17 13-48-13

Como nota, los fémures que está utilizando ya se han cortado con el método de recorte. No creo que esto se haga en un escenario real. Recuerde cómo eliminé ClipBinaryVolumes y apliquéCropping para femur_cut.py.
Screenshot from 2021-02-17 14-01-22

Asigneme cualquier problema futuro relacionado con el corte de planos (dentro de C ++). No he probado el código del plano de corte con mallas. No hay ninguna razón por la que no debería funcionar, pero sería bueno probarlo en busca de errores. ¡Gracias a todos!

@HeavenlyBerserker , está bien, entonces, en teoría, si las mallas y los planos de corte tuvieran sentido, ¿el error no existiría? Joe necesita optimizar con planos de corte en mallas de fémur sin recortar, estaba tratando de proporcionarle un xml de ejemplo. Así que simplemente hice planos de corte y usé mallas de fémur, pero si soy más cuidadoso, ¿debería funcionar?

Sí, intenté cortar planos que no se violen pero encontré el problema de espaciado, pero funciona. Si puede colocar todos los fémures en la misma área general y ajustar los planos de corte para que sean razonables, no veo ninguna razón por la que esto no debería funcionar, especialmente considerando que solo está usando un plano de corte.

De acuerdo, sí, no se confirmó ningún error cuando usé estos datos: test.zip

Gracias por ayudarme a entender a @HeavenlyBerserker
Cerrando esto ahora

No he probado el código del plano de corte con mallas. No hay ninguna razón por la que no debería funcionar, pero sería bueno probarlo en busca de errores.

Hemos cortado algunas mallas con éxito y hay pruebas unitarias para esto (MeshTests, PythonTests y shapeworksTests).

Asigneme a cualquier problema futuro dentro de C ++.

¡Absolutamente! ¡¡Gracias!!

@HeavenlyBerserker , ¿hay alguna forma de que se pueda detectar esta condición y

Hmm, debería ser posible verificar si al menos uno de los puntos de malla / imagen de cualquier entrada satisface la restricción. No es infalible, pero debería funcionar el 99,9% del tiempo.

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

akenmorris picture akenmorris  ·  32Comentarios

akenmorris picture akenmorris  ·  16Comentarios

akenmorris picture akenmorris  ·  23Comentarios

cchriste picture cchriste  ·  3Comentarios

iyerkrithika21 picture iyerkrithika21  ·  12Comentarios