Shaper 1.05

Shaper is a 3D modelling, texturing and animation package developed by Inverse Software. It includes support for the Torque engine.



The latest version can be downloaded from here.

More information on Shaper can be found here.

Quite a bit has been added and fixed since I last posted here. I am very interested to hear feedback from potential users. What features do you feel are missing? What bugs did you encounter?

I recently added a tool for automatically attaching a skeleton to a mesh. It uses a very simply distance based algorithm. Basically: vertex A is close to bones B and C so it will be influenced by them. And so on. I would be interested to hear if anyone has heard of any other simple algorithms in this area.

Discussion

Shaper makes extensive use of the Lua scripting language. The user interface is configured using Lua. Various tools, Face Sub-division for example, are written in Lua as Shaper extensions. All import and export extensions are written in Lua.

I use Luabind as the glue code between C++ and Lua. Luabind is great. My only other experience with script glue code was Unreal. In that case special headers had to be exported from native code which was less than ideal. It made building more complex than it needed to be.

So far there have been no major issues. Lua and Luabind do what they need to do.

Recently I wanted to add a progress indicator for export and import. Export and import are potentially very time consuming tasks so it is important that the user interface show the user that progress is being made and that Shaper has not imply hung. Long story short: I now wish I had isolated the script code in its own thread.

At this point all script processing occurs in the main thread. That is to say I create one instance of the Lua engine in the main thread and call into it when necessary. So to import I have the Lua engine run the requested Lua import script. This blocks the main thread until import is finished. I tried creating a thread to be used only for importing and exporting tasks however that did not work out. I concluded I would need to move all Lua processing over to a secondary thread. This will be a major change. Instead I have made all importers and exporters call back into native code periodically to update progress. This gives the native code a chance to update the user interface.

If from day one I had put all Lua processing in its own thread I could solve this problem without relying on importers and exporters to notify the native code of their progress. I could also add protection for runaway script code.

Lesson learned.