-
Notifications
You must be signed in to change notification settings - Fork 0
FAQ
Short answers. For the long version of any of these, follow the links.
Takes several meshes (each with their own textures) and produces:
- One shared atlas texture per channel (Albedo, Normal, etc.).
- A copy of every input mesh with its UVs rewritten to point into that atlas.
You can then use the atlas + rewritten meshes as a drop-in replacement in your engine or DCC.
UV Texture Repacker does pixel copy, not baking. If you already have textures you are happy with and you just want them on a shared atlas, baking is overkill — it can introduce noise, miss occluded geometry, and need cage tuning for nothing.
This app skips the bake step. What the artist painted is what lands in the atlas, exactly. Pack time is independent of geometry complexity.
It does not generate AO, curvature, or other rendered output. For that you still need a real bake; do that first, then bring the resulting textures into UV Texture Repacker for repacking.
See Concepts → Pixel-copy vs baking.
Yes, when the optional fbxsdkpy library is installed. Most release packages bundle it. OBJ, glTF, glb, PLY, and STL work without any optional libraries.
See Installation → Optional features.
Yes. 16-bit PNG works out of the box; EXR needs the optional OpenEXR library.
The Atlas format dropdown is a floor — the app may auto-promote the format when needed. A 16-bit source promotes the output to 16-bit; tangent-normal channels promote to at least 16-bit; floating-point sources promote to EXR.
See Concepts → Atlas formats and bit depth.
512, 1024, 2048, 4096, 8192, 16384, or 32768 pixels per side. Output is always square. Above 4 K, packs get noticeably slower (minutes, not seconds) and atlas files get large (hundreds of MB at 16 K). Use 16 K and 32 K for film or hero assets only.
In rough order of impact:
- Use the Bitmap packer (default). It is brute-force quality in seconds.
- Turn on Allow 90 UV rotation. Lets the packer rotate shells for tighter fits. Tangent normals are re-shaded automatically.
- Reduce padding if it is wider than your dilation requires. Padding too wide wastes atlas area.
- Authoring matters more than packer choice: small slivers and very thin shells eat a lot of padding overhead because each shell needs its own padding ring. Cleaner UVs always pack better.
Use a lower Resolution in Controls and Pack. The bitmap packer respects whatever value you pick exactly.
If you want the smallest possible atlas at any cost, switch the packer to xatlas with Brute-force xatlas on in Preferences. Xatlas treats the resolution as a hint and may shrink the atlas below what you asked for. Brute force adds significant time for marginal gains.
Padding is a gap reserved by the packer between shells. Dilation is the post-process bleed of pixels outward from each shell into the empty space around it.
Dilation needs Padding to operate without bleeding into neighbouring shells. Keep Padding ≥ Dilation (the defaults already do).
See Concepts → Padding vs Dilation.
Atlas fill includes the per-shell padding ring; raw UV area is just the sum of triangle areas in the [0,1] square. A layout with many tiny shells has a disproportionately large padding ring per unit shell area, so its Atlas fill is much higher than its Raw UV area. A layout with a few big shells shows the two numbers close together.
This question only comes up if you are using the standalone diagnostic probe (developer tool). The main app's status bar reports Atlas fill.
Yes — automatically. When Allow 90 UV rotation is on and a shell ends up rotated, the corresponding pixels in any tangent-space normal channel are re-shaded by the rule (R, G, B) → (1 - G, R, B). The lighting on the rotated shell looks identical to the unrotated form.
A texture is treated as a tangent-space normal when its channel name contains normal but not world or object. Name your normal channels sensibly (Normal, WSN, OSN) and the right thing happens. There is no per-row "Kind" picker.
See Concepts → Rotation and tangent normals.
By design. Setting changes never trigger a re-pack. Packs only happen when you press Pack.
This keeps the iteration loop predictable — you can tweak many settings and pack once, instead of waiting through implicit re-packs after every click.
~/muvp/settings.json (C:\Users\<you>\muvp\settings.json on Windows).
The same folder also has recent_files.json. Both are plain text and safe to delete; the app recreates them with defaults.
See Preferences and Installation → Where the app stores your data.
Yes. The .muvp file stores both absolute and relative paths to every mesh and texture. Zip the .muvp plus the source folders, send it; the recipient unzips, opens the .muvp, and the relative paths resolve correctly.
If the absolute paths happen to match (rare across machines), the app uses those. Otherwise it falls back to relative-to-the-.muvp. Missing rows show a red flag and can be fixed with right-click → Replace….
There is a CLI for power users. It is documented in the project README, not in this wiki — this wiki is for the GUI only.
No. UV Texture Repacker does not contact any server. No telemetry, no auto-update check, no analytics.
Those are small thumbnail sidecars (≤ 2048 pixels per side, lossy WebP). The Preview viewer reads them instead of decoding the full atlas, so even 16 K and 32 K atlases preview instantly when you reopen the project.
They are safe to delete — the Preview falls back to decoding the full atlas if a sidecar is missing or stale.
Open an issue on GitHub. Include your operating system, the app version (in the title bar), and a .muvp if the issue is project-specific.
New users
The interface
Working with channels
Reference
Help