LÖVE

Hi, I was looking for the fastest way to have 2D animated meshes in LÖVE, so I wrote this demo.
I modeled, rigged and animated something in Blender, then wrote a Python script to export that model as a .Lua script (easier to load with LÖVE than JSON or XML, which would require an external library).

If you think of any ways to speed this up, let me know!



Code and assets:
https://github.com/RNavega/2DMeshAnimation-Love2D

Two things i could recommend;

1. Put [0] = in front of the first datapoint in your loaded lua file, that way you dont have to use that 0-reindexing function with the costly table.remove the first element call (since it needs to move all others up one as well)... even if it just happens once at asset load time.

2. Get rid of love.timer.sleep from your update function. Either use a timer and/or use vsync... preferrably the former, at least.

Hi zorg, thanks for the tips!

zorg wrote: ↑Sun Aug 16, 2020 2:58 pm 1. Put [0] = in front of the first datapoint in your loaded lua file

Good point, the behavior will be the same but should speed up load time.

2. Get rid of love.timer.sleep from your update function. Either use a timer and/or use vsync... preferrably the former, at least.

When you say "use a timer", do you mean something like using 'dt' or os.clock() to manually measure time, and sleeping for only the time needed to complete the 33ms frame time, or something else?
Oh, I was also thinking of overriding love.run(), like a framerate limiting mechanism could work better in there. It's great that LÖVE lets us have full control over the main loop.

...and I just noticed that the SpriteBatchUsage in the love.graphics.newMesh() call is set to 'dynamic', when it should've been 'stream'. I think I changed it during testing, I'll change it back.

I meant that since love.run already sleeps 1ms so a cpu core's not consumed completely (and even more if you have vsync on... althouh that kinda depends on the graphics driver), you can just use a variable to accumulate dt in love.update, and if it's over your target, change the frame, and subtract the target from the accumulator;

Sleeping like you did it might work for one mesh/animation/whatever (although it is still not the best option), but it won't for multiple simultaneous ones, basically. (Whereas multiple timers will)

This looks really cool - any plans to turn it into a kind of small module somehow and/or document how you did the exporter for Blender?

I thought about doing some kind of multilayered mesh animations for short/simple cut scenes (mission briefings etc.) in our game using Spine as an editor but Blender would be an even more attractive option.

@Nelvin I'll get back to you on that, had to worry about something first.

I updated the demo!

• The deformation algorithm is faster now, after I figured which parts could be optimized.
• Added a GPU-based algorithm, doing hardware-accelerated skinning. On my system it's 10x faster than the CPU method. You can go in the code and switch between these two methods.
• Added support for animated shape keys (AKA morph targets), on both algorithms. Very important for character animation, besides skeletal deformations.
• Added an exporter add-on for Blender 2.79 (the version that I use). This one took a long time to make... You can grab it in the github repo.

https://github.com/RNavega/2DMeshAnimation-Love2D

Anyway, the speed improvements encouraged me to test a higher density mesh, it now has 4202 vertices (the original had 184 I believe):

Hi RNavega,

cool stuff, i am a bit new to blender and have installed 2.83.
I had to make quite some changes to the python script, but i *think* its working. (its exporting some other blend files now)

could you put the original .blend file in the repo so i can test if the output is identical?
Ill make a PR if i am a bit more certain the code update went ok.

[Edited]

The exporter now should work with Blender 2.79+, including the 3.x series.