carl.sutton Posted December 5, 2011 Posted December 5, 2011 It seems that the extents of the bounding area to enter the WidgetManipulator objects is less than that of the actual visible object on screen (For example, the translator at some viewing angles can highlight an axis on the tip of the arrow although the mouse is not recorded as entering the widget so a resulting mouse click and drag will not move it). If there is any chance you could tweak the widget so that its bounding area is just a little bit bigger it would be much appreciated. Thanks.
carl.sutton Posted February 9, 2012 Author Posted February 9, 2012 Sorry I was not specific enough in my asking of the question. I am not refering to the manipulators used by the editor but the manipulator widgets in general. What I had was a callback function for GUI_ENTER and GUI_LEAVE which I used to check if I could mouse click the widget. But these callbacks are not invoked when you highlight the very tip of the manipulator. Maybe I need to take another look at the editor code and see if I can implement it better but at the time the thinking in doing this was to prevent myself from drawing my custom selection drag boxes when moving my manipulators. Edit: actually it does do it in the samples too when using the editor, you can just highlight the very tip of an arrow (at some orientations), but when you click you will not gain focus of widget. I think in my project the problem is a little more exagerated, I'm not sure if this is because I'm reducing the bounding accuracy of the mouse click by embedding unigine into a winform, but it is really annoying thinking you have the widget manipulator highlighted, then you try to move it and instead you do one big drag selection.
manguste Posted February 14, 2012 Posted February 14, 2012 The root of the problem is that a bounding box is used to check enter/leave callbacks, so at some angles such behaviour seems to be pretty much inevitable evil.
Recommended Posts