Shapeworks: Otimização em malhas com planos de corte

Excelente relatório de bug @ jadie1 , pequeno conjunto de dados incluído e instruções para reproduzir.

@HeavenlyBerserker , para referência, está preso aqui:

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

Eu concordo com a qualidade deste relatório de bug. Eu olhei para o problema. Obrigado por verificar isso, Alan.

A função AdvancedAllParticleSplitting irá travar se nenhuma das partículas indo em qualquer direção por um certo raio (distância da partícula dividida à partícula original) satisfizer as restrições. Pensei em limitar o número de direções tentadas, mas decidi contra isso porque dependendo dos planos de corte, pode ser que um acerto seja extremamente raro, então qualquer número constante pode ser inadequado. Estou aberto a sugestões para lidar com isso, embora se o trabalho atual que estou fazendo der certo, AdvancedAllParticleSplitting não será estritamente necessário para que possamos discutir estratégias de divisão de partículas completamente diferentes.

Quanto ao teste em si, isso está acontecendo por causa do posicionamento das malhas. Os planos de corte cortam em z = -40,5 a -42,5, mas as malhas são posicionadas em z = -737,593 a -609,55, -1217,76 a -1114,47 e 1079,93 a 1206,3 (mostrado abaixo). Isso causa dois problemas. Primeiro, independentemente da direção que o normal está apontando (para cima / para baixo), haverá pelo menos um fêmur que viola completamente as restrições. Em segundo lugar, o raio de divisão da partícula é determinado por uma quantidade epsilon, dependente do espaçamento da entrada; neste caso, o espaçamento está na casa dos 1000, tornando qualquer divisão susceptível de violar as restrições.

Como observação, os fêmures que você está usando já foram cortados com o método de recorte. Não acho que isso seria feito em um cenário real. Lembre-se de como removi ClipBinaryVolumes e applyCropping para femur_cut.py.

Por favor, designe-me para quaisquer questões futuras relacionadas a planos de corte (em C ++). Não testei o código do avião de corte com malhas. Não há nenhuma razão para que não funcione, mas seria bom testá-lo em busca de bugs. Obrigado, pessoal!

@HeavenlyBerserker oh ok, então, em teoria, se as malhas e os planos de corte fizessem sentido, o bug não existiria? Joe precisa otimizar com planos de corte em malhas de fêmur não cortadas, eu estava tentando fornecer a ele um exemplo de xml. Então, acabei de inventar planos de corte e usar telas de fêmur, mas se eu for mais cuidadoso com isso, deve funcionar?

Sim, tentei cortar planos que não são violados, mas tive o problema de espaçamento, mas funcionou. Se você puder colocar todos os fêmures na mesma área geral e ajustar os planos de corte para serem razoáveis, não vejo razão para que isso não funcione, especialmente considerando que você está usando apenas um plano de corte.

Ok, sim, não confirmei nenhum bug quando usei estes dados: test.zip

Obrigado por me ajudar a entender @HeavenlyBerserker
Fechando isso agora

Não testei o código do avião de corte com malhas. Não há nenhuma razão para que não funcione, mas seria bom testá-lo em busca de bugs.

Cortamos algumas malhas com sucesso e existem testes de unidade para isso (MeshTests, PythonTests e shapeworksTests).

Por favor, atribua-me a quaisquer questões futuras em C ++.

Absolutamente! Obrigada!!

@HeavenlyBerserker , há alguma maneira dessa condição ser detectada e uma exceção levantada ou mensagem de erro? Eu realmente preferiria isso a travar ou quebrar. Além disso, há uma maneira de verificarmos antes de executar? Veja # 910.

Hmm, deve ser possível verificar se pelo menos um dos pontos da malha / imagem de qualquer entrada satisfaz a restrição. Não é infalível, mas deve funcionar 99,9% do tempo.