In my VS2019 project, I have added all the necessary header and source files, and configured the PCL library. However, strangely, when I include the PCL library, it causes errors in the PCL library itself. I'm not sure why this is happening.

# coding: utf-8
import laspy
import CSF
import numpy as np

inFile = laspy.read("D:\\dataset\\aoi.las")

xyz = np.vstack((inFile.x, inFile.y, inFile.z)).transpose() # extract x, y, z and put into a list

csf = CSF.CSF()

# prameter settings
csf.params.bSloopSmooth = False
csf.params.cloth_resolution = 0.5
# more details about parameter: http://ramm.bnu.edu.cn/projects/CSF/download/

csf.setPointCloud(xyz)
ground = CSF.VecInt() # a list to indicate the index of ground points after calculation
non_ground = CSF.VecInt() # a list to indicate the index of non-ground points after calculation
csf.do_filtering(ground, non_ground) # do actual filtering.

outFile = laspy.create(point_format=inFile.header.point_format, file_version=inFile.header.version)
outFile.points = inFile.points[ground] # extract ground points, and save it to a las file.
outFile.write(r"out.las")

Output/Traceback:

Traceback (most recent call last):
  File "test.py", line 26, in <module>
    outFile.points = inFile.points[ground] # extract ground points, and save it to a las file.
  File "C:\Anaconda\envs\env\lib\site-packages\laspy\lasdata.py", line 367, in __setattr__
    super().__setattr__(key, value)
  File "C:\Anaconda\envs\env\lib\site-packages\laspy\lasdata.py", line 98, in points
    if new_points.point_format != self.point_format:
AttributeError: 'numpy.ndarray' object has no attribute 'point_format'

Is there one have seen this error before when build solution?

Hello.

I have seen the project and related papers. And the project was interesting.

After that, the test was conducted with the data we have.

The 2GB data size worked fine. The results were very good.
However, there was no response to the data size of 10 GB.
Also, there was no error message.

Can you tell if there is a data size recommended for the project?

ps. I ran it with a python example

Hello,

I don't see a swig interface file in the repository.

Could you please add that?

It will help us make bug-fixes, etc.

Thanks.

我在源码src目录下make,make install，然后程序中包含CSF.h，但是编译时报错：CSF.h中包含的头文件point_cloud.h不存在，请问这个怎么解决？

# coding: utf-8
import laspy
import CSF
import numpy as np

inFile = laspy.read("/data/Shalun/lidar/pt03.las") # read a las file
points = inFile.points
xyz = np.vstack((inFile.x, inFile.y, inFile.z)).transpose() # extract x, y, z and put into a list

csf = CSF.CSF()

# prameter settings
csf.params.bSloopSmooth = False
csf.params.cloth_resolution = 0.5
# more details about parameter: http://ramm.bnu.edu.cn/projects/CSF/download/

csf.setPointCloud(xyz)
ground = CSF.VecInt()  # a list to indicate the index of ground points after calculation
non_ground = CSF.VecInt() # a list to indicate the index of non-ground points after calculation
csf.do_filtering(ground, non_ground) # do actual filtering.

outFile = laspy.LasData(inFile.header)
outFile.points = points[ground] # extract ground points, and save it to a las file.
out_file.write(r"out.las")

It looks like CSF finished, but the laspy format cannot use.

While writing the output file "Value error: seek out of range" error is showing. Is there any way to resolve it?

Good Morning I was having the following issues trying to install CSF in python 3.8 I get the following error
CSF_wrap.cxx(3135): fatal error C1083: Cannot open include file: '../src/CSF.h': No such file or directory
error: command 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.24.28314\bin\HostX86\x64\cl.exe' failed with exit status 2

I do have installed Visual Studio.

Please update the examples as per laspy latest version.

Hi,

It is a great package, and it would be most helpful if you could rebuild it for numpy 2.0 support.
Currently importing leads to this error message (slightly edited):

A module that was compiled using NumPy 1.x cannot be run in
NumPy 2.0.1 as it may crash. To support both 1.x and 2.x
versions of NumPy, modules must be compiled with NumPy 2.0.
Some module may need to rebuild instead e.g. with 'pybind11>=2.12'.

If you are a user of the module, the easiest solution will be to
downgrade to 'numpy<2' or try to upgrade the affected module.
We expect that some modules will need time to support NumPy 2.

Traceback (most recent call last):  File "/home/....py", line 6, in <module>
    import CSF
  File "/home/.../site-packages/CSF.py", line 15, in <module>
    import _CSF
Traceback (most recent call last):
  File "/home/.../site-packages/numpy/core/_multiarray_umath.py", line 44, in __getattr__
    raise ImportError(msg)
ImportError: 
A module that was compiled using NumPy 1.x cannot be run in
NumPy 2.0.1 as it may crash. To support both 1.x and 2.x
versions of NumPy, modules must be compiled with NumPy 2.0.
Some module may need to rebuild instead e.g. with 'pybind11>=2.12'.

If you are a user of the module, the easiest solution will be to
downgrade to 'numpy<2' or try to upgrade the affected module.
We expect that some modules will need time to support NumPy 2.

Very likely the only thing you would need to do is compile the code with Numpy 2.0 (and publish it on pypi :) ),
that suppose to be backward compatible. (But I don't completely follow the array magic inside
CSF codes, so maybe there is more.)
https://numpy.org/doc/stable/dev/depending_on_numpy.html#numpy-2-abi-handling

Thanks!

Device info:

• Macbook Pro, mid-2015, Intel processor
• macOS Montery (12.3)

After git cloneing and cding into the python directory, running python setup.py build results in the following error:

$ python setup.py build
running build
running build_py
running build_ext
building '_CSF' extension
clang -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -fwrapv -O2 -Wall -fPIC -O2 -isystem /Users/lusk/miniconda3/envs/PointClouds/include -fPIC -O2 -isystem /Users/lusk/miniconda3/envs/PointClouds/include -I/usr/local/opt/llvm/include -I/Users/lusk/miniconda3/envs/PointClouds/include/python3.9 -c ../src/CSF.cpp -o build/temp.macosx-10.9-x86_64-3.9/../src/CSF.o -fopenmp
clang: error: unsupported option '-fopenmp'
error: command '/usr/bin/clang' failed with exit code 1

I've tried installing the homebrew gcc package and then linking gcc to use gcc-11, but the issue persists.

Hi!
Is it possible to set input as '.pcd' files(3D point cloud data) and also get output as '.pcd' file?
Or do I have to convert '.pcd' to '.txt' or '.cfg'?
And if it is possible, could you let me know how to handle it?
Thank you!

Hi, I'm wondering if it is possible to return the cloth i.e. return the coordinates of the nodes programmatically. There is a an option exportCloth in CSF::do_filtering but it seems to write something in file. I'd like to get a C++ object I could transform into a raster in R. I can modify the code if needed.
Thanks.

Hello,

I want to use the CSF for my Master's Thesis but unfortunately I have some problems with varying results. My point cloud has in total 23,146,900 points and here are some results for example:

Number of non-ground points: 14675441
Number of ground points: 8471459

Number of non-ground points: 14632410
Number of ground points: 8514490

Number of non-ground points: 14591098
Number of ground points: 8555802

Number of non-ground points: 14595535
Number of ground points: 8551365

Number of non-ground points: 14595098
Number of ground points: 8551802

Number of non-ground points: 14592757
Number of ground points: 8554143

Since the answer to issue #21 said that the problem can be caused by multithreading, I first added os.environ["OMP_NUM_THREADS"] = "1" in my code. I didn't noticed any change in the results, so I tried to fork the repository and excluded all omp calls from the code (https://github.com/SabineZa/CSF). Unfortunately, I have still the same variations in my results, so I believe the non-deterministic results aren't caused by multithreading. I also tried it with different point clouds and examined the results from the CloudCompare plugin, which show the same behavior.
Is there an explanation why I always get different results? Is it supposed to be like this? Is it possible to get stable results? In order to use it in a scientific way I need reproducible results.
Thanks in advance and I would appreciate any advice to help me with my problem.

ImportError: DLL load failed while importing _CSF: The specified module could not be found.

I am having some trouble getting the generated executable csfdemo to work on Linux Mint(19.2).

gcc --version
gcc (Ubuntu 9.2.1-9ubuntu2~18.04.1) 9.2.1 20191008

cmake --version
cmake version 3.10.2

Steps:

I had to comment out the pragma omp parallel for in two files (Cloth.cpp and CSF.cpp) to build succesfully, otherwise it would fail.

After that I followed the README.md steps:

cmake .
make

then I added samp311.txt and params.cfg from the CSFDemo(V2.0) folder to the new /bin folder

Running the executable (./csfdemo) creates the two files 'ground.txt' and 'non-ground.txt' but they are both empty.

使用开源的代码和论文所说的参数对ISPRS数据集进行测试，已提前对ISPRS的原始点云进行了统计学滤波过滤低点了，但是一类误差和论文所述差距很大，请问会是什么原因导致的呢

Hi, jianboqi
I am curious what is the reason CSF using gravity like drop process? In order to hit the ground faster? Or is there any other reason using this model?
Miller

Hi, I have set threshold values for one LAS file like below but need to change thresholds for neighbor regions. Is it possibly to set thresholds automatically to separate ground and non ground regions.

LasFIle-1

csf.params.bSloopSmooth = True
csf.params.cloth_resolution = 0.5
csf.params.rigidness = 5
csf.params.time_step = 0.65;
csf.params.class_threshold = 0.02
csf.params.interations = 500;

Las File-2
csf.params.bSloopSmooth = True
csf.params.cloth_resolution = 0.25
csf.params.rigidness = 5
csf.params.time_step = 0.65;
csf.params.class_threshold = 0.02
csf.params.interations = 500;

Hi,
as reported in bug #8, CSF gets stuck while classifying a pretty regular point cloud: memory usage increases a lot and it gets into an infinite loop.
If you can provide a valid email address I can send you the test-file.
thanks!

Hi,this repo has impressive performance.But on large pcd,it runs quite slow.Any plan to release a gpu accelerate version?

Is your algorithm mainly developed for airborne scan data? Can I use it for segmenting out ground points from pointcloud constructed with velodyne placed on top of the vehicle? Which parameters need to be changed?

Hey might be a stupid question but trying to build on Linux gives me this error:
CMake Error at src/CMakeLists.txt:31 (install):
install TARGETS given no ARCHIVE DESTINATION for static library target "CSF".

Have I missed an obvious step in the installation? I just downloaded file made a build directory then tried to cmake.

readme里写了读取txt和las文件的方法，请问pcd和bin文件等格式怎么读取？

case there may be vary large pointcloud and this will takes a long time to execute,I want to show a progress bar in python , but I don't know how to modify it

pointcloud是自定义的还是可以使用pcl中的呢？我在编译的时候遇到了以下错误

Does the bSloopSmooth parameter correspond to the "Slope postprocessing for disconnected terrain" option (checkbox) that appears in the CC plugin?

thanks,

Hi, I tried to install CSF on WSL. It seemed that the install worked, however when importing the library in my code, this error occurs:

Traceback (most recent call last):
File "", line 1, in
File "/home/my_name/conda/lib/python3.9/site-packages/CSF-1.1.1-py3.9-linux-x86_64.egg/CSF.py", line 17, in
_CSF = swig_import_helper()
File "/home/my_name/conda/lib/python3.9/site-packages/CSF-1.1.1-py3.9-linux-x86_64.egg/CSF.py", line 16, in swig_import_helper
return importlib.import_module('_CSF')
File "/home/my_name/conda/lib/python3.9/importlib/init.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
ImportError: /home/my_name/conda/lib/python3.9/site-packages/CSF-1.1.1-py3.9-linux-x86_64.egg/_CSF.cpython-39-x86_64-linux-gnu.so: undefined symbol: _ZSt28__throw_bad_array_new_lengthv

Do you have an idea what could be wrong? Thanks so much in advance.

Thank you very much for your code. I am able to separate the ground and non-ground and visualize it. Works very well. I would like to apply classification algorithm for non-ground points. I have to extract the index of non ground points.

From your example:
inFile = laspy.file.File(r"in.las", mode='r')
points = inFile.points
xyz = np.vstack((inFile.x, inFile.y, inFile.z)).transpose()

How can I get the ground point index from xyz list?

Thanks again

