Moho Animation Forum

synthsin75 wrote:The AS11 add bone tool snaps to the tip of a nearby bone, so you might look there.

synthsin75 wrote:I don't use Mac, but I seem to remember reading something about right-clicking the program and selecting show package or something.

hayasidist wrote:Try this...

Code: Select all

	local i
	local vec = LM.Vector2:new_local()
	local tip = LM.Vector2:new_local()
	local angle, scale
	local bone, boneId
	local parent
	local pAngle

	boneId = moho:Skeleton():BoneID(bone)

	vec:Set(bone.fPos)
	angle = bone.fAngle
	length = bone.fLength
	scale = bone.fScale

	parent = bone.fParent
	pAngle = 0
	while parent >= 0 do
		local l = moho:Skeleton():Bone(parent).fAngle
		pAngle = pAngle + moho:Skeleton():Bone(parent).fAngle
		parent = moho:Skeleton():Bone(parent).fParent
	end

	local cum
	i, cum = math.modf ((pAngle + angle)/(2*math.pi))
	cum = cum*2*math.pi

	tip.x = scale * length * math.cos(cum) + vec.x
	tip.y = scale * length * math.sin(cum) + vec.y

this will give "world" coordinates of the tip in the same transform space as the bone -- IOW the vector layer in which the coordinates will be at the tip needs to be a child of the bone layer.

hayasidist wrote:Try this...

...

this will give "world" coordinates of the tip in the same transform space as the bone -- IOW the vector layer in which the coordinates will be at the tip needs to be a child of the bone layer.

function JL_compensate_bone_movement:CalculateBonePosition(moho, bone)
	local skel

	skel = moho:Skeleton()

	if (skel == nil) then return end

	local i
	local vec = LM.Vector2:new_local()
	local boneId
	local parent

	boneId = moho:Skeleton():BoneID(bone)


    local curFrame = moho.layer:CurFrame()

    -- local m= LM.Matrix:new_local()
    -- moho.layer:GetLayerTransform(curFrame,m,moho.document)

	vec:Set(bone.fPos)

	parent = bone.fParent

	while parent >= 0 do

		skel:Bone(parent).fMovedMatrix:Transform(vec)

        parent = moho:Skeleton():Bone(parent).fParent
   end

   -- m:Transform(vec)

   return vec

end

hayasidist wrote:this is why I said what I said about frames of reference.

where in the hierarchy is the layer in which you want to use the calculated coordinates?

e.g.
Bone <-- calculate here
>vector
Group
>vector <-- use here?

fPos as stored is not changed when the layer / camera transforms change
but the place on the screen where you'll find fPos does change
so if you have different transforms in the Bone and Group layers in the above example then the same fPos in the two vector layers will be in different places on the screen

The way to move the parent without moving the children would be to transform the children's position into world coordinates (using the inverse of the parent's fRestMatrix), move the parent, and then transform the children bones from world coordinates back to the parent's coordinates using the new fRestMatrix.

lehtiniemi wrote:Regarding to fPos, it doesn't seem to change when the parent bone is moving the bone, either. This is really weird to me. It only changes when the bone is translated directly but not when the parent is moving it as a part of the skeleton. This makes sense in that the skeleton calculates everything based on bone automations, but it seems to make reading and calculating the bone position unnecessary complicated. Same with fAnimPos.

lehtiniemi wrote: I'm trying to use the coordinates of the bone to move the same Bone layer accordingly in opposite direction so that the bone tip appears to stay still

hayasidist wrote:

lehtiniemi wrote: I'm trying to use the coordinates of the bone to move the same Bone layer accordingly in opposite direction so that the bone tip appears to stay still

ok so you want to translate the bone layer? (and not move the camera?) and it's all in just the x/y plane?

hayasidist wrote: a couple of initial observations:
> the layer transform matrix will change because you'll be translating the layer. Seems at first sight to be a bit of a catch-22 - you need the transform to get a "screen" position; but you use that to move the layer and so that'll change the transform matrix... hmmm...
> the bone will (likely) move in an arc and the layer will move in a straight line, so the toe will start and end in the right place but won't be right part way through its movement-- so this will need layer keys more frequently than bone keys.