Content Creation > Tools and Utilities

BrianOblivion StudioMDL with Texture Shifting fix

(1/2) > >>

AleKK:
BrianOblivion (AKA DoomMusic on Sven Co-op Forums) has created new StudioMLD compiler, that fixes UV-shifting problem. I've decided to redistribute it here, on HLC Forums, with the permission of BrianOblivion. Here's his original topic on SC Forums:

I've created a fixed version of the studiomdl compiler that's meant to fix the texture coordinate shifting
issue that's been present since time in memoriam. Keep in mind though, that you should keep your texture
resolutions at 512 maximum, as otherwise it will fail. You can override this with the -o command, if you're
using Xash or anything else that supports larger textures.

Part of the fix is that now textures are not resized, but put onto a larger canvas with a power of 2 resolution
closest to the original texture's resolution, but never lower. So if you have a texture with a res of 513x512,
it will be resized to 1024x512. For this reason, it's best to resize it to 512x512 in a program like IrfanView.
The reason this isn't done by studiomdl is that resizing 8-bit bmps without a proper algorithm, like the one in
IrfanView, will lead to artifacts in the texture. This artifact bug was present also in the original studiomdl.

To showcase the changes, this is what the original texture looked like:


And this is what the compiler will put in the model:


This studiomdl should work with any GUI compiler. Also keep in mind that in any models where you applied the
shift, you will have to re-adjust the UV coords to their intended locations.

Features(1.0):
- This version fixes the issue with bones that only have attachments being removed and causing compile errors.
Now, if your bone has no vertexes, but it still has attachments, it will not be optimized out.
- I've removed texture coord cropping in the 0-1 range, so your texture coords can be freely set as you wish.
- Currently the largest supported texture resolution for Half-Life is 512 in each dimension. If it's larger than
this, HL will resize it back to 512 pixels, and it might even crash.
This can be overriden by setting the -o parameter, which is useful if you are running in an environment that
supports textures larger than 512 pixels, like Xash and so.
- $cliptotextures doesn't do anything anymore.
- It supports Sven Coop's fullbright texture flag.

Features(1.01):
- Added alpha, nomips, flatshade and chrome support for $texrendermode.
- Added the -b parameter to specify a stretch-out border when padding textures
that are not power of 2. Normally this has a value of 1. It should get rid of
any artifacts with texcoords at the edges of textures.

Features(1.02):
- Added the $protected qc command. This lets you specify bones which cannot
be optimized out by the compiler even if they're not used by any vertices.
Example:
$protected "Bip01 Head"

Fixes(1.01):
- An issue was fixed when loading in textures that are not multiples of 4 in width. The cause of this issue
was that internally BMP stores them with the width as a multiple of 4, but studiomdl does not account for
that when setting the bmp's width for itself.

Important notice:
Altough this tool removes UV capping outside the 0-1 range, you still neeed to make sure you use power of 2
textures if you have UV coords outside of the 0-1 range, as the padding feature will mess that up.
In general you should never use non-power of 2 textures, since Half-Life already resizes everything to power
of 2 when loading models, which will cause loss of quality in the process.

You can get it at the following link:
https://1drv.ms/f/s!AlH6J8xz5g5lbDjpiIsWPk53qVw

Feel free to add any suggestions, and I'll see if I have time to implement them, if it's possible.

Here's link to original topic: https://forums.svencoop.com/showthread.php/45003-StudioMDL-with-Texture-Shifting-fix?p=528588#post528588

Norman The Loli Pirate:
This is some :2pro: shit right here.

Done a bunch of tests with a few different models and it's like night and day, even tired to decompile and recompile models a few different times and not a single bit of shifting happens.

This is definitely something we've needed for a long time coming now.

SPRKH:
The archive seems to be corrupt when I try to download it, mind attaching the thing on here?

Norman The Loli Pirate:
Here you go.

Editor:
Where were these tools back in our day? The time this would have saved...

Thanks for posting this!

Navigation

[0] Message Index

[#] Next page

Go to full version