Chaos Enscape Ideas Portal
The online platform for Enscape users to submit, vote, and collaborate on creative suggestions.
The online platform for Enscape users to submit, vote, and collaborate on creative suggestions.
I don't see any reason for disabling the ability to toggle between "walk" and "fly" when we can otherwise navigate freely when "synchronize view" is enabled.
Hi Pete,
Thank you very much for reaching out!
Currently, sync works one-directional (from CAD to Enscape), meaning it reflects the camera view on the Enscape side. Since, there is no "walk" or "fly" option on CAD side, we're disabling the walk mode and automatically active the fly mode on Enscape when Synchronize Views is enabled. If we have enabled walk mode when the Sync is on, that would cause the user to "drop" to the surface each time you are floating above the ground.
Hi Mehmet,
Thanks for your comment! I am a bit confused. When "Sync" is on, navigation in Enscape is not constrained to the current view in CAD (Vectorworks). As currently configured, the Enscape view is not transfered to CAD, but, from the other direction, when navigating in CAD the Enscape view follows along. So, the views can become unlinked as we navigate in Enscape.
What confuses me is the "drop to the ground" issue. Walk has a defined z value, so wouldn't you just drop to that level above the ground or floor? That's what toggling to walk mode does in "not Sync" mode. Even if VW could follow along, I'm not sure why that would be a problem.
Mathematically, I don't think there should be a problem. Navigating involves 2 vectors. Call the "view" vector V. It has an origin, a rotation, and an inclination angle. It's length is meaningless. It defines where the "eye" is looking. Then there is a vector M, for movement. It has the usual vector parameters, and the length of M defines the rate of movement.
In walk mode, the "origin" point of V is constrained to a plane parallel to the floor or walking surface. M has the same origin and rotation angle, but its inclination angle is constrained to be parallel to the walking plane. V can be "looking up," but M does not point up. The rotation of V affects the rotation of M, so you change direction as the "head" swivels.
In fly mode, V and M are coincident. If you look up, you move up. If you look at a point, you move toward that point.
Either way, movement results in a translation of the origin, and that value can be transfered to CAD.
VW walkthrough tool is very similar to Enscape walk mode. The z value of both V and M origin are constant, they do not follow a non-horizontal walking surface. M is constrained to inclination = 0, and rotation of M follows the rotation of V. You can "look up" and move horizontally, but looking left or right causes your direction of movement to rotate left or right. By the way, you should try the VW walkthrough tool if you haven't, it is based totally on mouse movement and is very intuitive and easy to use. Up and down changes your movement speed, left and right changes the rotation angle of M and V. The "alt" key modifier changes the inclination of V, but not M.
It seems to me that with this mathematical perspective, it should be easy to resolve the issue you perceive.