3D scan utility

[Dragos_Ioan_C_]

How can I eliminate the object/face/body/full constraints, in order to continously scan until sattisfied ?

What is the difference between 3D scan and Scene Perception, apart from the latter lacking the option to map textures and generate manifold objects ?

It seems like 3D scan works much faster (and better) than Scene Perception, although the latter should be more suitable for large scans.

[Xusheng_L_Intel]

3D scan is for object outside and scene perception is for object inside. SP also has textures capability. They are different usage.

[Dragos_Ioan_C_]

David Lu (Intel) wrote:

3D scan is for object outside and scene perception is for object inside. SP also has textures capability. They are different usage.

Hi David, thanks for responding.

How do you activate the texturing capability for SP ? Just copy-paste from the C++/C#/Java for the 3D Scan and rebuild ?

[Xusheng_L_Intel]

Yes, the output .obj already contains color for each vertex. 

[Bradley_F_]

"Full" as exposed in the demo app is the same as "VARIABLE" in the SDK.  Which is the mode you want to just be able to keep scanning within the "area" in a more generic manner.

The "area" is not exposed in the demo app either.  But if you hack it up, you can specify the "area to scan."  Which should help with scanning more arbitrary objects/scenes.

You will also want to expose the "resolution" which is also available in the SDK but not in the demo app.

That's for starters.  I've done these things in my scanning app, as well as exposing a whole lot more.  And it has made the scan module more functional for more generic objects while allowing the nice "texture" and "solid" features to work as intended.

Scene perception providing vertex colors, of course, is not a substitute for texture coordinates and the blended texture you can get out of the scan module.  I don't know of a way to make the scene perception SDK do these things like the scan module does.  So I hope the information I've suggested regarding the scan module is useful to you.

-brad

[Dragos_Ioan_C_]

David Lu (Intel) wrote:

Yes, the output .obj already contains color for each vertex. 

I'm not talking about the vertex color, which relate to the generated point cloud, but to the texture, material file, you name it :) which is usually mapped onto the mesh. Like the 3D Scan utility does.

[Dragos_Ioan_C_]

Bradley F. wrote:

"Full" as exposed in the demo app is the same as "VARIABLE" in the SDK.  Which is the mode you want to just be able to keep scanning within the "area" in a more generic manner.

The "area" is not exposed in the demo app either.  But if you hack it up, you can specify the "area to scan."  Which should help with scanning more arbitrary objects/scenes.

You will also want to expose the "resolution" which is also available in the SDK but not in the demo app.

That's for starters.  I've done these things in my scanning app, as well as exposing a whole lot more.  And it has made the scan module more functional for more generic objects while allowing the nice "texture" and "solid" features to work as intended.

Scene perception providing vertex colors, of course, is not a substitute for texture coordinates and the blended texture you can get out of the scan module.  I don't know of a way to make the scene perception SDK do these things like the scan module does.  So I hope the information I've suggested regarding the scan module is useful to you.

-brad

Cheers for the input Brad, will take a look at the .sln's for the 3D Scan, in order to tweak with the resolution and the area, and possibly eliminate the area constraints.

It seems like the app is implementing some sort of an algorythm in order to detect the edges of a certain object/body/full, which basically stops the processing of adiacent areas while scanning.

At the same time, I think there are some big changes in how 3D scan does the scanning, versus the Scene Perception. 3D scan is much more versatile and fast. Maybe this will change in subsequent releases of the SDK.

[Bradley_F_]

You're not far off.  In order to "scan" the module does seem to need bounds, or a finite area to start.  This is likely a memory matter related to oct-tree or kd-tree structures.  In "object," and "face" modes, it is trying to divine such a bounding volume from the context of what you are scanning.

In object, it's detecting a plane and detecting an object on that plane, and estimating bounds.  Internally, it's setting the "area" based on that detection at the start.  So, the green box is showing you the "estimate."  The estimate is turned into the area when you "start scanning."  In practice, it's pretty bad at it.  It crops too close and doesn't seem to do too good a job of thinking about the mass behind the current view.  And that causes a lot of frustration as you end up not being able to "fit" the object in the view because the mode sets the area too small and clips the object.

In "face," it's using face detection and setting reasonable bounds based on the face it finds.  Which is more functional.  But it really does insist on a face.

In "full" mode, which is really meant to be called "variable," it seems to set a default area.  And that default value may not be ideal for the object you are scanning.  But that's clearly not how its meant to be used, based on the way the SDK is written.  In this mode, you can set the area and resolution yourself.  And that makes for the control you need to scan arbitrary objects where you know what you're scanning, and the SDK can't guess for you.

Even in "variable" mode, when you set an area, that area is the limit.  But at least that area is under your control.  The resolution, is relative to the area.  And therefore you end up balancing scan area, versus resolution, versus memory limits, in practice.