Monthly Archives: June 2017

More FBX — this time with Mixamo and Babylon.js

Ah, yes! FBX, the sodding nightmare that just keeps on giving. I just want to get on and do some programming! Is that too much to ask?!?

Model source Mixamo’s Pearl.fbx (other formats supported: DAE and BVH).

Babylon.js has no built-in support for FBX  , requiring conversion with their

Unity3D ➔ Babylon exporter

It looks like normals are inverted, clipping is set incorrectly or something similar.

Additionally, the normal map texture needs to be marked as such. Fixing that is only a slight improvement.

After a bit of research it turns out to be a transparency setting.

Now we’re cooking.

Babylon standalone converter

Nope! It looks inside out.

The import shows similar problems Unity. Unfortunately, despite messing around with normals, winding order and transparency in Babylon, I haven’t been able to rescue the model.

Blender3D ➔ Babylon exporter
The Blender exporter really choked on this model.
The import looks OK, apart from the missing textures.

Dude! Where’s my textures???

However, it complained about being unable to export due to an armature.

Oh noes!

Once the armature was removed, something was exported.

Lookin’ shady. Too shady.

I’m not a user of Blender (I’m not a fan of it’s idiosyncratic interface, and dammit! I’m a doctor… er, programmer not an artist) so I called time on this abortive effort.

Clara.io
Clara.io doesn’t quite make it. Which is a pity as I really like it.

Eye-balls around the ankles is not a good look

Alas, the foot ‘n’ balls issue persists in the export.

Summary
FBX is a complex and proprietary format, clearly not all APIs can handle all the variations. We should probably be grateful that we get any import functionality.

Ultimately, this is a win. I have at least one viable fall back should PlayCanvas fail. I’m also hoping that the Three.js FBX importer gets the kinks ironed out and comes on line soon.

There is further research to be done, e.g. with glTF and JSON formats.

FBX with PlayCanvas

I decided to use the “Pearl” model from Mixamo to experiment with animation and (as it turns out) importing FBX files.

Importing into PlayCanvas is straightforward, simply drag and drop the FBX into the assets area. PlayCanvas converts the file to JSON format with associated textures (in PNG format) and materials. You end up with two JSON files (not sure why) but it’s fairly obvious which is the one to use.

The model can now be added to the scene.

There were problems with the eyes, they were black and the eyelashes were solid black.

Dear god! No!

Frankly after a long day I was fed up and knocked off for the day, after leaving a request for help on the PlayCanvas forums.

After some very helpful suggestions by Steven Yau, I was able to tweak some settings to correct the model.

A black specular colour tint fixed the eyes.

Looking good

Setting the opacity blend type to alpha fixed the black eyelashes, but caused them to act as a stencil straight through the poor model’s head when viewed from below.

Will the horror never end!?!

Setting opacity “alpha to coverage” fixed the clipping eye syndrome.

Finally! Yay!!!

Maybe now I’ll be able to get on with coding… nah… ¯\_(ツ)_/¯

Down the rabbit hole with FBX

PlayCanvas

PlayCanvas does an admirable job of importing FBX models and animations, but animation control seems limited. In particular, there seem to be no events for animation start, end, etc.

Animated Sackboy

This immediately prompted me to stop and reassess all my requirements (and not just animation).

Workflow

  1. I felt that I would almost certainly need more control over animation events than PlayCanvas provides.
  2. PlayCanvas only has version control (very important) for legacy scripts.
  3. A fall back is needed if PlayCanvas fails for some reason (e.g. it’s cloud based, so poor internet or even just high contention would be problematic).

Using an API would immediately address issues 2 and 3. This leaves FBX support as the main issue.

It’s apparent that game creation requires a smooth workflow. Easily getting assets into the game is very important, regardless of their source. Be it pre-existing from a store or newly created by an on-site 3D artist, assets have to come from somewhere, and FBX is one of the more common formats particularly for animation. FBX support is very important.

Checking out the main alternatives:

Babylon.js

Babylon.js doesn’t support FBX directly. I was advised to use the Babylon exporter for Unity or Blender. Alas, the results were not impressive.

Source model (Pearl.fbx) as should be

Model after exporting to Babylon (from Unity and Blender)

Clara.io has an “export to Babylon” option, unfortunately its own FBX import is lacking, and I’m still trying to work out how to add animation to a model.

Model after import into Clara.io

Three.js

Three.js currently only supports ASCII FBX not binary (Takahiro is doing some sterling work to add binary FBX).

Current state of FBX import to Three.js (not released yet)

So, it may be a contender if support is available in time, but for now it’s back to PlayCanvas.

Conclusion (if you can call it that)

Converting 3D assets seems inevitable, to reduce file size and minimise load time (even PlayCanvas converts FBX to JSON).

I will look into FBX – glTF or JSON converters, but for now I’m returning to PlayCanvas (in fact, PlayCanvas engine is also available, so it’s its own fallback).

Choosing a framework/engine

Naturally, I want to work on a WebGL based game. This automatically makes it web based with all the attendant benefits and disadvantages.

My first choice is PlayCanvas (free version), which is like a (simplified) on-line Unity. The only alternative that I know of, GooCreate, sadly declared bankruptcy a few months ago.

Pros

  • on-line editor (drag ‘n’ drop)
  • six years old (so relatively mature and stable)
  • support is through forums for free accounts
  • FBX support
  • collaboration

Cons

  • no download for off line storage
  • no version control
  • limited animation control

Develop Game Jam

I’ll be attending this year’s (2017) Develop Game Jam in July.

I usually just ruck up on the day and use the opportunity to learn a bit about some game development technology or techniques.

While fun and educational, this is not the ideal way to compete. Frequently, I achieve little by way of a final result.

This year, I thought I’d actually do some real preparation and take a real stab at completing a “proper” game.

I plan to use WebGL (naturally), so I’m focusing on PlayCanvas, along with Three.js and Babylon.js as possible fall backs.

If things really go pear shaped there’s always Unity (or possibly Unreal or CryEngine).

I intend to blog the process for reference purposes and I’ll add links to blog/articles as I progress.