Dear Faro -Expected Behavior

Discuss all FARO SCENE related software issues here.
Post Reply
User avatar
Jfout
I have made 50-60 posts
I have made 50-60 posts
Posts: 55
Joined: Mon Jan 28, 2019 2:11 pm
Full Name: John Fout
Company Details: Russell Construction
Company Position Title: Russell Construction
Country: United States
Linkedin Profile: Yes

Dear Faro -Expected Behavior

Post by Jfout » Wed Mar 13, 2019 11:05 am

Dear Faro
I am ranting about expected behavior because:
A. I assume u want people to buy your software
B. I also assume you want people to keep purchasing your software and not abandon it out of frustration

First. The right click "move and keep position" trick. Is most definitely expected behavior and should not be hidden in the interface. I can't think of one instance where I move a scan or cluster of scans in the tree that I want it's current registration to be shifted in some random manner(which it does consistently) . If I am moving a scan or cluster it's so that it can then be registered against a master cluster or scan. A scan/cluster should only move when the user acts upon it with a registration command.

Second.in manual registration mode one panel should be designated as stationary (keeping its registration) and one should be designated as "moving". Adopting a registration close to the stationary cluster/scan.

Third. Fixed and locked mean something very similar. Both IMO should mean that the registration of this particular cluster or scan should not move in any way. And these should actually work. What is the difference between these two and what is their expected behavior? It seems like it should be obvious as stated above but it never seems to work as expected.

I will end by saying your processing filters and VR experiences are second to none. But the foundation of your software is and has to be ease of registration. Without that you will lose users to other software consistently.
This is my sixth year in scanning. I have been in and out of scene, but the truth is I am definitely tinkering with the idea of going back to a more consistent software(they are out there. I have used them) . Obviously you see that registration is the user's biggest time suck, and reason for blowing budgets, because you are developing on site registration. You might want to fix the current registration methods first in my opinion. The battery drain with on site registration is a huge hurdle unless you have four or five batteries rotating on a charger at all times.
Please fix scenes registration problems. :evil:
John Fout
VDC Manager
Russell

modeling/animation/scanning/drones. the four pillars of life. :ugeek:

User avatar
JohnBunnFARO
I have made 20-30 posts
I have made 20-30 posts
Posts: 27
Joined: Thu Aug 11, 2016 6:18 pm
Full Name: John Bunn
Company Details: FARO
Company Position Title: Account Manager
Country: USA
Linkedin Profile: Yes

Re: Dear Faro -Expected Behavior

Post by JohnBunnFARO » Tue Jun 04, 2019 8:48 am

Jfout wrote:
Wed Mar 13, 2019 11:05 am
Dear Faro
I am ranting about expected behavior because:
A. I assume u want people to buy your software
B. I also assume you want people to keep purchasing your software and not abandon it out of frustration

First. The right click "move and keep position" trick. Is most definitely expected behavior and should not be hidden in the interface. I can't think of one instance where I move a scan or cluster of scans in the tree that I want it's current registration to be shifted in some random manner(which it does consistently) . If I am moving a scan or cluster it's so that it can then be registered against a master cluster or scan. A scan/cluster should only move when the user acts upon it with a registration command.

Second.in manual registration mode one panel should be designated as stationary (keeping its registration) and one should be designated as "moving". Adopting a registration close to the stationary cluster/scan.

Third. Fixed and locked mean something very similar. Both IMO should mean that the registration of this particular cluster or scan should not move in any way. And these should actually work. What is the difference between these two and what is their expected behavior? It seems like it should be obvious as stated above but it never seems to work as expected.

