I might be in a very specific situation, hopefully some of you can provide me with some guidance.
I am using a 8 Kinect setup with Depthkit Studio 0.7.0 pre-release.
I calibrated the setup and got fair results, I know my Kinects are far away thus limiting the quality of both calibration and capture, but that’s a trade off we are ready to make in order to allow us for a larger capture space.
Here’s a screenshot of the calibration results.
We’ve been shooting all morning and in Depthkit everything’s great. Captures are what we expect and the fusion preview is fine. However, once exported in CPP Video and imported in Unity I get a lot of meshing issues. The problem is present on two different exports I tried on two different recordings. Watch this video for a comparative view of Depthkit and Unity results. https://youtu.be/CAJU4GKf9YY
It feels like the exported version omits some parts of the camera even though it’s still inside the bounding box.
I also ran into and issue with the bounding box. I did set the values too high, trying to include more space to see if the export would do the same bug with the whole space. Now I’m unable to open this particular recording because it overloads GPU memory by trying to allocate 20gbs+ in VRAM. Is there a way to reset to the default bounding box?
Thanks for your post, and congrats on being the first to find bugs in the 0.7.0 pre-release!
It does look like you’ve encountered a bug with the larger volume - its a scenario we have not yet tested as thoroughly. With your blessing, I will send you an email to start a process of gathering the project file from you so we can reproduce it on our side.
With regards to your project overloading your GPU, we will look to put a fix in for this. IN the meantime, you can reset your project settings in the json project file as a hack.
- Close Depthkit
- Go into your Depthkit project folder
- make a back up of your dkproject.json
- Open the dkroject.json in a text editor
- Find the “fusedMeshConfig” entire for your capture.
- Change the max/min bounds to be smaller
- And/or change the Mesh Density to be lower
- Reopen Depthkit and reload the Recording
Let us know how this goes as a quick fix!
Think we encountered a similar issue using the 0.7.0 pre-release where what looked like perfectly fine captures in Depthkit exported with cropped CPP video files which meant that in Unity the meshes are reconstructed badly.
We also found a bug that meant every time I opened the TAKE to view it in Depthkit it would crash. From memory - I think this was because I’d set the export bitrate very high, I think I fixed it by opening a different take, reducing the export bitrate, then opening the take and it stopped crashing then.
Is this bug evident in Image Sequences as well as the CPP videos?? Could we get around it by exporting images and recompressing those into a video?
Hi @Psicon_Lab -
We’ve fixed the cropped CPP bug in the production release, which is very close to release. Let me know if this is holding you up and we can send you an updated Pre-release build with a fix for this issue. We’re still smashing a few new bugs in the release which has caused the delay.
Regarding the crashing - I could be wrong, but it’s not likely to be due to changing the bitrate setting because that isn’t used until export time. Crashes in Editor in the 0.7.0 Pre-release that we have seen have either been out of date drivers, or the Mesh Density/Volume Bounds being too large. We’ve fixed both if these issues in the upcoming release.
Thanks for the bug reports!
Hi James, thanks for the response! May be helpful, depending on when the release is coming out, but we can probably wait - we’ve finished our week at Nottingham so don’t necessarily have access to the files again until we return at a later date.
Could be you’re right - may have been the mesh density, can’t quite remember now. I solved it by looking at a different clip, reducing the value, then returning to the first and was able to play the clip again.
I did manage a 100% configuration using your new video as a guide which was great, so thanks for that, as I’d been struggling a bit before to get precision captures.