LDraw.org Discussion Forums
Thoughts on animation scripting language - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: LDraw Programs (https://forums.ldraw.org/forum-7.html)
+--- Forum: LDraw Editors and Viewers (https://forums.ldraw.org/forum-11.html)
+--- Thread: Thoughts on animation scripting language (/thread-12368.html)

Pages: 1 2 3 4


Re: Thoughts on animation scripting language - Roland Melkert - 2014-02-06

I did read about LUAJit, but I decided to use the plain lua for now as it is easier to get started with (i think), if needed I could replace it later like you wrote as it's pretty much api compatible.

As for speed I have not jet tested that, the scripts are going to do matrix math etc on per frame/movement basis, but I was planning to move the core matrix stuff to C functions and give the user only access to container handles (lua calls it user data), e.g. matrix.loadID, matrix.mul(matrix2) etc. Or using operator functions (which lua seems to support, but I haven't really looked into it)


Re: Thoughts on animation scripting language - Ben Supnik - 2014-02-07

Hi Roland,

Yep - LuaJIT is more or less API compatible - a later switch-over should be easy.

The only gotcha: for 64-bit ABIs, LuaJIT needs to allocate from the lowest 2 GB of address space. If you start your Lua session early or run only Lua this isn't much of a problem, but if you run your app for a while and then have to allocate a pile of Lua memory, you can run out. There are ways to work around this though - I can send you an email if you ever run into this case.

If you have to make a large number of calls into C that do a relatively small amount of math (e.g. one matrix multiply), LuaJIT might be competitive with C due to the overhead cost.

Cheers
Ben


Re: Thoughts on animation scripting language - Roland Melkert - 2014-02-11

Thanks for the info, but I think basic LUA will do for now.

At the moment I'm trying to set up a global approach for the animation handing, as I have zero experience in LUA and you seem to have some I would appreciate your thoughts regarding the below approach.

Consider the following (pseudo) LUA script

Code:
--global scope part of the script, will be ran upon file load.


--Setup custom group 'methods' for the ldcGroup pseudo class
--  this will determine the way we want to animate the groups
--  simple rotation over the z axis in this example.


function ldcGroup.initLink(grpName)

  result=ldcGroup.link(grpName)
  result.angle=0 --introduce obj var ??
  return result
end

function ldcGroup:getAngle()
  --does not really need a function, but maybe we want to do more in here in the future
  return self.angle
end

function ldcGroup:setAngle(newAngle)

  self.angle=newAngle
  local matrix=self.getCurrentMatrix()
  matrix.loadRotation(newAngle, 0.0, 0.0, 1.0);
end


--make global lua vars for groups we want to manipulate
gearA=ldcGroup.initLink('group1')
gearB=ldcGroup.initLink('group2')


--called by LDCad on 'reset' event
function init()

  gearA:setAngle(0.0);
  gearB:setAngle(0.0);  
end


--called by LDCad on 'frame change' event
function calcFrame()

  angleA=gearA.getAngle() + 15
  gearA:setAngle(angleA)

  angleB=angleA*-2
  gearB:setAngle(angleB)
end

The thing I want to achieve here is setting up a scripting environment which is extremely dynamic. I don't want to restrict users to animate in a certain way. So by using LUA they should be able to animate simple gears, but also e.g. walking mini figs etc.

In the long term you could setup a LUA library containing code for handling gears universally etc. This would also allow for third party written code handling e.g. extremely complex kinetics to be used by others.

So my question is: Does the above approach makes sense, or I'm I thinking in a wrong direction here or are there any LUA limitations spoiling this.

if anybody wants to actively help think out this environment please let me know.

[edit] made minor corrections to the script


Re: Thoughts on animation scripting language - Stephen - 2014-02-11

I haven't used LDCad, so forgive me if any of this misses the point. I haven't used it because I'm very experienced with my existing setup (MLCad -> LDView -> PovRay), because I don't presently have the time to investigate it, and because LDCad looks a little too "heavy" for my aging PC :-)

But it does look interesting, so I wanted to just say a few words.

I've done complex animations before (example: http://www.youtube.com/watch?v=oFR6u9_lnoY). The method I use is to use standalone command-line PHP as a general scripting engine to write a script that modifies the .pov file output by LDView to include all the additional calculations and rotations needed for the animation.

Using this technique not only can I easily manipulate the position of parts and the camera, but I can also programatically generate sequences whereby parts become hidden or unhidden on a frame-by-frame basis thus automatically generating a brick-by-brick build animation of an entire model regardless of whether the model is flattened first or left in a sub-model/structured state (parts are first sorted using MLCad's part sorting feature - example http://www.youtube.com/watch?v=Aj4AUgJApys). I also use this technique to assist in automatically disabling sub-models which are not visible within specific ranges of frames (or still renders) in order to reduce the memory footprint and speed up the render times.

The example script you gave is in fact very similar to the code I inject into the .pov file for cyclic animations, so for someone of my skills I feel you are going about this the right way. The choice of language matters more to the developer than the end user, as long as it has access to stuff like sin/cos/tan/asin/acos/atan/sqrt and preferably also inbuilt functions for splines and beziers. It's clearly too complex for a non-programmer, but in my experience those type of people would only attempt an animation if they had some sort of simple "wizard" to generate the script or animation sequence for them - which is something you could consider later for novices and simpler animations such as the wheels of a car spinning (from recollection SolidWorks provides something similar whereby you select some parts, select a single rotation axis and speed, and you're good to go - all without writing any code).

One thing I would like to say about that example script. Your example uses relative position calculations on each frame. That's fine, for many cases. But I've found that in most of my cases I prefer the ability to perform absolute calculations based upon PovRay's frame_number. I realise it was only an example, and you were probably going to allow something like this anyway, but I'd hate to see you implement an animation system where absolute calculations could not be done - it's much easier to choreograph and splice sequences which have been calculated absolutely with respect to the frame number.

The other thing that is unclear to me is what LDCad would be outputting here. Are you going to output a new unique .mpd for every frame and leave it to the user to convert these to a format suitable for raytracing? Or are you going to output a new .pov file for every frame? If that's the case, someone like myself is more likely to stay with my current system. One php script. One master .mpd file. Possibly one programatically altered .mpd file. One master .pov file. And one programatically altered .pov file. From that last file I can generate 1000s of renders using a batch file.

Ultimately, given the range of functions my scripts provide, I'm probably always going to roll my own anyway, so I'm probably not the best person to offer advice ;-) but I'll certainly be keeping an eye on what you're doing.


Re: Thoughts on animation scripting language - Roland Melkert - 2014-02-11

Stephen Wrote:I haven't used LDCad, so forgive me if any of this misses the point. I haven't used it because I'm very experienced with my existing setup (MLCad -> LDView -> PovRay), because I don't presently have the time to investigate it, and because LDCad looks a little too "heavy" for my aging PC :-)

