Thread: StudioMDL with Texture Shifting fix

Page 1 of 2 12 LastLast
Results 1 to 25 of 26
  1. #1
    Fagnus the Gay Pink Dragon DoomMusic's Avatar
    Join Date
    May 2013
    Posts
    26

    StudioMDL with Texture Shifting fix

    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.
    Last edited by DoomMusic; 12-09-2017 at 04:02 PM.
    She plants her seed in my head
    Opium narcosis, hypnotic dread
    I feel her death grow within me
    It's like a cancer, yet I crave the disease

  2. #2
    200 MB Angelscript log file KernCore's Avatar
    Join Date
    Apr 2016
    Location
    Brazil
    Posts
    254

    Re: StudioMDL with Texture Shifting fix

    This is pretty nice!
    Wonderful job

  3. #3
    trigger_delay & func_lazy TrEmPlEr's Avatar  
    Artist
    Join Date
    Jul 2002
    Location
    Valve Hammer Editor 3.5 beta
    Posts
    2,258

    Re: StudioMDL with Texture Shifting fix

    <3 lovely and super usefull. Thanks a lot.

    here
    Modstatus: Unknown

  4. #4
    Registered User
    Join Date
    Feb 2014
    Posts
    88

    Re: StudioMDL with Texture Shifting fix

    give this man a cookie, and update the sdk with this

  5. #5
    REE3 The303's Avatar
    Join Date
    Jul 2015
    Posts
    375

    Re: StudioMDL with Texture Shifting fix

    Astounding work, this not only fixes the long-time UV shift but the nonpower-2 OpenGl renderer down-scaling issue.

    A visual of the difference:


    The only suggestion I have is having the "padding fix" color sampled from the edges as I had an issue with some models where it would put black and you would see a faint black line on the pant legs. However, it does seem on some textures it does seem to pad with a good similar color (like it was fine on some face textures with a flesh color) so idk; mabey its just glitchy for now?

  6. #6
    Fagnus the Gay Pink Dragon DoomMusic's Avatar
    Join Date
    May 2013
    Posts
    26

    Re: StudioMDL with Texture Shifting fix

    I've fixed some issues with the compiler. Namely I've implemented a solution for the problem The303 had with the edges. You can now set a "stretch-out" border with the -b parameter. Normally this border is 2 pixels in size. What it does, is that it will copy pixels from the edge for the number of pixels specified by the -b parameter. This should avoid issues with texcoords at the edges.

    Normally, the blank areas are filled with the color at index 255, which would be the transparent color, thus why you always see a different color there.

    A complete feature list is available in the post.
    Last edited by DoomMusic; 03-09-2017 at 03:32 AM.
    She plants her seed in my head
    Opium narcosis, hypnotic dread
    I feel her death grow within me
    It's like a cancer, yet I crave the disease

  7. #7
    Registered User
    Join Date
    Apr 2016
    Posts
    33

    Re: StudioMDL with Texture Shifting fix

    Hey, I'm really eager to try this out, sounds like a dream come true, however I'm having trouble opening the file it keeps saying "This archive is either in unknown format or damaged". I checked that the file is a ".rar" according to my computer. The file shows up as 120 KB and I'm using Windows 7. I used 2 browsers to try and download it, IE and Firefox.

    I want to ask some questions if that's okay, since we have all these people with such great knowledge here. Where I'm coming from is I'm a hacker who decompiles and recompiles skins to convert them for various reasons, e.g. I've been porting Firearms 3.0 models over to Sven without the original assets. From my experience when I try to write concisely people misunderstand me so I'm going to be rather verbose to prevent any confusion and ultimately save time.

    From my experience the best way to describe the studiomdl.exe that is shipped with Sven SDK is to call it a "recompiler" because it attempts to, or I've noticed that it does, fix up misalignments such as you described. The reason I say recompiler specifically, is because when I tried to convert a player model from source (Garry's mod) for my friend, I found that NOTHING would compile the model properly except for some old DOD (Day of Defeat) compiler (studiomdl.exe) I had lying around. The other compilers (including the SDK compiler) would put something like 4 pixels (out of 512) of the texture file across the whole of the player model and therefore it was a complete failure for what I was trying to achieve (a decompile from source and recompile in Sven/goldsrc). The reason this happened, I assume, is because the decompilation of the original source model was done with crowbar. This is as opposed to goldsrc; where people, I guess, are all using the "Half-Life MDL Decompiler v1.2" by Kratisto from "2003". In this case, the studiomdl.exe from the Sven SDK was trying to reverse non-existent errors (I assume) and thus failing to compile the model correctly. A pure compiler like the DOD stuidomdl.exe (studiomdl_dod1.3) wasn't trying to reverse any decompilation errors so it compiled perfectly (if I am correct). Given this background, I will now ask some questions with numbered points:

    1. Firstly, is my understanding correct that the misalignments are caused by the decompiler, namely Half-Life MDL Decompiler v1.2" by Kratisto from "2003"?
    2. If this is the case, is this "studiomdl.exe" "compiler" meant to be used as a "recompiler" for people who have decompiled a model using the Kratisto decompiler?
    3. In my experience there are 2 misalignments that can happen (but maybe I'm wrong please correct me if so) and that is the exact position of the triangle in the 3D space (best described as the "model") and the position of the texture on that triangle (usually described as the "skin"). Is that correct, and if so, is this "compiler" purely to do with just the "skin" misalignments? I also acknowledge that UV maps are also an issue and those are apparently fixed so we already have an answer to that.
    4. Now I may really be way off at this point but why is there so much emphasis on getting a perfect studiomdl.exe compiler/recompiler and not a better decompiler? Is that to do with the source of the decompiler not being available?


    I hope to learn from anybody's answers to these questions and I hope I have respected your thread and am on topic.

    Thank you to the OP and everyone else.

  8. #8
    Fagnus the Gay Pink Dragon DoomMusic's Avatar
    Join Date
    May 2013
    Posts
    26

    Re: StudioMDL with Texture Shifting fix

    I think I remember others noting your issues as well with the .rar file. I'll upload the archive as a .zip, as it seems a lot of people are for some reason having trouble opening .rar files. I compiled this archive with WinRAR, so try using that until I get the opportunity.

    Regarding your question about terminology, I'm confused. The application is a compiler, as in it takes a bunch of source files and compiles them into a final format of one or more files. I'm not even sure if the "recompiler" thing is a valid term. Anyway, your issue is most likely caused by texcoord clamping. A lot of Source models have texcoords outside the 0-1 range, and most studiomdl versions clamp texcoords in that range. Why you're seeing only 4 pixels of the 512 is because Studiomdl's normal behaviour is to cut out parts of the bmp file that are not used. Because of the aformentioned texcoord clamping in the 0-1 range, it "pancakes" everything into the right side of the texture, and studiomdl rounds the 1 pixel width to 4.

    As for your other questions:
    1 - The UV shifting is perfectly explained in the article as being caused by the other buggy studiomdl binaries. As far as others told me, the decompilers themselves aren't responsible for any further UV shifting. I know that one of the members here at least has decompiled and then recompiled models several times with this new studiomdl and saw no further shifting.
    2 - This studiomdl is supposed to work with any model, that's all I can say really. As for the behaviour of Source models that were ported to GoldSrc, I can't guarantee anything. Source's models use vertex weights, which GoldSrc normally doesn't support. You're likely to have all sorts of artifacts from the hard transformations done by GoldSrc. My advice is not to use Source models, as the result will be ugly.
    3 - That's correct. This version only deals with the UV misalignments. Any misalignment in the 3d coordinates of vertexes has to come from the decompiler for Source models. The only change studiomdl does to vertex coords is that it merges vertexes if their coordinates are very close to eachother(down to two fractional digits), but that distance is so small, it shouldn't be noticeable.
    4 - As it was said before, Krastito's mdl decompiler is not known to be responsible for any of the shifting issues.
    She plants her seed in my head
    Opium narcosis, hypnotic dread
    I feel her death grow within me
    It's like a cancer, yet I crave the disease

  9. #9
    Still learning wolf-3d's Avatar  
    Tester
    Join Date
    Jan 2011
    Location
    Somewhere Warm.
    Posts
    1,413

    Re: StudioMDL with Texture Shifting fix

    @DoomMusic, Great Work and Many Thanks.
    Not a model maker or artist myself but now seriously tempted to try some minor fixes.
    (Simply because I am seeing lots of praise and good comments about your version of StudioMDL on our Discord Channel.)
    Regards
    Wolf-3D

  10. #10
    Fagnus the Gay Pink Dragon DoomMusic's Avatar
    Join Date
    May 2013
    Posts
    26

    Re: StudioMDL with Texture Shifting fix

    My pleasure.

    I've updated the binary, now with a new feature. Refer to the original post.
    The archive is now in .zip format, so hopefully everyone can open it now.
    Last edited by DoomMusic; 12-09-2017 at 04:20 PM.
    She plants her seed in my head
    Opium narcosis, hypnotic dread
    I feel her death grow within me
    It's like a cancer, yet I crave the disease

  11. #11
    REE3 The303's Avatar
    Join Date
    Jul 2015
    Posts
    375

    Re: StudioMDL with Texture Shifting fix

    @Thundercracker

    Crowbar currently has some issues with some decompiles at the moment, as well as issues with GoldSrc; however ive spoken with Zeq and there is some fixes on the way especially on the GoldSrc side of things. As for Source engine SMD's as mentioned before doing ports can be iffy for a variety of reasons. Currently importing into a 3D editor and doing manual fixes and exporting as GoldSrc format is your best bet.

    EDIT: If it helps you can look at this current WIP I made describing the SMD differences with Source & Goldsrc SMD quick reference

    @DoomMusic
    I was wondering if you knew of an old error that occasional shows up with studiomdl where it will not "find" the path in some cases. At times having the QC and sources in a folder with a space will confuse it, and ive been told some people (possibly a windows10 issue?) that on some it will say "smd not found" even though its in the right place. Do you think this is an old issue with the way it looks at directories or something to do with GUIstudiomdl wrapper?

  12. #12
    Fagnus the Gay Pink Dragon DoomMusic's Avatar
    Join Date
    May 2013
    Posts
    26

    Re: StudioMDL with Texture Shifting fix

    I don't know about that particular, but I'll be able to take a look during the weekend probably, do some tests.
    She plants her seed in my head
    Opium narcosis, hypnotic dread
    I feel her death grow within me
    It's like a cancer, yet I crave the disease

  13. #13
    Registered User
    Join Date
    Apr 2016
    Posts
    33

    Re: StudioMDL with Texture Shifting fix

    Thanks for the detailed replies. Not sure if I will ever understand everything.

    I was using winrar, I forgot to mention that. Maybe mine is old, but it works now. I tend to always use .zip personally so that everyone can open it.

    True to what you said this only adjusts the textures and is much more accurate to the original skin which I decompiled then recompiled with your studiomdl.exe. I'm kind of glad in a way to not have to readjust all the fine-tuning of my hackwork with respect to placing models in the exact right place. I did fine-tune some textures I'm going to have to go back over and check. The reason I say I'm "kind of glad" is that I'm sure most hackers would like some way of recompilng something perfectly without the original source. I know this is not the purpose of this compiler but this is just discussion, so please don't take this as an attack on your work. What you have done is amazing, this a great step forward for everyone.

    For those who may not realise it, this compiler will add to your file size somewhat. If you want to minimise file size as much as possible for what ever reason you can use the studiomdl.exe supplied with the Sven SDK and from what I can tell it's the best of what existed before this new compiler. On a rather detailed akimbo uzi compilation I am working on it only added about 7% to the file size. The file size with the Sven SDK compiler says "1,032 KB" and after compiling with this studiomdl.exe it now is "1,104KB".

    Also I did successfully hack a source player model to goldsrc with nothing but notepad. My main problem was the compiler, otherwise it's relatively easy, except hacking the model onto new animations was a bit screwy and I didn't get the model to fit perfectly for the arms. But guess what, using your compiler it didn't screw up the textures, it compiled perfectly, so this gets bonus bonus points! Both the Sven SDK and xash compilers fail this test! DoomMusic if you want the files for that specific compilation just ask, but it was a private thing I did for my friend that I will not personally release.

    One other thing, I did a recompile for something I'm working on and here are some pictures:

    Click image for larger version. 

Name:	v_g36e FA30.jpg 
Views:	55 
Size:	136.0 KB 
ID:	17830
    This is the original FA 3.0 G36E.

    Click image for larger version. 

Name:	v_g36e recompile Sven.jpg 
Views:	78 
Size:	137.0 KB 
ID:	17831
    This is a recompile for Sven.

    So one great thing to note is the lens of the scope is much sharper now (same thing as what The303 was showing with old Einstein there) but the reason I put this picture up is because of that weird white artefact that appeared now (on the top right of the stock, near where it meets the receiver). Any idea what's going on here? I tried the -b parameter but I couldn't get that to work properly. My batch file looks like this:

    Code:
    "G:\Users\Username\Downloads\Games\Sven Co-op\FA mod\9mmar\studiomdl.exe" -b "G:\Users\Username\Downloads\Games\Sven Co-op\FA mod\9mmar\v_9mmar.qc"
    
    pause
    When I use "-i" instead of "-b" things work correctly, but the reason I say that is because I'm not a whiz with batch files and this is my first time trying to invoke a parameter. What did I do wrong here? I must say, I can't even really understand what you said about what the "-b" parameter does.

    @The303
    Thanks that's a good resource, I think I looked on the valve website to figure stuff out but mostly I discover/rediscover things by just messing around with numbers and testing. For my source to goldsrc compile I didn't even have to cut off the extra information in the source .smd for it to work, if anyone wants to make simple hacks it's not hard. I'd show you what I made but it was private for a friend but I assume it's the same thing people did with TF2 models.

    *EDIT* So yeah, here's what the texture file looks like for the stock, similar problem to what The303 already mentioned but now with pictures :

    Click image for larger version. 

Name:	recompiled g36e stock texture.jpg 
Views:	60 
Size:	97.0 KB 
ID:	17833
    Last edited by Thundercracker; 16-09-2017 at 05:17 AM.

  14. #14
    Fagnus the Gay Pink Dragon DoomMusic's Avatar
    Join Date
    May 2013
    Posts
    26

    Re: StudioMDL with Texture Shifting fix

    You're not using -b correctly. You need to use -b with a value for the stretch size, like -b 12 if you want it to be stretched for 12 pixels, or 4096 for example if you want it to stretch all over the free space. This will fix your artifact issue as well. Also the increase in file size is to be expected, if the textures are padded out by a lot. I however wouldn't worry about file sizes for GoldSrc models in 2017.
    She plants her seed in my head
    Opium narcosis, hypnotic dread
    I feel her death grow within me
    It's like a cancer, yet I crave the disease

  15. #15
    Registered User
    Join Date
    Apr 2016
    Posts
    33

    Re: StudioMDL with Texture Shifting fix

    Thanks I got it working! This is fantastic, everyone should be using it.

    Just a general note for people, the two pictures I posted of the model are a great example of why you should only do one decompile and recompile (or as few as possible) when doing a hack. If you click the buttons to go back and forth between the images you can see just how much the model gets distorted because of this process.

  16. #16
    Advanced Leveldesigner SourceSkyBoxer's Avatar
    Join Date
    Apr 2011
    Location
    Germany
    Posts
    735

    Re: StudioMDL with Texture Shifting fix

    Wow news I don't see studiomdl.exe thanks I will try it. Does it support many multi bitmaps example hw_wall_512.bmp, hw_wall_light.bmp , etc...
    $texrendermode hw_wall_light_fl.bmp
    ...

    Okay thanks I will check if it works.
    Hello guys, Svencoop. I am sorry Please respect me! I am deaf. Thanks, Sven-Coop Forum!

    Please do not share to shit dropbox! Please share only Mega.nz!

  17. #17
    Fagnus the Gay Pink Dragon DoomMusic's Avatar
    Join Date
    May 2013
    Posts
    26

    Re: StudioMDL with Texture Shifting fix

    What you're asking for, if I understand it correctly(and it's really hard to), is special rendering maps for textures, like luminance maps?
    If so, then that's not supported. That would need to be added in the engine itself.
    She plants her seed in my head
    Opium narcosis, hypnotic dread
    I feel her death grow within me
    It's like a cancer, yet I crave the disease

  18. #18
    Registered User tschumann's Avatar
    Join Date
    Feb 2016
    Location
    Australia
    Posts
    5

    Re: StudioMDL with Texture Shifting fix

    Nice work - respect for distributing the source too.

  19. #19
    Registered User
    Join Date
    Sep 2012
    Location
    Spain
    Posts
    47

    Re: StudioMDL with Texture Shifting fix

    The link doesn't work, can someone put it again to download ? thanks

  20. #20
    snarks snarks snarks snarks snarks snarks snarks snarks Green Astronauts's Avatar
    Join Date
    Mar 2013
    Location
    Nijmegen, the Netherlands
    Posts
    182

    Re: StudioMDL with Texture Shifting fix

    In-game name:


    Administrator at the ModRiotGaming servers

  21. #21
    Registered User tschumann's Avatar
    Join Date
    Feb 2016
    Location
    Australia
    Posts
    5

    Re: StudioMDL with Texture Shifting fix

    I just noticed that all of the texture render modes this supports are available in default Half-Life (see https://github.com/ValveSoftware/hal...ngine/studio.h). I know that STUDIO_NF_CHROME was always supported by Half-Life and that STUDIO_NF_ADDITIVE and STUDIO_NF_MASKED got added by Day of Defeat but I guess the other ones were just undocumented until now. Anyone have any screenshots of the others in effect?

  22. #22
    REE3 The303's Avatar
    Join Date
    Jul 2015
    Posts
    375

    Re: StudioMDL with Texture Shifting fix

    Quote Originally Posted by tschumann View Post
    I just noticed that all of the texture render modes this supports are available in default Half-Life (see https://github.com/ValveSoftware/hal...ngine/studio.h). I know that STUDIO_NF_CHROME was always supported by Half-Life and that STUDIO_NF_ADDITIVE and STUDIO_NF_MASKED got added by Day of Defeat but I guess the other ones were just undocumented until now. Anyone have any screenshots of the others in effect?
    You mean extended Sven render modes like $texrendermode fullbright mode? I have some pics in action:

    (from this tutorial I made http://www.the303.org/tutorials/sven_fullbright.htm )

    Sven Flatshade on left comparison. Flatshade basically ignores all vertex normals and shades everything evenly so if its in shadow the whole model will be the same uniform shade.

    (Note HLMV does NOT display this, have to run in sven to see).

    Classic BMP name set Chrome vs $texrendermode flag set chrome


    Standard Masked texture:


    Standard Additive texture:

  23. #23
    Registered User tschumann's Avatar
    Join Date
    Feb 2016
    Location
    Australia
    Posts
    5

    Re: StudioMDL with Texture Shifting fix

    Thanks for the screenshots.

    Looks like standard Half-Life has STUDIO_NF_FULLBRIGHT, STUDIO_NF_NOMIPS and STUDIO_NF_ALPHA as well. Someone suggested to me that STUDIO_NF_FULLBRIGHT might only be supported by Valve's mdlviewer and not the engine itself. I'm also told that Half-Life models don't have mip-maps either so not sure what that flag would do. I assume STUDIO_NF_ALPHA was a prototype transparency mode - no idea if it still works in the engine though.

    Also, standard filenames with chrome look different because studiomdl applies STUDIO_NF_FLATSHADE as well.

  24. #24
    Advanced Leveldesigner SourceSkyBoxer's Avatar
    Join Date
    Apr 2011
    Location
    Germany
    Posts
    735

    Re: StudioMDL with Texture Shifting fix

    Oh wait you mean for faked light thrower like Unity 3D. I saw sometimes Game Dragon you know emission-light on model without entity light and model csn throw real light. I think Half-Life Engine forgets method STUDIO_NF_EMISSIONLIGHT. If you see in game example:

    STUDIO_NF_FULLBRIGHT like The303 ATM models
    It neans light without throwers

    STUDIO_NF_EMISSIONLIGHT like Unity3D's or Unresl Engine's light texture like info_texlight
    It means light with throwers.

    And we have problem with flashlight if you move over models ( props ) than it looks wrong. And Xash 3D has same problem. We would like to fix if flashlight doesn't make wrong.
    Last edited by SourceSkyBoxer; 23-01-2018 at 08:01 AM.
    Hello guys, Svencoop. I am sorry Please respect me! I am deaf. Thanks, Sven-Coop Forum!

    Please do not share to shit dropbox! Please share only Mega.nz!

  25. #25
    REE3 The303's Avatar
    Join Date
    Jul 2015
    Posts
    375

    Re: StudioMDL with Texture Shifting fix

    Quote Originally Posted by tschumann View Post
    Thanks for the screenshots.

    Looks like standard Half-Life has STUDIO_NF_FULLBRIGHT, STUDIO_NF_NOMIPS and STUDIO_NF_ALPHA as well. Someone suggested to me that STUDIO_NF_FULLBRIGHT might only be supported by Valve's mdlviewer and not the engine itself. I'm also told that Half-Life models don't have mip-maps either so not sure what that flag would do. I assume STUDIO_NF_ALPHA was a prototype transparency mode - no idea if it still works in the engine though.

    Also, standard filenames with chrome look different because studiomdl applies STUDIO_NF_FLATSHADE as well.
    Yeah correct with the additional flatshade thing via that BMP activated chrome. It was almost certainly added as a performance saving thing for back in the day.

    As for "MipMap" and "Alpha" those ive been told were present in code but non-functional / incomplete or just a cut feature. I talked with sniper about "Alpha" and eventually It will function in a later update at some point but no ETA. Thing to note that it is not standard 8-bit Alpha channel image but rather the "IndexAlpha" mode which is already used for map decals and "indexalpha" sprites. Basically the image itself is the greyscale mask with the final index as the "color" its masking. So pretty much soft edge transparency however only with solid color and not a base image. Example here.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •