[Octave-bug-tracker] [bug #55642] isosurface is slow

[Michael Leitner]

Follow-up Comment #4, bug #55642 (project octave):

Answers to your comments: 
- yes, then it would be best to apply my patch just to
__unite_shared_vertices__.m (and compute J according to its previous
definition), because it indeed is the vectorization Markus asked for in the
FIXME. Thus the speed improvement would apply also to reducepatch.
- I was initially thinking that marching_cubes works sequentially, thus that
every cube can affect every other one. Then the eps of the largest vertex
overall would indeed apply. But yes, seemingly it works in parallel, so only
the largest vertex in the cube defines the achievable precision. So yes, it
would become a vector, but I think the previous choice was too optimistic
(when one vertex results very close to zero, its position is still affected by
the finite precision of the other vertices of the cube it resulted from). But
there is no one true solution --- you will always either keep returning
vertices as distinct that with perfect arithmetic would be just one, or you
will merge vertices that actually should be separated. So I would say, it is
good enough.
- You want to drop all faces that have at least two equal vertices. And if
neither f(1)==f(2) nor f(2)==f(3) nor f(3)==f(1), then necessarily all three
are distinct. If you knew that the faces were sorted, then you would need only
two comparisons (as in the last lines of __unite_shared_vertices__.m). 

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?55642>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/