"Unknown Location -1" Error when Exporting a Shape Key's Normals and/or Animations

[MBetters]

This...

results in...

Here's my blend file. Remove the .txt from the provided Player.blend.txt to open it in Blender, then export it with the same settings as above.

Player.blend.txt

Note: My Blender files (including this one) are all in C:\Projects\NonTerra\Models, while my .mesh etc. files are all in C:\Projects\NonTerra\Media\models.

Thanks for the great addon!

[MBetters]

Here's another stack trace view.

[MBetters]

Export log. OgreXMLConverter.log

[MBetters]

Ok just fixed it. I had to uncheck Shape Animation and Shape Normals. The export runs fine with those unchecked. Looks like this is a bug in the way shape anims/normals are exported. I changed the title of this issue to reflect that. The only shape key I have that could be causing this (that I know of) is the Skinny shape key I have on the PlayerArmature -> Player -> Cube.001 mesh. Any help with fixing this would be appreciated. Thanks.

[VENTDEV]

One of my users is reporting the same issue trying to make a mod for my game.

He's trying MBetter's solution of unchecking shape animations and shape normals, but I believe that will not export morph animations which is required. I'll try to get sample files from him and hopefully I can hunt down the cause myself without pestering paroj...

Here is his traceback: `Traceback (most recent call last): File "F:\SteamLibrary\steamapps\common\Blender\2.80\scripts\addons\io_ogre\ui\export.py", line 136, in execute scene.dot_scene(target_path, target_file_name_no_ext) File "F:\SteamLibrary\steamapps\common\Blender\2.80\scripts\addons\io_ogre\ogre\scene.py", line 160, in dot_scene xmlparent = doc._scene_nodes File "F:\SteamLibrary\steamapps\common\Blender\2.80\scripts\addons\io_ogre\ogre\scene.py", line 457, in dot_scene_node_export mesh.dot_mesh(ob, path, overwrite=overwrite, tangents=tangents) File "F:\SteamLibrary\steamapps\common\Blender\2.80\scripts\addons\io_ogre\ogre\mesh.py", line 611, in dot_mesh pn = mathutils.Vector( [snormals[ vindex 3 ], snormals[ vindex 3 + 1], snormals[ vindex * 3 + 2]] ) IndexError: tuple index out of range

location: :-1

location: :-1`

[sercero]

The problem is with this line: https://github.com/OGRECave/blender2ogre/blob/6e86b20fc8575201e8496ce1834a4d77f42eeee0/io_ogre/ogre/mesh.py#L599

If the object is shaded flat, then bpy crashes on this line: https://github.com/OGRECave/blender2ogre/blob/6e86b20fc8575201e8496ce1834a4d77f42eeee0/io_ogre/ogre/mesh.py#L611

That is because skey.normals_polygon_get() is not returning enough data and the index goes past the end of the snormal array.

One solution I found is to replace snormals = skey.normals_polygon_get() with snormals = skey.normals_split_get(). But when doing that, exporting the mesh and trying in OgreMeshy with a FFP material the normals seem to be wrong.

Perhaps the export normals option is only useful for materials that take the normals into account.

@paroj do you think it is best to have the option SHAPE_NORMALS : False by default?

@VENTDEV can you try exporting without the option SHAPE_NORMALS and report to us?

@MBetters are you using some shaders that require the pose normals?

This code seems to have been introduced by xissburg I will try to contact him.

[paroj]

That is because skey.normals_polygon_get() is not returning enough data and the index goes past the end of the snormal array.

probably that gives us per-face normals, while for exporting we need per-vertex normals. Note, that we have to jump through hoops with the main exporting code to get the right normals as well:

https://github.com/OGRECave/blender2ogre/blob/6e86b20fc8575201e8496ce1834a4d77f42eeee0/io_ogre/ogre/mesh.py#L190-L207

Also the blender API here is different between 2.7 and 2.8+, so I suggest fixing this only in master to avoid doing the work twice.

[sercero]

I was thinking of leaving the SHAPE_NORMALS option disabled by default because honestly I don't understand what is the value of this feature.

If I export a mesh with Poses and without the shape normals the poses work perfectly.

But when exporting with shape normals, when applying the pose the shading of the object suddenly is wrong most likely because of the normals.

I have been trying to make it work by using snormals = skey.normals_split_get() instead of snormals = skey.normals_polygon_get(). That way Blender gives me enough data to have a per vertex normal and I tested that these normals are correct testing with a simple shape: a plane.

So even a shape as trivial as a plane (2 triangles) with all the normals pointing in the y direction (I checked the exported .xml) the shading is wrong when applying the pose so the thing is I don't understand how Ogre is interpolating these normals.

[paroj]

I was thinking of leaving the SHAPE_NORMALS option disabled by default because honestly I don't understand what is the value of this feature.

shape normals are required to update normals during animation. Otherwise only the initial normals are used, which can result in the lighting being off.

If you have Ogre compiled with Tests, compare Playpen_MorphAnimNoNormals & Playpen_MorphAnimNormals in the SampleBrowser.

[MBetters]

@sercero No I'm not using shaders that require the pose normals. I just want to use the shape key "Skinny" in the attached blender file so the Player model's thighs don't pop through the pants when walking/running.

[sercero]

@MBetters you can solve this quickly by just disabling "Shape Normals" you don't need them anyway.

The add-on is crashing when trying to export the shape normals.

Meanwhile we are working on a solution to the problem.

[MBetters]

@sercero Awesome, thanks for your help.

[sercero]

No problem, let us know if there are other problems or if you are still having issues with this.

Don't close this issue because the problem you found is not actually fixed yet.

[MBetters]

Enabling Shape Animation and disabling Shape Normals also doesn't work. See https://github.com/OGRECave/blender2ogre/issues/78. Changed the title of this issue to reflect that.

[sercero]

@MBetters they are actually different issues, the add-on scripts are failing at different instances.

In this issue the error is in mesh.py, and on the other issue the error seems to be in util.py when calling the OgreMeshTool.

Since I'm not using Ogre 2.x, I didn't test this scenario when recommending that you disable only Shape Normals.