Ogre Forums

The script now loads and saves its options to a text buffer called "ogreexport.cfg" inside the current .blend file.

This couples the script settings to the life cycle of the .blend file. In particular, if you like to keep the settings permanent, you have to save the .blend file after you exited the script.

To convert your old settings, just load the particular .blend file, start the script, quit without exporting and save the .blend file. You can check that the settings are stored with Blender's text editor window. After that, the .blend.ogre file that corresponds to that .blend file is no longer needed.

Yesterday sinbad commited support for non-uniform scale parameters in keyframes to CVS. I will add this feature to the exporter, just give me some time.

Sounds good. Thanks for the heads up.

How about a link to the script?

Its in the CVS, of course.
ogreexport.py

Thanx , I wasn't aware of any CVS thingy.

There is now an option to export Blender objects in their local coordinates. Be aware that in this case the skeleton file will be prefixed with the corresponding mesh object name. This is necessary since the skeletons rest pose has to be exported using the objects local coordinate system, too, and therefore the armature needs to be exported into a separate skeleton for each mesh it is parented to.

Exporting a mesh in form of the skeleton ("Export Armature as Mesh") is disabled at the moment. This option will be back, soon. Use Revision 1.22 of the export script if you need this feature.

reimpell wrote:Exporting a mesh in form of the skeleton ("Export Armature as Mesh") is disabled at the moment.

This option is enabled again. To export an armature as mesh, select the armature and press the export button. However, the armature is now exported as you see it in Blender, i.e. it has it's own object center and local coordinate system.

With revision 1.26 there are two important changes:
First, files are now named after the datablock of the corresponding object. In previous versions the object name was used. The new behaviour is more consistent with Ogre's naming scheme as the object corresponds to the node, not to the mesh or skeleton.
Second, the ambient colour is now (material ambient factor)*white. Previously it was (material ambient factor)*(world ambient colour). You have to set your scene's ambient colour to Blender's world ambient colour to get the old colour impression. Also, there is a new option called "Coloured Ambient". It provides a workaround for Blender's missing material ambient colour information. If this option is set, the exported ambient colour is (material ambient factor)*(material diffuse colour), which is a common choice. Note that this way the colours rendered with Ogre significantly differ from the ones rendered with Blender.

The way materials get exported has changed with revision 1.30.

There is now an option to switch between "game engine materials" and "rendering materials". Game engine materials behaves basically as before, whereas "rendering materials" tries to match the materials as rendered with Blender. For convenience, both material export types support the "Two Sided" face option. Note that the "InterPol" and "MidMap" texture options affect the rendering material's export:

when exporting game engin materials the .material file is missing the ambient and emmisive settings. What am i doing wrong?

biteme wrote:when exporting game engin materials the .material file is missing the ambient and emmisive settings. What am i doing wrong?

Nothing, they are not used by the blender game engine (as far as I read the code correctly). Use the rendering material instead.