31
Finished Works and Works in Progress / Re: Fun with Morphing
« on: May 30, 2015, 10:31:00 am »
I put an explanation with the scripts used for this video here: http://www.anim8or.com/smf/index.php/topic,5166.0.html
Anim8or Community
- June 23, 2025, 05:20:43 pm
- Welcome, Guest
News:
Ian Ross has just released a book on Anim8or. It's perect for a beginner and a good reference for experienced users. It contains detailed chapters on every aspect, with many examples. Get your own copy here: "Anim8or Tutorial Book"
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
32
ASL Scripts / Mesh to Mesh Morphing Hack
« on: May 30, 2015, 10:29:50 am »
Mesh to Mesh Morphing Hack:
The idea behind this technique for mesh to mesh morphing is to have an intermediate shape "between" the starting and ending mesh rather than flowing smoothly from the starting to the ending mesh. Direct morphing is prohibitive in Anim8or because it would require that one "map" specific areas of one mesh to the other mesh ahead of time. Theoretically, the mapping could be done with textures, but it would be very slow and laborious.
When I first started playing with this technique, I wrote a script that would convert any mesh into a simple shape like a sphere, cylinder, cube, or any other easily definable shape. Taking a mesh in Object Mode, creating a new "Morph Target" (Build->Morph Target->New...), then running the script, the points of the mesh are transformed to the desired shape. In Scene Mode, you can watch the original mesh change into the simple shape and back by adjusting the scene morph target keys.
The next logical extension to this is to take two different meshes and convert each of them to the same sized intermediate shape. In Scene Mode, you make the first mesh visible and unmorphed, the second mesh invisible and fully morphed, perfectly superimposed. When the first mesh is fully morphed, make it invisible, make the second mesh visible and proceed to unmorph it back to its original shape. You get the illusion that the first mesh flowed to the intermediate shape and then flowed into the second mesh. This looks pretty cool and has many possibilities on its own.
The next logical extension is to try to get the illusion of flowing somewhat more smoothly from the starting mesh to the ending mesh by using scripting that allows the starting mesh to be transformed so that it "shrink wraps" the ending mesh. Then, the ending mesh is transformed so that it "shrink wraps" the morph of the starting mesh. After that, the same visibility tricks in Scene Mode are used. That is how the video in http://www.anim8or.com/smf/index.php/topic,5165.msg38573.html is done.
A further note on "shrink wrapping" one mesh around another: I convert the mesh that will be the "wrapper" to a sphere (To_Sphere.txt)that is larger than the target before applying the "shrink wrapping" script (ShrinkWrap_Target.txt).
The idea behind this technique for mesh to mesh morphing is to have an intermediate shape "between" the starting and ending mesh rather than flowing smoothly from the starting to the ending mesh. Direct morphing is prohibitive in Anim8or because it would require that one "map" specific areas of one mesh to the other mesh ahead of time. Theoretically, the mapping could be done with textures, but it would be very slow and laborious.
When I first started playing with this technique, I wrote a script that would convert any mesh into a simple shape like a sphere, cylinder, cube, or any other easily definable shape. Taking a mesh in Object Mode, creating a new "Morph Target" (Build->Morph Target->New...), then running the script, the points of the mesh are transformed to the desired shape. In Scene Mode, you can watch the original mesh change into the simple shape and back by adjusting the scene morph target keys.
The next logical extension to this is to take two different meshes and convert each of them to the same sized intermediate shape. In Scene Mode, you make the first mesh visible and unmorphed, the second mesh invisible and fully morphed, perfectly superimposed. When the first mesh is fully morphed, make it invisible, make the second mesh visible and proceed to unmorph it back to its original shape. You get the illusion that the first mesh flowed to the intermediate shape and then flowed into the second mesh. This looks pretty cool and has many possibilities on its own.
The next logical extension is to try to get the illusion of flowing somewhat more smoothly from the starting mesh to the ending mesh by using scripting that allows the starting mesh to be transformed so that it "shrink wraps" the ending mesh. Then, the ending mesh is transformed so that it "shrink wraps" the morph of the starting mesh. After that, the same visibility tricks in Scene Mode are used. That is how the video in http://www.anim8or.com/smf/index.php/topic,5165.msg38573.html is done.
A further note on "shrink wrapping" one mesh around another: I convert the mesh that will be the "wrapper" to a sphere (To_Sphere.txt)that is larger than the target before applying the "shrink wrapping" script (ShrinkWrap_Target.txt).
33
Finished Works and Works in Progress / Fun with Morphing
« on: May 27, 2015, 08:02:13 pm »
I wrote a script to help morphing from one mesh to another. It is kind of a hack where one superimposes the ending mesh on the starting mesh and runs the script while in the morph, then does the opposite (the starting on the ending) then uses scene mode visibility tricks.
34
ASL Scripts / ASL Command render() always crashes Anim8or
« on: February 02, 2015, 10:06:17 am »
Has anyone ever successfully used the render() command in an ASL script? I have tried to use it off an on since V0.95, but it always crashes Anim8or.
I like to write scripts to do physics simulations, but these type of scripts only work object mode. (See topic http://www.anim8or.com/smf/index.php/topic,2358.msg25814.html#msg25814 for tricks required to render.) It would be nice to be able to render the results of the simulations more easily. Rendering from object mode is not ideal, but perhaps workable.
Another possibility is an Object Mode ASL command to switch to Scene Mode and render and save a particular frame before continuing: RenderSceneFrame(int Frame,string Filename)
Any thoughts?
I like to write scripts to do physics simulations, but these type of scripts only work object mode. (See topic http://www.anim8or.com/smf/index.php/topic,2358.msg25814.html#msg25814 for tricks required to render.) It would be nice to be able to render the results of the simulations more easily. Rendering from object mode is not ideal, but perhaps workable.
Another possibility is an Object Mode ASL command to switch to Scene Mode and render and save a particular frame before continuing: RenderSceneFrame(int Frame,string Filename)
Any thoughts?
35
General Anim8or Forum / Re: SMD skeleton to an8 skeleton
« on: December 29, 2014, 04:54:07 pm »
Smirkguy,
The attached zip file contains the SMD2Anim8or conversion executable. It works with all three of the SMD files you gave links to.
NickE
The attached zip file contains the SMD2Anim8or conversion executable. It works with all three of the SMD files you gave links to.
NickE
36
General Anim8or Forum / Re: SMD skeleton to an8 skeleton
« on: December 28, 2014, 08:38:03 pm »
Smirkyguy,
I do not have any other SMD example files to work from except the ones from Deepthough. If you would post some files, I can try to alter the program to work with them. The source code has been posted earlier, if you'd like to do it yourself.
NickE
I do not have any other SMD example files to work from except the ones from Deepthough. If you would post some files, I can try to alter the program to work with them. The source code has been posted earlier, if you'd like to do it yourself.
NickE
37
General Anim8or Forum / Re: 3d Printing with Anim8or
« on: December 16, 2014, 04:23:03 pm »
I regularly use Anim8or to produce models for 3D printing. I designed many upgrade parts for my 3D printer in Anim8or, and then printed them on my Kossel 3D printer. I like designing my robot prototypes in Anim8or because I can then animate the robot to see if the parts will actually go together and move correctly before I print them.
38
General Anim8or Forum / Re: SMD skeleton to an8 skeleton
« on: December 03, 2014, 09:05:46 am »
In the SMD format, the skeleton is represented explicitly by joints (or the vertices between bones). The "bones" in SMD format are implicit. In AN8 format, the skeleton is represented explicitly by bones, and the joints are implicit. To be able to map orientation, motion, and skinning from SMD to AN8, one must convert the explicit joints to explicit bones. This requires that the implicit bone after the last joint in the SMD kinematic chain be formed explicitly in the AN8 kinematic chain. If it is not done, there is no AN8 structure to carry the motion of the last SMD joint.
Dizzy yet? Me too, just from writing that. It is much easier to see in the picture.
Dizzy yet? Me too, just from writing that. It is much easier to see in the picture.
39
General Anim8or Forum / Re: SMD skeleton to an8 skeleton
« on: December 02, 2014, 03:31:50 pm »
I have attached a zip file containing the VB 2013 source code for the SMDtoAnim8or converter. The previous executable I posted was written in VB6. I did the minimum required to port it to VS 2013 VB and tested it to be sure it works.
The source code for the converter (especially the parsing routines) is very inefficient in VB.net terms given it is minimally changed from VB6. There are nice parsing libraries available in VB.net, but I did not take the time to implement them.
VS 2013 Community version is free (takes forever to install) if you want to compile or modify it.
In this converter, unlike the BVH converter, the program calculates the joint offsets, then the figure's bone orientation from the offsets. I implemented it this way since the SMD format is not in hierarchical format (unlike BVH), so the parent/child relationships are not known until all the bones are read. It was easier to calculate the offsets first (in this case), then the orientation rather than the other way around. The math concepts are the same.
I explained the difficulties in writing this kind of converter in http://www.anim8or.com/smf/index.php/topic,4861.msg36976.html#msg36976
NickE
The source code for the converter (especially the parsing routines) is very inefficient in VB.net terms given it is minimally changed from VB6. There are nice parsing libraries available in VB.net, but I did not take the time to implement them.
VS 2013 Community version is free (takes forever to install) if you want to compile or modify it.
In this converter, unlike the BVH converter, the program calculates the joint offsets, then the figure's bone orientation from the offsets. I implemented it this way since the SMD format is not in hierarchical format (unlike BVH), so the parent/child relationships are not known until all the bones are read. It was easier to calculate the offsets first (in this case), then the orientation rather than the other way around. The math concepts are the same.
I explained the difficulties in writing this kind of converter in http://www.anim8or.com/smf/index.php/topic,4861.msg36976.html#msg36976
NickE
40
General Anim8or Forum / Re: SMD skeleton to an8 skeleton
« on: December 01, 2014, 10:30:43 am »
Deepthought,
Attached is a program that will convert the SMD files you posted to an8 format. I will only do the object and figure, since none of the files you posted contain animation. I do not have any other SMD files to test with, so it may not work with other SMD files that vary in format, spacing, white spaces, etc.
Sorry this took so long. Family medical problems have kept me far from home the last several weeks. I'll post the source code when I get a chance to clean it up.
NickE
Attached is a program that will convert the SMD files you posted to an8 format. I will only do the object and figure, since none of the files you posted contain animation. I do not have any other SMD files to test with, so it may not work with other SMD files that vary in format, spacing, white spaces, etc.
Sorry this took so long. Family medical problems have kept me far from home the last several weeks. I'll post the source code when I get a chance to clean it up.
NickE
41
General Anim8or Forum / Re: .an8 Format, jointangles, how are they stored?
« on: December 01, 2014, 09:56:57 am »
Converting other animation files to Anim8or is complicated not because of the math, but because the other animation formats have different skeleton standards and frames of reference. The first hurdle in converting formats is finding a way to correlate the foreign skeleton to an Anim8or skeleton. I found this to be the most challenging part because of two things: (1) most foreign formats use joints and Anim8or uses bones, and (2) the reference frames of foreign formats differs from Anim8or's. Once you solve the correspondence of foreign joints/bones to Anim8or's bones, you must deduce the the difference in world reference frames and rotate the skeleton into Anim8or's world reference frame.
The next challenge is deducing the reference frame of the foreign bone's orientation. In Anim8or, the orientation of each bone is relative to the parent (BVH and SMD are similar in that respect), but the reference frame in Anim8or is y-axis along the bone, left-handed axis system. What is the foreign format reference frame axis system?
The foreign format's often give Euler angles for orientation, but does it use XYZ, YXZ, ZYX or other order? This must be deduced. Internally, Anim8or uses quaternions, so Euler to quaternion conversions must be done. The math for this conversion is different depending on what the world and local reference frame axis systems are.
These problems, coupled with the brain-twisting non-intuitiveness of quaternions will make your brain explode! Each part of the conversion of a foreign format to Anim8or's is dependent on the previous part. You can get all but one step correct and the result will look as wrong as getting them all wrong.
The math (and code for the math) itself is fairly straightforward. Pretty much everything you need to know math-wise can be found on Martin Baker's site http://www.euclideanspace.com/maths/geometry/
The next challenge is deducing the reference frame of the foreign bone's orientation. In Anim8or, the orientation of each bone is relative to the parent (BVH and SMD are similar in that respect), but the reference frame in Anim8or is y-axis along the bone, left-handed axis system. What is the foreign format reference frame axis system?
The foreign format's often give Euler angles for orientation, but does it use XYZ, YXZ, ZYX or other order? This must be deduced. Internally, Anim8or uses quaternions, so Euler to quaternion conversions must be done. The math for this conversion is different depending on what the world and local reference frame axis systems are.
These problems, coupled with the brain-twisting non-intuitiveness of quaternions will make your brain explode! Each part of the conversion of a foreign format to Anim8or's is dependent on the previous part. You can get all but one step correct and the result will look as wrong as getting them all wrong.
The math (and code for the math) itself is fairly straightforward. Pretty much everything you need to know math-wise can be found on Martin Baker's site http://www.euclideanspace.com/maths/geometry/
42
Anim8or v0.98 Discussion Forum / Re: [Bug Report] - Switching to Sequence Mode or Scene Mode Crashes Anim8or
« on: November 17, 2014, 08:43:16 am »
With fixing the framerate issue, you can switch to the Sequence or Scene Mode without Anim8or crashing, but if the figure is clicked while in Skinning mode, then changed to Sequence or Scene Mode, Anim8or crashes.
Can anyone see anything wrong with the bone weighting section of the an8 file?
Thank you,
NickE
Can anyone see anything wrong with the bone weighting section of the an8 file?
Thank you,
NickE
43
Anim8or v0.98 Discussion Forum / Re: [Bug Report] - Switching to Sequence Mode or Scene Mode Crashes Anim8or
« on: November 17, 2014, 08:18:45 am »
MvGulik,
Good catch! Thank you so much!
NickE
Good catch! Thank you so much!
NickE
44
Anim8or v0.98 Discussion Forum / [Bug Report] - Switching to Sequence Mode or Scene Mode Crashes Anim8or
« on: November 16, 2014, 03:23:12 pm »
If the attached an8 file is opened and switched to Sequence Mode or Scene Mode, Anim8or crashes. Oddly, if the figure (and object) are imported into another an8 project, the figure can be added to a sequence and work as long as the figure is not modified. If an attempt is made to alter the figure, Anim8or will crash.
This file was created by a prototype SMD file importer (similar to the BVH importer) that I am writing. This crashing behavior occurs regardless of whether the object is added to the skeleton. A bare skeleton causes the same behavior.
Any insight would be appreciated.
Thank you,
NickE
This file was created by a prototype SMD file importer (similar to the BVH importer) that I am writing. This crashing behavior occurs regardless of whether the object is added to the skeleton. A bare skeleton causes the same behavior.
Any insight would be appreciated.
Thank you,
NickE
45
General Anim8or Forum / Re: SMD skeleton to an8 skeleton
« on: November 09, 2014, 08:37:19 am »
Deepthought,
Is it your intention to (1) gain the experience and satisfaction of having written a converter for SMD files for Anim8or or (2) do you just want something that works?
If (1), then you need to gain a thorough understanding of the both the SMD file format(s) and reference frames and Anim8or's conventions for handling figures, sequences, and scenes. The code in the BVH converter is not going to make sense unless you understand those concepts. In a nutshell, the code reads and parses a BVH file, constructs an Anim8or figure, constructs a sequence for the non-positional movements, and then constructs a scene containing the figure and sequence so that position can be added. In Anim8or, the figure's root bone is relative to the world coordinate system, but each child bone is relative to it's parent. A cursory reading of the SMD format suggests the same arrangement (although it is not completely clear), but the world coordinate system is different from Anim8or's.
The math part essentially steps through the bones, rotates the bones into the reference frame, performs the relative rotation of child to parent, then rotates them back.
If (2), I'd be happy to help you out if you can be patient. I would need some sample SMD's and either some viewer program or screenshots to see what the SMD file is supposed to look like. My first guess is that the BVH conversion program can be easily adapted by writing a new parsing routine and other small changes.
NickE
Is it your intention to (1) gain the experience and satisfaction of having written a converter for SMD files for Anim8or or (2) do you just want something that works?
If (1), then you need to gain a thorough understanding of the both the SMD file format(s) and reference frames and Anim8or's conventions for handling figures, sequences, and scenes. The code in the BVH converter is not going to make sense unless you understand those concepts. In a nutshell, the code reads and parses a BVH file, constructs an Anim8or figure, constructs a sequence for the non-positional movements, and then constructs a scene containing the figure and sequence so that position can be added. In Anim8or, the figure's root bone is relative to the world coordinate system, but each child bone is relative to it's parent. A cursory reading of the SMD format suggests the same arrangement (although it is not completely clear), but the world coordinate system is different from Anim8or's.
The math part essentially steps through the bones, rotates the bones into the reference frame, performs the relative rotation of child to parent, then rotates them back.
If (2), I'd be happy to help you out if you can be patient. I would need some sample SMD's and either some viewer program or screenshots to see what the SMD file is supposed to look like. My first guess is that the BVH conversion program can be easily adapted by writing a new parsing routine and other small changes.
NickE