Continuing with the idea of the 3Dgrid and its limbs concept development.
1) I think we can avoid to do the collection of pt, Rx, Ry and masterX and masterY bones EVERY TIME the embedded script is called. BTW, the embedded script is called
three times each frame movement. I don't know why but it is. I have tested a simple menu script and a simple embedded script to verify if a menu call can set a variable to a determined value where the embedded script can take access from. The answer is yes.
I have made a menu script called:
ge_test.lua
Code: Select all
-- **************************************************
-- Provide Moho with the name of this script object
-- **************************************************
ScriptName = "GE_Test"
-- **************************************************
-- General information about this script
-- **************************************************
GE_Test = {}
function GE_Test:Name()
return "Test"
end
function GE_Test:Version()
return "1.0"
end
function GE_Test:Description()
return "Test sample"
end
function GE_Test:Creator()
return "Genete"
end
function GE_Test:UILabel()
return("Test sample...")
end
--------------------------------------------------
GE_Test.myvalue = nil
--------------------------------------------------
-- **************************************************
-- The guts of this script
-- **************************************************
function GE_Test:Run(moho)
local b
if(GE_Test.myvalue == nil) then
print ("seting...")
GE_Test.myvalue = 0
else
print ("value =" .. GE_Test.myvalue)
end
local skel = moho:Skeleton()
if (skel == nil) then
return
end
b = skel:Bone(0)
b.myvalue = 77 -- arbitrary value
end
and a simple embedded script (test.lua)
Code: Select all
function LayerScript(moho)
local bone
local skel = moho:Skeleton()
if (GE_Test.myvalue ~= nil) then
print ("GE_Test.myvalue =" .. GE_Test.myvalue)
else
print ("no value")
end
bone = skel:Bone(0)
print ("Bone.myvalue =" .. bone.myvalue)
end
The two interesting things:
a) You can store values to your menu script instance that can be accessed by other scripts. GE_Test.myvalue is the example. It is filled by the menu script and retrieved by the embedded script.
b) You can also modify the moho objects with your particular variables as you have said it to me (That's great). It would be loose everytime you open the file but if you maintain the bones there, the information could be redone
Also I have made some test to try to find the global angle of a bone. I have used the samples from the master (LM the legend!) in the original announcing of the Embedded Script feature.
Here is the sample files.
http://darthfurby.com/genete/Scripting/angle-test.zip
Open the angle.anme file and manipulate the bones beyond frame 0. You will see the lua console showing the global angle of the bone number 2 (ID= 1), in degrees.
So my proposal is:
1) Create a menu script just extracting the code lines from 3Dgrid script first part. The values of RX, RY, masterX, masterY, etc. can be stored in the menu object instance. Every time you call the menu script it refill the corrects values to a matrix that is attached to the menu script object. It is the same than the embedded script but run only once. Also it sets a on/off variable that tell the embedded script if the menu script has been called or not. Even you can store more information about the found values (for example the amount of pt bones, etc.) specific information to make the embedded run faster.
2) Obviously the embedded script should take account that and make its job as far as possible.
3) Once I can retrieve the global angle of a bone I can play with the new concepts for the limbs.
---
Rules:
a) A pt bone can be a rotation center of other pt bones. The only condition to do that is that the pt bones should be its children.
b) A pt bone can be part of a local mesh. it only need to know if it have a parent ad his parent is a pt bone. If his parent is a pt bone then the alpha and beta don't come from masterX and masterY. They come from bonename.mX and bonename.mY being bonename the name of its pt parent. It will retrieve the
global angle of bonename.mX/Y. if the bonename.mX or bonename.mY bones don's exists then it will move as the masterX and masterY move (it can be a mix of master and bonename). It is a responsability of the designer to create and setup the bonename.mX or Y bones. It could be automated but seems to be difficult.
c) The masterX and the subsequent bonename1.mX/Y, bonename2.mX/Y, etc. would be linked as normal skeletons. I this way you can manipulate bones with IK and the 3D model would response properly in his rotation angle.
d) The masterX and masterY bones only would have sense to those bones that are not part of the sub meshes.
For example body can be manipulated by masterX/Y bones and arms and rest of limbs can be manipulated by other .mX/Y bones.
Makes it sense?
Waiting for your thoughts,
Best
-G