hello, @jianboqi
i see a comment in 9fdcc5b, so why change float to double, does float influence the result? thanks!

Hi, guys! This is really a good method. I have separeted the ground points and the object points. Could you tell me how to generate the DTM with the ground points?

I believe this code is wrong for omp
See CloudCompare/CloudCompare#909 where same problem is reported for the CSF cloud compare plugin

#pragma omp parallel for
    for (int i = 0; i < particleCount; i++) {
        if (particles[i].isMovable()) {
            double diff = fabs(particles[i].old_pos.f[1] - particles[i].pos.f[1]);

            if (diff > maxDiff)
                maxDiff = diff;
        }
    }

I am trying to use CSF from Python 3.7 and I am not able to download the source code under python folder with the lines:

python setup.py build python setup.py install

because I get this error message: Unable to find vcvarsall.bat

As a consequence I can´t use the CSF.py script. I am really interested in filtering a lidar point cloud data with this method but I don´k now how to continue. I have tried also creating and environment in Python 2.7 and I hava the same problem.Any help?

Is there an option to fill in holes created by CSF in either the CloudCompare plugin, C++ or python port? Or would this need to be implemented by the user?

Hello, I want to know the correspondence between the point cloud filtered by csf and the original point cloud. For example, there are 40120 points obtained after csf filtering. Which of these points correspond to among the 81000 points in the original point cloud? How should I modify the code to get the result I want?

Hi. I think source code in src/CSF.cpp
`void CSF::setPointCloud(double *points, int rows) {
#define A(i, j) points[i + j * rows]

for (int i = 0; i < rows; i++) {
    csf::Point p;
    p.x = A(i, 0);
    p.y = -A(i, 2);
    p.z = A(i, 1);
    point_cloud.push_back(p);
}

}`
A(i, j) is wrong defined. for rows = 3, i from 0 to 3, x, y, z index will be:
p.x = A(0, 0) = points[0 + 0 * 3] = points[0]
p.y = -A(0, 2) = -points[0 + 2 * 3] = -points[6]
p.z = A(0, 1) = points[0 + 1 * 3] = points[3]
p.x = A(1, 0) = points[1 + 0 * 3] = points[1]
p.y = -A(1, 2) = -points[1 + 2 * 3] = -points[7]
p.z = A(1, 1) = points[1 + 1 * 3] = points[4]
p.x = A(2, 0) = points[2 + 0 * 3] = points[2]
p.y = -A(2, 2) = -points[2 + 2 * 3] = -points[8]
p.z = A(2, 1) = points[2 + 1 * 3] = points[5]

That means input points contains data in an odd order:
x0, x1, x2, y0, y1, y2, z0, z1, z2

but if the macro function defined like this:
#define A(i, j) points[i * rows + j]

Everything will be OK.

So is it a bug or I wrongly understand the function?

The CSF ground filter does not give consistent results when multithreading. i.e. between runs we get slightly different ground and non-ground classifications.

I've attached a CSV point cloud I used for testing that contains 500,000 points (trimble_500k.zip). For testing I'm running the CSF filter with the settings:

Scene = Relief
Slope processing = True
Cloth Resolution = 1.0
Max Iterations = 500
Classification Threshold = 0.5
Export Cloth Mesh = False

Out of 5 runs I got the following number of ground points.

1. 71,275
2. 71,276
3. 71,275
4. 71,275
5. 71,276

Setting the environment variable OMP_NUM_THREADS to 1 results in each run returning 71,274 ground points. I'd assume that this would be the correct result?

As a workaround we removed all #pragma omp parallel for statements from CSF (there is only a few). This resulted in seemingly consistent results between runs. I also didn't observe too much of a drop in performance which was surprising, even for a ~63 million point cloud.

How does singleMove1 and doubleMove1 come from? Is 0.3 obtained by experiments?

Hello,

I'm using laspy on WinPython-64bit-2.7 + MinGW and would like to install the CSF python module, but the install is failing during build (see below).

I'm not familiar with building and installing from sources so if someone can point me to the right direction it would be great !

Thanks for your help.
Alex

