Code Monkey home page Code Monkey logo

normals_hough's People

Contributors

aboulch avatar asmaloney avatar hroncok avatar nirzarrabi avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

normals_hough's Issues

Python wrapper does not compile under Windows out of the box

The Python wrapper does not compile under Windows. In this fork I added some quick and dirty fixes you could maybe use.

The issues I encountered:

  • setup.py does not include the numpy's include directory.
  • The compile flags specified in setup.py only apply to GCC, not to MSVC.
  • MSVC's math.h does not define M_PI unless _USE_MATH_DEFINES is defined.
  • The typedef kd_tree uses the matrix type Eigen::MatrixX3d. This results in the KDTreeEigenMatrixAdaptor's IndexType to be __int64 under MSVC. In MSVC, long int cannot be converted to __int64 and resulted in type errors at places where knnSearch() and list_of_triplets() were called. I solved this by introducing a typedef pointIdxType which is __int64 when using MSVC and long int otherwise.

Infinite loop in `list_of_triplets`

Below is the source of list_of_triplets from normals.h:

	/*!
	 * generates a list of triplets
	 * @param triplets : table of 3-vector to fill with the indexes of the points
	 * @param number_of_points : number of points to consider
	 * @param triple_number : number of triplets to generate
	 * @param vecRandInt : table of random int
	 */
	inline void list_of_triplets(Eigen::MatrixX3i &triplets,
			const int &number_of_points,
			const unsigned int &triplet_number,
			std::vector<int> &vecRandInt){

		unsigned int S = vecRandInt.size();
		triplets.resize(triplet_number,3);
		unsigned int pos=vecRandInt[0]%S;
		for(unsigned int i=0; i<triplet_number; i++){
			do{
				triplets(i,0) = vecRandInt[pos%S]%number_of_points;
				triplets(i,1) = vecRandInt[(pos+vecRandInt[(pos+1)%S])%S]%number_of_points;
				triplets(i,2) = vecRandInt[(pos+vecRandInt[(pos+1+vecRandInt[(pos+2)%S])%S])%S]%number_of_points;
				pos+=vecRandInt[(pos+3)%S]%S;
			}while(triplets(i,0)==triplets(i,1) || triplets(i,1)==triplets(i,2) || triplets(i,2)==triplets(i,0));
		}
	}

The do-while-loop may run forever. This could happen if vecRandInt[(pos+3)%S]%S evaluates to 0 and the condition (triplets(i,0)==triplets(i,1) || triplets(i,1)==triplets(i,2) || triplets(i,2)==triplets(i,0)) holds true.

test_cpp compile issue

when compiling on ubuntu 16.04, the test_cpp fails with

........../normals_Hough/test_cpp/../third_party_includes/nanoflann.hpp:1823:16: error: âlog2â is not a member of âstdâ
treeCount = std::log2(maximumPointCount);

the nanoflann.hpp treeCount = std::log2(maximumPointCount); is incompatible with something?

some installation issues

Hello,

Thanks for the code. I had some issues during installation, and want to put it here in case others have similar issues.

I tried to install on Ubuntu 18 using conda, and had to make the following changes to setup.py:

  1. add import numpy
  2. add numpy.get_include() to include_dirs

Thanks.

there is something wrong

when i compile the normals_hough,it comes
E:\normals_Hough-master\normals_Hough-master\include\Normals.h(252) : error C2664: “nanoflann::KDTreeSingleIndexAdaptor<Distance,DatasetAdaptor,DIM,IndexType>::knnSearch”: 不能将参数 3 从“long *”转换为“__w64 int *”
how can i solve this problem

Fast and Robust Normal Estimation

Hello,

Thanks for sharing the source code. I am now comparing different normal estimation methods.
But would you mind to refine the README for running example of "Fast and Robust Normal Estimation"? There are several errors when compiling.

Best,
Yumin

Bug in radius values in cubes_radius() and Unif_radius()

Dear Alexandre,

There seems to be an inconsistency in the methods of cubes_radius() at L1682 and Unif_radius() at L1418 where the radius2 is used as it is from the input argument, while in two other methods, e.g. cubes_knn() and the Unif_knn() it is computed as follows (L1287 or L1573): radius = sqrt(radius);
Is this a bug?

Best regards
Dmytro Bobkov

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.