You basically create an appropriately sized array of shorts that the method populates with the volume’s voxel data. They very kindly went ahead and implemented a new API named ExportVolumeBlock(), which provided more direct access to the volume’s low-level data. This “point cloud generation” is then (hopefully) happening multiple times a second as we execute our jig before we then perform a more detailed query of the volume’s data to generate the final, full-colour point cloud.īack when I first started working with Kinect Fusion, I identified this need to pass via a mesh object as a potential issue and raised it with the Kinect for Windows team. The reason for doing this is simple: AutoCAD is not architected to deal with huge, dynamically generated meshes (we have other products such as Maya and now Project Memento that are much better at this), so it’s a deliberate choice to just take the points.
This has always felt like a bit of a longwinded way of doing things, as we’re throwing away a bunch of data – we’re only using the vertices, not the triangles – but that’s what I was able to get working.
I haven’t been very happy with the approach I’ve so far taken to do this: I’ve been asking the Kinect Fusion runtime to calculate a mesh for a reconstruction volume and have then used its vertices to get point (XYZ) – and now colour (RGB) – data. With 3D systems such as AutoCAD, though, you really want to take the 3D data directly and integrate it into your 3D scene in some way, such as via a jig. The primary benefit of this approach is its low latency: it all happens very quickly and the only data you need to move from the runtime into your app is the bitmap itself. Something you realise quite early on when working with the Kinect Fusion component in the Microsoft Kinect SDK is that it’s really meant to integrate into a 2D UI: it takes care of rendering the volume that’s being mapped, and you simply have to integrate the generated bitmap somewhere into your app’s UI.
0 kommentar(er)
