10 replies to this topic

[jamoram62]

PLEASE NOTE:

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.

 

Let's face it: modding for Moviestorm, although not necessarily a too complex task, it's an activity plagued by traps and that demands every little bit of the modder's attention.

 

Sometimes even the more experienced modders can fall victims of one of these mishaps, which, unless you're well aware of the reason which causes it, can prove to be really nasty and exasperating.

 

We'll see some of them in the next posts, which hopefully will be extended with new entries and contributions.

 

 

[jamoram62]

Mishap #1: Tribulations of an unmaterialistic object

 

Symptoms

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:

 

 01-01.jpg   61.36KB   0 downloads

 

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:

 

 01-21.jpg   31.83KB   0 downloads

 

After publishing, we'll eagerly launch Moviestorm, and dart to the Dressing Room to put it on Jack's (our random test subject) head, and...

 

 01-31.jpg   28.47KB   0 downloads

 

Something's gone terribly bad. Deselecting the hat, everything goes back to its normal state, lucky us. Should we insist in Jack wearing the cursed hat, the Director View will look even worse:

 

 01-32.jpg   12.85KB   0 downloads

 

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):

 

 01-91.jpg   55.34KB   0 downloads

 

So there are a few faces highlighted. Further, please switch to the Wireframe view and change the orientation of some views, to be sure we don't miss one single face. Much better:

 

 01-91a.jpg   69.33KB   0 downloads

 

To fix this problem we're given two options to choose from:

1. Either assign a material to every face with none applied,
2. 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.

 

 

[jamoram62]

Mishap #2: Now you see it, now you don't

 

Symptoms

 

One easy modder's predicament follows. Its symptoms vary depending on the type of the asset affected, so we'll illustrate this problem with two cases for the price of one:

 

Case #1: The case of the vaporous boiler

Let's start with an animated prop, such as this cute animated model:

 

 02a-01.jpg   93.42KB   0 downloads

 

Again, it looks A-OK on the Modder's Workshop:

 

 02a-21.jpg   26.82KB   0 downloads

 

So let's launch Moviestorm, put our new toy on the set and trigger one of its animations and...

 02a-31.jpg   59.19KB   0 downloads

 

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:

 

 02b-21.jpg   31.83KB   0 downloads

 

But things look a tad bit different when we instruct Jack to wear our Handsome-etc-thingy:

 

 02b-31.jpg   87.43KB   0 downloads  02b-32.jpg   65.42KB   0 downloads

 

So what blessed darn thing has gone wrong this time?

 

Fixing It

 

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:

 

 02z-91a.jpg   103.92KB   0 downloads

 

So, in the Case #1, all the vertices of the boiler group were left unrigged.

 

And, in the case of the HHH:

 02z-92.jpg   83.96KB   0 downloads

 

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.

 

[jamoram62]

Mishap #3: A mesh so large, it can't be seen

 

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:

 

 03-01.jpg   57.49KB   0 downloads

 

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...

 

 03-21.jpg   16.21KB   0 downloads

 

Oops! What was that? Where has everybody gone?

 

If now we select another prop with no known issues, it will be displayed as usual, but if we select again own crown of thorns, things will go painfully wrong one more time.

 

Looking for some clue that could cast light on the reason of the problem, we'll see a lot of registered exceptions, each one of them like this:

 

 

java.lang.IllegalArgumentException: Submesh has too many vertices: 17806

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

       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.renderShadows(SceneView.java:1370)

       at fuze3d.scenegraph.ShadowCaster.renderShadowMap(ShadowCaster.java:123)

...

 

The first line tells all the story: there's a submesh in our model that has too many vertices.

 

Fixing It

Back to our modding tool, if we now check the statistics for our model mesh, we'll get these values:

 03-31.jpg   55.12KB   0 downloads  03-31a.jpg   28.76KB   0 downloads

 

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:

 

 03-51.jpg   92.84KB   0 downloads

 03-52.jpg   91.9KB   0 downloads

 

We've got now a model with two groups (submeshes):

• ThornCrown: with only 5,550 faces left
• ThornCrown1: with 6,472 faces

They add up to the original 12,022 faces of the original mesh. If they don't, either you've done something wrong or we've run into another problem, but this one belongs to the realm of Arithmetic.

 