I will end by saying your processing filters and VR experiences are second to none. But the foundation of your software is and has to be ease of registration. Without that you will lose users to other software consistently.
This is my sixth year in scanning. I have been in and out of scene, but the truth is I am definitely tinkering with the idea of going back to a more consistent software(they are out there. I have used them) . Obviously you see that registration is the user's biggest time suck, and reason for blowing budgets, because you are developing on site registration. You might want to fix the current registration methods first in my opinion. The battery drain with on site registration is a huge hurdle unless you have four or five batteries rotating on a charger at all times.
Please fix scenes registration problems. :evil:
Hi John,

First, let me say that I have a lot of respect for your opinions and experience level; both with our solutions and others. It is immediately evident that you know what you are talking about, and you are definitely the type of person who spends time investigating issues before addressing them. So for that, let me say thank you and tip my hat.

SCENE's problem isn't really functionality. The core issue is simply educating our customers on that functionality. There are very specific ways to get SCENE to do exactly what you want, however, we have not done the greatest job making this evident to our users. This is the exact reason why I have been creating in-depth tutorial videos for SCENE lately.

I will try to address each issue, and feel free to contact me directly with any further questions/comments.

Right-click > Move Scans Keep Position This is definitely expected behavior, as you pointed out. This functionality was essentially taken over by the (non-documented) change to our Clusters. The easiest way to explain it is to simply make sure you are moving Clusters instead of individual Scans. We do this on purpose, even though we didn't explain our reasoning for the change. Basically, we wanted to ensure that everything is moved with a local ScanManager to govern that group of files. Here is an example of the correct and incorrect way to align new scans to an existing project. The only difference is having the new scans in a nested Cluster. One of the biggest advantages of doing it this way is it gives the user more control on which scans/clusters are given which priorities.
clusteryesno.jpg
Manual Registration with Reference Scans This actually abides by the same rules I mentioned above, so you can definitely see why I say we needed to do a better job of educating our customers on changes in the functionality. With Manual Registration, you want to have a Reference Cluster and a Reference Scan that doesn't move. You then choose that scan for the first scan, and you choose the "adapting scan" for the second scan. All you have to do is make sure that second scan isn't from within that same cluster during the time of Manual Registration. The reason we use this new Clustering priority in Manual Registration is the same as stated above, but also to allow users to register entire clusters together by simply matching 1 scan from each cluster. By the way, if you wish to change which scan is being used as the "anchor scan" at any point, you can right-click > Scan Properties and make sure Reference Scan is checked in the Scan tab.
manRegRefScan.PNG
Fixed vs Locked Trust me, I feel your pain on this one. I have been saying for a while that Scan Fixed is the dumbest thing about SCENE. Allow me to simplify this for you : NEVER USE SCAN FIXED! This essentially is the same thing as Freezing a layer in AutoCAD. Not only does it lock the scan in place, but it also makes it a non-factor with registration. It literally removes the scan from the calculations altogether. If you want to keep a scan in place while also using it as an "Anchor scan", you want to use the option for Reference Scan. When you say Locked, I am assuming you are referring to Locked Scan Managers. This is very important, and one of the most essential ways to control registrations. This Locking works hand-in-hand with the Clustering changes. You want to have Scan Managers locked for all clusters that have been "locally registered". By this, I mean those scans in that cluster are registered correctly to themselves.

I hope this helps, and again, feel free to contact me directly with any questions/comments. And thank you for your business and continued support!
You do not have the required permissions to view the files attached to this post.
Half Nerd, Half Amazing

surveypm
I have made 40-50 posts
I have made 40-50 posts
Posts: 44
Joined: Mon May 18, 2015 5:31 pm
Full Name: Tom Elbich
Company Details: Solid Ventures Inc
Company Position Title: President
Country: USA
Linkedin Profile: Yes
Location: Dallas, PA
Contact:

Re: Dear Faro -Expected Behavior

Post by surveypm » Tue Jun 04, 2019 12:48 pm

John,
Please share where your more in-depth tutorials might be. Faro creates extremely technically detailed manuals but they do lack explanation of what will happen when certain features are used. I often find those instances on this forum from other users.

