Next up: Trial and error.

So, there will be a process involved here, its not quite clear what that is yet, but would follow certain required work flow:

Scan Item

Clean item

Export Item

Import Item

Use Item

After performing an initial scan, I realized a couple things.

First, manually moving the kinect sensor around an object of relative large size is awkward.

The cables are long enough for my needs, but they do drag along the floor and can be a tripping hazard. Ideally, at some point, we'd setup a platform for scanning, and remove manual manipulation and error input ;).

Taking is slow and steady, I have a scan! Though, my scan is ugly, really ugly.

First thing I noticed was, in my garage..., the lighting condition isnt that well... This cuases defects and deformities in the 3d model.

Ill be making a trip to lowes and will  try to improve this tomorrow.

Second, my deformed model, not only picked up my object of interest, but it also picked up a lot of noise.

It's important to remove this extra data, which can bloat the 3d models quick!

The internet has suggested different 3d tools, currently I am looking at freely available options...

meshlab seemed promising in the past, but I suspect my current model has too much data, and it just cant handle my needs.

netflab free version is asking for a licence again, so I am not interested in messing with that...

I am actually considering writing a utility that can clean these models up... in fact, I most likely will later in the process, after this POC is further along.

But, for now, I actually found Autodesk's meshmixer somewhat helpfull.

It too freezes up a lot, but so far, if I am nice* to it, it has provided some pleasing results.

The plane splitting option is great.

Also, the mirror utility can prove to be helpful: http://www.meshmixer.com/download.html

Though, as we speak I just tried doing something,in fact I forget what I was doing, mostly becuase meshmixer has been frozen for a little while now...

Anyway, I also suggest looking into the hollow function, it seems? to be able to fill holes, which is a big problem with kinect data...

OH YEA, I was trying to fill holes... I think.

Good day ladies and gentlemen.

So, after being away for the early part of the year, I am back and ready to tackle this project and any issues that may arise.. one at  a time.

Alright, so after starting up any of the sample apps that require displaying a picture to screen using directx2d(c++) I ran into the issue of not seeing my sensor data(image).

Ok, my first thought was that, my wife put a virus on the computer, from all the Asian web sites she visits ;).

But no, maybe, we will move on from that... Next I tried reinstalling the sdk and drivers from microsoft for the kinect.
Then, I reran, from the sdk browser, the samples, noticing, only the wpf samples showed me images...


After more tinkering, I realized the sensor was actually grabbing data from the c++ samples, the problem, was that, it just wasn't drawing* to screen; I Determined this via, one of the sample apps that allow you to take a screen shot. So, since my  screen shots, looked fined, I moved on and focused on the directx2d code within the c++ samples.

What I found was enlightening...


So, browsing msdn, I found sample directx code. Using that as a template, I started plugging in initialization parameters...
One such parameter was the size input:
            hr = m_pD2DFactory->CreateHwndRenderTarget(
            rtProps,
            D2D1::HwndRenderTargetProperties(m_hWnd, size/*D2D1::SizeU(
rc.right - rc.left,
rc.bottom - rc.top)*/),
            &m_pRenderTarget

Above, you can see that the second parameter for HwndRenderTargetProperties, takes in a size. This size was being maxed to the screen resolution.

So, out of curiosity, I then replaced this size with a customized value of:

                RECT rc;
GetClientRect(m_hWnd, &rc);


Using this commented out code above**, this actually passed in a different size to the app.
This size, smaller, was actually the size of the app window. Though being smaller, it worked!
Well kinda, with this window size I was able to see a percentage of the sensor data, so not my full view; I saw my full view, when I took a screen shot, using the sample app, or using the graphics debugger from within visual studio, and grabbing a frame; therefore my kinect sensor had more data available.

Knowing this, I started to think would cause this??? Well, looking into the size parameter more, I noticed its related to the size in pixels. And when you consider pixels, you need to consider the screen dpi.

Then I started googling, how to check windows desktop dpi...

When I did this, I found that at some point, in between last using the kinect(3 months ago???) I must have changed my dpi...

See this page on how to change back: http://www.tenforums.com/tutorials/5990-dpi-scaling-level-displays-change-windows-10-a.html

So in short, if your having issues, where your sensor is grabbing good data, but directx will not draw that data, it could be related to your dpi setting.

Personally, I had mine set to 130 %, after changing back 100%, and logging out and back in, this resolved my data resolution issue.


COOL, so now I have to determine if I can improve performance, increase data collection, offline processing? and prevent api exceptions; api returned a result: 0x80004005


Until next time, have fun!