Don't worry about it.

Stephen Wrote:...Using this technique not only can I easily manipulate the position of parts and the camera, but I can also programatically generate sequences whereby parts become hidden or unhidden on a frame-by-frame basis...

Access to visibility will also be possible, as lua gets full control over the associated group of ldraw parts, I might even let the user manipulate the individual parts inside the group or whole model not sure about that yet.

Stephen Wrote:... thus automatically generating a brick-by-brick build animation of an entire model regardless of whether the model is flattened first or left in a sub-model/structured state...

The current LDCad version supports editing a multi file model at the top level as if it were a single flat model, it's called the nesting mode. While this mode is active you can also create groups out of parts living in different files. It will be those groups you can manipulate (realtime) using LUA scripts during a special animation mode.

Stephen Wrote:... example http://www.youtube.com/watch?v=Aj4AUgJApys). I also use this technique to assist in automatically disabling sub-models which are not visible within specific ranges of frames (or still renders) in order to reduce the memory footprint and speed up the render times.

Great animation

Stephen Wrote:The example script you gave is in fact very similar to the code I inject into the .pov file for cyclic animations, so for someone of my skills I feel you are going about this the right way. The choice of language matters more to the developer than the end user, as long as it has access to stuff like sin/cos/tan/asin/acos/atan/sqrt and preferably also inbuilt functions for splines and beziers.

