TUTORIAL LIDAR (Point cloud) to mesh tutorial
- Thread starter DanTDBV
- Start date
Hey @PseT , I don't know to propose a solution, but I would definitely be interested as well in one. Maybe @DanTDBV or @Mr Whippy could help us.
Until now, in my eyes this is was more of a reference to assure alignment and accuracy in regards to the original than an actual usable mesh. But would like to change this opinion
.
Until now, in my eyes this is was more of a reference to assure alignment and accuracy in regards to the original than an actual usable mesh. But would like to change this opinion
.
Woodee
Member
I have been able to get UK point data into 3dsmax.
ASC - LasTools (txt2las) - LAS - Cloud Convert - Merged - points reduced - Made mesh - FBX.
The one problem I am finding is now that I can import KML paths using Mario's track tools or Klaas Nienhuis' KML parser which stay to scale. Terrain I import from point cloud is not which pretty much defeats the object of getting some accuracy to a track!!
Where am I going wrong?
Also once the point cloud becomes mesh, how can I paint grass or dirt onto it (maybe using satellite map as background) ?
ASC - LasTools (txt2las) - LAS - Cloud Convert - Merged - points reduced - Made mesh - FBX.
The one problem I am finding is now that I can import KML paths using Mario's track tools or Klaas Nienhuis' KML parser which stay to scale. Terrain I import from point cloud is not which pretty much defeats the object of getting some accuracy to a track!!
Where am I going wrong?
Also once the point cloud becomes mesh, how can I paint grass or dirt onto it (maybe using satellite map as background) ?
DanTDBV
Member
PseT
I am not quite sure about what you are asking, but I am guessing that you ask about, cleaning away the trees and the rest of the unnessesarry objects.
I only have any real experience with the Danish LAZ pointclouds. In CloudCompare I use the Scalar fields Filter by Value function and only create a landscape mesh, from the surface values.
They seem to have the same values in the Danish files.
What type of pointcloud are you working with?
I ask because one of the difficulties with pointcloud files, is that there are so many different formats, that can contain from few to many kinds of information. It is almost entirely, up to the creators of the files, to decide what they put in there.
3dsmax is way beyond my payscale, so I can be of no help there. I work in Blender.
I wish I could do more, but I am new to this as well.
Happy modding
I am not quite sure about what you are asking, but I am guessing that you ask about, cleaning away the trees and the rest of the unnessesarry objects.
I only have any real experience with the Danish LAZ pointclouds. In CloudCompare I use the Scalar fields Filter by Value function and only create a landscape mesh, from the surface values.
They seem to have the same values in the Danish files.
What type of pointcloud are you working with?
I ask because one of the difficulties with pointcloud files, is that there are so many different formats, that can contain from few to many kinds of information. It is almost entirely, up to the creators of the files, to decide what they put in there.
3dsmax is way beyond my payscale, so I can be of no help there. I work in Blender.
I wish I could do more, but I am new to this as well.
Happy modding
DanTDBV
Member
Woodee
I have earlier looked a little into the British data, and I have to admit, that I cannot find head and tail in it.
I know that I have to tell CloudCompare, what to do with the information, but I can for the life of me not find out what. I have never been a number crusher and when I look on one of those files in Notepad+, it's like the letters and numbers begin to swim around the page.
I have no idea for what you should do for your scaling issues. That is also one of the things, I need to work out in Blender for my projects.
3dsmax is still way beyond my payscale ;-)
When you have created your mesh, you need to add a material to it, before you can add a texture.
I would look for add materials and add textures tutorials for 3dsmax, maybe together with the version number, of the software that you use.
My newest attempt will be a mesh, from a full ressolution cloud, where I will add an Ortho photo as texture. You can see how that looks, on a mesh from a reduced cloud in post 9 here:
http://assettocorsamods.net/threads/nisseringen-denmark-lidar-landscape.420/
I will do a retopology on the mesh, that is draping a lower resolution mesh, on top of the high res mesh. I will among other things, use a plugin called RetopoFlow for Blender, that should make it much easier.
When that is done I will add different materials, to the different parts of the mesh. Like dirt, grass, roads, sandtrap and the like. Here I would add basic textures for the materials.
I will attempt to see if I can export 1 mesh, with multiple materials to see how drivable it is.
Otherwise it is time, to split the mesh by material. It is easy in Blender:
Blender 2.76b:
Edit mode / Select object / Hit A until all is selected / Press P / Select By Material
You will need to find a HowTo for 3dsmax.
At this point the continuation is somewhat open.
Happy modding
I have earlier looked a little into the British data, and I have to admit, that I cannot find head and tail in it.
I know that I have to tell CloudCompare, what to do with the information, but I can for the life of me not find out what. I have never been a number crusher and when I look on one of those files in Notepad+, it's like the letters and numbers begin to swim around the page.
I have no idea for what you should do for your scaling issues. That is also one of the things, I need to work out in Blender for my projects.
3dsmax is still way beyond my payscale ;-)
When you have created your mesh, you need to add a material to it, before you can add a texture.
I would look for add materials and add textures tutorials for 3dsmax, maybe together with the version number, of the software that you use.
My newest attempt will be a mesh, from a full ressolution cloud, where I will add an Ortho photo as texture. You can see how that looks, on a mesh from a reduced cloud in post 9 here:
http://assettocorsamods.net/threads/nisseringen-denmark-lidar-landscape.420/
I will do a retopology on the mesh, that is draping a lower resolution mesh, on top of the high res mesh. I will among other things, use a plugin called RetopoFlow for Blender, that should make it much easier.
When that is done I will add different materials, to the different parts of the mesh. Like dirt, grass, roads, sandtrap and the like. Here I would add basic textures for the materials.
I will attempt to see if I can export 1 mesh, with multiple materials to see how drivable it is.
Otherwise it is time, to split the mesh by material. It is easy in Blender:
Blender 2.76b:
Edit mode / Select object / Hit A until all is selected / Press P / Select By Material
You will need to find a HowTo for 3dsmax.
At this point the continuation is somewhat open.
Happy modding
Woodee
Member
I know how to map material in max, it's just that the LiDAR I import which is not to scale, it would be hard to match up with a google map that covers the data.
I'll have a look for a retopo plugin or method in max as this may be more useful than conforming low dense mesh to the (somewhat) dense mesh imported. Trying to import the most hi-res 50cm/1m LiDAR makes my computer hang (i7 6700 16 gb RAM), I have to tone it down a little before importing it in a manageable state.
I use LAS Tools (txt2las) to convert from ASC (which is what the UK data comes as) to a LAS then I can use Cloud Compare to make a mesh from it (OBJ/FBX etc...)
Once I have a few things figured out in my workflow and find some decent way to overcome these problems with scale, I will post it up.
Glad these places exist to help each other modding
Mr Whippy
Active Member
Woodee, it sounds like you're using the ASCII format grid data that was generated *from* LiDAR data?
That is what I've used and posted about it in another thread on here.
If that is the data you're using (which it sounds like it is), then the scaling is an easy fix because the space between each vert (xy plane, not actual edge length as they slope) is the distance marked in the meta-data at the head of the ascii file. Ie, 50m, 5m, 1m, 50cm, whatever.
The Z (height) values are in absolute metres, so the bottom left point on the grid should have a Z height of the first value in the file after the meta data.
PseT, that data looks pretty nice.
But there is no 'button' to make any task easy. This is just 3D blueprints, so you still have to do lots of work to get a nice track.
For example, defining chunks as trees, the track outline, removing features etc, are all done manually in real life. It's one of the main reasons LiDAR data is so expensive... all the manual work tidying and filtering and defining objects.
I've spent weeks with another chap just outlining the road edges on 20km of road LiDAR data before... so yes the road was accurate for sure, but it didn't just happen, it also took huge amounts of work to get the data out of points and into a grid perfectly matched to them
Cheers
Dave
That is what I've used and posted about it in another thread on here.
If that is the data you're using (which it sounds like it is), then the scaling is an easy fix because the space between each vert (xy plane, not actual edge length as they slope) is the distance marked in the meta-data at the head of the ascii file. Ie, 50m, 5m, 1m, 50cm, whatever.
The Z (height) values are in absolute metres, so the bottom left point on the grid should have a Z height of the first value in the file after the meta data.
PseT, that data looks pretty nice.
But there is no 'button' to make any task easy. This is just 3D blueprints, so you still have to do lots of work to get a nice track.
For example, defining chunks as trees, the track outline, removing features etc, are all done manually in real life. It's one of the main reasons LiDAR data is so expensive... all the manual work tidying and filtering and defining objects.
I've spent weeks with another chap just outlining the road edges on 20km of road LiDAR data before... so yes the road was accurate for sure, but it didn't just happen, it also took huge amounts of work to get the data out of points and into a grid perfectly matched to them
Cheers
Dave
Mr Whippy
Active Member
Hey Woodee,
The scaling issue you have is easily fixed.
If your using a 1m DTM or DSM for instance, then the top-down grid sizing is 1m. So as long as the imported grid has 1m x 1m squares in the top-down view, then it's to scale.
Or 50cm for a 50cm DTM/DSM, and so on for the other sizes.
And to clarify on those data-sets, they're not LiDAR data. They are DSM/DTM grids made from LiDAR scan data. So they're accurate but they're not point cloud data. You can't load them in point cloud software.
One other thing to note is that the grids are not covering the entire area on OS grids, since the very last row (top of grid), or very last column (right of grid) are left with a gap the size of the grid density (1m, 50cm or whatever the resolution is), since the last row or column of data needs to fill the gap up to the next strip of height data points.
Simply put, don't load several tiles and place them right up next to each other because that is incorrect, the need offsetting by the grid size value.
Dave
The scaling issue you have is easily fixed.
If your using a 1m DTM or DSM for instance, then the top-down grid sizing is 1m. So as long as the imported grid has 1m x 1m squares in the top-down view, then it's to scale.
Or 50cm for a 50cm DTM/DSM, and so on for the other sizes.
And to clarify on those data-sets, they're not LiDAR data. They are DSM/DTM grids made from LiDAR scan data. So they're accurate but they're not point cloud data. You can't load them in point cloud software.
One other thing to note is that the grids are not covering the entire area on OS grids, since the very last row (top of grid), or very last column (right of grid) are left with a gap the size of the grid density (1m, 50cm or whatever the resolution is), since the last row or column of data needs to fill the gap up to the next strip of height data points.
Simply put, don't load several tiles and place them right up next to each other because that is incorrect, the need offsetting by the grid size value.
Dave
Mr Whippy
Active Member
Yeah the software you're using should figure it out.
If your software keeps the meshes split by grid import, but sorts the seams and alignment, then just export one at a time to your 3D app so it's smaller meshes as possible.
If it's joining them then the meshes will get huge and the 3D app unhappy I think haha
But it might still be ok if you can get the import to work, albeit slowly and sluggishly. You can always split the mesh up in your 3D app later into managable chunks
The main thing is to be aware of what the data set really looks like, so you can check the software is dealing with it right and doing the seams and so on.
I did lots of testing on the OS open data 50m DSM models which are the same data type, but much faster for processing/testing with to check things work right. Also any discontinuity at edges is really easily visible with such a large grid size too!
Dave
If your software keeps the meshes split by grid import, but sorts the seams and alignment, then just export one at a time to your 3D app so it's smaller meshes as possible.
If it's joining them then the meshes will get huge and the 3D app unhappy I think haha
But it might still be ok if you can get the import to work, albeit slowly and sluggishly. You can always split the mesh up in your 3D app later into managable chunks
The main thing is to be aware of what the data set really looks like, so you can check the software is dealing with it right and doing the seams and so on.
I did lots of testing on the OS open data 50m DSM models which are the same data type, but much faster for processing/testing with to check things work right. Also any discontinuity at edges is really easily visible with such a large grid size too!
Dave
Mr Whippy
Active Member
i7 4700k here with 16gb of ram too, and a dedicated fast SSD for swap file etc etc.
Those meshes kill my computer in most 3D apps too.
The 25cm ones are like 16 mill quads, or 32 mill triangles!
50cm are 4 mill quad, 8 mill tris.
1m are 1 mill quad, 2 mill tries (they start getting managable as whole chunks now!)
For the finer detailed ones you just have to chop them up really and then manage them in layers or whatever else.
But to lengthen the distance between points will make the grid out of scale. If the size is 25cm for instance, then the grid is 25cm, so 4000 x 4000 squares = 1km x 1km in size.
50cm = 2000 x 2000 squares = 1k x 1km
1m = 1000 x 1000 squares = 1km x 1km
Etc.
The only way you could increase the distance between points is to make the grid out of scale.
Those meshes kill my computer in most 3D apps too.
The 25cm ones are like 16 mill quads, or 32 mill triangles!
50cm are 4 mill quad, 8 mill tris.
1m are 1 mill quad, 2 mill tries (they start getting managable as whole chunks now!)
For the finer detailed ones you just have to chop them up really and then manage them in layers or whatever else.
But to lengthen the distance between points will make the grid out of scale. If the size is 25cm for instance, then the grid is 25cm, so 4000 x 4000 squares = 1km x 1km in size.
50cm = 2000 x 2000 squares = 1k x 1km
1m = 1000 x 1000 squares = 1km x 1km
Etc.
The only way you could increase the distance between points is to make the grid out of scale.
Mr Whippy
Active Member
The 25cm data isn't much better than 50cm really in my view, since you just start seeing more of the noise than more sharp details it seems.
50cm is good over 1m mainly because at 50cm the noise/error of the data is just starting to show.
For most stuff 1m is pretty good though.
I've imported 50cm (the best data) for a project I'm working on, and then have the 1m for everything beyond the main track/driving area since for all intents and purposes it's just as good as a reference.
On the other thread on here I've added a load of info/pics of which tracks are covered by the UK DSM/DTM grid data so far... so if you're looking at more that are not on there it'd be cool to add them for others so they know for future reference maybe
Cheers
Dave
50cm is good over 1m mainly because at 50cm the noise/error of the data is just starting to show.
For most stuff 1m is pretty good though.
I've imported 50cm (the best data) for a project I'm working on, and then have the 1m for everything beyond the main track/driving area since for all intents and purposes it's just as good as a reference.
On the other thread on here I've added a load of info/pics of which tracks are covered by the UK DSM/DTM grid data so far... so if you're looking at more that are not on there it'd be cool to add them for others so they know for future reference maybe
Cheers
Dave
Mr Whippy
Active Member
I've no idea what your software does unfortunately.
I have a feeling it may just trim rows/columns to reduce the resolution then. That should be ok if that is what it's doing, but it'll be lossy of course. Better to just download the next grid size up really. Ie, get 1m instead of 50cm, if you want to reduce the resolution any way.
This is where working on the Open Data DSM/DTM which are 50m grids is better as it's super fast and easy to check/cut up and test things with so you know what's happening
I can happily send some of the 50m grids to you for testing if you wanted?
Dave
I have a feeling it may just trim rows/columns to reduce the resolution then. That should be ok if that is what it's doing, but it'll be lossy of course. Better to just download the next grid size up really. Ie, get 1m instead of 50cm, if you want to reduce the resolution any way.
This is where working on the Open Data DSM/DTM which are 50m grids is better as it's super fast and easy to check/cut up and test things with so you know what's happening
I can happily send some of the 50m grids to you for testing if you wanted?
Dave
Share this page
Support the site
