Raised This Month: $51 Target: $400
 12% 

[TUT] How to overcome some annoying problems on converted models for CS 1.6


Post New Thread Reply   
 
Thread Tools Display Modes
Author Message
Costin83
Senior Member
Join Date: Jul 2008
Location: Romania
Old 12-17-2011 , 04:38   [TUT] How to overcome some annoying problems on converted models for CS 1.6
Reply With Quote #1

1. The Wry Necked player model symptom (can be valid for hands too) Link
2. The fake lack of smoothing groups (abnormal normals) Link
3. The Tiled UV-Map problem (the UV overcome boundaries of the texture) Link

Example pictures:

- Wry Neck symptom


- Wry Neck symptom also applies to Hands


- Abnormal Normals


- Tiled UV-Map




1. Wry Necked symptom:

Ok, so you've got your super cool hi-poly hi-shit hi-etc. model from star-wears or god knows what game and you want to convert it and rig it into a CS 1.6 suitable model.
So far so good.
After being very enthusiast about what it may be, you hit your head into first problem: The high poly count.
Ok, so you split your model into more groups, textures etc... you're all good again.
You continue, rigging your model, then compile it. Now you open the model in HLMV... SUCCESS ! ! !
Well, not really... not until you see your model in game.
Now you put your new model in the game folder and you anxiously run the game in the most desperate manner like the world's coming to an end...
Surprise! What the fuck is this ! ? ! your player model has a broken neck ! ! !
Oh noes ! ! ! how can this be happening... ? My model looks alright in HLMV. It cannot be ! This is impossible !
OK, so back to the drawing board... search for the problem, smoke some cigarettes, after hours of pain... FINALLY!
No... The problem it's still there... You're about to crack...