running build
running build_py
running build_ext
building '_CSF' extension
C:\MinGW\bin\gcc.exe -mdll -O -Wall -IC:\WinPython\WinPython-64bit-2.7.12.3Zero
python-2.7.12.amd64\include -IC:\WinPython\WinPython-64bit-2.7.12.3Zero\scripts
..\python-2.7.12.amd64\PC -c csf_wrap.cxx -o build\temp.win-amd64-2.7\Release\cs
f_wrap.o
C:\MinGW\bin\gcc.exe -mdll -O -Wall -IC:\WinPython\WinPython-64bit-2.7.12.3Zero
python-2.7.12.amd64\include -IC:\WinPython\WinPython-64bit-2.7.12.3Zero\scripts
..\python-2.7.12.amd64\PC -c ../CSFDLL/c2cdist.cpp -o build\temp.win-amd64-2.7\R
elease..\csfdll\c2cdist.o
In file included from ../CSFDLL/Cloth.h:46:0,
from ../CSFDLL/c2cdist.h:5,
from ../CSFDLL/c2cdist.cpp:1:
../CSFDLL/Particle.h: In constructor 'Particle::Particle(Vec3, double)':
../CSFDLL/Particle.h:31:7: warning: 'Particle::old_pos' will be initialized afte
r [-Wreorder]
Vec3 old_pos; // the position of the particle in the previous time step, used
as part of the verlet numerical integration scheme
^
../CSFDLL/Particle.h:25:7: warning: 'Vec3 Particle::acceleration' [-Wreorder]
Vec3 acceleration; // a vector representing the current acceleration of the pa
rticle
^
../CSFDLL/Particle.h:49:2: warning: when initialized here [-Wreorder]
Particle(Vec3 pos, double time_step) : pos(pos), old_pos(pos), acceleration(Ve
c3(0, 0, 0)), mass(1), movable(true), accumulated_normal(Vec3(0, 0, 0)), time_st
ep2(time_step)
^
../CSFDLL/Particle.h:25:7: warning: 'Particle::acceleration' will be initialized
after [-Wreorder]
Vec3 acceleration; // a vector representing the current acceleration of the pa
rticle
^
../CSFDLL/Particle.h:23:9: warning: 'double Particle::mass' [-Wreorder]
double mass; // the mass of the particle (is always 1 in this example)
^
../CSFDLL/Particle.h:49:2: warning: when initialized here [-Wreorder]
Particle(Vec3 pos, double time_step) : pos(pos), old_pos(pos), acceleration(Ve
c3(0, 0, 0)), mass(1), movable(true), accumulated_normal(Vec3(0, 0, 0)), time_st
ep2(time_step)
^
../CSFDLL/Particle.h:23:9: warning: 'Particle::mass' will be initialized after [
-Wreorder]
double mass; // the mass of the particle (is always 1 in this example)
^
../CSFDLL/Particle.h:21:7: warning: 'bool Particle::movable' [-Wreorder]
bool movable; // can the particle move or not ? used to pin parts of the cloth

   ^

