Forum Replies Created
-
Posts
-
Hi @jdbaker500 this forum isn’t super active so you have to be a little patient sometimes to get a response. If you check the first post you’ll find an updated versions of the AR Sandbox suite. The site you linked to didn’t work for as it looks like a private subnet at UC Davis.
I think this is the public facing version of the same thing: https://web.cs.ucdavis.edu/~okreylos/ResDev/SARndbox/
That site still has the older installation instructions but a lot of it still relevant and worth a read through to get the most out of the software.
The videos are not totally obsolete but there have been some changes with the updates so that may be why the descriptions say that.
This forum isn’t super active but if you’re patient there’s a few enthusiasts of us who check in once in awhile including the author of the software to answer questions and provide some support.
Thank you @okreylos !
I’ll delete my forum thread about it so it doesn’t cause any confusion in the future.
I was concerned that the data being passed to the rest of the KinectUtil program to create the Intrinsic parameters file wouldn’t be correct since the handling of that data had changed so I asked it to check and this is what it told me.
After analyzing both Camera.cpp files, I can confirm the differences in the expected number of bytes to read for the calibration parameters:
In the original version (../../../src/PullPackage/Camera.cpp):
calibrationParameterReplySizes[0] = 126
calibrationParameterReplySizes[1] = 16
calibrationParameterReplySizes[2] = 12
calibrationParameterReplySizes[3] = 330 or 342 (depending on the Kinect model)
In the Kinect-4.1 version (../../../src/PullPackage/Kinect-4.1/Kinect/Camera.cpp):The expected sizes are exactly the same as the original version.
The key difference is not in the expected sizes, but in how the reading is handled:The original version reads the entire expected size for each subset without any additional checks.
The Kinect-4.1 version introduces a new read function that takes a bytesToRead parameter, allowing it to handle cases where the actual received data might be less than expected. It checks the number of bytes read against the bytesToRead parameter, ensuring that it doesn’t read beyond the actual data size.
This change in the Kinect-4.1 version makes the code more robust when dealing with potentially incomplete or corrupted data, but it doesn’t change the expected number of bytes to read. Both versions expect to read the same amount of data; the Kinect-4.1 version just handles potential discrepancies more gracefully.
Here is a summary the differences between the original Camera.cpp and the new modified one. It should explain a little more succinctly and technically than my previous reply.
In the original version (../../../src/PullPackage/Camera.cpp), there are two read functions:
void read(int subsection, IO::File& file) void read(IO::File& file)In the Kinect-4.1 version (../../../src/PullPackage/Kinect-4.1/Kinect/Camera.cpp), there are three read functions:
void read(int subsection, IO::File& file, size_t bytesToRead) void read(int subsection, IO::File& file) void read(IO::File& file)The new overload in the Kinect-4.1 version
(read(int subsection, IO::File& file, size_t bytesToRead))allows for more controlled reading of calibration data. It checks the number of bytes read against the bytesToRead parameter, ensuring that it doesn’t read beyond the intended data size. This can prevent buffer overruns and makes the function more robust when dealing with potentially incomplete or corrupted data.This change reflects an improvement in error handling and data safety in the newer Kinect-4.1 version of the code.
Without seeing the error you’re getting its hard to know whats going on. Have you tried running the ‘KinectUtil getCalib -0’ to get a new intrinsic parameters file for the newer Kinect?
I’ve used a BenQ MW632ST for years and its been very reliable. You can buy them used on Ebay for cheap but I’m not sure if it’s what you need without knowing more about your project. What projector you should choose is really dependant the design of your sandbox structure.
Do you have a link to your sandbox build?
I wrote a post how I think I may have fixed the KinectUtil getCalib 0 function not writing the intrinsic parameters file. I rewrote part of the Camera.cpp file and recompiled it and it seems to be working now. You can read more on my thread here
I wrote a reply explaining how I got to this solution but the forum won’t let me reply so I put the text in a pastebin link for anyone that’s interested.
https://web.cs.ucdavis.edu/~okreylos/ResDev/SARndbox/
Has all the instructions for you to calibrate your Sandbox.So I’ve just had a little refresh looking at the program again and I am wondering if you tweaked your program startup script if it may help.
if you type
/usr/local/bin/SARndbox -hin your terminal you get quite a bit of options.There is one in there that may help you.
-wts <water grid width> <water grid height> Sets the width and height of the water flow simulation grid Default: 640 480My best guess, and it’s truly just a shot in the dark, is that you may want to changing this setting to a resolution that matches the resolution you are running the program at.
So you could try running the program with a command like this
/usr/local/bin/SARndbox -fpv -uhm -wts 1024 768I really hope this helps!
I just wanted to add my config file that I use with a simple arcade button USB Adaptor combo.
section Vrui section Desktop section MouseAdapter mouseIdleTimeout 5.0 endsection inputDeviceAdapterNames += (HIDAdapter) section HIDAdapter inputDeviceAdapterType HID inputDeviceNames (USBEncoder) section USBEncoder name USBEncoder deviceVendorProductId 0079:0006 trackingDeviceName Mouse endsection endsection section Window windowFullscreen false endsection section Tools toolClassNames += (ScriptExecutorTool) section DefaultTools section WaterTool toolClass GlobalWaterTool bindings ((USBEncoder, Button0, Button1)) endsection endsection endsection endsection endsectionHi Stephanie, I have yet to encounter this bug myself, any chance you could make a video?
Normally with something like this I would try to make sure I redid the calibration from scratch. Have you had any luck fixing it?One issue I have had is being able to calibrate it properly in a well lit environment. It seems that the Kinect sensor can’t seem to read the sand properly in daylight conditions. It could be because of the reflective quality of the type of sand I’m using and this might not be an issue for you. But it is something I would test before committing to an expensive build.
I may be wrong here, but I think the water part of the simulation is CPU heavy and has no built in limit to how much a user can add. It can easily overwhelm even the beefiest of computer builds.
One way to deal with this is to increase the evaporation rate in the command line when you start the program. If you make it aggressive it’ll dry out the map pretty quickly. It’ll be up to you to see what works best for your users. I’m assuming their aware they can add water by using the hand gesture so even if the evaporation rate is high they can still add enough to find the simulation useful. This can at least reduce slow-downs. You can also change the amount of reflections in the water and a few other settings and see if that helps.
Another way is to add an arcade button that can “drain” the water. Possibly in conjunction with a little sign that says “If program is slowing down, press and hold me to remove some water.”.
There’s a few tutorials on this forum that can show you exactly what I’m talking about if you do a little search for them. I’ll check back when I have more time and see if I can dig them up for you if you’re still having trouble.
