That's an interesting work. Yes, the motion sickness can happen because of sensory conflicts (DoF), and/or low frame rate, but also depending on the design (ie. colors, object movements, uncanny valley...). You can auto-detect what hardware you are using an application (ie. a simple UI built in C# or C++), define DoF for each of them, then call the specific scene for the detected device. To keep interaction consistency the colliders should work the same with every system. That's easy when you develop in Unity3D. If you still have problems, maybe you should try using controllers for all the movements. With that, you would not use real-time head movements on HMDs, but it can reduce possible latency and freeze during live features, also reducing motion sickness.

Thank you for your answer Fernando.

I feel it to be a bit more tricky in UMI3D Environments since we are speaking about networked CVE with a master server managing all the business logic without any knowledge of the connected device. Otherwise I am not sure having a consistent way to handle collisions with the environment is always a good think due to the gap between best practices for navigation depending on the device (e.g. HMD vs. laptop).

I'm not sure this is what you are looking for as it may involve changes or annotations in the 3D environment, but I think it may be a good idea to make the limits "less hard". I mean instead of letting the user bump his head right into the wall and then limit the motion to only sliding along the wall or moving back, which may be ok on a pc, but not a HMD, try to set the boundary much wider and use other cues, such as lighting up (gradually) a graphical representation of the boundaries, a stop sign etc. once the user comes close to the boundary. This way you don't need to block the user's motion in VR, unless he or she completely ignores the other cues. I would think most users react to that and would not get to the hard limit and therefor those freezes or breaks between motion in the real world and virtual world that cause motion sickness can be prevented. While that strictly would only be required for head tracked VR (eg. HMD), it should also be acceptable for other devices. In fact for interaction with a PC I could imagine using a repelling force, probably proportional to how deep you entered the border zone, that pushes you back out in the direction of the surface normal, which effectively would still let you glide along the wall if that is a convenient way for people to navigate in 3D environments with mouse or trackpad.

I would think that it could also make it easier to handle from a central server, as you probably have more time to react from when a user enters the border zone to when he or she may actually reach the hard border than if you only react once there is contact (or intersection) with the wall.

In short, handle the problem at the 3D environment level instead of the interaction device level.