fun thing about LUA is you can get additional stuff from else where, but I will be supplying built-in functions for most logical LDraw / animation related things. And I could always add things upon request.

Stephen Wrote:It's clearly too complex for a non-programmer, but in my experience those type of people would only attempt an animation if they had some sort of simple "wizard" to generate the script or animation sequence for them

You are right about that, the reason I'm only going to do the scripting route is because my full GUI animation software (LD4DStudio) was still considered to hard by most, so I simply won't even implement the 'easy' way. But supplying wizards at some point is a good idea, I might even be able to make those plugin based so others could add them for me Smile

Stephen Wrote:...One thing I would like to say about that example script. Your example uses relative position calculations on each frame. That's fine, for many cases. But I've found that in most of my cases I prefer the ability to perform absolute calculations based upon PovRay's frame_number.

Yes in the example it's relative, but it won't be limited to that. The two main functions will have no or very little parameters, but things like frame rate and current frame etc will be accessible through global functions/variables. Also the script won't be exclusive for just animation, it will also be possible to use them for 'action response' e.g. the user spins an axle in the model, all the rest moves based on script calculations.

Stephen Wrote:The other thing that is unclear to me is what LDCad would be outputting here. Are you going to output a new unique .mpd for every frame and leave it to the user to convert these to a format suitable for raytracing?

The first goal is realtime animation inside LDCad it self, but later on I want to offer export to multiple mpd's / pov-ray simular to the export functionality of LD4DStudio.



Thanks for you thoughts on the issue.


Re: Thoughts on animation scripting language - Stephen - 2014-02-12

Roland Melkert Wrote:Thanks for you thoughts on the issue.
You're welcome.

Roland Melkert Wrote:it will also be possible to use them for 'action response' e.g. the user spins an axle in the model, all the rest moves based on script calculations.
That sounds good, and based on your obvious programming skills (I watched one of your videos even if I haven't run the software) I would say you're the perfect man for the job.

I wonder, have you ever used SolidWorks or similar? SW has a "mating" feature that allows you to define mating relationships between components via a point-and-click interface and dialog property boxes, so no script needs to be written. You can define for example a concentric relationship for rotational parts, and a coincident planar relationship for sliding parts, and you can further refine scaling (for gear ratios) or constraints in movement range, and so on.

You can then, for example, drag the steering wheel on a car to rotate it and the steering rack will move linearly and the wheels will turn left/right. Of course, you can also drag a wheel and cause the steering wheel to turn. Things do get a bit hairy though when a part has multiple degrees of freedom - when you drag a wheel on a car, are you trying to rotate the wheel on its axle, or are you trying to push the wheel against the suspension. Things can quickly get confusing with complex mating arrangements and the version of SW I've used does struggle at times.

If you managed any usable kind of interface for visually dragging a part (on a 3D view) and its mated parts (scripted or otherwise) then I think people would be impressed, especially in a free CAD application.


Re: Thoughts on animation scripting language - Roland Melkert - 2014-02-12

Thanks

Quote:have you ever used SolidWorks or similar? SW has a "mating" feature that allows you to define mating relationships between components via a point-and-click interface and dialog property boxes

I have never used Solidworks but the concept is familiar, I would love to implement this in LDCad, but I also know I will never be able to hard code every kind of interaction. This is why I chosen to go the scripting route.

The described behavior is something I want to be possible using the scripting environment, but I'm not yet sure how I'm going to handle the interaction. It's ether going to be using extra information on the groups, or maybe some kind of special LDraw meta you can move around like normal parts but will also supply interaction information to the script.

Linking groups (e.g. a robot arm) for relative movement must then be taken care of by the script, it can do so by reading the extra info like freedom of movement and angle etc.

At the moment I'm not even sure if I want things to work with a single script for the top level model (like in my example above) or using a script per group pairing/collection (a bit like the mating you wrote about) or both.


Re: Thoughts on animation scripting language - Tore Eriksson - 2014-02-17

Roland Melkert Wrote:While LUA or pearl might be very powerful, it also will be difficult for non programmer users ( I Think) to get started with. A simple custom language on the other hand will be much easier to learn but limited to basic single function formulas etc. Although I could expand the language over time.

In short I find it difficult to decide at the moment, so I was hoping for some additional thoughts.

I made a working proof of concept (called LDA) with focus on easy to understand. It was kind of a modified LDraw syntax combined with some BASIC-like commands. I believe if I have had the tenth of your programming skills, my concept would really have worked. And it would have been user friendly enough to become popular.

I tried LD4D a little, but to be honest I didn't understand anything at all. So I'd suggest you go for a little more limited in "powerfulness" but easier to get over the threshold of getting started. Some wizard to guide the user through the first steps would have been very helpful.

/Tore


Re: Thoughts on animation scripting language - Roland Melkert - 2014-02-17

Currently I'm working with the assumption to create a (very dynamic) LUA scripting environment only. On top of that I could later build wizards or automatic generation to help less experienced users.

API wise iI'm thinking about things like Matrix tools, LDraw group/model access and animation timers. A user then can use those lowlevel tools to write a script which will be able to animate a complete clock based on e.g. the winding tension or make technic figure do a walking sequence. And as LUA is extremly dynamic people could reuse (sub)scripts (aka modules) to reuse certain sequences or math solutions in other animations or build some kind of library of solutions to common problems. I'll be supplying the start of such a collection with things like gear / steering mechanics.

Is your LDA information online somewhere as I'm very open to suggestions.


The biggest problem with LD4D is/was it's interface I guess, it uses a object oriented interface which is very confusing for non programmers I have been told Smile

LDCad is more context and WYSIWYG orientated I'm not yet sure how to tie the scripts to the interface yet though.


Re: Thoughts on animation scripting language - Tore Eriksson - 2014-02-19

Roland Melkert Wrote:Is your LDA information online somewhere as I'm very open to suggestions.

No. I'm afraid most of it, like the latest tutorials and examples, were lost when I ended the contract with the ISP who hosted the webpages I stored them at. However, I did store something I called "Animation Start Kit" in a folder, along with what must be the latest version of the executable as recent as April 2011.

Animation Start Kit

If you want to test run the executable, it's a good idea to unpack all content not in a subfolder but directly into your LDraw\Models folder, because that is where LDA will write all its output files, the temporary as well as final ones. And, if you use Dropbox or similar, you need to temporarily pause the updating while LDA "compiles" or it will crash due to file access conflict.

I want to believe that most of the syntax is totally self-explaining. Most lines begin with [object_name].[command] followed by some arguments. From the smpl.txt file, a minifig object namned "Minifig01" is created by the line:

Code:
Minifig01.Load Scene 1  0 0 -10  0 0 1  0 1 0  -1 0 0  mf01.txt
The object Minifig01 is created by loading the file mf01.txt with the object Scene as parent and the LDraw color and matrix applied.

Inside the mf01.txt file, for example the object Minifig01.LeftHand is created on its parent object Minifig01.LeftArm with theis line:
Code:
Self.LeftHand.Create Self.LeftArm 14  5 18 -10  1 0 0  0 0.73 -0.64  0 0.64 0.73  983.dat
where every 'Self' is replaced by the object name from where it is called, in this case 'Minifig01'

Code:
Minifig01.Animation = MFWalk01.txt
tells LDA to apply the animation instructions in MFWalk01.txt on the object Minifig01.

And the walk looks like this:
Five Seconds in Datsville

Please feel free to ask if there is anything you'd like to know about LDA.
/Tore