Hi, thanks for the question.
1) I'd like to see more "space-ship" friendly features in the areas of UV-mapping, multi-res and 3D paint.
1a) LSCM is fine for human heads and cows, but (wo)man made things are not served well enough either by LSCM or the other unwrapping modes. An area of a space-ship (or a racing car, for that matter) might be fairly flat and best served by a sort of "from view" unwrap, but it may not be aligned with any of the three orthogonal planes. It boils down to grueling manual labor to group all the polygons that should unwrap together from that view; in addition to having to set the view exactly in the first place. Perhaps a way to set a number of "cameras" or angular directions by drawing them on orthogonal planes, such as placing 7 cameras around a circle for an alien ship of aliens obsessed with the number 7... and then an algorithm that places optimized seams to split surfaces as per optimal views from those "cameras" and throws out the islands... As well as ways to select a pipe or hose and mark it for cylindrical unwrap. Yes, hoses are a PITA to unwrap, presently; there should be an easy way to get a rectangualr strip for each, regardless how they twist and turn. Ability to tell the unwrapping tool that, say, the front of the ship should be oriented UP in the UV layout, would also help. In fact, main reason we can't use Archimap is that it lays out the islands in any orientation it feels like.
1b) A second dimension to multi-res; namely a tri/quad mode "dimension". For most work, one wants to work in quad mode, but for export to and OGL pipeline, and for bakings, one needs tri mode. Why? Because if a mesh is exported to OGL with quads, the quads get split into tris in real time, and the split may not be along the same diagonal as the way they were split during bakings. The two must agree, and triangualtion needs a lot of manual tweaking that is lost whenever the mesh is de-triangulated. The solution, IMO, would be to to have triangulation that is res-level specific and permanent, but which can be "hidden away" via a button. Quad mode needs to allow tris, of course; but not viceversa. Cutting and editing should only be allowed in quad mode, and should work like de-tri, cut, re-tri.
1c) 3D Draw, to complement 3D Paint. Namely, the ability to draw straight lines by clicking in two places. I've tried to use 3D Paint for placing marks on a texture, to help matchings across seams when using Gimp later, for example; but 3D Paint is too "analog", too mouse-sensitive for that kind of work. I'm talking about a tool that would allow me to draw straight edges to represent seams around square plates and hatches and air-locks. As in Gimp, perhaps using Shift and Ctrl to draw straight/orthogonal lines.
2) Bakings. This has been mentioned already; but just to elaborate a bit:
I find myself still going back to the old "Radiosity Baking" method for things such as producing non-AO light maps. But Radiosity Baking doesn't accept lights, for instance; only radiant materials, which is a PITA when you have dozens of light sources in a scene. Finally, RB doesn't do a very good job where geometries interpenetrate, due to its being vertex-based.
Besides light-maps, we need to do PRT bakings, which use radiant red, green and blue orthogonal planes; frontal bakes, for baking textures that modulate things such as impacts and scratches during texture production; and finally self-radiant baking, for computing a hint of a self-radiosity-like effect to the PRT's.
There are three ways people go about using tangent normal maps in games.
- 3a) Tangent-less: The tangent is assumed to point towards the (right) in the UV-map, which means that during UV unwrap, the (front) of the ship must always face (UP) in the texture.
- 3b1) The tangent vector is added to the mesh, just like the normal. The shader reads the tangent vector per-vertex from the mesh.
- 3b2) The tangent vector is added to the mesh, but encoded as vertex color, rather than as a real vector. This method has the advantage that it works on MacIntoshes.
- 3c) The tangent computed per-pixel and is color-encoded and saved to a texture.
As far as I'm aware, none of these methods is presently supported by Blender in the way of producing exportable mesh tangents, or baking tangents to textures or vertex colors. Method 3b2 we have a pressing need for in the Vegastrike engine.
One more note on UV modes:
LSCM and the other unwrapping modes could universally benefit from dynamically disallowing any part of an island having a reversed normal. In large meshes, it takes a long time to find and fix areas where parts of the unwrap are flipped. Flips in the unwrap can cause bumps and depressions in the normal map to appear reversed. Flipped islands are an error in terms of normal mapping, and it would be helpful to have a setting to disallow them. Overlaps are also errors for UV sets hosting AO or lightmaps. Similarly, it would be useful to be able to disallow overlaps.
And, by the way, to have OGL-friendly normal maps look right in renders, they have to be set inverted in the texture output tab. Would be nice to have an OGL button that sets things globally right for OGL-like results in renders. This also applies to the max angle of auto-smoothing for renders, which in Blender maxes out at 80 degrees, and is applied even when autosmooth is turned off. OGL does not have such 80 degree limitation, and my wires and thinner pipes are often square in section.
Also, as LetterRip was mentioning, setting of backgrounds from 3 or 6 orthogonal views. Perhaps in addition, what would be very good is having per-camera backgrounds. Some old games, like Wing Commander, used multiple views (37) to fake continuous 3D views.
In game reference images of Rapier II
(scroll down a bit).
Those images are not parallel projections; they have some arbitrary focal length. So, even if one used only the 3 orthogonal views (which often don't suffice), one would need to attach the textures to cameras, rather than to planes.