search

gj210 / autoPACK

16 stars 12 forks source link

Merge latest autoPACK as of 2/25/2015 #17

Closed wukevin closed 9 years ago

corredD commented 9 years ago

hey,

I actually integrated your code with the HIV packing and the general packing code. I was surprise as the performance is not as good as the jordan, but is more reliable. I am sure we can find way to improve the performance of your approach.

L

De : wukevin [notifications@github.com] Date d'envoi : mercredi 25 f�vrier 2015 17:10 � : gj210/autoPACK Objet : Re: [autoPACK] Merge latest autoPACK as of 2/25/2015 (#17)

Closed #17https://github.com/gj210/autoPACK/pull/17.

� Reply to this email directly or view it on GitHubhttps://github.com/gj210/autoPACK/pull/17#event-242187930.

gj210 commented 9 years ago

Hi Ludo, Can you push your version? Kevin implemented it into cellPACK as well and when testing on HIV 1.6, it seems that "kevin" takes about 3-4x longer than Jordan3. We plan to look for bottlenecks next week, but if you see any, let us know... I suspect the marching cube is doing many redundant calculations. Here are some other early observations that may be helpful: Jordon is extremely slow in the build tab [gridify] button.... much slower than it is with the same HIV envelope surface than it is in cellPACK. (we pasted HIV envelop Pack surface into a new file and ran kevin (takes about 40sec) and Jordan3Raycast (takes about 20 minutes). Jordan 3 on that same surface in cellPACK takes well under 10sec. Kevin seems to be faster when the grid is finer, so Jordon 3 gets much slower as the grid density increases and eventually becomes slower than Kevin. Kevin seems to get much slower if there are a lot of vertices to test (again, probably some redundant calculations from the marching cube). Kevins initial tests indicate that kevin is leakproof, but I haven't tested it exhaustively yet, so yes, it will be good to have a more robust algorithm when needed, but even better if we can speed it up significantly. G

On Feb 25, 2015, at 6:23 PM, ludo notifications@github.com wrote:

hey,

I actually integrated your code with the HIV packing and the general packing code. I was surprise as the performance is not as good as the jordan, but is more reliable. I am sure we can find way to improve the performance of your approach.

L

De : wukevin [notifications@github.com] Date d'envoi : mercredi 25 f�vrier 2015 17:10 � : gj210/autoPACK Objet : Re: [autoPACK] Merge latest autoPACK as of 2/25/2015 (#17)

Closed #17https://github.com/gj210/autoPACK/pull/17.

� Reply to this email directly or view it on GitHubhttps://github.com/gj210/autoPACK/pull/17#event-242187930.

— Reply to this email directly or view it on GitHub.

corredD commented 9 years ago

Hey Graham,

yes I agree with your test, I have to check out whats wrong, also in gridify the jordan wasnt properly working... the bottleneck in kevin appraoachs are :

L

De : Graham [notifications@github.com] Date d'envoi : mercredi 25 février 2015 19:50 À : gj210/autoPACK Cc : Ludovic Autin Objet : Re: [autoPACK] Merge latest autoPACK as of 2/25/2015 (#17)

Hi Ludo, Can you push your version? Kevin implemented it into cellPACK as well and when testing on HIV 1.6, it seems that "kevin" takes about 3-4x longer than Jordan3. We plan to look for bottlenecks next week, but if you see any, let us know... I suspect the marching cube is doing many redundant calculations. Here are some other early observations that may be helpful: Jordon is extremely slow in the build tab [gridify] button.... much slower than it is with the same HIV envelope surface than it is in cellPACK. (we pasted HIV envelop Pack surface into a new file and ran kevin (takes about 40sec) and Jordan3Raycast (takes about 20 minutes). Jordan 3 on that same surface in cellPACK takes well under 10sec. Kevin seems to be faster when the grid is finer, so Jordon 3 gets much slower as the grid density increases and eventually becomes slower than Kevin. Kevin seems to get much slower if there are a lot of vertices to test (again, probably some redundant calculations from the marching cube). Kevins initial tests indicate that kevin is leakproof, but I haven't tested it exhaustively yet, so yes, it will be good to have a more robust algorithm when needed, but even better if we can speed it up significantly. G

On Feb 25, 2015, at 6:23 PM, ludo notifications@github.com wrote:

hey,

I actually integrated your code with the HIV packing and the general packing code. I was surprise as the performance is not as good as the jordan, but is more reliable. I am sure we can find way to improve the performance of your approach.

L

De : wukevin [notifications@github.com] Date d'envoi : mercredi 25 f�vrier 2015 17:10 � : gj210/autoPACK Objet : Re: [autoPACK] Merge latest autoPACK as of 2/25/2015 (#17)

Closed #17https://github.com/gj210/autoPACK/pull/17.

� Reply to this email directly or view it on GitHubhttps://github.com/gj210/autoPACK/pull/17#event-242187930.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/gj210/autoPACK/pull/17#issuecomment-76117918.

NOTE: This message was trained as non-spam. If this is wrong, please correct the training as soon as possible.

gj210 commented 9 years ago

Hi Ludo, We should break Kevin's code into modules to allow you to handle a Random list of points, but right now, its big potential speed improvement should be from the flood fill, which requires a very predictable grid, i.e., it finds where the transitions are from outside to inside or inside to outside, flags them, and then fills in everything in between. If I remember, an issue with that approach is that it may require full and water-tight surfaces... can't recall if my pseudocode made a plan to handle that or if Kevin addressed in his implementation. His code currently splits triangles with edges longer than the gridspacing by 3_gridSpacing (a number he just found heruistically), but I think we will be leakproof if it instead we do expectedRoundingErrorLimit_gridspacing which would create a much coarser surface and less calculations. I think he currently hardcodes the thickness of the "shell" to one layer of points away from the surface, but this will need to be set as a shell thickness that covers the packing radius of the largest packing ingredient.... A shell thicker than 1 may cause huge slowdowns and this is where I think the marching cube would be doing redundant calculations to ensure that the corners are covered, so it might be good to find a speed improvement before pushing it down to some faster compiled code. G

On Feb 26, 2015, at 10:10 AM, ludo notifications@github.com wrote:

Hey Graham,

yes I agree with your test, I have to check out whats wrong, also in gridify the jordan wasnt properly working... the bottleneck in kevin appraoachs are :

  • the prepass where the code create a finer grid / interpolation to avoid leak
  • the raycast line triangle intersection which is pure python. Using native raycasting may improve the performance, I am going ti push my change and look into it further... To do will be to decompose the code to extract the flood fill, also I was wondering if kevin approach will work on any set of point. Namely, if I create a random list of points, can I use his approach to determine if they are inside/outside ?

L

De : Graham [notifications@github.com] Date d'envoi : mercredi 25 février 2015 19:50 À : gj210/autoPACK Cc : Ludovic Autin Objet : Re: [autoPACK] Merge latest autoPACK as of 2/25/2015 (#17)

Hi Ludo, Can you push your version? Kevin implemented it into cellPACK as well and when testing on HIV 1.6, it seems that "kevin" takes about 3-4x longer than Jordan3. We plan to look for bottlenecks next week, but if you see any, let us know... I suspect the marching cube is doing many redundant calculations. Here are some other early observations that may be helpful: Jordon is extremely slow in the build tab [gridify] button.... much slower than it is with the same HIV envelope surface than it is in cellPACK. (we pasted HIV envelop Pack surface into a new file and ran kevin (takes about 40sec) and Jordan3Raycast (takes about 20 minutes). Jordan 3 on that same surface in cellPACK takes well under 10sec. Kevin seems to be faster when the grid is finer, so Jordon 3 gets much slower as the grid density increases and eventually becomes slower than Kevin. Kevin seems to get much slower if there are a lot of vertices to test (again, probably some redundant calculations from the marching cube). Kevins initial tests indicate that kevin is leakproof, but I haven't tested it exhaustively yet, so yes, it will be good to have a more robust algorithm when needed, but even better if we can speed it up significantly. G

On Feb 25, 2015, at 6:23 PM, ludo notifications@github.com wrote:

hey,

I actually integrated your code with the HIV packing and the general packing code. I was surprise as the performance is not as good as the jordan, but is more reliable. I am sure we can find way to improve the performance of your approach.

L

De : wukevin [notifications@github.com] Date d'envoi : mercredi 25 f�vrier 2015 17:10 � : gj210/autoPACK Objet : Re: [autoPACK] Merge latest autoPACK as of 2/25/2015 (#17)

Closed #17https://github.com/gj210/autoPACK/pull/17.

� Reply to this email directly or view it on GitHubhttps://github.com/gj210/autoPACK/pull/17#event-242187930.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/gj210/autoPACK/pull/17#issuecomment-76117918.

NOTE: This message was trained as non-spam. If this is wrong, please correct the training as soon as possible. — Reply to this email directly or view it on GitHub.

corredD commented 9 years ago

one difference between gridify and packing is the lookup and the grid class used. Maybe thats one issue...the gridify use the Environement.py Grid class while the packing use the Grid.py Grid class.

L

De : Graham [notifications@github.com] Date d'envoi : jeudi 26 février 2015 11:21 À : gj210/autoPACK Cc : Ludovic Autin Objet : Re: [autoPACK] Merge latest autoPACK as of 2/25/2015 (#17)

Hi Ludo, We should break Kevin's code into modules to allow you to handle a Random list of points, but right now, its big potential speed improvement should be from the flood fill, which requires a very predictable grid, i.e., it finds where the transitions are from outside to inside or inside to outside, flags them, and then fills in everything in between. If I remember, an issue with that approach is that it may require full and water-tight surfaces... can't recall if my pseudocode made a plan to handle that or if Kevin addressed in his implementation. His code currently splits triangles with edges longer than the gridspacing by 3_gridSpacing (a number he just found heruistically), but I think we will be leakproof if it instead we do expectedRoundingErrorLimit_gridspacing which would create a much coarser surface and less calculations. I think he currently hardcodes the thickness of the "shell" to one layer of points away from the surface, but this will need to be set as a shell thickness that covers the packing radius of the largest packing ingredient.... A shell thicker than 1 may cause huge slowdowns and this is where I think the marching cube would be doing redundant calculations to ensure that the corners are covered, so it might be good to find a speed improvement before pushing it down to some faster compiled code. G

On Feb 26, 2015, at 10:10 AM, ludo notifications@github.com wrote:

Hey Graham,

yes I agree with your test, I have to check out whats wrong, also in gridify the jordan wasnt properly working... the bottleneck in kevin appraoachs are :

  • the prepass where the code create a finer grid / interpolation to avoid leak
  • the raycast line triangle intersection which is pure python. Using native raycasting may improve the performance, I am going ti push my change and look into it further... To do will be to decompose the code to extract the flood fill, also I was wondering if kevin approach will work on any set of point. Namely, if I create a random list of points, can I use his approach to determine if they are inside/outside ?

L

De : Graham [notifications@github.com] Date d'envoi : mercredi 25 février 2015 19:50 À : gj210/autoPACK Cc : Ludovic Autin Objet : Re: [autoPACK] Merge latest autoPACK as of 2/25/2015 (#17)

Hi Ludo, Can you push your version? Kevin implemented it into cellPACK as well and when testing on HIV 1.6, it seems that "kevin" takes about 3-4x longer than Jordan3. We plan to look for bottlenecks next week, but if you see any, let us know... I suspect the marching cube is doing many redundant calculations. Here are some other early observations that may be helpful: Jordon is extremely slow in the build tab [gridify] button.... much slower than it is with the same HIV envelope surface than it is in cellPACK. (we pasted HIV envelop Pack surface into a new file and ran kevin (takes about 40sec) and Jordan3Raycast (takes about 20 minutes). Jordan 3 on that same surface in cellPACK takes well under 10sec. Kevin seems to be faster when the grid is finer, so Jordon 3 gets much slower as the grid density increases and eventually becomes slower than Kevin. Kevin seems to get much slower if there are a lot of vertices to test (again, probably some redundant calculations from the marching cube). Kevins initial tests indicate that kevin is leakproof, but I haven't tested it exhaustively yet, so yes, it will be good to have a more robust algorithm when needed, but even better if we can speed it up significantly. G

On Feb 25, 2015, at 6:23 PM, ludo notifications@github.com wrote:

hey,

I actually integrated your code with the HIV packing and the general packing code. I was surprise as the performance is not as good as the jordan, but is more reliable. I am sure we can find way to improve the performance of your approach.

L

De : wukevin [notifications@github.com] Date d'envoi : mercredi 25 f�vrier 2015 17:10 � : gj210/autoPACK Objet : Re: [autoPACK] Merge latest autoPACK as of 2/25/2015 (#17)

Closed #17https://github.com/gj210/autoPACK/pull/17.

� Reply to this email directly or view it on GitHubhttps://github.com/gj210/autoPACK/pull/17#event-242187930.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/gj210/autoPACK/pull/17#issuecomment-76117918.

NOTE: This message was trained as non-spam. If this is wrong, please correct the training as soon as possible. — Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/gj210/autoPACK/pull/17#issuecomment-76248032.

NOTE: This message was trained as non-spam. If this is wrong, please correct the training as soon as possible.