For a start, a problem which can lead to spectacular and puzzling results.

So we have just finished to work on our mighty cute animated model with our favourite modding tool (we'll use FragMotion throughout all the examples in the text) . In this case, a hat with a style of its own:

Next thing to do is exporting it to Cal3D and the rest of boring chores we Moviestormers use to do to get our brilliant creation imported thanks to the magic of the Modder's Workshop. So far, it looks fine:

An uninspiring good deal of nothing, isn't it? So what's the reason behind such a bizarre behaviour?

If we bother to look into the log file, we'll find lots of exceptions registered, every one of them stating the same gibberish piece:

java.lang.IllegalArgumentException: Texture map id to enable tangents does not exist

at fuze3d.animation.cal3d.CalCoreSubmesh.setTangentsEnabled(CalCoreSubmesh.java:802)

at fuze3d.animation.cal3d.CalCoreSubmesh.ensureTangentsEnabled(CalCoreSubmesh.java:842)

at fuze3d.animation.Puppet.buildSubmeshGeometry(Puppet.java:2328)

at fuze3d.animation.Puppet$SubmeshPrim.renderBatch(Puppet.java:2589)

at fuze3d.scenegraph.SceneView.renderBatch(SceneView.java:561)

at fuze3d.scenegraph.state.RenderQueue.renderBatches(RenderQueue.java:80)

at fuze3d.scenegraph.SceneView.renderBatches(SceneView.java:944)

...

What gives us a hint is the first line (the rest can be safely ignored, it's only boring techie stuff): there's some problem with the texture map of the materials applied, which is missing.

Fixing It

Back to our favourite modding tool (FragMotion), please select in the menu: Texture > Select Faces With No Material, which will highlight those faces in the mesh of our model which have no material applied. And you got this (I have previously hidden the puppet meshes):

or, if that fits better with our plan, delete those faces that are to be left out the model. In this case, please also be sure to delete every orphaned vertex, ie, those vertices not being part of any face (usually, they cause no issues, but it's a good practice).

Conclusion

Before exporting to Cal3D, be sure every single face in your model's mesh has been assigned a material.

ars longa vita brevis - Hippocrates (attributed)

If you want to tell jokes then use Muvizu; if you want to make 'Movies', use iClone; but if you want to tell stories, use Moviestorm - PrimaveraNZ

Much to our dismay, for the duration of the animation, the engine's boiler disappears (the prop farthest on the right is static. The prop on the left is the one executing the "Move" animation.)

Before proceeding to the solution of this conundrum, it would be nice on your part to go through the Case #2, for it took me a while to put it together. Only thing I can tell you for now is there are neither UFOs nor politicians involved in this subtraction.

Case #2: The case of the decaying hat

An old acquaintance of ours will help us to illustrate an identical problem affecting an accessory. Again, our Handsome Heptagonal Hat[1] looks brilliant both on the modding tool and on the Modder's Workshop:

Back again to our favourite modding tool (FragMotion), if we care to select the tool Bone > Select Unassigned Vertices, those vertices of the mesh not rigged to any of the bones in the skeleton will be highlighted:

Again, the vertices of the yellow front whatever-it-be were left unrigged.

Once the cause of the issue is identified, the solution comes in pretty easily: just bind the unrigged vertices to the bone they're expected to be bound to.

In the case of animated props, should it had be a part expected to move during any of the animations, the problem had been easily spotted from the start. But in this case, the affected submesh had to be rigged to a bone not being driven by any animation.

As for an accessory, early detection of this issue calls for our full attention, for apparently it's not an animated asset. Actually, it is, but it's rigged to the character's skeleton.

It's interesting to note that this mishap apparently causes no visible effects on purely static props.

Conclusion

Before exporting to Cal3D, be sure every single vertex in your model's mesh is rigged, ie, bound to one of the skeleton bones.

[1] Actually it's an octagonal hat. Please concede me the licence for the sake of the alliteration.

ars longa vita brevis - Hippocrates (attributed)

If you want to tell jokes then use Muvizu; if you want to make 'Movies', use iClone; but if you want to tell stories, use Moviestorm - PrimaveraNZ

This time we're running into a real nuisance, which, lucky us, can be fixed. Most probably, we'll meet this dastardly villain while trying to bring some awesome visually-appealing model by a pro modeller.

Here you are an innocent looking model brought in from the 3D warehouse: a detailed crown of thorns Mr. Gibson asked us for, for his next controversial production:

It's a static prop, with only one material, we've made sure has been applied to every face of the model. Also, all the vertices have been rigged to the only bone in its skeleton. What can go wrong this time? Here we go again.

So please launch the Modder's Workshop, select the addon containing our new model, create a new template, add the only mesh and...

In this case, there's only one submesh (that of the group named 'ThornCrown'), so there will be no problem to identify the submesh causing the problem.

Actually, from my experience, I've reckoned this problem is triggered when one of the meshes of the model exceeds the critical threshold of 10,000 faces (if there's a threshold for the vertex count, I don't know what is it, although it must be necessarily a lesser number).

To fix this problem, only option we are left is subdividing the offending mesh (or group) into two or more submeshes or groups, so every one of them has a count of faces below the critical value.

In this case, splitting the only mesh ('ThornCrown') in two will do the trick:

First things first: this series of posts is the output of a work made in close collaboration with John Nahton, whom must be given his own share of the credit as its co-author.

Whaaaaat?!!

I appreciate the acknowledgement Jam, but to raise my contribution to the level of a co-author is waaaaay toooo generous and lessens the hard work you put into producing this document. I think I would characterize my participation as that of a beta tester providing feedback leading to some minor tweaking of the content that is largely the same in the published version as it was in the draft presented to me.

I appreciate the acknowledgement Jam, but to raise my contribution to the level of a co-author is waaaaay toooo generous and lessens the hard work you put into producing this document. I think I would characterize my participation as that of a beta tester providing feedback leading to some minor tweaking of the content that is largely the same in the published version as it was in the draft presented to me.

Probably this is not the best place to discuss about a subject which is by large a question of semantics Maybe it's because of my past background when I was a fellow in the Department of Pathology: every time a paper was to be published, although actually written at most by one or maybe two individuals, appeared in press signed by half a dozen of co-authors. The reasons for each name to be included was largely diverse, but in the end this practice benefited everyone.

That's not the current case, though. When I finished writing the first draft of this little case review and asked for assistance and advice, you did promptly replied with some valuable contributions. So the work, in its final incarnation owes something to you, and, from my point of view, qualifies you as a co-author to a much larger extent than my Pathology fellows.

Also, IMHO what really matters in a collective adventure like this one, trying to keep alive Moviestorm as a Machinima platform that still has a lot to offer to the enthusiast and bringing it back to its better Golden Days, is the community's work and contributions as a whole. Individuals, by themselves, won't be able to reverse what seems to be its fate, according to the most pessimistic of the observers.

ars longa vita brevis - Hippocrates (attributed)

If you want to tell jokes then use Muvizu; if you want to make 'Movies', use iClone; but if you want to tell stories, use Moviestorm - PrimaveraNZ

Thanks for sharing this knowledge. It certainly is appreciated. Should I get back into modding, I will certainly keep this info in mind and save it to my modding folder w/ other helpful modding things.

Again, thank you, Jamm ... and Nahton, and everyone who's been a modder and helpful as well. Moviestorm can get stubborn by crashing, but I still like it and enjoy creating with it.

Have you hear of supernumerary organs? Never? Really? C'mon, take a look at the page in the Wikipedia before continuing reading...

Ready? Ok. Having an excess of organs in your body does not necessarily goes in your favour, but supernumerary bones don't usually cause problems, either. At least, that's the case in humans: when those affected are Moviestorm's characters, things are a bit different.

We'll see two cases illustrating the real meaning and reach of my last statement.

Case #1: The Hat of Doom

Do you remember our much praised HHH? This time we'll make sure everything's right: no faces without a material assigned, no unrigged vertices and of course the polygon count for each and every one of its submeshes remains low in their poly count. So this time everything will go ok from start.

One more time, it looks gorgeous in the Modder's Workshop:

Got it published and this time, full of self-confidence, launch Moviestorm. Open the Set Workshop... OK. Hold your breath, switch to the Dress Room and...

Just the very same gibberish utterance. And the log file looks exactly the same as in the previous case.

So, what has gone wrong this time?

Fixing It

Remember the first threatening line in the log file:

java.lang.IllegalArgumentException: Unrecognised bone HEAD

There's a reference to a bone, so this line may point at some problem with the puppet's skeleton. We made sure that out hat in the case #1 was correctly rigged and bound to the puppet's Head bone, so what's the problem, then?

Actually, our model is absolutely right. If we now closely inspect the contents of the addon folder hierarchy we'll find something like this:

The red arrow points at the very origin of the problem. We had inadvertently included a skeleton file as part of the asset file deploy. Actually the file, despite its name, is the stock Male01's skeleton.

If we now take a look at the addon for the case #2 (the Very Silly Gesture):