You gotta simplify that mesh! I highly recommend Meshlab cleaning filters to get those faces to be a little more uniform with regards to shape and size. It’ll help your machine run a little smoother. Simplify it and then re-export as a .ply to reimport into SU. It’ll look super clean.
Because I’m a nice guy. no need to be a dick.
Also, you wrote a message with the exact same problem in march. same issue. for some reason your files are read as meters and not feet. nothing to do with SU template
Here was the solution Yannick gave you, did you try it ? you didn’t answer back then, did it not solve your issue ?
The mesh is similar an Undet mesh displayed in Trimble Connect. It’s pretty sparce already so it doesn’t lag at all.
The point cloud shown previously was .las (not a mesh).
For higher numbers of triangles and FBX/OBJ I’d reduce triangles. There are some SU extensions for that. But I don’t generally bring those into SU. They look nice (sometimes) but aren’t usually accurate enough for my needs.
(OBJ)
Another reason to resize everything is so that multiple point clouds can be used with the same models.
1 Like
Wasn’t trying to be and tried to make light of it.
Yeah, I saw that after I had posted this one.
Nope, didn’t work. Still trying to figure out why this is still happening.
1 Like
Well hey, if you’re not getting lag with those faces, then don’t worry about it.
I was referring to this:
I would still recommend taking a loot at either MeshLab or Meshmixer, both are free so it doesn’t hurt and while I haven’t looked into SU extensions for face reduction I would assume both are probably a little more efficient at managing faces.
I’m just not comfortable scaling my models or the point cloud. Every process in a workflow has a chance of negatively impacting accuracies & precision, and when I’m dealing with PEs and PLSs, I need to do everything I can to not take that chance. Importing a file and recognizing units should be a pretty elementary part of CAD software, IMO.
As it is mentioned in another thread (ateliernab posted the link above) Scan Essentials reads the unit from the point cloud file.
The default unit in Scan Essentials is in meters. SketchUp templates have no impact on how point clouds are imported.
That being said we will consider adding a scale option as it seems many files are not properly scaled.
Jacques
2 Likes
e57 as a file format is always using coordinate units that are metres - it sounds as if you coordinates have been scaled away from this in cloud compare - or your original data has been recording feet and hasn’t been scaled during processing it to an e57.
This would explain why your 120 “foot” tower is 393feet. 120metres = 393feet.
SE is always expecting e57 in metres as per the specification of the file.
As mentioned in the other thread, LAS files record this differently the unit of the file is recorded in the header. If you are exporting a LAS file, then this needs to be recorded in the file during processing in cloud compare.
2 Likes
Nope, didn’t work. Still trying to figure out why this is still happening.
What is the native format of the clouds you receive?
From what device?
How did you check the header of the LAS file?
Yes, that’s the mesh. I zoomed in a bit for a closer look. I’ve made plenty with Undet that would crush my computer and grind it to a halt. I haven’t used Meshlab but probably ought to take another look… someone just taught me how to reduce triangles using Blender. But I digress… again :^).
I may have used unclear terminology. I did mean to “resize” the model and not “scale” or “rescale” the SU model. So, considering that CloudCompare is a ‘unitless system’, whatever the LAS comes into SU as, those SU units can be changed to match a known length, which in your case is the ~120’ tower height. If you measure the tower and it is say, 623’, in SU, you need to tell SU that it is actually 120’ by resizing. The ~120m or 400’ are red herrings. If the tower measures 120m, resize that to 120’. SU/SE can’t resize the PC so the only option within SU is to resize the SU model. That’s how to ‘scale’/resize it correctly. It won’t be off by any multiple or conversion between units.
If you already have an SU model of the tower or surroundings that you do not want to resize (the ‘ref’ model), you can import the PC into another file, draw a line between the 2 known points that are 120’ apart (e.g., top of tower and base) and whatever that line length is, enter 120’ to resize the model. When you import the SU model that you did not want to resize (the ‘ref’ model), the SU model and PC will match. You should be able to do this with any SU template or modelling unit setting.
Hopefully I cleared up my misuse of the term ‘scaling’.
Blender is such a cool system from what I see others do with it, but it just has too much capabilities for me. I know that sounds odd, but every time I try to learn it more I just get frustrated. I honestly don’t know how people take a single cube and make it into complex objects by stretching and scaling.
Give Meshlab another look. Meshmixer (Autodesk) is also free and runs a little lighter than the former, but both are great tools if you need them for workflows.
I’m still not quite sure I’m reading this right, but I’ll convey what I’m saying from my perspective:
The fact of the matter is that the tower is 120’ ft. It’s not a dimension I’m trying to determine, it’s a dimension I know. But because Scan Essentials apparently only allows for units to be in meters (and my point cloud is apparently “unitless”), it isn’t possible for me to import it how it is and have it be correct in size. So the only object(s) I can change the size of are the drawing entities & objects I create in SketchUp. But I’m not going to model a 400’ ft tower if I know it’s 120’ ft tall in reality. That’s going to mess things up and result in my having to create long winded explanations for anyone that catches on, because they won’t understand the nuances of this workflow.
At the moment the only solution seems to be to scale the point cloud from within the software I’m using for cleanup and classification, and that really bothers me. I’m going to have to scale down the entire point cloud dataset, which is going to put a damper on my confidence of absolute accuracy for sure (this is a georeferenced file).
It’s kind of crazy to me that SU hasn’t implemented a process for this, tbh. Especially if I’m importing a unitless x,y,z dataset, why wouldn’t the imported positioning values adopt the units I specify in the template??
I’m frustrated and will continue to voice those frustrations. I like SU a lot, but this is a big deal for the projects I’m currently working on.
I’ve said this already, but just incase you missed it.
If you know the unit, then that unit needs to be encoded into the file (LAS).
Have you got one of the LAS files to check? a user has offered to check what is being written for you, but you’ve not taken them up on this quality check as of yet.
If you are using e57, then your units HAVE to be metres. There is no arguing with that, it’s in the spec of e57 and SE is respecting that specification.
If you have taken a file not recorded in metres and want to use it as an e57, then you need to adjust the scaling of the points to respect this during your cloud processing- again this is part of the file preparation.
No. I get it. I have to limit the things I get into and Blender is not intuitive to me. The utility that I saw and the help I got made it possible to use the workflow. Tucked a new utility into my pocket.
I’ve installed it and looked at it just a bit. My main hang up is that I don’t like OBJ and FBX that much in SU because they aren’t usually accurate enough… Some of the better importers are paid as well and I need to be a little selective.
Yes. That’s your golden ticket. You are going to tell SU that the tower is 120’ no matter what SU ‘says’ when you import the LAS. You do that by drawing a line (or a box if that’s easier to see) from the base of the tower to the top. The line or box might be 364’ when you draw it. But you don’t care because you know that the tower is 120’. So, using the Tape Measure Tool, you measure the line (and it says whatever number) and you then type in 120’ and press enter. That will resize the SU model (the line). Now your model matches your PC. When you measure the ‘line’ it will now be 120’, which is your tower height.
You may be able to change units in CloudCompare or whatever other software. But basically, if you take your LAS ‘as-is’ from whatever your workflow is, you can tell SU what size it is. I think you’d be over-thinking or doing extra work: just tell SU what size it is.
Yes. I believe that’s the case.
That’s why you ‘tell’ SU that the tower is 120’. If the tower is 120’ and you resize a line that matches the tower to 120’, everything else follows. All of your model entities will be the correct size.
If the model is resized/scaled it will not be some kind of weird situation. If you sent it to me, I’d open it and know everything was correct. Here is a video of the PC, SU model stuff I posted pictures of. You can see that the SU model is accurate as viewed in the HoloLens viewer on site: China Friendship Garden XR - YouTube
I know the model is spot on. I built this using measurements taken from an SU Viewer on site. The survey was resized, the model resized… everything fits together.
I don’t think you have to do that to achieve your goals.
The georeferencing is another matter.
It may be that there are differences between LAS, e57, and other point cloud file types that make automation impossible for every type. But even if it were meters (or whatever unit), you still want to be able to use m, ft, etc., in SU depending on your use case.
The option to match the SU file works.
But is it really - or could it be 119ft or 121ft? I tend to get real life dimensions from the point cloud rather than the other way around. I would find out why your point cloud is wrong rather than trying to fudge it.
Context: I’m speaking with regards to the alternative of it being shown to be 400’ ft because Scan Essentials isn’t’ recognizing the units.
From how I am reading this thread, it appears the original point cloud file was altered by cloud compare such that it’s not importing correctly into SketchUp. Is it not possible to import the original point cloud file into SketchUp or is that not practical? The point I am making is that the point cloud file (in my experience) is the starting point for your model and shouldn’t be messed with. I am always being told by builders, architects etc, that such and such a dimension on a building equals X but the point cloud shows it equals something else and the point cloud is correct. Out of interest - what is the original point cloud format and what was its source.
See the multiple posts above - the solutions are all here for you.
The file is likely the issue or the workflow to create your file.
Not quite. The original point cloud was delivered to me with units in US ft.
Not practical and not a good workflow. The point cloud as it was delivered to me didn’t have the necessary segmentation and/or classification for me to do what I need.
Which is why it surprised me how many people suggested scaling the point cloud dataset (which can’t actually be done in SU). But segmenting and classifying is a standard operating procedure for point cloud data and doesn’t change the dimensional attributes of the data.
So long as the collection was done properly, this is true.
The sensor used was a Phoenix MiniRanger Lite system (UAV) that scanned approximately 175 acres of mixed-use applications, delivered to me in .las format.
The fact of the matter is this issue isn’t being caused by any processing on my end or even the original data collection, but rather it’s just the units of the file: the prime contractor wanted it delivered with USft as units and SU/Scan Essentials doesn’t let you specify what units a point cloud dataset is (which is absurd, IMO). So the only way I can do this is to create a clone of the data and then scale it, all in CloudCompare, so that when imported into SU the units of meters will place the points at the “right” place form a relative accuracy perspective.
It’s a serious disappointment that this limitation of Scan Essentials exists. It’s also just another reason I can not stand how so many people I interact with professionally are infatuated with LiDAR when they never actually work with it to create anything.
The only solution is to scale it in Cloud Compare. There is not solution that exists from within the SketchUp Studio platform. I’m not going to scale my models to be 3.2x larger than they actually are just because Scan Essentials has decided to not deal with units. I’m extremely disappointed that in this day in age the SU or Scan Essentials people decided there was no need to allow users to specify units. I mean…how long has CAD been around???
It doesn’t ignore units - it follows either the instructions from the file or the specification of the file format itself.
E57 is always meters - if you file is scaled incorrectly, then you have to correct it .
LAS files specify the unit of the original coordinates as a header, which SE will also account for.
If this is wrong, then you have to correct it.
If your files are wrong, your results will be wrong, that’s what the issue seems to be.
For SE to have a scaling option is a work around for poor quality data.
Until that day, the best solution is to make your data right in the first instance.
1 Like
I haven’t scaled anything.
The units of the original coordinates are US Feet. I’m not sure how to view or edit a header, but I’m seeing this when viewing the properties of the dataset in ArcGIS Pro.
And I keep saying “I don’t want to scale anything”, yet here we are with people telling me to scale the point cloud.