View > Direction > Menu items trough script?
Moderators: Víctor Paredes, Belgarath, slowtiger
View > Direction > Menu items trough script?
Is it possible to access the view > direction > menu items through script?
I'm specifically looking to toggle between "View > Direction > Camera" and "View > Direction > Front".
I've tried some things with:
https://mohoscripting.com/search/?subject=viewmode
MOHO.MohoGlobals.MingViewMode (0 director, 1 camera, 2 panel)
But with no success. I might be doing it wrong or it might just not be possible. Does anyone have a clue?
I'm specifically looking to toggle between "View > Direction > Camera" and "View > Direction > Front".
I've tried some things with:
https://mohoscripting.com/search/?subject=viewmode
MOHO.MohoGlobals.MingViewMode (0 director, 1 camera, 2 panel)
But with no success. I might be doing it wrong or it might just not be possible. Does anyone have a clue?
- hayasidist
- Posts: 3596
- Joined: Wed Feb 16, 2011 8:12 pm
- Location: Kent, England
Re: View > Direction > Menu items trough script?
FWIW: Ming is (was) Motion Artist (http://www.lostmarble.com/forum/viewtop ... 5&p=185800) which was based on the Moho core software - and that used those views ...Lukas wrote: ↑Sun Oct 10, 2021 8:38 am I've tried some things with:
https://mohoscripting.com/search/?subject=viewmode
MOHO.MohoGlobals.MingViewMode (0 director, 1 camera, 2 panel)
An idea to try (I haven't)
in the View class there are various Zoom / Pan / Orbit / Rotate functions that take as their input an LM_Point
It might be feasible to determine the effective value of the two values of LM_Point that would represent the "Front" and "Camera" views -- this might mean some adept conversion between world and screen coordinates for the camera position and various rotations (and similarly for "front").
Or, ofc, there might be a much simpler way which, for now, eludes me...
Re: View > Direction > Menu items trough script?
Hmm, thanks!hayasidist wrote: ↑Sun Oct 10, 2021 9:45 amFWIW: Ming is (was) Motion Artist (http://www.lostmarble.com/forum/viewtop ... 5&p=185800) which was based on the Moho core software - and that used those views ...
An idea to try (I haven't)
in the View class there are various Zoom / Pan / Orbit functions that take as their input an LM_Point
It might be feasible to determine the effective value of the two values of LM_Point that would represent the "Front" and "Camera" views -- this might mean some adept conversion between world and screen coordinates for the camera position and various rotations (and similarly for "front").
Or, ofc, there might be a much simpler way which, for now, eludes me...
Motion Artist... Well, that makes some sense at least
I've tried both OrbitPan() and CameraPan(), but they don't seem to be able to switch modes. Calculating the camera and going to that view position in orbit mode is not what I'm looking for because the main reason I'm looking into this is the difference in how the Camera view moves along with an animated camera and how the Front view doesn't. I wrote a (imo) great camera tool for animating a 2D camera which I'll share soon, access to switch between front and camera view would improve it a lot, because the main feature is how it actually shows the animated viewport (the original camera tool's path is very unhelpful to me) and it's very useful to watch it from orbit mode too, but switching modes is currently not very fast or intuitive.
- hayasidist
- Posts: 3596
- Joined: Wed Feb 16, 2011 8:12 pm
- Location: Kent, England
Re: View > Direction > Menu items trough script?
I'm not familiar with those functions?! But ...
would taking the camera transform out of the whole view transform lead towards what you wanted? (e.g.)
Code: Select all
layer:GetFullTransform (moho.frame, m, moho.document) -- includes camera and layer motion
--
layer:GetFullTransform (moho.frame, m, nil) -- layer motion only
- synthsin75
- Posts: 10051
- Joined: Mon Jan 14, 2008 11:20 pm
- Location: Oklahoma
- Contact:
Re: View > Direction > Menu items trough script?
I think you'd want MohoDoc:GetOutsideViewMatrix(m) https://mohoscripting.com/methods/762
EDIT: Oops, no, it doesn't look like there's a way to set MohoDoc:IsOutsideViewEnabled as true.
EDIT: Oops, no, it doesn't look like there's a way to set MohoDoc:IsOutsideViewEnabled as true.
- Wes
Donations: https://www.paypal.com/paypalme/synthsin75 (Thx, everyone.)
https://www.youtube.com/user/synthsin75
Scripting reference: https://mohoscripting.com/
Donations: https://www.paypal.com/paypalme/synthsin75 (Thx, everyone.)
https://www.youtube.com/user/synthsin75
Scripting reference: https://mohoscripting.com/
- synthsin75
- Posts: 10051
- Joined: Mon Jan 14, 2008 11:20 pm
- Location: Oklahoma
- Contact:
Re: View > Direction > Menu items trough script?
You'd probably have to call:
mouseEvent.view:OrbitDown(mouseEvent.pt)
and then
mouseEvent.view:OrbitMoved(mouseEvent.pt)
with a difference between the first and second LM_Point arguments to straighten out the default orbit view to head-on.
And then call LM_OrbitW:HandleMessage(moho, view, MOHO.MSG_BASE) to reset the view.
mouseEvent.view:OrbitDown(mouseEvent.pt)
and then
mouseEvent.view:OrbitMoved(mouseEvent.pt)
with a difference between the first and second LM_Point arguments to straighten out the default orbit view to head-on.
And then call LM_OrbitW:HandleMessage(moho, view, MOHO.MSG_BASE) to reset the view.
- Wes
Donations: https://www.paypal.com/paypalme/synthsin75 (Thx, everyone.)
https://www.youtube.com/user/synthsin75
Scripting reference: https://mohoscripting.com/
Donations: https://www.paypal.com/paypalme/synthsin75 (Thx, everyone.)
https://www.youtube.com/user/synthsin75
Scripting reference: https://mohoscripting.com/
Re: View > Direction > Menu items trough script?
Smart! I hadn't even thought of looking how the orbit tool did it. This will probably work! I hope I can just use moho.view and not need actually use a mouseEvent. Will give it a shot tomorrow.synthsin75 wrote: ↑Sun Oct 10, 2021 2:32 pm You'd probably have to call:
mouseEvent.view:OrbitDown(mouseEvent.pt)
and then
mouseEvent.view:OrbitMoved(mouseEvent.pt)
with a difference between the first and second LM_Point arguments to straighten out the default orbit view to head-on.
And then call LM_OrbitW:HandleMessage(moho, view, MOHO.MSG_BASE) to reset the view.
- synthsin75
- Posts: 10051
- Joined: Mon Jan 14, 2008 11:20 pm
- Location: Oklahoma
- Contact:
Re: View > Direction > Menu items trough script?
I assume moho.view will work.
- Wes
Donations: https://www.paypal.com/paypalme/synthsin75 (Thx, everyone.)
https://www.youtube.com/user/synthsin75
Scripting reference: https://mohoscripting.com/
Donations: https://www.paypal.com/paypalme/synthsin75 (Thx, everyone.)
https://www.youtube.com/user/synthsin75
Scripting reference: https://mohoscripting.com/
Re: View > Direction > Menu items trough script?
It does!
I’m now executing OrbitDown within HandleMessage followed by OrbitMoved (once, only executing if OrbitDown has been executed) in UpdateWidgets.
The result is really weird though… it does switch to orbit-mode and back. But the OrbitMode position is different each time.
In OrbitDown the point argument is set to (0, moho.document:Height()). And I have no clue what to give to OrbitMoved. Tried lots of stuff.
Calling OrbitMoved right after OrbitDown in the HandleMessage doesn’t do anything at all.
Especially the seemingly random results are very confusing. Any ideas?
- hayasidist
- Posts: 3596
- Joined: Wed Feb 16, 2011 8:12 pm
- Location: Kent, England
Re: View > Direction > Menu items trough script?
More thoughts - nothing more concrete... sorry in advance ...
at the risk of telling you what you already know: LM_Point (0,0) is workarea top left (not the render area) and the numbers increase to the bottom right -- what that limit is depends on your display and how far in / up you've adjusted the other panels - layers / timeline etc -- but view:Width() and view:Height() give you those. Those are different from doc:Width() and doc:Height() which are the pixel dimensions of the rendered output. (IOW doc:Height() might not give you what you wanted)
looking at the code in the various lm_orbit_workspace etc stuff - they all seem to follow the pattern that in the three mouse handlers: OnMouse[down/moved/up] they call view:[orbit/rotate/pan/zoom][down/moved/up](LM_point)...
The following is GUESSWORK:
so I'm guessing that "down" sets the start LM_Point; "moved" calculates the difference in Point(x and y) then uses that to determine how much to adjust the view : so (e.g.) in a view pan if x has increased by 200 pixels, then this means that world coords needs to move 200 pixels - IOW: "moved" turns point(200,0) into world(dx,dy) then does a graphics:Translate(dx,dy) -- similarly, "rotate" will work out what angle to give graphics:Rotate(angle) -- but I'm not seeing anything other than graphics:ApplyMatrix() that might explain how "orbit" might use the mouse motion to calculate a view rotation around the x and y axes
(still guesswork) so you could maybe get the camera transform matrix: doc:GetCameraMatrix(frame, m), and use its inverse in graphics:ApplyMatrix(m:Invert())????
at the risk of telling you what you already know: LM_Point (0,0) is workarea top left (not the render area) and the numbers increase to the bottom right -- what that limit is depends on your display and how far in / up you've adjusted the other panels - layers / timeline etc -- but view:Width() and view:Height() give you those. Those are different from doc:Width() and doc:Height() which are the pixel dimensions of the rendered output. (IOW doc:Height() might not give you what you wanted)
looking at the code in the various lm_orbit_workspace etc stuff - they all seem to follow the pattern that in the three mouse handlers: OnMouse[down/moved/up] they call view:[orbit/rotate/pan/zoom][down/moved/up](LM_point)...
The following is GUESSWORK:
so I'm guessing that "down" sets the start LM_Point; "moved" calculates the difference in Point(x and y) then uses that to determine how much to adjust the view : so (e.g.) in a view pan if x has increased by 200 pixels, then this means that world coords needs to move 200 pixels - IOW: "moved" turns point(200,0) into world(dx,dy) then does a graphics:Translate(dx,dy) -- similarly, "rotate" will work out what angle to give graphics:Rotate(angle) -- but I'm not seeing anything other than graphics:ApplyMatrix() that might explain how "orbit" might use the mouse motion to calculate a view rotation around the x and y axes
(still guesswork) so you could maybe get the camera transform matrix: doc:GetCameraMatrix(frame, m), and use its inverse in graphics:ApplyMatrix(m:Invert())????
Re: View > Direction > Menu items trough script?
Thanks for thinking along here guys.
Yeah, I did mean view:Height() instead of doc:Height()! Sorry. So I am trying to mimic a mouse drag from bottom left towards somewhere top right. I am not exactly sure if the camera matrix would help here. Maybe?
Here's what I've got to try and toggle between camera-view and front-view:
Here's what it does, and I've got no idea why the orbit view isn't always the same. The front view I'm accessing trough the menu at the end is the view I'm looking for (but more zoomed in probably, but I'd be satisfied with the correct angle):
edit: By the way, if you comment out "moho.view:OrbitMoved(pt)" it does consistently go to the same orbit position/angle (the one you get when you click the viewport without dragging with the Orbit tool)
Yeah, I did mean view:Height() instead of doc:Height()! Sorry. So I am trying to mimic a mouse drag from bottom left towards somewhere top right. I am not exactly sure if the camera matrix would help here. Maybe?
Here's what I've got to try and toggle between camera-view and front-view:
Code: Select all
function LK_Camera:HandleMessage(moho, view, msg)
if msg == self.TOGGLE_VIEW_MODE then
if moho.document:IsOutsideViewEnabled() then
LM_OrbitW:HandleMessage(moho, moho.view, MOHO.MSG_BASE)
else
local pt = LM.Vector2:new_local()
pt:Set(0, moho.view:Height())
moho.view:OrbitDown(pt)
self.orbit = true
end
Code: Select all
function LK_Camera:UpdateWidgets(moho)
if self.orbit then
local pt = LM.Vector2:new_local()
pt:Set(moho.view:Width()/2, moho.view:Height()/2)
moho.view:OrbitMoved(pt)
self.orbit = false
end
edit: By the way, if you comment out "moho.view:OrbitMoved(pt)" it does consistently go to the same orbit position/angle (the one you get when you click the viewport without dragging with the Orbit tool)
- hayasidist
- Posts: 3596
- Joined: Wed Feb 16, 2011 8:12 pm
- Location: Kent, England
Re: View > Direction > Menu items trough script?
thinking only - sorry not to have time to try this out first - but I imagine that "moved" needs a start point - if you use the tools you can click anywhere then drag, it doesn't matter where the first click is - and you've done that in the message handler --- but when you get to update widgets it's the displacement from "down" to "up" (via "moved") that matters. Therefore rather than "moved" - how about replacing that call with "up" ? (or, if that fails, add a "moved" at (say) {moho.view:Width()/4, 3*moho.view:Height()/4} (i.e. half way) before the "up" ????)
(oh - and - just to be picky - LM_OrbitW.RESET would, IMO, be a better choice than MOHO.MSG_BASE -- but since all the routine does is view:ResetView() - why not just moho.view:ResetView() in this tool???)
[EDIT:]
Oh hang on -- UpdateWidgets can get called many times .. there's no guarantee of a one-to-one correspondence between handle message and update widgets -- so I'm guessing that's happening and is upsetting the "mouse tracking" logic - which could account for unpredictability??!?? ... so how about in the message handler just follow the "down" with an "up" (maybe with an intervening moved if necessary)??????
(oh - and - just to be picky - LM_OrbitW.RESET would, IMO, be a better choice than MOHO.MSG_BASE -- but since all the routine does is view:ResetView() - why not just moho.view:ResetView() in this tool???)
[EDIT:]
Oh hang on -- UpdateWidgets can get called many times .. there's no guarantee of a one-to-one correspondence between handle message and update widgets -- so I'm guessing that's happening and is upsetting the "mouse tracking" logic - which could account for unpredictability??!?? ... so how about in the message handler just follow the "down" with an "up" (maybe with an intervening moved if necessary)??????
- synthsin75
- Posts: 10051
- Joined: Mon Jan 14, 2008 11:20 pm
- Location: Oklahoma
- Contact:
Re: View > Direction > Menu items trough script?
With a little trial and error, this seems to work consistently.
You always want to ResetView before setting OrbitDown, to make sure the LM_Point is always the same relative to the orbited workspace. This is probably why you were getting random results, as the OrbitDown is where it "grabs" the workspace. IOW, you grab and drag, and then the next time you grab and drag, you're adding to the rotation.
Lukas, your example used LM_Vector2 instead of LM_Point.
Code: Select all
moho.view:ResetView()
local pt = LM.Point:new_local()
local w, h = moho.view:Width(), moho.view:Height()
pt:Set(0, h)
moho.view:OrbitDown(pt)
pt:Set(w/8, h-(h/4))
moho.view:OrbitMoved(pt)
Lukas, your example used LM_Vector2 instead of LM_Point.
- Wes
Donations: https://www.paypal.com/paypalme/synthsin75 (Thx, everyone.)
https://www.youtube.com/user/synthsin75
Scripting reference: https://mohoscripting.com/
Donations: https://www.paypal.com/paypalme/synthsin75 (Thx, everyone.)
https://www.youtube.com/user/synthsin75
Scripting reference: https://mohoscripting.com/
Re: View > Direction > Menu items trough script?
Thanks Wes! That makes a lot of sense. Didn't notice the point/vector2 situation and would never have figured out the ResetView part. This works great!synthsin75 wrote: ↑Mon Oct 11, 2021 6:54 pmYou always want to ResetView before setting OrbitDown, to make sure the LM_Point is always the same relative to the orbited workspace. This is probably why you were getting random results, as the OrbitDown is where it "grabs" the workspace. IOW, you grab and drag, and then the next time you grab and drag, you're adding to the rotation.
Lukas, your example used LM_Vector2 instead of LM_Point.
Picky is good! Haha, I'll change that. A lot of my code is a big spaghetti mess, I'm trying to be better.hayasidist wrote: ↑Mon Oct 11, 2021 4:06 pm(oh - and - just to be picky - LM_OrbitW.RESET would, IMO, be a better choice than MOHO.MSG_BASE -- but since all the routine does is view:ResetView() - why not just moho.view:ResetView() in this tool???)
Re: View > Direction > Menu items trough script?
This is so much nicer to work with than disabling the camera channels on the timeline!
No clue if zoomFactor 5.45 would work on all systems, but it's the magic number that compensates the difference on my display at least. Now I'm wondering if I can compensate the position as well... I guess that's where the cameramatrix is coming into play. I'll look into that later.
My camera tool is coming along nicely. It can't handle pan/tilt, and the viewports are a bit off on extreme zoom's, but I usually use the Track and Roll tools exclusively and the show path feature is perfect in those scenarios:
Code: Select all
local zoom = moho.view:Graphics():ViewZoom()
local zoomFactor = 5.45
if moho.document:IsOutsideViewEnabled() then
moho.view:ResetView()
zoom = zoom / zoomFactor
moho.view:Graphics():SetViewZoom(zoom)
else
moho.view:ResetView()
local pt = LM.Point:new_local()
local w, h = moho.view:Width(), moho.view:Height()
pt:Set(0, h)
moho.view:OrbitDown(pt)
pt:Set(w/8, h-(h/4))
moho.view:OrbitMoved(pt)
zoom = zoom * zoomFactor
moho.view:Graphics():SetViewZoom(zoom)
end
My camera tool is coming along nicely. It can't handle pan/tilt, and the viewports are a bit off on extreme zoom's, but I usually use the Track and Roll tools exclusively and the show path feature is perfect in those scenarios: