Warriors of The North

[Dark Fox]

Warriors of The North

A gathering of warriors with the fighting spirit of a northener within them!

We're here to fight our way through tough areas for loot, and help any other person in need of the desired loot.
Along with helping any newly arrived warrior to get started on his great adventure in the world of Daragoth.

Rules:

Don't be an asshat.

Applying:

Throw a reply in this thread with your character name, HP & MP.

We've got a nicely made crest by JonnyBoy0719:

 

[Dark Fox]

Members we've got so far:

Me(STEAM_0:1:8122893)
Maximus(STEAM_0:0:7019991)
JonnyBoy0719(STEAM_0:1:24323838)
Kakon(STEAM_0:1:8288907)
Cephear(STEAM_0:1:12961481)

Attaching the .bmp of the crest to this reply.

 

[JonnyBoy0719]

Aye, I am a real 6000 year old boy.

 

[MaximusPrimus]

I'M READY FOR SCAVENGING, NOW, WHO THE FUCK STOLE MY NICKNAME?

 

[greatguys1]

func_door
HP 988
MP 440
Hardly active but I wanna try this guild thing out.
Also want that sweet crest

 

[Dark Fox]

@greatguys1 You're here by accepted into WoTN!

 

[zeus9860]

Maybe i should return to collect this new crest and walk away again. Hehe.

Nah, just kidding. Can't really be bothered with that stuff anymore, good luck with the guild!

 

[Kakon]

Bingo Bongo

 

[Thothie]

Nice crest, but incorrect dimensions. 384x384 based on the template, plzktnx.

 

[Dark Fox]

Rip, gotta talk to Jonny then.

 

[MS:C community]

Nice crest, but incorrect dimensions. 384x384 based on the template, plzktnx.

Out of sheer curiosity: Would the above template, pasted on a 512x512 canvas (and then using this StudioMDL) give a crisper result?

 

[JonnyBoy0719]

Nice crest, but incorrect dimensions. 384x384 based on the template, plzktnx.

You do not need the template, and the template itself is a incorrect dimension, I simply used the UV texture that had correct placement and created my own template, because the "template" bmp isn't really a template.

If you use the correct dimensions, as I saved the BMP as (8 bit BMP), you get the correct cords for the UV. As an example, I have recompiled the model by just making a new SMD and applied the correct bmp, and there we go.

I am also using the latest updated studiomdl.exe that doesn't use $cliptotexture anymore, it will resize all textures to the nearest power of 2 (the link that
@MS:C community posted), which Goldsrc must actually read, which is the same in Source Engine (due its based on Goldsrc technology).

But using that, you get the the results from the attachment below.

But in short, you don't need the "template", and the template is using wrong cords anyway, and it's not actually a template if its just a BMP, since there are no real layers. You should have used a PSD and / or GIMP proj file for a template.

 

[MS:C community]

Out of sheer curiosity: Would the above template, pasted on a 512x512 canvas (and then using this StudioMDL) give a crisper result?

Called it!

 

[Thothie]

Out of sheer curiosity: Would the above template, pasted on a 512x512 canvas (and then using this StudioMDL) give a crisper result?

Yes, though you might lose a pixel or two of alignment towards the edges. Works with any StudioMDL though. Provided the ratios are the same, you can scale textures dynamically. The downside is a 512x512 texture eats more texture space within the model.

I am also using the latest updated studiomdl.exe that doesn't use $cliptotexture anymore, it will resize all textures to the nearest power of 2 (the link that
@MS:C community posted), which Goldsrc must actually read, which is the same in Source Engine (due its based on Goldsrc technology).

Problem with that I ran into is that it causes merged models to reach the maximum texture limit much more quickly. Models that hold less textures means we need more models, and as there's a limit to how many models we can have, it is not an option for merged models like the crest set, p_weaponsX set, projectiles.mdl, etc. Seems $cliptotexture actually saves quite a bit of texture space, though it of course varies with the shape of the UV map.

Bit of a shame, as otherwise that tool would be much more useful - still good for monsters and other such models that aren't merged and aren't part of the universal precache though.

But in short, you don't need the "template", and the template is using wrong cords anyway, and it's not actually a template if its just a BMP, since there are no real layers. You should have used a PSD and / or GIMP proj file for a template.

The template is using the right coords for the source model, your BMP is not. Extracting a texture from the crest model will result in the wrong coords, as it is clipped. That's the problem. A PSD/Gimp isn't really going to make it much easier to line up, and unlike the BMP, isn't as universal a file format, much less the desired end result.

In anycase, come back when you have a crest that matches the template and format requested.

 

[JonnyBoy0719]

the BMP is directly from the source model (aka, the SMD file), and your "template" isn't even using the correct UV cords nor size for the HL1 SMD files. Using the crest texture on the template is an easy copy paste, but you will notice its not using the full texture space, because none of the SMD does, so your template is wrong.

I added 2 templates, template 1, wotn_template, shows you the *actual* UV size for the SMD, while wotn2_template covers everything.

But really, need to change / update how you handle the compiling process for MSC models, and use actual texture sizes when exporting and not doing some weird stuff to make it somewhat work. You may just end up making the textures going outside of the UV cords, which makes so that you can see the the ugly seams of the models, it is not pretty.

 

[Thothie]

the BMP is directly from the source model (aka, the SMD file), and your "template" isn't even using the correct UV cords nor size for the HL1 SMD files. Using the crest texture on the template is an easy copy paste, but you will notice its not using the full texture space, because none of the SMD does, so your template is wrong.

*sigh* I think you are missing the point. The BMP you are extracting has been clipped, from a source model, that you do not have. In order to integrate a new crest image into that source model, it has match the template provided, not a texture you have extracted by decompiling or exporting from that model, as the intact source is no longer present in the final model, only the bits the UV map actually requires.

In other words, the actual source model, and a decompiled model, do not and cannot match, regardless of what you decompile it with. The template is correct, your extraction is wrong.

Granted it'd be less time for me to fix this in Photoshop than to explain it, but it happens often enough that I'm just making folks do as they are told.

But really, need to change / update how you handle the compiling process for MSC models, and use actual texture sizes when exporting and not doing some weird stuff to make it somewhat work. You may just end up making the textures going outside of the UV cords, which makes so that you can see the the ugly seams of the models, it is not pretty.

As I tried explain earlier, we can't do that. We have far too many models in this game, and the only reason we can have as many as we do, is because most of them use clipped textures, allowing us to stuff more models into a single file. Using unclipped textures would require us to more than quadruple our model count, and the game is already more than half way through the model limit before a map even loads - which severely hampers our mappers as it is, when they want to add a huge variety of mobs through msmonster_random and the like. (Ask Oyster, he'll tell ya all about that... >_>)

 

[JonnyBoy0719]

original SMD and decompiled SMD is the same, due SMD are not encrypted, they are all TXT based files with X,Y,Z cords. Then your source file isn't an SMD file, and is either a MAX, or any other 3D program file. Which means that when you export to SMD, you break the actual UV cords, or the texture itself. Or that you have a messed up studiomdl that somehow break texture cords and the UV.

If you make an hl1 (or hl2/source) model, and is saved as an SMD from the start, the actual template wouldn't break or crop to that size, unless the UV and texture file is manually moved and/or changed.

 

[Thothie]

*sigh* Of course they aren't encrypted - but what I'm trying to explain to you, and you are refusing to listen to, is that the original texture isn't there in its entirety.

Maybe I need to go by way of visual demonstration, since apparently I can't seem to make this understood via text.

This is a random texture from the source model (albeit PNG'd, so I can just show ya here):
Source 384x384
Decompile 372x341

Note the size difference.

I hope we have an understanding now?

The reason we allow the textures to be clipped like that is that it lets us put more models in a single file. It doesn't cause any seam problems *provided* you use the original model source, with the original texture sizes, when compiling. It *will* cause splits when decompiled and recompiled without the source, or using textures of a different size, if the final UV map comes to an odd ratio, unless you use that new StudioMdl that compensates, but when using the new "use forever and eternally" compiler, you can't stick as many models into the same file, and we are critically limited to how many model files we can have.

 

[JonnyBoy0719]

The "decompiled" one, isn't really decompiled, its the cropped version from $cliptotextures from studiomdl, if you open up the model, that's what you get, which is why the textures becomes that. If you use the already cropped version and recompile, nothing changes, because it already is using the correct size for the model. So using the template, like i said, is quite pointless, because from the model, i just saved the 8bit BMP from it to a folder and opened up Photoshop. Inserting it in, or recompiling it, won't make a diff, or a dent on the texture, because it already uses the correct size for the SMD.

$cliptotextures only resize the texture down to the correct UV, if you got a 512x512 or w/e texture, open it up in your 3D software, and setup the UV, and then save & compile, it will then cut down to the same size as the rest (if the UV align correctly, and you actually moved the whole UV across.

Using the same QC token, with already cropped textures, won't make a diff, because they are already using the correct cords & size. So I don't see a problem why you can't just use the proper texture size, that the program will crop down to, imho.

 

[Thothie]

When the model is compiled only the cropped version is stored, thus that isn't the original full texture.

Because some of the crests in the model have different UV offsets than others, if you don't use the original texture sizes for all the models in the source, some of them offset. It is thus best to use the source models with the original source texture, all at the original size. If you try to put extracted textures back into the source model, they misalign and you get those dreaded seams and repeats.

Thus we request a 384x384 image based on that template, rather than extracted texture that won't fit the source model.

 

[Thothie]

If we try to put the decompiled 372x341 texture back into the original model source, for instance, this happens:

The result would be a similar skew if I had simply used the original texture you provided.

 

[JonnyBoy0719]

if you check wotn_templates.zip, and use wotn2_template.bmp, that's the full one. And for the $cliptotextures messing up already cropped ones doesn't make any sense, It works fine on my end, so I don't know why your studiomdl is acting up on correctly sized textures (note: if already sized / cropped down, you don't need $cliptotextures, but that token shouldn't screw up already cropped textures. If it does, then its faulty code.)

EDIT:
direct link: https://www.msremake.com/attachments/wotn_templates-zip.5513/

 

[MaximusPrimus]

Dang Janny, just do what the lord tells ya to!

 

[JonnyBoy0719]

Nevar, Maximooos!

ontopic: wotn2_template.bmp (If i remember the name correctly) is the 384x384 size, to save the $cliptotextures studiomdl problem.

 

[Thothie]

It works fine on my end, so I don't know why your studiomdl is acting up on correctly sized textures (note: if already sized / cropped down, you don't need $cliptotextures, but that token shouldn't screw up already cropped textures. If it does, then its faulty code.)

It's working on your end because you aren't working with the original model source as I am, you are working with the decompiled one. Compiles with the same skew in either compiler when using the original model, because in there, the UV's are aligned for different offsets, being aligned for 384x384, rather than the clipped textures.