The rendered stylus beam origin doesn’t start from the physical stylus tip but slightly further away on the right or left so the rendered beam appears weirdly “angled” from a user point of view. ( zspace 200 & WIn7, zCore 5, same behavior with the previous zCore ) .
It looks like the virtual and physical spaces are not synced/calibrated properly scale-wise : I also tested with objects constantly looking at the head position , they were not looking at my actual head, but at a point situated between my head and the screen. Changing the zcore scale factor didn’t help. Provided samples or new apps show same behaviors.
Moving the stylus across the screen (left/ right, up / down) with the stylus pointed normal to the screen shows that as the stylus moves towards the screen limits, the beam goes further away from the stylus tip ( higher when at the top, lower when at the bottom, etc) . the beam also angles a bit. (from straight normal to the screen when the stylus is above the center of the screen, then angled when the stylus (which is still oriented normal to the screen) is reaching a border.
I do have the same behavior whith the zspace experience demo.
Here’s how I was looking at the head :
m_Camera.position = m_zcore.GetFrustumEyePosition(ZCore.Eye.Center, ZCore.CoordinateSpace.World);
m_UIElement.rotation = Quaternion.LookRotation(m_UIElement.position - m_Camera.position);
zspace software version 220.127.116.11745
display panel 18.104.22.168943
tracker version 22.214.171.124
formware kernel 126.96.36.199947
I was about to suggest that it may be the eye-swap problem, but then I realized that you and I had conversed about that issue about a month ago. Are you that same developer?
The solution ended up being upgrading to the newest System Software (4.4.2) but you’re reporting the system is on 4.4.1.x
Can you confirm that the issue persists with the newer 4.4.2 system software?
Yes that’s me
Good catch for the 4.4.1 version - Now we have an interesting thing going on, as I had installed the latest 4.4.2 zspace system software (installer says 188.8.131.52, dated 03/08/2018) , which fixes the former eye swap issue.
But - looking at the zspace control panel, and the system info - it still says 4.4.1 (!!)
I tried again today, same thing.
(Note that I installed everything after a un-installation + reboot. I also disabled the automatic windows searching for drivers that pops up when the zspace is plugged in)
Okay thanks, I’m following up with some folks about the version discrepancy to see if that might be part of the issue.
In the mean time, could you let me know what the zSpace Control panel is reporting as your display’s resolution? does it happen to differ from what windows display settings says or is a secondary monitor connected that has a different resolution? My best guess right now is that something is reporting display information incorrectly.
Both Windows and zspace control panels say 1920x1080 for both the laptop and the zspace screens - as it should be.
Now : I was using the “duplicate” projection mode. I tried with the laptop closed to have only the zspace display active.
And it changed everything. It made the view correct; I realized that because I was finally seeing the UI buttons at the bottom of the screen in the zspace experience demo (they were outside the screen before).
Note that the scene view angle also changed. In my app, the way my scene is viewed is now consistent with the main camera setup in the authoring (in Unity).
Switching back to duplicate, the display was still OK.
Rebooting made the initial behavior come back.
So what it takes now it to run any zspace app with the zspace screen as the sole display at least once to get the right display resolution/angle.
Aaah I see, well I’m glad there’s a partial solution despite its inconvenience.
Are you speaking of Windows display settings’ duplicate mode? Do the apps run correctly in “extended” or “Show only on 2” display modes?
Yes I was referring to the Windows display setting “duplicate” mode.
With “Projector only” (= show only on 2" ) the zspace view is wrong again.
With “Extended” and the zspace display set as the primary display , the zspace view is right.
One more thing - In Unity, the visual helpers ( viewport zero parallax, comfort zones,…) in the ZCore components behave the very same way .
Thanks for the information.
I ran this upstream and it sounds like a shortcoming of how our software acquires display information. We’ll have to make an effort to address it in future software releases, but for now, I can only recommend sticking with extended display mode.