../CSFDLL/Particle.h:49:2: warning: when initialized here [-Wreorder]
Particle(Vec3 pos, double time_step) : pos(pos), old_pos(pos), acceleration(Ve
c3(0, 0, 0)), mass(1), movable(true), accumulated_normal(Vec3(0, 0, 0)), time_st
ep2(time_step)
^
../CSFDLL/c2cdist.cpp: In member function 'void c2cdist::calCloud2CloudDist(Clot
h&, csf::PointCloud&, std::vector&, std::vector&)':
../CSFDLL/c2cdist.cpp:11:20: warning: comparison between signed and unsigned int
eger expressions [-Wsign-compare]
for (int i = 0; i < pc.size(); i++)
^
C:\MinGW\bin\gcc.exe -mdll -O -Wall -IC:\WinPython\WinPython-64bit-2.7.12.3Zero
python-2.7.12.amd64\include -IC:\WinPython\WinPython-64bit-2.7.12.3Zero\scripts
..\python-2.7.12.amd64\PC -c ../CSFDLL/Cloth.cpp -o build\temp.win-amd64-2.7\Rel
ease..\csfdll\cloth.o
../CSFDLL/Cloth.cpp:75:0: warning: ignoring #pragma omp parallel [-Wunknown-prag
mas]
#pragma omp parallel for
^
../CSFDLL/Cloth.cpp:82:0: warning: ignoring #pragma omp parallel [-Wunknown-prag
mas]
#pragma omp parallel for
^
../CSFDLL/Cloth.cpp:89:0: warning: ignoring #pragma omp parallel [-Wunknown-prag
mas]
#pragma omp parallel for
^
../CSFDLL/Cloth.cpp:116:0: warning: ignoring #pragma omp parallel [-Wunknown-pra
gmas]
#pragma omp parallel for
^
In file included from ../CSFDLL/Cloth.h:46:0,
from ../CSFDLL/Cloth.cpp:1:
../CSFDLL/Particle.h: In constructor 'Particle::Particle(Vec3, double)':
../CSFDLL/Particle.h:31:7: warning: 'Particle::old_pos' will be initialized afte
r [-Wreorder]
Vec3 old_pos; // the position of the particle in the previous time step, used
as part of the verlet numerical integration scheme
^
../CSFDLL/Particle.h:25:7: warning: 'Vec3 Particle::acceleration' [-Wreorder]
Vec3 acceleration; // a vector representing the current acceleration of the pa
rticle
^
../CSFDLL/Particle.h:49:2: warning: when initialized here [-Wreorder]
Particle(Vec3 pos, double time_step) : pos(pos), old_pos(pos), acceleration(Ve
c3(0, 0, 0)), mass(1), movable(true), accumulated_normal(Vec3(0, 0, 0)), time_st
ep2(time_step)
^
../CSFDLL/Particle.h:25:7: warning: 'Particle::acceleration' will be initialized
after [-Wreorder]
Vec3 acceleration; // a vector representing the current acceleration of the pa
rticle
^
../CSFDLL/Particle.h:23:9: warning: 'double Particle::mass' [-Wreorder]
double mass; // the mass of the particle (is always 1 in this example)
^
../CSFDLL/Particle.h:49:2: warning: when initialized here [-Wreorder]
Particle(Vec3 pos, double time_step) : pos(pos), old_pos(pos), acceleration(Ve
c3(0, 0, 0)), mass(1), movable(true), accumulated_normal(Vec3(0, 0, 0)), time_st
ep2(time_step)
^
../CSFDLL/Particle.h:23:9: warning: 'Particle::mass' will be initialized after [
-Wreorder]
double mass; // the mass of the particle (is always 1 in this example)
^
../CSFDLL/Particle.h:21:7: warning: 'bool Particle::movable' [-Wreorder]
bool movable; // can the particle move or not ? used to pin parts of the cloth

   ^

