View > Direction > Menu items trough script?

[Lukas]

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?

[hayasidist]

I've tried some things with:
https://mohoscripting.com/search/?subject=viewmode
MOHO.MohoGlobals.MingViewMode (0 director, 1 camera, 2 panel)

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 ...

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...

[Lukas]

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 ...

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...

Hmm, thanks!

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]

I've tried both OrbitPan() and CameraPan(), but they don't seem to be able to switch modes.

I'm not familiar with those functions?! But ...

the Camera view moves along with an animated camera and how the Front view doesn't.

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]

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.

[synthsin75]

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.

[Lukas]

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.

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]

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.

I assume moho.view will work.

[Lukas]

I assume moho.view will work.

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]

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())????

[Lukas]

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:

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

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)

[hayasidist]

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)??????

[synthsin75]

With a little trial and error, this seems to work consistently.

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)

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.

[Lukas]

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.

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!

(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???)

Picky is good! Haha, I'll change that. A lot of my code is a big spaghetti mess, I'm trying to be better.

[Lukas]

This is so much nicer to work with than disabling the camera channels on the timeline!

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

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: