I've been testing the art pipeline of OpenMW and CS in the last couple of weeks, during which I encountered several things getting in the way. Some of them are already well-known or on the roadmap, but I'm including those as well. My purpose is to give a thorough overview from an artist's perspective on what's ideally needed for an efficient workflow. My background is in 3d modelling, rigging and animation for games and for that I mainly use Blender.
I would also like to add, I understand the alpha state of OpenMW CS, and I understand nothing implements itself through wishing alone So, here they are:
----------Blender navigation scheme in viewport----------
As an open source project OpenMW naturally fits with other open source projects. With this in mind, it would help familiarity if orbit view controls in OpenMW CS preview window used the same control scheme as Blender.
- MMB rotate view
- Shift + MMB pan view
- Ctrl + MMB zoom view
- Alt + MMB click focus view under the mouse cursor and set the orbit point there
- ALT + LMB rotate/orbit view
- ALT + MMB pan view
- ALT + RMB zoom view
----------Reloading / refreshing of assets without restarting OpenMW CS----------
When adding a new asset to /data folder, you need to restart OpenMW CS for the asset to show in the editor. Doing this once per asset is ok, but when iterating on one or more assets it quickly adds up. Ideally this would be done automatically whenever a change in /data is detected.
----------Scaling factor for the OSG exporter----------
Blender:OpenMW scale ratio is 70:1, where 70 Blender units translate into 1m in OpenMW. This is an odd scale to work with. It's a lot easier to say 1 Blender unit equals 1m when creating models and then apply a desired scale at export, without affecting the working files.
----------Custom mesh normals----------
In Blender and other 3d apps, you can define custom normals for meshes, to adjust and improve their shading. This is useful for many things, especially foliage and trees. BetterCollada exporter from the Godot engine and Blender's FBX one support this (in case anyone wishes to inspect how it's being done)
http://ericchadwick.com/img/ericchadwic ... arison.gif
----------Exporting of textures named other than diffuseMap, normalMap, specularMap----------
The current setup requires textures with specific names so they fit into appropriate slots in OpenMW's shader. The problem appears as soon as you have more than one material per Blender file, where different textures cannot share the same name. This requires some sort of post-export fixing of texture names in the files. Perhaps an approach can be used where only a part of texture's name is taken into account, e.g. texture01, texture01_spec, texture01_nor etc.
----------Custom collision meshes----------
A way is needed to export custom collision shapes. Like OpenMW, Blender uses Bullet for physics. If possible, the exporter could check whether an object has physics enabled in Blender and with what kind of collision hull. Preferably a separate object would be used for that.
Alternatively, the collision mesh could share its name with the asset, and have a suffix to tell the mesh is meant for collision. For example:
- rock, rock_col
- item, item_col
- chair, chair_col
Currently you need to assign a mesh to an object before you can check the preview. It'd allow faster inspection of meshes and other assets, if you could preview them on their own.
There are two ways I can think of editing the terrain – importing a heightmap, and terrain editing tools in OpenMW CS. heightmap would be applied to a rectangular region of cells, ranging from a single cell to any desired, sensible size. This way you could create a whole world at once, smaller areas such as individual islands, and tweak and edit individual cells.
Terrain editing tools in the editor.
- level – make flat terrain at a particular height
- smooth / sharpen
- noise – add random noise offset to break regularity.
Beside animation support in the native format, an option is needed when exporting rigs due to how they are made. A common, usable rig in Blender has bones with different roles:
- deform bones – they deform the mesh but are not animated directly
- control bones – used to control the rig, made to behave and feel nice for animation
- helper bones – various extra bones used to automate and drive the rig, not animated directly
It's quite a list and from what I understand, these suggestions are all beyond the initial purpose of OpenMW (So it's mostly a post 1.0 affair). But hopefully, it'll give you an insight into the needs of asset creators. If you've come this far, thank you for reading