This page lists new features for MeshMaker 1.1. If you have suggestions, add them under the Suggestions topic – I will review them and put them under any of the other topics as appropriate.
Also, if you have comments on anything on this page, please add them. (Use the handy
~~~ markup at the start of the paragraphs you add to include your user name.)
The Status shown at the end of each section is one of the following:
|Implemented||Finished, pre-beta-tested and ready to go.|
|Unfinished||Implementation has begun, but isn't finished yet.|
|Concept||Thought through and deemed feasible and worthwhile; about to be implemented.|
|Idea||Nice-to-have without any further thoughts about feasibility and implementation details.|
MeshMaker doesn't take Unreal Tournament's base directory from the registry anymore if MeshMaker.exe is located in an Unreal engine game's directory structure. That way users with multiple installations of Unreal Tournament aren't stuck with the one they installed last anymore.
If MeshMaker.exe is located somewhere else, it still looks in the registry for the correct paths.
MeshMaker 1.0 checked the Paths entries in UnrealTournament.ini to determine the directories used for texture search. Some mods (total conversions like Tactical Ops and Infiltration) keep their texture packages (and other packages that are crossreferencing those texture packages) in completely different directories though which are specified in other .ini files (TacticalOps.ini, for instance).
To address that, MeshMaker now scans all .ini files in the System directory for Paths entries.
While MeshMaker itself doesn't care about secondary packages referenced from texture packages (like footstep sounds in a separate .u file) when loading those packages, the compiler does and doesn't properly load those packages then – the result are meshes that come out unskinned.
The new version (apart from taking more package directories into account, see above) displays a warning message if the compiler stumbled over such a problem.
MeshMaker makes an effort to automatically realign textures whose alignment on the original prefab collides with the entirely different notion of skinning a mesh (the former uses origin and direction on the texture, the latter works by specifying an UV coordinate per vertex).
In the implementation of that, a small bug sneaked in so that, in rare cases, the "corrected" alignment wasn't as close to the original as possible (which still can be pretty far away from the intended alignment).
A small bug made MeshMaker 1.0 not use the full resolution of the limited coordinate space meshes reside in. In the new version, the vertex coordinate resolution is almost doubled.
MeshMaker's user interface is completely localizable now; similar in functionality to UnrealScript's localization support, every string that appears in the user interface has a unique section and label and can be read from a language file. (If no file is found, the strings default to English.)
Such a localization file is a plain-text file with the extension .lang and looks like this:
[FormMain] CheckBoxExportCollision=Kollisionshülle erstellen HeaderControlTextures(Texture)=Textur HeaderControlTextures(Package)=Paket HeaderControlTextures(Status)=Status LabelCaptionExportClass=Klasse: LabelCaptionExportPackage=Paket: LabelDescriptionDecoration1=Mit dieser Option wird MeshMaker automatisch ein Paket %s.u
MeshMaker automatically switches to your operating system's interface language if a localization for that language is available; that behavior can be overridden by a registry entry.
Available languages: English, German, French, Swedish, Dutch, (Spanish)
Deus Ex uses an updated version of Unreal's mesh format, employing higher-resolution vertex coordinates. MeshMaker automatically determines whether it is run from a Deus Ex installation and converts meshes into that new format if appropriate.
For convenience, MeshMaker could memorize the directory of the last prefab imported (rather than using the Maps directory by default on each run).
MeshMaker 1.0 always references textures in their original packages, unlike most other decorations which have those textures embedded in the .u files. The new version will provide an option to embed those textures in the .u file; maybe even to specify external bitmap files (.pcx, .bmp, .tga). (The latter was originally planned as part of .3ds support for MeshMaker, but I think I'm going to scratch that – it's a lot of hassle for a little worth.)
Decorations generated by MeshMaker used to have LOD processing switched off entirely; the reason for that is that prefab vertices can't be properly welded in many cases, which confuses the LOD processing algorithm and makes it create undesired gaps and holes.
An Advanced Options dialog box in MeshMaker could provide a slider bar for that setting, leaving it to users to determine how much distortion their prefabs/meshes can handle.
MeshMaker 1.0 splits polys in the way shown on the left side (the simplest possible approach), but since the way faces are arranged has an influence on how they're lit, the option on the right side might occasionally be desirable.
That could also be an option in that Advanced Options dialog.
Something else for Advanced Options could be a checkbox controlling the bEdShouldSnap property of the finished decoration.
MeshMaker has to convert the model from UnrealEd's world coordinate space to the rather coarsely discrete and pretty limited vertex coordinate space used for meshes. That leads to aliasing/quantization errors which can be visible in the finished mesh as small gaps between adjacent faces.
The feature I dubbed Smart Resizing would try to determine the optimal resizing factor to keep such quantization errors at a minimum. (Uh-huh, I know.)
As mentioned above, prefab vertices frequently can't be properly welded as it would be needed for effective LOD processing or to prevent aliasing effects from showing up as gaps between faces. Smart Vertex Welding would create additional mesh vertices (and, thus, additional faces) to be able to properly connect two faces if one of the first face's vertices lies on the second face's edge. (One more for Advanced Options.)
Click "Edit text of this page" (below) and add suggestions here.