I have been migrating work slowly from a variety of SDK 4.1 Unity projects into a 4.2 Unity project, and while 4.1 was never stable for me for successive runs, I might get half a dozen runs before a crash. In 4.2, any scene I ported over would crash the editor within 3 runs, all but guaranteed, while the same functionality in the sample scenes would run fine.
I’ve been comparing settings between the two, and the only one to correlate so far is that most of my old work used Position Tracking: GEN_2. Setting the provided sample scenes to use GEN_2 can produce a crash within a dozen runs; setting my ported scenes to GEN_1 has yet to produce a crash.
I have, however, observed the same sort of intermittent sensor drift on GEN_1 in SDK 4.2 as compelled me to (at StereoLabs’ recommendation) switch to GEN_2 to begin with.
When I see a crash, the Windows Application Event log shows one of two errors (arbitrarily, afaict):
Faulting application name: Unity.exe, version: 2022.3.38.54695, time stamp: 0x668daab5
Faulting module name: sl_zed64.dll, version: 0.0.0.0, time stamp: 0x6704ee6a
Exception code: 0xc0000005
Fault offset: 0x00000000023bcf73
Faulting process id: 0x49f8
Faulting application start time: 0x01db2a2f45bb889b
Faulting application path: C:\Program Files\Unity\Hub\Editor\2022.3.38f1\Editor\Unity.exe
Faulting module path: C:\Program Files (x86)\ZED SDK\bin\sl_zed64.dll
Report Id: 63c42e77-5651-4999-aca9-98c87d98aea7
Faulting package full name:
Faulting package-relative application ID:
or
Faulting application name: Unity.exe, version: 2022.3.38.54695, time stamp: 0x668daab5
Faulting module name: MSVCP140.dll, version: 14.40.33810.0, time stamp: 0xb3df2f63
Exception code: 0xc0000005
Fault offset: 0x00000000000127cf
Faulting process id: 0x5fec
Faulting application start time: 0x01db2a2bc3b93abd
Faulting application path: C:\Program Files\Unity\Hub\Editor\2022.3.38f1\Editor\Unity.exe
Faulting module path: C:\Windows\SYSTEM32\MSVCP140.dll
Report Id: 77f3fecf-f3c6-40b0-9382-47a8e2db9d8b
Faulting package full name:
Faulting package-relative application ID:
If this is reproducible for anyone else, it would be great to get a fix, since ultimately I’m going to need a solution with both the GEN_2 positional stability and the GEN_1 runtime stability.
Hi,
Unfortunately, I was not able to reproduce the crash on my side.
Can you tell me with which example scene the crash occurs for you? That will allow me to use the exact same parameters as you.
Thanks.
Body Tracking is what I’ve been using most rigorously. I forget if I’ve seen it as often in other demos, but if I have, it would be Object Detection (mostly 2D) or possibly Point Cloud.
I will also say that a revised body tracking scene which could run in a built demo for several days in 4.1 on an independent machine (albeit at degrading performance as the memory leak grew) seems to reliably crash within 24 hours when rebuilt on 4.2, or at least the camera itself stalls even if independent UI elements continue to update.
some typical settings, notwithstanding being set to GEN_1 presently for stability.
Thanks for sharing this, it’s helpful.
I’ll investigate on my side but I see that you keep “Tracking is static” enabled.
Can I ask you why you are using the tracking Gen_2 in that case?
Edit : With this option enabled, the camera is completely static, you should not experience any drift.
Good eyes. It’s an independent investigation, as (a) this was the recommended fallback before we learned about GEN_2 (we were worried about Static initially, as our internal creative direction sometimes calls for absolute replicability of virtual setup, and if Static gets its angle/height wrong on its first pass, it will never correct) and (b) in our current work with body tracking in a relative vacuum, we are observing an accumulation of drift over time between the raw skeleton and posed avatar, specifically on the camera Y axis (which was, as I now recall, the axis we originally noticed GEN_1 drift on). This is mildly intriguing from a tech standpoint, as in our initial testing half a year ago, the camera was horizontal and we noticed lateral drift; now it’s vertical (portrait) and we’re getting vertical drift, so it seems the unstable value may be physical/hardware rather than any gravity-relative algorithmic factor.
The drift can be coming from the IMU calibration.
What you can do is opening your camera with the tool called “ZED Sensor viewer”. Then, you can look at the values of the Accelerometer too see if their are coherent.
Last time around, a recalibration didn’t help, but GEN_2 did, so we stuck with it. Good reminder, though, since we’re working with a slightly newer unit now.
As an update, an actual build on 4.2 with GEN_2 has just crashed twice consecutively, after 15 seconds each. Changing only back to GEN_1 and doing a fresh build, it seems stable so far.