Review Request 117816: Use marching cubes algorithm from Aqsis

[Aleix Pol Gonzalez]

> On April 28, 2014, 11:15 p.m., Commit Hook wrote:
> > This review has been submitted with commit 6a896c373e0940c09a5efae6ee067bb9f59be7e0 by Percy Camilo Triveño Aucahuasi to branch master.
> 
> Aleix Pol Gonzalez wrote:
>     Oh come on. You're a mathematician, 4 or 6, what difference does it make? ;)
> 
> Percy Camilo Triveño Aucahuasi wrote:
>     hehehe ... :D :D ok If we use 8 as initial cube edge, then some examples (surfaces) in plots3ddemo will not be plotted totally. I guess, this was because our old implementation covered more space at the initial iteration (partition) see:
>     
>     octree.cpp:25 raiz->cubo.setCenter(initial_edge/2,initial_edge/2,initial_edge/2);
>     
>     With 12 as new size the issue is solved and the surfaces are plotted ok. 
>     
>     If you want a more deeply explanation of this topic, then the answer is in the Octree. Since we were using an octree based space partition method, instead Aqsis approach is using a fixed interval to traverse through x,y and z. The reference to create a new space in the octree method was the center of the father/old cube. 
>     
>     octree.cpp:47 father->nodes[i]->cube.setHalfEdge(father->cube.halfEdge()/2);
>     
>     Instead, in Aqsis, the reference to generate a new cube is the previous one, since you just need to jump to the next cube using the interval length. To jump intervals we have this variables, in new version of marchingcubes.cpp:98-99, see: 
>     
>     hx = (xmax-xmin)/i_size_x;
>     hy = (ymax-ymin)/i_size_y;
>     hz = (zmax-zmin)/i_size_z;    
>     
>     In any case, and for sure, I trust more in Aqsis implementation than our old one.
>     
>     If you need more explanation, I can study this to confirm and point out wich of those quotients in octree (that are edge/2) are causing the difference ;)
>     
>     :p

I'm satisfied now, thanks :)


- Aleix


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117816/#review56811
-----------------------------------------------------------


On April 28, 2014, 11:15 p.m., Percy Camilo Triveño Aucahuasi wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117816/
> -----------------------------------------------------------
> 
> (Updated April 28, 2014, 11:15 p.m.)
> 
> 
> Review request for KDE Edu.
> 
> 
> Repository: analitza
> 
> 
> Description
> -------
> 
> Replace our marching cubes algorithm implementation for the one of Aqsis project. The Aqsis implementation is fastest and offers topological guarantees, in other words we'll have better surfaces as result (without missing faces, etc.)
> 
> Finally, we'll have less code to maintain :)
> 
> 
> Diffs
> -----
> 
>   analitzaplot/private/utils/octree.cpp 6106120 
>   analitzaplot/private/utils/octree.h 1cf4b24 
>   analitzaplot/private/utils/marchingcubes.cpp 49331f1 
>   analitzaplot/private/utils/marchingcubes.h ef0b0c4 
>   analitzaplot/private/utils/lookuptable.h PRE-CREATION 
>   analitzaplot/private/backends/implicitsurface.cpp 68c7918 
>   analitzaplot/CMakeLists.txt 9890449 
> 
> Diff: https://git.reviewboard.kde.org/r/117816/diff/
> 
> 
> Testing
> -------
> 
> Builds ok.
> All analitzaplot tests pass.
> Also, there is no licenses issues since the code is GPL >= 2 (same of Analitza)
> 
> 
> Thanks,
> 
> Percy Camilo Triveño Aucahuasi
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20140429/0dbd1d21/attachment.html>