Anim8or Community

Please login or register.

Login with username, password and session length
Advanced search  


An update to Anim8or, v1.00b, is available with a few bug fixes. Get your copy HERE. See the "ReadMe" file for details.

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.

Messages - NickE

Pages: 1 [2] 3 4 ... 11
ASL Scripts / Re: BVH File Import into Anim8or
« on: July 03, 2015, 03:26:30 pm »

The file from the link is working fine for me.  I have attached the latest version of the program (executable and source) and the an8 file from the conversion.  The latest version is smarter about white space in the bvh file than the previous version.  I found that GoldenEye bvh files tend to use multiple spaces as a separator rather than the single space or tab.  In the previous version, multiple spaces as a separator would cause parsing errors.

The only parameter I changed in BVH2Animator is the scale factor to 0.15, so the figure (originally at 638) would not be so large (more like 100).

ASL Scripts / Re: BVH File Import into Anim8or
« on: June 15, 2015, 11:33:03 pm »
The missing pieces of required information is the reference frames for the rotations.  Does FBX use a right-handed or left-handed reference frame?  Are the skeletal orientation given in the global reference frame, object reference frame, or local reference frame?  Are the keyframe joint rotations given in the global reference frame, object reference frame, or local reference frame?

Since you already have the Anim8or skeleton constructed from the FBX file, you have some knowledge of the FBX reference frame.  Otherwise the skeleton would be distorted or rotated.   So, essentially what you need to do is transform the FBX Euler rotation angles from whatever reference frame they are in to the Anim8or local bone reference frame (the rotation of the bone relative to the parent).

The BVH2Anim8or source code routine "Calc_Figure_Orientation" calculates the each bone orientation relative to its parent bone.  The root bone (the ultimate parent) is located in the Anim8or global reference frame Left-Handed (0,1,0).  The routine "Calc_NetOrient" calculates the each bone orientation relative to the Anim8or global reference frame.  The routine "Calc_Sequence_Motion" transforms the BVH keyframe joint rotations to the Anim8or local bone reference frame.

I know this is very confusing and extremely frustrating.  While writing the BVH2Anim8or and SMD2Anim8or converters, I kept having to remind myself "What frame I am in?  What frame do the actions take place?  What frame does Anim8or need?"

ASL Scripts / Re: BVH File Import into Anim8or
« on: June 14, 2015, 11:45:39 pm »
All the math you need is in the BVH2Anim8or code.  I have also attached a SMD2Anim8or source.  It does something very similar. 

Anim8or does not use a 3 axis-angle format.  Anim8or uses quaternions to encode the orientation of the bone relative to its parent.

Do you have a link to the FBX format specification where it describes the reference frame for the bone orientations?

Please read the thread,5005.msg37381.html#msg37381 for some discussion of the math required.

ASL Scripts / Re: BVH File Import into Anim8or
« on: June 14, 2015, 09:04:46 pm »
Can you please be more specific about what you are trying to do?  Euler angles relative to what?  Is there a source format you are using?

ASL Scripts / Re: BVH File Import into Anim8or
« on: June 13, 2015, 12:37:16 pm »
The source code is for Visual Studio 2013 (available free).


ASL Scripts / Re: Mesh to Mesh Morphing Hack
« on: May 30, 2015, 03:51:28 pm »
I am sorry I did not explain the process very clearly.  I will post a step-by-step tutorial soon.

Until then, attached is the an8 file used to do the video.

Finished Works and Works in Progress / Re: Fun with Morphing
« on: May 30, 2015, 02:31:00 pm »
I put an explanation with the scripts used for this video here:,5166.0.html

ASL Scripts / Mesh to Mesh Morphing Hack
« on: May 30, 2015, 02:29:50 pm »
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,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).

Finished Works and Works in Progress / Fun with Morphing
« on: May 28, 2015, 12:02:13 am »
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.

ASL Scripts / ASL Command render() always crashes Anim8or
« on: February 02, 2015, 03:06:17 pm »
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,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?

General Anim8or Forum / Re: SMD skeleton to an8 skeleton
« on: December 29, 2014, 09:54:07 pm »

The attached zip file contains the SMD2Anim8or conversion executable.  It works with all three of the SMD files you gave links to.


General Anim8or Forum / Re: SMD skeleton to an8 skeleton
« on: December 29, 2014, 01:38:03 am »
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.


General Anim8or Forum / Re: 3d Printing with Anim8or
« on: December 16, 2014, 09: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.

General Anim8or Forum / Re: SMD skeleton to an8 skeleton
« on: December 03, 2014, 02:05:46 pm »
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.

General Anim8or Forum / Re: SMD skeleton to an8 skeleton
« on: December 02, 2014, 08: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 terms given it is minimally changed from VB6.  There are nice parsing libraries available in, 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,4861.msg36976.html#msg36976


Pages: 1 [2] 3 4 ... 11