In June 2014 I defended my Master’s Thesis: Fluid Morphing for 2D Animations. The thesis includes a C++ library and demo programs that allow arbitrary *.PNG images to be morphed in a fluid and fully automated fashion. The paper can be accessed here:
http://hyena.net.ee/ut/pdf/FluidMorphingThesis.pdf
For the original demo of the library I used Allegro 5 and thus I believe I have good reasons to create this topic here. What is more, on page 16 of the original paper I refer to the allegro.cc forums. The thesis is primarily dedicated to game developers and thus I believe these forums suit well for such an announcement.
You can download the source code here:
http://atomorph.org/atomorph-1.0-linux.tar.gz
I also suggest checking out my blog entry: http://www.hyena.net.ee/?p=199
Development footage featuring Allegro 5 is below:
https://www.youtube.com/watch?v=kDR5F5Uan9k&list=PLcMZtKdjvcmIMZBG1X6Y7-j72O9YPxkun
Some notable results produced with the atomorph library:
{"name":"montage_berry.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/5\/e58af451e35904999e4cf41e28a17d34.jpg","w":576,"h":432,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/5\/e58af451e35904999e4cf41e28a17d34"}
{"name":"test_regenmorph.gif","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/5\/a5ce402b28d88e5f6ef5fb42b203c479.gif","w":300,"h":400,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/5\/a5ce402b28d88e5f6ef5fb42b203c479"}
Other images are here: http://atomorph.org/img/
Very impressive! Can images be morphed in real time?
Real time morphing is possible and all the development footage is actually real time!
That was an interesting read
If I have the time, I'm definitely going to play with this.
Very nicely done.
You've got some pretty great results here!
I downloaded your pdf and src. I will be sure to read them over later.
Wow, this looks great. Is it all MIT licensed? I'll probably try to port it to C so I can use it in my own game engine..
Oh, my gosh. This is absolutely amazing.
This may or may not go perfectly with my previous goal of creating a 2-D in 3-D sprite engine. Basically, skeletal animation for 2-D linkages plus "doom style" billboard sprites (for each "limb" piece) that change for given camera angles. "Morphing" could provide intermediate stages to reduce source sprite development time and provide un-intuitive merges.
The goal would be fluid isometric skeletal animation, ala Crusader: No Remorse with unlimited sprites.
{"name":"2-00-03.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/b\/8b66245c5e68f9eea46e8c167caf4595.jpg","w":640,"h":480,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/b\/8b66245c5e68f9eea46e8c167caf4595"}
Here's a preliminary question: Is it possible to "morph" to an intermediate stage between 3 (or more) different pictures?
Lastly: How did you get approved to do a Master's thesis on 2-D sprites?
I would love to build this, but MinGW 4.8.1 doesn't support std::thread yet, even though the <thread> header is there. Or else I'm doing something wrong trying to compile it.
I can't even get this :
#include <thread> int main(int argc , char** argv) { std::thread t; return 0; }
to compile, even with -std=c++11 or -std=gnu++11. It says 'thread is not a member of namespace std'.
Couldn't you just use pthreads, instead of trying to support experimental features?
Hyena_: Hey, did you ever file that std::modf bug with GNU?
Couldn't you just use pthreads, instead of trying to support experimental features?
Or, you know, use a development platform that includes support for modern features. Perhaps you should update MinGW?
Reminds me of Kai's power tools photo morpher that was all the rage back in the mid-late 90's.
Or else I'm doing something wrong trying to compile it.
You might be, this compiles fine for me with MinGW.
On my compiler, g++ -v outputs:
Specifically of interest is "enable-threads=posix", maybe your binary is built without threading support?
I might not have enough personal motivation to continue the development, thus I decided to at least deliver the proof of concept for the interested parties to see as an inspiration. The atom cloud morphing is a really simple concept and could just be implemented application-specifically. Many game developers prefer to build their own sprite engine for example. Atom cloud morphing should be seen as a potential side aspect of that engine instead of a separate library.
I've never been part of any open source project development and I'm mostly a solo programmer. However, should the atomorph library spark interest in some veteran open-source developers I'd be happy to cooperate. For that purpose I have registered the domain names atomorph.org and atomorph.com.
Answering all the questions made so far.
Is it all MIT licensed?
All of the code I personally have written is MIT but you might want to check out Appendix D (it originates from http://svn.lam.fr/repos/glnemo2/trunk/).
Is it possible to "morph" to an intermediate stage between 3 (or more) different pictures?
If I understand correctly then you mean taking a weighted average of multiple pictures. Please see page 68 (N-way fluid morphing). I believe what you are asking for is easily possible but requires a custom implementation of the atom cloud morphing procedure.
How did you get approved to do a Master's thesis on 2-D sprites?
I told my idea to the director of my study programme and he allowed me to do such a thesis. In retrospect I can say that the thesis turned out to have strong connections with typical data mining tasks. Data mining was a mandatory part of the software engineering programme. In my institute they value it greatly if the student has their own research ideas for the thesis. My bachelor's thesis was about random world generation for example (http://www.hyena.net.ee/?p=127).
Couldn't you just use pthreads, instead of trying to support experimental features?
I believe it's time to get used to C++11. For a full-blown library it might not be the best idea just yet but for a proof of concept library it can be justified.
Hyena_: Hey, did you ever file that std::modf bug with GNU?
No I did not it's hard to believe that they don't know about it. I suspect they would answer "it's not a bug, it's a feature" because that's how double arithmetic works --- sometimes 1.0 turns into 0.(999)?
One more thing. You said it runs on real-time, which is GREAT!
Did you try a load test to see at what point it became slow? 10, 100, 1000 sprites, etc?
And on what hardware did you test this on?
@Slartibartfast
My gcc -v says "... --enable-threads ..." but there's no "=posix" there. Apparently plain mingw doesnt' support threads but mingw-64 does.
Plain MinGW cannot support std::thread. You will need to use a MinGW-w64 toolchain (such as those shipped with Qt 5) that has "posix" threading enabled, so that libstdc++ exposes the <thread>, <mutex> and <future> functionality.
You can find an installer here, but you can also try just replacing the whole mingw toolchain root folder with one of these packages. You can choose 32- or 64-bit, remember to select threads-posix if you want to play with std::thread and friends. No special compiler options other than the ones you already have are needed. I do suggest using -std=c++11 if you don't need GCC 4.6 compatibility.
That's a real pita. I just upgraded to 4.8.1 not that long ago for C++11 support and it turns out it doesn't actually have full support. And only MSVC 2010 is supported on Vista so I can't use MSVC either. What was MinGW thinking, not supporting something like std::thread?
You simply have to switch to a mingw-64 toolchain, no need for it to be a 64-bit one thou.
Plain Mingw is outdated and behind.
Well I have MSYS2 and mingw-w64 installed, and it successfully built the library and atomorph.exe. I'll try them out later.
Personally, I do all my development in a Linux VM inside Windows 7. I didn't use to, but I love it now.
Chris Katko: I have not load tested it.
Once you have computed a morph of satisfactory quality you can stop seeking for better morphs and just use the one you have found. It will no longer consume processing power. However, if you also enable fluid simulation then it gets pretty slow.
edit:
I strongly suggest using a Linux environment for testing out the library because I have included a whole lot of automated tests as shell scripts. These tests make up a pretty good example set of how to use AtoMorph.
For example, a "rotating" green star is produced with the following script: