[EMAIL PROTECTED] wrote: > However, the proposed approach is versatile, but > complicated and for complicated operations, whose > purpose is not explained. I can envision that with these > kinds of features one can _manipulate_ the objects > as in a 3D design space, such as CAD or 3D > modeling applications.
Yes, my proposal is not needed for simply viewing objects. However, it could be useful for selecting or dragging a specific vertex, or a specific object. For example, imagine I wrote code to model a checker board, in opengl. I might use this mouse mechanism for the user to pick up and move checkers. Trying to code a reasonable way of selecting a checker on a board being viewed in perspective is... well, it's doable, but it's not as easy as it should be. With more involved sets of objects the issue becomes worse. > Mouse movement positions the cursor, dragging mouse > changes the view point: > - no modifier: move around (fly or walk) > up/down: zoom, left/right: turn changing direction > - alt: pan > - ctrl: study (rotate the space sphere along meridian and equator > ralative to the closest object in the live of view) > - shift: increase spead Sure, this is doable now with just a screen or so of code. This might be more appropriate for the programming forum, but I'd want to refine the spec a bit before implementing it. > - no modifier: move around (fly or walk) > up/down: zoom, left/right: turn changing direction Hmm... I think here you mean: up/down (y-axis mouse movement) would correspond to movement either along the eye's z axis, and left/right (x-axis mouse movement) would rotate the direction the eye faces holding either the eye's y-axis constant. There's an ambiguity here, though -- if you use the keyboard to change the orientation of the eye's y-axis, does that change the behavior of these keys? Or do you mean to maintain a concept of vertical which is independent of the eye? > - alt: pan Here, I'll guess that you're changing the meaning of left/right to mean move along the eye's x-axis, and that up/down mouse motion retains "zoom" meaning you specified above. > - ctrl: study (rotate the space sphere along meridian and equator > ralative to the closest object in the live of view) I think this wouldn't work very well, with J's canned opengl support because it's designed to render arbitrary command lists. I don't know of a general way of relating "the pixels rendered in the center of the screen" with "the center of moment of the corresponding logical object. It's certainly doable, but it would place constraints on the system which are not currently present. Typically, a command list represents a rigid object, but this object might be rendered centered on the origin, or it might be rendered 300 units down the x axis. Also, I think it's possible to design command lists which shift the point of view for subsequent commands (always in the same fashion, since command lists take no parameters but this could be reflection, rotation, scaling, displacement, etc.) I think it would be better to define basic mouse-controlled movement in terms of what's possible using the standard keyboard mapping. > - shift: increase spead Seems simple enough. -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