../CSFDLL/Particle.h:49:2: warning: when initialized here [-Wreorder]
Particle(Vec3 pos, double time_step) : pos(pos), old_pos(pos), acceleration(Ve
c3(0, 0, 0)), mass(1), movable(true), accumulated_normal(Vec3(0, 0, 0)), time_st
ep2(time_step)
^
In file included from ../CSFDLL/Cloth.cpp:1:0:
../CSFDLL/Cloth.h: In constructor 'Cloth::Cloth(const Vec3&, int, int, double, d
ouble, double, double, int, double)':
../CSFDLL/Cloth.h:81:6: warning: 'Cloth::num_particles_height' will be initializ
ed after [-Wreorder]
int num_particles_height; // number of particles in "height" direction
^
../CSFDLL/Cloth.h:77:7: warning: 'Vec3 Cloth::origin_pos' [-Wreorder]
Vec3 origin_pos;
^
../CSFDLL/Cloth.cpp:5:1: warning: when initialized here [-Wreorder]
Cloth::Cloth(const Vec3& _origin_pos,
^
../CSFDLL/Cloth.cpp: In member function 'void Cloth::addForce(Vec3)':
../CSFDLL/Cloth.cpp:105:20: warning: comparison between signed and unsigned inte
ger expressions [-Wsign-compare]
for (int i = 0; i < particles.size(); i++)
^
../CSFDLL/Cloth.cpp: In member function 'void Cloth::terrCollision()':
../CSFDLL/Cloth.cpp:117:20: warning: comparison between signed and unsigned inte
ger expressions [-Wsign-compare]
for (int i = 0; i < particles.size(); i++)
^
../CSFDLL/Cloth.cpp: In member function 'void Cloth::saveToFile(std::_cxx11::st
ring)':
../CSFDLL/Cloth.cpp:383:22: error: no matching function for call to 'std::basic
ofstream::basic_ofstream(std::__cxx11::string&)'
ofstream f1(filepath);
^
In file included from ../CSFDLL/Cloth.cpp:2:0:
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\fstream:697:7: note: candidate: std::
basic_ofstream<_CharT, _Traits>::basic_ofstream(const char*, std::ios_base::open
mode) [with _CharT = char; _Traits = std::char_traits; std::ios_base::open
mode = std::_Ios_Openmode]
basic_ofstream(const char* __s,
^
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\fstream:697:7: note: no known conve
rsion for argument 1 from 'std::__cxx11::string {aka std::__cxx11::basic_string<
char>}' to 'const char*'
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\fstream:682:7: note: candidate: std::
basic_ofstream<_CharT, _Traits>::basic_ofstream() [with _CharT = char; _Traits =
std::char_traits]
basic_ofstream(): __ostream_type(), _M_filebuf()
^
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\fstream:682:7: note: candidate expe
cts 0 arguments, 1 provided
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\fstream:656:11: note: candidate: std:
:basic_ofstream::basic_ofstream(const std::basic_ofstream&)
class basic_ofstream : public basic_ostream<_CharT,_Traits>
^
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\fstream:656:11: note: no known conv
ersion for argument 1 from 'std::__cxx11::string {aka std::__cxx11::basic_string
}' to 'const std::basic_ofstream&'
../CSFDLL/Cloth.cpp: In member function 'void Cloth::saveMovableToFile(std::_cx
x11::string)':
../CSFDLL/Cloth.cpp:404:22: error: no matching function for call to 'std::basic
ofstream::basic_ofstream(std::__cxx11::string&)'
ofstream f1(filepath);
^
In file included from ../CSFDLL/Cloth.cpp:2:0:
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\fstream:697:7: note: candidate: std::
basic_ofstream<_CharT, _Traits>::basic_ofstream(const char*, std::ios_base::open
mode) [with _CharT = char; _Traits = std::char_traits; std::ios_base::open
mode = std::_Ios_Openmode]
basic_ofstream(const char* __s,
^
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\fstream:697:7: note: no known conve
rsion for argument 1 from 'std::__cxx11::string {aka std::__cxx11::basic_string<
char>}' to 'const char*'
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\fstream:682:7: note: candidate: std::
basic_ofstream<_CharT, _Traits>::basic_ofstream() [with _CharT = char; _Traits =
std::char_traits]
basic_ofstream(): __ostream_type(), _M_filebuf()
^
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\fstream:682:7: note: candidate expe
cts 0 arguments, 1 provided
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\fstream:656:11: note: candidate: std:
:basic_ofstream::basic_ofstream(const std::basic_ofstream&)
class basic_ofstream : public basic_ostream<_CharT,_Traits>
^
c:\mingw\lib\gcc\mingw32\5.3.0\include\c++\fstream:656:11: note: no known conv
ersion for argument 1 from 'std::__cxx11::string {aka std::__cxx11::basic_string
}' to 'const std::basic_ofstream&'
error: command 'C:\MinGW\bin\gcc.exe' failed with exit status 1

I just implement this program into removing the ground lidar point. And the lidar was equipped on a car. I use kitti dataset to test this program. But i got a bug.
[0] Configuring terrain...
[0] Configuring cloth...
[0] - width: -2147483644 height: -2147483644
[0] Rasterizing...
[0] Simulating...
Segmentation fault
the parameter that i choose was:
csf.setPointCloud(cld);
csf.params.bSloopSmooth = false;
csf.params.class_threshold = 0.12;
csf.params.cloth_resolution = 1;
csf.params.interations = 200;
csf.params.rigidness = 1;

in CSF/src/Cloth.cpp inside function Cloth::timeStep() on lines 111- 118 where we are calculating the diff, it assigns the absolute difference in the y values of the particle's old position and new position. As mentioned in the paper the particles are constrained to move in the vertical direction. The point cloud data that I am using has height values in z, so should I switch the y and z columns in my data?