So here comes the Fix: Note that this problem can occur to the head and also the hands of the player models. Why ? Because the Head and the Hands have bone controllers or attachments. Do not confuse the two of them; bone controllers are one thing, attachments are a total different thing.
You are aware that your model has more then one reference meshes. You have now just took the first step into fixing the problem.
The next step is that you need to be aware that the first mesh reference from your model (that means that it's first body reference written in the .QC file) need to have some vertices assigned to the head bone, right hand bone and left hand bone. Once you have all these bones bounded to some vertices from the first reference mesh then you are good to go.

Here's a reference player .QC file:

PHP Code:
/*
==============================================================================

QC script generated by Half-Life MDL Decompiler 1.2 
2003, Kratisto. Based on code from Valve's HL SDK.

player.mdl

Original internal name:
"gign\gign.mdl"

==============================================================================
*/

$modelname "player.mdl"
$cd ".\"
$cdtexture ".\"
$scale 1.0
$cliptotextures


$bbox 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000
$cbox 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000
$eyeposition 0.000000 0.000000 0.000000


//reference mesh(es)
$body "studio" "reference_a" -> This is the first reference mesh in your model ! It needs to have some vertices assigned to Head/LHand/RHand bones !

$body "studio" "reference_b"

$body "studio" "reference_c"

$body "studio" "reference_d"

$body "studio" "reference_e"

$bodygroup "backpack"
{
blank
studio "
defuse"
}


// 2 attachment(s)
$attachment 0 "Bip01 R Hand" 10.855000 -0.416715 1.870680
$attachment 1 "Bip01 L Hand" 10.855000 -0.416715 1.870680

// 1 bone controller(s)
$controller 4 "Bone01" ZR 0.000000 30.000000

// 21 hit box(es)
................................................ 


2.
Abnormal Normals problem:

This is the situation where a model (player model or weapon model really doesn't matter) appears like it has no smoothing groups when in game; it looks alright in HLMV, however...
This happens when a model with more then one texture, has at least one texture set to additive mode.
As in the situation above, your model may have more then one reference meshes, but if it's not, it sure does have more then one group, each group being a texture.
One of the groups is mapped to the additive texture. Now contrary of the above situation fix you need to regroup the additive texture part of the mesh into a standalone reference and this reference needs to be the last reference mesh in your model. Same thing as above, just this time the reference mesh with the additive texture needs to be the last one.

Again a .QC file example:

PHP Code:
/*
==============================================================================

QC script generated by Half-Life MDL Decompiler 1.2 
2003, Kratisto. Based on code from Valve's HL SDK.

player.mdl

Original internal name:
"gign\gign.mdl"

==============================================================================
*/

$modelname "player.mdl"
$cd ".\"
$cdtexture ".\"
$scale 1.0
$cliptotextures


$bbox 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000
$cbox 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000
$eyeposition 0.000000 0.000000 0.000000


//reference mesh(es)
$body "studio" "reference_a

$body "studio" "reference_b"

$body "studio" "reference_c"

$body "studio" "reference_d"

$body "studio" "reference_e"

$bodygroup "backpack"
{
blank
studio "
defuse"
}

$body "studio" "reference_additive" -> This needs to be your last reference mesh, the one with the additive texture !


// 2 attachment(s)
$attachment 0 "Bip01 R Hand" 10.855000 -0.416715 1.870680
$attachment 1 "Bip01 L Hand" 10.855000 -0.416715 1.870680

// 1 bone controller(s)
$controller 4 "Bone01" ZR 0.000000 30.000000

// 21 hit box(es)
................................................ 
3. Tiled UV-Maps

This happens due to bugs in decompilers for different model file formats or other unknown factors... When this does happen it appears to be quite hard to fix. Well, it's not. At least not in most cases.
Before attempting to make any edits to a mesh that needs to be converted make sure you won't mess with it's normals!
For this you need to go and UNcheck the "Auto Smooth" Check Box or whatever your 3D editor has there to screw the normals.
After this has been done you can now start and fix your tiled UV-map.
Select all your model and go to Vertex > Unweld. This will allow you to select vertices independently from the faces they belong to.
A vertex can belong to multiple faces -> so in the UV editor the same vertex will appear in multiple instances thus when you select one vertex, you forcibly select it in all it's instances. Unwelding all the vertices allows you to select every vertex without selecting it's other instances.
While the UV-map appears to be fucked-up, you will only need to select a set of tiled vertices and drag them back into the first square so to say...
locking X/Y axis one at a time can help you in the process. Most of the time, the groups of vertices have offsets just on a single axis...

I almost forgot... After all the editing process is done (that includes fixing the UV, realign textures, grouping/regrouping, etc... ) you select all your model again and weld the vertices together -> Vertex > Weld Together


Some Modelling Tips:


- HL1 engine doesn't support textures with a pixel count greater than 512 X 512 !
- Don't use texture sizes as 768 X 384 ! Use only texture sizes that are power of TWO, as the following:
2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, etc.
For ex: 1024 X 256 or 2048 X 128
Using 768 X 384 will look the same as 512 X 256 ! So don't waste the pixels for nothing !
If you have a texture 1024 X 512 you should scale it to 512 X 512 for best quality !
- Use the default Microsoft Paint for resizing (downscaling) textures ! Believe it or not, it has the best downscaling filter quality wise !
- Do NOT use Microsoft Paint for converting the texture color depth to indexed 256 bit ! Use a dedicated Image editor as Photoimpact, Photoshop, etc...
- DO NOT clone textures ! I mean use the same texture twice with different name... If it's the case of a texture that has an additive part then cut the texture accordingly and regroup the result in two or more parts.
- Always realign UV-Maps on models you will convert or models you have decompiled for modifying before recompiling them ! You should also know that when you compile any HL/CS model the UV-Maps will be offset -1 ~ 2 pixels on X/Y axis so after you finish to realign the UV-Map you should move the entire UV-Map 1~2 pixels to the right and 1~2 pixels down.
- Use small textures for small or distant objects. Only use large textures for close objects or larger ones. If you fail to do this your models will look "pixelated" and ugly. A bigger texture doesn't always mean a better looking model.
- The correct way to get an alien format texture into a HL1 compatible texture:
a. Get your alien texture (tga/png/dds/vtf/etc.) into the appropriate converter
b. Export it as ".BMP" file type RGB True Color (24bit) bit depth
c. Now it's the proper time for the resizing (downscaling) process if necessary. (texture too big or model very small/distant in game)
There may also be cases when you need/want to cut/crop your texture into pieces...
d. Convert the "prepared" texture(s) to Optimized Indexed 256bit color depth.



- To be continued...


EDIT!

2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, etc.
For ex: 1024 X 256 or 2048 X 128

^ ^ WRONG!

2, 4, 8, 16, 32, 64, 128, 256, 512.
For ex: 512 X 256 or 512 X 128

^ ^ CORRECT!
__________________
Originally Posted by Hawk552
Actually, if your style pisses me off enough, I'll generally go through your code and find some reason to unapprove it or at least hold it back.

Last edited by Costin83; 04-07-2014 at 06:05.
Costin83 is offline
Send a message via Yahoo to Costin83
bibu
Veteran Member
Join Date: Sep 2010
Old 12-17-2011 , 05:27   Re: [TUT] How to overcome some annoying problems on converted models for CS 1.6
Reply With Quote #2

Good job. You forgot how to solve the UV-Map tough.
__________________
Selling tons of my own private works.
Accepting paid work for clans and communities.
Don't hesitate to contact me.
bibu is offline
GAARA54
Veteran Member
Join Date: Oct 2009
Location: Everywhere
Old 12-17-2011 , 06:25   Re: [TUT] How to overcome some annoying problems on converted models for CS 1.6
Reply With Quote #3

oh, i had all this 3 problems...
and break my head when trying to found solution for this problems
big thanks for tutor

1 part look like you type a short story
__________________

Last edited by GAARA54; 12-17-2011 at 06:27.
GAARA54 is offline
Costin83
Senior Member
Join Date: Jul 2008
Location: Romania
Old 12-17-2011 , 06:32   Re: [TUT] How to overcome some annoying problems on converted models for CS 1.6
Reply With Quote #4

Quote:
Originally Posted by GAARA54 View Post
oh, i had all this 3 problems...
and break my head when trying to found solution for this problems
big thanks for tutor

1 part look like you type a short story
Where do you think the pictures came from... ? Those are your print-screens...
I did "break my head" too trying to fix the dang things...
__________________
Originally Posted by Hawk552
Actually, if your style pisses me off enough, I'll generally go through your code and find some reason to unapprove it or at least hold it back.

Last edited by Costin83; 12-17-2011 at 06:34.
Costin83 is offline
Send a message via Yahoo to Costin83
XINLEI
me too
Join Date: Jun 2011
Location: Colombian Coffee storage
Old 12-20-2011 , 14:21   Re: [TUT] How to overcome some annoying problems on converted models for CS 1.6
Reply With Quote #5

Quote:
- HL1 engine doesn't support textures with a pixel count greater than 512 X 512 !
Excuse me but:
http://www.gamebanana.com/tools/5094
Quote:
If you have a texture 1024 X 512 you should scale it to 512 X 512 for best quality !
That is depending how the texture is applied to the model IMO, for example This model uses 1024 X 256 textures.

i'm not a modeler or something like that, but Damn That's a good guide. there's a bunch of those gliched models over here.
XINLEI is offline
Costin83
Senior Member
Join Date: Jul 2008
Location: Romania
Old 12-20-2011 , 20:35   Re: [TUT] How to overcome some annoying problems on converted models for CS 1.6
Reply With Quote #6

Quote:
Originally Posted by XINLEI View Post
Excuse me but:
http://www.gamebanana.com/tools/5094

That is depending how the texture is applied to the model IMO, for example This model uses 1024 X 256 textures.

i'm not a modeler or something like that, but Damn That's a good guide. there's a bunch of those gliched models over here.
1. 1024 X 256 = 512 X 512 = 262144 = 2048 X 128 etc...

2. Even if you can compile a model with 552 X 552 texture size, as I have seen lately in some models from cs***.ru or even greater, up to 1024 X 1024 (if that is indeed true) it won't help you at all...
HL engine only supports gl_maxsize = 512 ! -> so... waste, waste, waste, waste, waste...



EDIT:
ANY TEXTURE WITH SIZE BIGGER THAN 512px IN ANY PLANE (X or Y) IT'S A WASTE.
So... any texture like 1024 X 256 or 2048 X 128 for example, it'll be the same as 512 X 256 and respectively 512 X 128 !
Take a look at the following self explanatory screenshot:
Even though the screenshot it's compressed (for size reasons) the difference can be seen easily. The difference it's much more noticeable in fact.

Attached Thumbnails
Click image for larger version

Name:	waste.jpg
Views:	2449
Size:	99.1 KB
ID:	132416  
__________________
Originally Posted by Hawk552
Actually, if your style pisses me off enough, I'll generally go through your code and find some reason to unapprove it or at least hold it back.

Last edited by Costin83; 04-07-2014 at 05:48.
Costin83 is offline
Send a message via Yahoo to Costin83
ARES[ro]
Senior Member
Join Date: Apr 2010
Old 12-22-2011 , 22:24   Re: [TUT] How to overcome some annoying problems on converted models for CS 1.6
Reply With Quote #7

Nice tuts, I'm not a modeler but it can come in use any time...
__________________
okay
ARES[ro] is offline
nss
Junior Member
Join Date: Feb 2011
Old 12-25-2011 , 12:03   Re: [TUT] How to overcome some annoying problems on converted models for CS 1.6
Reply With Quote #8

thanks for this tuts , i have some problem about the texture size ,would you like to help me ? (i set gl_maxsize = 512)

Use only texture sizes that are power of TWO, as the following:
2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, etc.

1.
i have a model that texture size 508x508 (the texture i see in hlmv)
in game the texture will become 256x256 or 512x512 ?
if : 256<texture size <512 , how to know when in game ,it will be 256 or 512 ?
2.
do you think there is a value that if texture size >this value ,in game they will take the larger size
for example if we have 256<texture size <512 , i assume that the value =average= (256+512):2 =384
if texturesize > 384 in game its size will be 512
if texturesize <= 384 in game its size will be 256
there is a value like this ? how to know the texturesize in game ?

3.
i can't find anyway in mspaint to resize/rescare the bmp. there is only a function : toolbar => image =>attributes
but it doesn't rescale the image, it only add the white image to bottom ,
i try to use photoshop and ForceVision both are ok but when i rescale size to 512x512 and save as 256 bmp
recompile and open in hlmv, the texture size is 512x511
i must reopen the bmp file and rescale to 513x513 ,at this moment, the texture size is 512x512
is it needed to do these (rescale to 513x513) when hlmv show the size is 512x511 ?

if anyone sure about the answer ,please help me, thanks


Last edited by nss; 12-25-2011 at 12:04.
nss is offline
Costin83
Senior Member
Join Date: Jul 2008
Location: Romania
Old 12-25-2011 , 21:05   Re: [TUT] How to overcome some annoying problems on converted models for CS 1.6
Reply With Quote #9

Quote:
Originally Posted by nss View Post

1.
i have a model that texture size 508x508 (the texture i see in hlmv)
in game the texture will become 256x256 or 512x512 ?
if : 256<texture size <512 , how to know when in game ,it will be 256 or 512 ?

2.
do you think there is a value that if texture size >this value ,in game they will take the larger size
for example if we have 256<texture size <512 , i assume that the value =average= (256+512):2 =384
if texturesize > 384 in game its size will be 512
if texturesize <= 384 in game its size will be 256
there is a value like this ? how to know the texturesize in game ?

3.
i can't find anyway in mspaint to resize/rescare the bmp. there is only a function : toolbar => image =>attributes
but it doesn't rescale the image, it only add the white image to bottom ,
i try to use photoshop and ForceVision both are ok but when i rescale size to 512x512 and save as 256 bmp
recompile and open in hlmv, the texture size is 512x511
i must reopen the bmp file and rescale to 513x513 ,at this moment, the texture size is 512x512
is it needed to do these (rescale to 513x513) when hlmv show the size is 512x511 ?

if anyone sure about the answer ,please help me, thanks

1. It will become 512X512

The original texture in that model (before compile) was 512X512 (this is not related with your texture becoming 256X256 or 512X512 in game btw)
After the compile the texture was cropped by the compiler (studiomdl.exe) to 508X508 (upscaled to 512X512 ingame)

Q: Why was a texture cropped, how and why should I avoid this ?

A: The Half-Life Model Compiler will crop any texture if the UV-Map doesn't fill the entire texture surface on at least two min/max points on it's Width and Height. Theoretically to disable this nag feature, you would search in your model's .QC file for the line "$cliptotextures" and comment it out like this: "// $cliptotextures" or delete it completely.
BUT: Due to a stupid bug in the compiler doing this wouldn't change a thing... at least most of the times...
Being the fact that this bug will most likely cause you headaches and eventually you will be ending up by hurting yourself (depending on the person involved in the process) there is another workaround for this:
Make a plane in your problem model (a plane consists of two faces/triangles) and map it to your texture. Be sure that your plane's UV-Map covers ALL the texture surface!
Otherwise, you can make use of two hidden neighbor faces within your model and do the same thing as you would've done with the created plane mentioned above.

You can take a look at the next picture to understand more clearly where the cropping of the texture will occur:



Note the red square that is covering the whole UV-Map surface. what's left outside of it will be cropped by the compiler. If it were the case where the UV-Map would cover the entire texture surface, the texture wouldn't be cropped.


Why avoiding cropping the textures in a model; wouldn't this help with my models using less resources/memory.disk space... ?
Well, actually for a short answer: NO.
Because the texture will be up/down-scaled accordingly anyways.
After de/compiling one model over and over, you will find yourself in the situation of a repetitive cropping of your texture until nothing remains out of it (so to speak)
Another problem when compiling textures with non standard dimensions or already cropped textures (due to a poor compiling procedure) is that the texture may become like it would be corrupted (in fact it really isn't... )

Here's an example of decompile/recompile damaged texture:


2. 384X384 will become 256X256 (downscaled) and 385X385+ will become 512X512 (upscaled/stretched)
Don't get yourself fooled in n'either one of the situations above.
a. downscaled texture = waste of disc space (bigger filesize for SAME DETAIL)
b. upscaled texture = waste of detail and Memory usage.

3. Remember that your model originally had a 512X512px texture.
Before and after compiling that model the outside parts of the cropped texture weren't used anyways... So the simplest and most effective solution in this situation would be to add white borders on the sides of your texture, thus bringing it to it's original dimensions. Do this in MS Paint.
Take a look in the first post and don't forget to read the line where it says DON'T resize/scale/stretch/etc. Indexed 256bit. textures. You can only cut them, slice them, crop them (operations that don't imply the work with colors of any kind)

The best result you could obtain, will be by searching the internet for the original texture the model used. If you can find it then you're in luck; If you don't, well... just add the borders to the texture.
Attached Thumbnails
Click image for larger version

Name:	cropped_texture.jpg
Views:	3071
Size:	35.7 KB
ID:	97272  
__________________
Originally Posted by Hawk552
Actually, if your style pisses me off enough, I'll generally go through your code and find some reason to unapprove it or at least hold it back.

Last edited by Costin83; 12-25-2011 at 21:15.
Costin83 is offline
Send a message via Yahoo to Costin83
nss
Junior Member
Join Date: Feb 2011
Old 12-26-2011 , 04:07   Re: [TUT] How to overcome some annoying problems on converted models for CS 1.6
Reply With Quote #10

thanks for the detail answer ,Costin
there is some problem , please help me if you're not trouble
1. that means if i don't have source texture and if texture size < 512x512 ,it's better don't touch the texture ,right ?
what about models that texture size >512x512 if we don't have source texture ?
Quote:
Originally Posted by Costin83 View Post
Take a look in the first post and don't forget to read the line where it says DON'T resize/scale/stretch/etc. Indexed 256bit. textures
2. if we don't have source texture ,( only had 256bit texture that export from model) :
there are some models that texture size > 512x512
a. in this case ;should we downscale it to 512x512 (for better performance) ? (because you said DON'T resize/scale/stretch/etc. Indexed 256bit texture) ?
b. it seems that downscale 256 bits texture don't effect much to color ? i used this way to resize a texture >512 and can't realize the different between
downscaled and original images :

b1 .(i'm not sure the meaning of "downscale" here , so please tell me if i'm wrong) :

downscale here is that make the texture stretch to 512x512 ,no crop ,
and add no space to picture , and don't keep the old ratio of width and height image size
(change ratio)
in photoshop : i downscale image by go to toobar =>image => image size =>
width 512 ,height 512,i uncheck "constrain proportions" box ,the resize mode i choose "bicubic"
and save as 256bit bmp

3.
Quote:
Originally Posted by Costin83 View Post
Before and after compiling that model the outside parts of the cropped texture weren't used anyways... So the simplest and most effective solution in this situation would be to add white borders on the sides of your texture, thus bringing it to it's original dimensions. Do this in MS Paint.
could you please tell me more detail about that : this is for source texture - or for 256 bits texture that exported into 24 bits bmp ?
because MSpaint can't save 256 bits image without losing color ,so i think the best solution here if we don't have source texture is use photoshop as i mention above ,is it right ?
nss is offline
Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -4. The time now is 02:31.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Theme made by Freecode