Besides SCENE I have As-Built and any tutorials don’t seem to keep up with the most released version of the software so some features aren’t covered well. And again the manuals, while technical, often don’t explain operations like the examples you show here. Faro’s knowledge base could be better in my opinion.

However, thanks for the explanation to this post.

User avatar
msivil
I have made 60-70 posts
I have made 60-70 posts
Posts: 61
Joined: Tue Oct 19, 2010 10:12 am
Full Name: Marko Sivil
Company Details: Sivil 3d Oy
Company Position Title: CEO
Country: Finland
Linkedin Profile: Yes
Contact:

Re: Dear Faro -Expected Behavior

Post by msivil » Tue Jun 04, 2019 2:01 pm

"If you want to keep a scan in place while also using it as an "Anchor scan", you want to use the option for Reference Scan."

Could also be useful, if it would be possible to define more than just one scan as a reference scan(?)
Best Regards,
Marko Sivil

www.sivil3d.fi

jedfrechette
V.I.P Member
V.I.P Member
Posts: 846
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: Dear Faro -Expected Behavior

Post by jedfrechette » Tue Jun 04, 2019 9:06 pm

msivil wrote:
Tue Jun 04, 2019 2:01 pm
"If you want to keep a scan in place while also using it as an "Anchor scan", you want to use the option for Reference Scan."

Could also be useful, if it would be possible to define more than just one scan as a reference scan(?)
Exactly, the problem is that Scene confounds 3 orthogonal variables:
  • This Scan should not move.
  • This Scan should be considered for registration.
  • This group of scans should not move relative to each other.
In order to have an adequate amount of control over registration without jumping through hoops you need to be able to control all 3 of those independently. Because you can't control those variables independently in Scene, the workflows for moderately complicated registrations get convoluted very quickly.
Jed

jedfrechette
V.I.P Member
V.I.P Member
Posts: 846
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: Dear Faro -Expected Behavior

Post by jedfrechette » Tue Jun 04, 2019 9:09 pm

JohnBunnFARO wrote:
Tue Jun 04, 2019 8:48 am
Here is an example of the correct and incorrect way to align new scans to an existing project. The only difference is having the new scans in a nested Cluster. One of the biggest advantages of doing it this way is it gives the user more control on which scans/clusters are given which priorities.
What if I want to do a bundle adjustment of the new scans to the old scans individually rather than as a group?
Jed

Scott
V.I.P Member
V.I.P Member
Posts: 762
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
Location: Berkeley, CA USA
Contact:

Re: Dear Faro -Expected Behavior

Post by Scott » Tue Jun 04, 2019 9:14 pm

jedfrechette wrote:
Tue Jun 04, 2019 9:09 pm
JohnBunnFARO wrote:
Tue Jun 04, 2019 8:48 am
Here is an example of the correct and incorrect way to align new scans to an existing project. The only difference is having the new scans in a nested Cluster. One of the biggest advantages of doing it this way is it gives the user more control on which scans/clusters are given which priorities.
What if I want to do a bundle adjustment of the new scans to the old scans individually rather than as a group?
+1

User avatar
JohnBunnFARO
I have made 20-30 posts
I have made 20-30 posts
Posts: 27
Joined: Thu Aug 11, 2016 6:18 pm
Full Name: John Bunn
Company Details: FARO
Company Position Title: Account Manager
Country: USA
Linkedin Profile: Yes

Re: Dear Faro -Expected Behavior

Post by JohnBunnFARO » Thu Jun 06, 2019 6:19 am

surveypm wrote:
Tue Jun 04, 2019 12:48 pm
John,
Please share where your more in-depth tutorials might be. Faro creates extremely technically detailed manuals but they do lack explanation of what will happen when certain features are used. I often find those instances on this forum from other users.

Besides SCENE I have As-Built and any tutorials don’t seem to keep up with the most released version of the software so some features aren’t covered well. And again the manuals, while technical, often don’t explain operations like the examples you show here. Faro’s knowledge base could be better in my opinion.

However, thanks for the explanation to this post.
Your experience is definitely from our old method of support material. We all internally made the same complaints as you, and the good news is we actually made something great as a result!

Our Insights center is incredible, and our new knowledgebase is as good as any company's I have ever seen.
Here is the one for As-Built AutoCAD https://knowledge.faro.com/Software/As- ... D_Software

Make sure to scroll down and go to the Directory tab.
asbuiltDir.PNG
You do not have the required permissions to view the files attached to this post.
Half Nerd, Half Amazing

User avatar
JohnBunnFARO
I have made 20-30 posts
I have made 20-30 posts
Posts: 27
Joined: Thu Aug 11, 2016 6:18 pm
Full Name: John Bunn
Company Details: FARO
Company Position Title: Account Manager
Country: USA
Linkedin Profile: Yes

Re: Dear Faro -Expected Behavior

Post by JohnBunnFARO » Thu Jun 06, 2019 6:28 am

msivil wrote:
Tue Jun 04, 2019 2:01 pm
"If you want to keep a scan in place while also using it as an "Anchor scan", you want to use the option for Reference Scan."

Could also be useful, if it would be possible to define more than just one scan as a reference scan(?)
You can. You have reference scans and reference clusters.
jedfrechette wrote:
Tue Jun 04, 2019 9:06 pm
msivil wrote:
Tue Jun 04, 2019 2:01 pm
"If you want to keep a scan in place while also using it as an "Anchor scan", you want to use the option for Reference Scan."

Could also be useful, if it would be possible to define more than just one scan as a reference scan(?)
Exactly, the problem is that Scene confounds 3 orthogonal variables:
  • This Scan should not move.
  • This Scan should be considered for registration.
  • This group of scans should not move relative to each other.
In order to have an adequate amount of control over registration without jumping through hoops you need to be able to control all 3 of those independently. Because you can't control those variables independently in Scene, the workflows for moderately complicated registrations get convoluted very quickly.
You can easily do all of this in SCENE...because of the new Clustering system. That was what I was trying to explain in my earlier post. They didn't educate our customers on it, but it IS a huge upgrade to our previous functionality.
  • Reference Scan
  • Always considered unless set to Fixed Scan
  • Locked ScanManager of a Cluster

    Here is an example of a walkthrough video I made to demonstrate all 3 of those points :
    FAROFlows021319.png
    jedfrechette wrote:
    Tue Jun 04, 2019 9:09 pm
    JohnBunnFARO wrote:
    Tue Jun 04, 2019 8:48 am
    Here is an example of the correct and incorrect way to align new scans to an existing project. The only difference is having the new scans in a nested Cluster. One of the biggest advantages of doing it this way is it gives the user more control on which scans/clusters are given which priorities.
    What if I want to do a bundle adjustment of the new scans to the old scans individually rather than as a group?
    I am loving your questions, because it is validating our new system!

    To do what you are asking, simply unlock the ScanManager for the Cluster of the scans you want to adjust individually. Locking a Cluster's ScanManager makes those scans not move relative to each other. Unlocking it allows them to move independently.
You do not have the required permissions to view the files attached to this post.
Half Nerd, Half Amazing

User avatar
msivil
I have made 60-70 posts
I have made 60-70 posts
Posts: 61
Joined: Tue Oct 19, 2010 10:12 am
Full Name: Marko Sivil
Company Details: Sivil 3d Oy
Company Position Title: CEO
Country: Finland
Linkedin Profile: Yes
Contact:

Re: Dear Faro -Expected Behavior

Post by msivil » Thu Jun 06, 2019 10:04 am

"You can. You have reference scans and reference clusters."

How? Please see image.
You do not have the required permissions to view the files attached to this post.
Best Regards,
Marko Sivil

www.sivil3d.fi

Post Reply

Return to “FARO SCENE”