Provided our little surgery procedure has gone as expected, our model will be displayed on the Modder's Workshop at last:

 

 03-60.jpg   26.6KB   0 downloads

 

Conclusion

Try to never import too much complex and or detailed models, with a high poly count. And if strictly required, be sure to no submesh or group exceeds a face count estimated in 10,000.

 

 

 

 

[Nahton]

PLEASE NOTE:

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. 

[jamoram62]

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. 

 

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.

 

[jamoram62]

Finally, for the convenience of anyone interested in the subject, I've put together a ZIP archive, named 'Mishaps in Modding.zip', containing:

• A PDF document with the cases described so far in the thread
• Another "nested" Zip archive (Modding Mishaps - Models and Addon.zip) including:

1. A Moviestorm's addon file with the assets used to illustrate the cases.
2. The models for the assets, both for Milkshape 3D and FragMotion

The archive can be downloaded from this link, located inside my shared folder (see signature), subfolder Documents & Guides.

 

 

 

[mloakley]

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. 

I am a diehard moviestorm user.   

[jamoram62]

Mishap #4: Too Many a Skeleton in the Cupboard

Symptoms

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...

 

 101 Error switching to Dressing Room.jpg   14.41KB   0 downloads

 

[NOTE: the title of the dialog box says: 'Unknown HUD component in DressingRoomDirector', and the text states: 'Unkown component requested from director character selector']

 

The what?  The text in the dialog box could be very well expressed in Euskera, Lojban or Welsh, for one thing: it would make the same sense to me.

Check the log file and we'll find something like this:

java.lang.IllegalArgumentException: Unrecognised bone HEAD

...

Failed to switch due to nulljava.lang.NullPointerException

...

missing component designer from DressingRoomDirector

missing component character selector from DressingRoomDirector

java.lang.NullPointerException

      at mscope.ui.charactershop.DressingRoomDirector.isCelShadingActive(DressingRoomDirector.java:73)

...

java.lang.NullPointerException  <-- Lots of this

...

 

Not the more enlightening text in the world, but please note there's a reference to a 'bone HEAD', which is unrecognized.

Before moving to the solution, let's take a look at the second closely related  case:

 

Case #2: From Hell's heart I stab at thee with this gesture.

 

Everything began with an innocent, mostly useless, silly gesture, which in its mid-point looks like this in our modding tool:

 

 201 Anim 00.jpg   46.91KB   0 downloads

 

What was the modder thinking of when he created this gesture, I can only guess. Anyway, we'll proceed to make it into Moviestorm.

Everything looks fine on the Modder's Workshop, so Jack should be completely safe when executing out new animation:

 

 202 Anim 01.jpg   46.34KB   0 downloads

 

Again: got published, launch Moviestorm, switch to the Dress Room and...

 

 101 Error switching to Dressing Room.jpg   14.41KB   0 downloads

 

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:

 

 301 Accessory.jpg   24.57KB   0 downloads

 

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):

 

 302 Anim 91.jpg   17.46KB   0 downloads

 

Exactly the same case in the end: somehow a skeleton file has managed to slip into out puppet folder hierarchy.

 

So, how to fix it? First thought: simply delete the offending skeleton file.

 

If we do so, deleting the file and immediately launching Moviestorm, that's what we get:

 

 401 Tras borrar csf sin replublish.jpg   45.2KB   0 downloads

 

Things have even got worse! Actually, we're unable to create a new movie or load a pre-existent movie.

 

The only and real way to fix this occurrence implies:

1. Deleting the skeleton file in excess
2. Re-publishing the addon

Proceeding this way, we'll get things ok again, and we'll enjoy watching at Jack executing our Silly Useless Gestures while donning his pretty stupid HHH:

 

 501 Anim 99.jpg   33.84KB   0 downloads

 

Conclusion

When creating puppet assets, such as bodyparts (bodies, heads, accessories, etc) and animations of any kind, be sure not to include any Cal3D Skeleton file (.csf) inside the Puppets folder hierarchy.

 

 

 

[primaveranz]

Yes I've done this too many times

[jamoram62]

Yes I've done this too many times

 

Indeedy, you won't be recognized as a real modder by the Bombastic Union of Moviestorm's Modders for Enlightenment and Responsive Self-improvement until you've run into this one at least thrice.