Computer for Cyclone

Discuss all Cyclone related issues here.
winslowkr
I have made 30-40 posts
I have made 30-40 posts
Posts: 30
Joined: Tue Oct 30, 2018 7:39 pm
Full Name: Kevin Winslow
Company Details: Olsson
Company Position Title: Surveying-Reality Capture-107 UAV Pilot
Country: United States
Linkedin Profile: No

Re: Computer for Cyclone

Post by winslowkr » Wed Feb 13, 2019 7:51 pm

James Hall wrote:
Sat Dec 08, 2018 12:32 pm
The last time I checked "-Exporting the edited point cloud to PTS" used only one core.

James
Should I be exporting in the different/more effective file type that can better use multi-core processors? I only have used PTS because that the way I was trained.
Kevin Winslow
Surveying/Reality Capture/UAV Pilot
Olsson

Graham
V.I.P Member
V.I.P Member
Posts: 151
Joined: Mon Apr 27, 2009 3:38 pm
Full Name: GrahamM
Company Details: AVEVA
Company Position Title: Software Engineer

Re: Computer for Cyclone

Post by Graham » Thu Feb 14, 2019 10:11 am

Should I be exporting in the different/more effective file type that can better use multi-core processors? I only have used PTS because that the way I was trained.
As a developer of software that consumes data exported from Cyclone the short answer anything is better than PTS.

That does not answer you question as to best use of a multi-core processor.

winslowkr
I have made 30-40 posts
I have made 30-40 posts
Posts: 30
Joined: Tue Oct 30, 2018 7:39 pm
Full Name: Kevin Winslow
Company Details: Olsson
Company Position Title: Surveying-Reality Capture-107 UAV Pilot
Country: United States
Linkedin Profile: No

Re: Computer for Cyclone

Post by winslowkr » Thu Feb 14, 2019 1:18 pm

Graham wrote:
Thu Feb 14, 2019 10:11 am
Should I be exporting in the different/more effective file type that can better use multi-core processors? I only have used PTS because that the way I was trained.
As a developer of software that consumes data exported from Cyclone the short answer anything is better than PTS.

That does not answer you question as to best use of a multi-core processor.
What do you like best?
Kevin Winslow
Surveying/Reality Capture/UAV Pilot
Olsson

User avatar
smacl
V.I.P Member
V.I.P Member
Posts: 155
Joined: Tue Jan 25, 2011 5:12 pm
Full Name: Shane MacLaughlin
Company Details: Atlas Computers Ltd
Company Position Title: Managing Director
Country: Ireland
Linkedin Profile: Yes
Location: Ireland
Contact:

Re: Computer for Cyclone

Post by smacl » Thu Feb 14, 2019 1:53 pm

Graham wrote:
Thu Feb 14, 2019 10:11 am
Should I be exporting in the different/more effective file type that can better use multi-core processors? I only have used PTS because that the way I was trained.
As a developer of software that consumes data exported from Cyclone the short answer anything is better than PTS.

That does not answer you question as to best use of a multi-core processor.
Also a software developer working with large point cloud data, in order of preference I'd go for E57, LAS, LAZ, PTS but these are all very workable options. PTS is slow to write but can be fast to read given you''re not reliant on a 3rd party SDK and the format is simple enough that it is easy to multi-thread the input. E57 is potentially the strongest as it can include embedded photography and other data, LAZ is currently the most compact which is becoming increasingly important.

User avatar
gsisman
V.I.P Member
V.I.P Member
Posts: 209
Joined: Fri Oct 07, 2016 1:51 pm
Full Name: Steve Long
Company Details: Montgomery County DOT _ MD
Company Position Title: Land Survey Supervisor
Country: United States
Skype Name: gsisman1
Linkedin Profile: Yes

Re: Computer for Cyclone

Post by gsisman » Thu Feb 14, 2019 1:58 pm

Rikore wrote:
Tue Dec 11, 2018 9:26 pm
Our desktops are Z840's with Windows Pro 10.
Intel(R) Xeon(R) CPU E5-2697v4 @ 2.30 GHZ 2 processors total.
Ram at 256 but can do 512.
64 Bit
6 1TB drives with 4 of them SSD's
High speed USB's

Laptops are Z Books 17G3" with Windows Pro 10.
Intel(R) Xeon(R) CUP E3-1535Mv5 @ 2.90GHZ.
Ram at 64
4 1TB drives with 2 of them SSD's.
High speed USB's
Docking system with Benq monitors PD series 32".
Also have LG OLEG 65" 4K monitor glass.

