The eternal struggle of Lightwave FBX exports continues...

Unity Engine
1

I know, we’re flogging a horse here, but I’m having issues with FBX exports from Lightwave. So I guess we need to discuss this (again).

I have Lightwave 10 and a backup, non-upgraded copy of 9.6 for certain compatibility reasons. Both 64-bit. So unless otherwise noted, assume that I’ve done all steps with both versions.

I set up a very basic test model, drew skelegons, imported to Layout. Converted skelegons to bones. This does not cause a problem within Unity.

The problems begin once I run Record Pivot Rotation on misaligned bones (a standard procedure so that you can turn them on every axis). Unfortunately, FBX doesn’t like this. So when I export (I’ve tried using the 2006, 2009, 2010, and 2011 exporters) and bring it into Unity, the result is a character that is contorted into a very disturbing wad (particularly on every bone I’ve run a RPR on).

As Lightwave users may know, some bones simply require RPR; especially things like shoulder or thigh bones, which are notorious for not orienting properly making it impossible to move them forward and back unless you get lucky. Not using RPR isn’t an option (unless someone has an alternative to RPR that doesn’t break my FBX files and still repairs rotations).

I understand this isn’t a problem with Unity, per se, probably an issue with Lightwave’s FBX exporter not dealing with RPRs on export. But I’m hoping someone here has had this issue and figured out a fix.

Since I do believe it’s a problem with the exporter, I just wonder if there’s any other exporter plugin for Lightwave (must be compatible with 9.6 or above, 64-bit) that does a better job handling FBX files (Lightwave’s sloppy manner of handling it even up to version 10 is very disappointing).

Or just any other solution that would prevent me from tearing more hair out would be welcome.

2

this might come as a shock, but: NOT using RPR actually IS the option!

i’m a Lightwaver myself and yes, RPR is a cool function but only inside Lightwave. it was created to avoid the problem of so called ‘Gimbal-Lock’ especially on simple bone rigs. (Gimbal-Lock: ‘over-rotation’ that makes an axis loose it’s orientation) but using it for content that is going to other platforms/applications will always produce crap.

you should get into the habit of using ‘GIMBAL-Bones’.

let’s say that we create a human arm rig, like: UppArmR > LowArmR > HandR.
you would probably create a 3 bones chain, rotate the bones into position and then use RPR to reset all angles to 0.

but you should create the chain like this:

create the first bone and name it ‘Gimbal_UppArmR’, add a child and name it ‘UppArmR’. reset the Z-position of ‘UppArmR’ back to 0, add a child and name it ‘Gimbal_LowArmR’, add a child and name it ‘LowArmR’, reset the Z-position of ‘LowArmR’ back to 0…etc.

‘Gimbal-UppArmR’ will only be used to position/rotate ‘UppArm’ into the default rest state. ‘Gimbals’ will NOT be ACTIVE, will NOT be animated and have a single keyframe only at frame 0. this way, the bones that will get animated have Rest-Position and Rest-Rotation all at 0 ! (in relation to their ‘Gimbal’ parents).

so, if after you animated but then decide to start over, just select all Active Bones (not the Gimbals), reset all angles (H,P,B) to 0 and you will have your default skeleton pose. it’s like RPR, only without.

besides having to create more bones (about twice) than with using RPR, it produces the same effect in a somewhat classic way which is compatible with almost every 3d app. in the end it’s generally more practical to use as standard bone-setup which should remain ‘tweakable’ in a simple way.

i uploaded a crappy little scene that exports quite nice as FBX for use in Unity3D. use it to study the bone structure. in this scene you can for example use the GIMBALS to offset the arms from the body without affecting the animated bones (for Gimbals, do this at frame 0).

http://www.sheep.ch/bones

i hope this helped.