No problems with Cyclone and I have several projects near 2TB's and one that will be close to 3TB's when done.
Processed 2TB scan to TruView Enterprise with no issues and within 6 hours on the laptop.
We use 8TB Seagates for storage and have several 1TB SSD externals.
Don't work off networks as too slow.
Has anyone out there investigated working with Cyclone or Register 360 in a Virtual Workstation environment with GRID Graphics card/s? I know that Register 360 has been touted as not capable of work in a virtual environment. (Actually it can't even handle working effectively on the same database on a network drive by different users on different machines at different times-unless you do major gymnastics with the C:\ProgramData\Leica Geosystems\Cyclone REGISTER 360\ServerDb.db files).
I know the Enterprise version of Cyclone can. And Leica's Infinity Products (and former LGO products) could just Re-Register an existing Project-similar to Cyclone)
This is probably a high-end solution, but wondering if some bigger organizations have looked into this. We had earlier looked at this or our Autodesk Production environment as we have many users. The number of Point Cloud users and processors is minimal now but will be growing as more of our departments adopt this "Big Data'" comprehensive work flow.

jedfrechette
V.I.P Member
V.I.P Member
Posts: 825
Joined: Mon Jan 04, 2010 7:51 pm
Full Name: Jed Frechette
Company Details: Lidar Guys
Company Position Title: CEO and Lidar Supervisor
Country: USA
Linkedin Profile: Yes
Location: Albuquerque, NM
Contact:

Re: Computer for Cyclone

Post by jedfrechette » Thu Feb 14, 2019 5:54 pm

smacl wrote:
Thu Feb 14, 2019 1:53 pm
Also a software developer working with large point cloud data, in order of preference I'd go for E57, LAS, LAZ, PTS but these are all very workable options.
...clip...
E57 is potentially the strongest as it can include embedded photography and other data.
One of the things that has started to worry me about E57 is that although most software seems to have basic support for it at this point, there doesn't seem to be much interest from software vendors in actually moving it forward to meet the developing needs of users (compression, spatial index?). Instead everybody seems happy to push their own proprietary formats that don't offer any interoperability between vendors.

Meanwhile, the official reference implementation is looking more and more like abandonware every day. The website get's updated occasionally, but the actual code hasn't been touched in more than 4 years and there hasn't been a release in 6 years. Hell, the CloudCompare developers finally just forked it. I guess this comment probably says a lot about why the reference implementation is slowly dying.

Ultimately, I guess it's the fault of us users as we continue to accept the status quo. God, I hate pushing around giant text files though.
Jed

User avatar
smacl
V.I.P Member
V.I.P Member
Posts: 155
Joined: Tue Jan 25, 2011 5:12 pm
Full Name: Shane MacLaughlin
Company Details: Atlas Computers Ltd
Company Position Title: Managing Director
Country: Ireland
Linkedin Profile: Yes
Location: Ireland
Contact:

Re: Computer for Cyclone

Post by smacl » Thu Feb 14, 2019 6:52 pm

jedfrechette wrote:
Thu Feb 14, 2019 5:54 pm
smacl wrote:
Thu Feb 14, 2019 1:53 pm
Also a software developer working with large point cloud data, in order of preference I'd go for E57, LAS, LAZ, PTS but these are all very workable options.
...clip...
E57 is potentially the strongest as it can include embedded photography and other data.
One of the things that has started to worry me about E57 is that although most software seems to have basic support for it at this point, there doesn't seem to be much interest from software vendors in actually moving it forward to meet the developing needs of users (compression, spatial index?). Instead everybody seems happy to push their own proprietary formats that don't offer any interoperability between vendors.

Meanwhile, the official reference implementation is looking more and more like abandonware every day. The website get's updated occasionally, but the actual code hasn't been touched in more than 4 years and there hasn't been a release in 6 years. Hell, the CloudCompare developers finally just forked it. I guess this comment probably says a lot about why the reference implementation is slowly dying.

Ultimately, I guess it's the fault of us users as we continue to accept the status quo. God, I hate pushing around giant text files though.
It is a good comment, I've played around with the E57 reference code myself and made a few optimizations but it isn't the easiest in the world to work with. For those of us not up to speed on quaternion maths, there was a bit of light reading to do and plenty of head scratching ;) I was in conversation with Gene Roe on the subject a couple of months ago and he was talking about some more work and enhancements being carried out on the code base. Outside of imaging, where E57 scores very strongly over LAS and PTS is that it stores set-up information so it is possible to correct registration errors and select by setup, which is very important for a laser scanning transfer format. I had a look at one of the E57 forks recently (probably Cloudcompare but not sure), and while it made things simpler it also dropped image support which is also becoming increasingly important. Spatially linked imaging is probably the easiest mechanism to leverage machine learning tools on a point cloud and this is a valuable technology that is rapidly becoming ubiquitous.

I think it is important to differentiate between an efficient transfer format and a good storage format, as the latter may be quite a bit more involved using the likes of multi-resolution octrees to keep the data fast as well as compact.

This should probably be the subject of another thread, but I'm strongly of the opinion that the industry needs robust, efficient, open data exchange standards and we should not be constrained by closed source SDKs and unfavorable licenses for a multitude of propitiatory formats from instrument manufacturers. The reason I favor E57 and LAS is that they're already widely adopted so enhancing what already works rather than coming up with something entirely new keeps everyone in the loop.

Scott
V.I.P Member
V.I.P Member
Posts: 725
Joined: Tue Mar 29, 2011 7:39 pm
Full Name: Scott Page
Company Details: Scott Page Design- Architectural service
Company Position Title: Owner
Country: USA
Linkedin Profile: No
Contact:

Re: Computer for Cyclone

Post by Scott » Thu Feb 14, 2019 8:02 pm

+1: a good thread and comments, especially from Jeff and Shane!

jedfrechette
V.I.P Member
V.I.P Member
Posts: 825
Joined: Mon Jan 04, 2010 7:51 pm
Full Name: Jed Frechette
Company Details: Lidar Guys
Company Position Title: CEO and Lidar Supervisor
Country: USA
Linkedin Profile: Yes
Location: Albuquerque, NM
Contact:

Re: Computer for Cyclone

Post by jedfrechette » Thu Feb 14, 2019 8:30 pm

smacl wrote:
Thu Feb 14, 2019 6:52 pm
This should probably be the subject of another thread
True, and I pretty much agree with everything else you said in that post too. There's no need to belabor the point, but I really hope that in a couple of years we don't find ourselves right back where we were a decade ago due to neglect of the commons. The cynic in me thinks that is exactly what the big vendors would like to see. Users and independent developers like yourself benefit a great deal from open data formats. Incumbent players such as Leica, Faro, and Autodesk; not so much.
Jed

Post Reply

Return to “Leica Cyclone”