Share Your Tips and Tricks!

Garry's Mod modelling
#1

Some of us here have been working in this field for quite some time now and we’ve learned all sorts of odd, but useful tips and tricks for things. Why not make a thread specifically for them for others to read through when bored or simply interested?

Absolutely anything related to modeling is welcome, from Source engine tricks to anything regarding modeling, texturing, and so on. Post those neat little things you’ve learned over the years, or even just today!

I’ll start with something simple regarding Shadow Miku:

Here’s what I learned – this is the Spy’s cloak shader. You can kind of break the transparency simply by adding $opaque to the model (make sure you don’t have $mostlyopaque anywhere in it).

The materials:

Body:



    "$basetexture" "models\captainbigbutt\vocaloid\shadow_miku_append\body"      // Any texture works; I just stuck to a very small black texture
    "$bumpmap" "models\captainbigbutt\vocaloid\shadow_miku_append
ormal"      // Not really necessary
    "$nodecal" "1"      Also not necessary

    "$cloakpassenabled" "1"      // Enables the cloak shader
    "$cloakfactor" "0.95"      // Defines how blurry it is
    "$cloakcolortint" "[0 0 0]"      // Tints the color to black
    "$refractamount" "0"      // Controls how refractive the model is (distorts the view as light passes through the model).

Eyes / lights:



"VertexlitGeneric"
{
    "$basetexture" "models\captainbigbutt\vocaloid\shadow_miku_append\eye"      // Anything works here as well really, but I used a small white texture
    "$nodecal" "1"      // Disable decals
    "$selfillum" "1"      // Makes the lights, er, light up
    "$selfillumtint" "[32 32 32]"      // Brightens the lights up a bit, even when colored -- unnecessary but mess with the settings to see what you like
      // There is a player color proxy in this material as well if you want the model to be colorable. Alternatively you could replace this to color the shadow by changing the resultvar and adding this to the body instead. See full material url="http://pastebin.com/M83tPizG"]where.
}

I’ve posted this before but I was still experimenting with it and never posted this much info about it. It’s also long since been buried in the ports and hacks thread which is why this one was created. I’ll post some more and hopefully newer stuff tomorrow.

Also, please don’t bother complaining if someone posts something you claim to be obvious as others may still not know about it.

Anyway, share your knowledge!

#2

I’ll start by sharing something basic, and then share cooler stuff each week.

To get phong working correctly on your models, in addition to a bumpmap (which is actually a normal map!) and the phong/phongboost/phongexponent lines, you’ll also need to add lines for the tint and fresnel:


	
"$phongtint" "[.85 .85 1]"
"$phongfresnelranges" "[.3 .65 30]"

In total, it should look something like this:



	"$phong" 1
	"$phongboost" "0.5"
	"$phongexponent" 25
	"$phongtint" "[.85 .85 1]"
	"$phongfresnelranges" "[.3 .65 30]"
#3

Here’s a trick I figured out just the other day regarding 3ds max and face flexes. The morph targets are based on where verts should be in the shapekey rather than based on how much they’ve moved as opposed to the default head. Source does the same way. So if you want to make any large changes to the face after morph targets have already been made, you’ll most likely need to remake your morph targets. Instead of doing that though, you could just make the changes in a separate editable poly modifier which can just be copied over to other heads. Certain specific flexes may need some minor tweaks but it generally works fine as long as you only move or remove verts – welding any causes problems. Morph targets will need to be reloaded in the modifier as well.

#4

=========Static world models for Counter-Strike Source (and similar Source games)=========
This one mostly applies to Counter-Strike Source, but it can be applied to other Source games that behave similarly with their world animations for weapons (assuming they use the classic v_model/w_model setup). It’s purely for aesthetic nuts that don’t like to see weapon clipping and are willing to sacrifice part of the visible animations for the world model when reloading the weapon. This method will essentially remove the animation from being visible on weapon world models, but it does help for people that hate seeing the magazine just floating away from where it should be.

As I’m sure most people are aware, the default world models (and even a majority of custom world models) for Counter-Strike Source seem to be a bit buggy with their animations (and by buggy, I mean you end up having the magazine floating out of the magazine well and partially into the barrel when standing idle or running around).

For what modelling programs that actually allow people to assign the .VMT itself to certain model segments (such as Milkshape 3D for the quickest example), you’ll first need to import the .SMD of the model you are wanting to apply this to and duplicate the magazine model so that you have two of them present; this will be necessary for later steps. Once you get around to assigning materials/textures to the model, assign them as you would normally, but assign a dummy .VMT file to the duplicate magazine (I would advise throwing your dummy .VMT file into the same folder that’s in use for your world model’s texture files for the sake of not having to edit your .QC file before compiling). The info inside of the dummy .VMT file should show as follows:


	
vertexlitgeneric
{
	$no_draw 1
}

Those who know what $no_draw does will know what the results will be. As for those who don’t know what $no_draw does, that command will (when active, hence the 1) hide a given segment of a model from being seen in the Source engine when the model is in use. This is required in order to hide the duplicate magazine from being seen.

After you’ve finished assigning your .VMTs to the your model and the duplicate magazine, it’s now time to move on to assigning the model segments to their appropriate bones/joints; for the time being, this will be explained with Milkshape 3D (3DS Max isn’t wanting to work with me atm). Now, Counter-Strike Source isn’t too picky when it comes to assigning bones/joints to the models, so all you really need to work with are the ValveBiped.weapon_bone, ValveBiped.weapon_bone_Clip (for rifles and pistols; shotguns make no use of this and therefore don’t have it present), and ValveBiped.flash (and ValveBiped.flash_silencer when working with the M4A1’s world model) bones/joints. Assign everything appropriately to the aforementioned bones/joints, except for the ValveBiped.weapon_bone_Clip bone/joint; instead of assigning the magazine that you normally would, assign the duplicate magazine with the dummy .VMT file attached to it. After doing all of this, export your .SMD file for your world model, and then compile it as you would normally (making the proper changes to your .QC as necessary).

Once the model is compiled, load up Counter-Strike Source and create a server. Once you’re finally in the game, simply open the console and give yourself the weapon (give weapon_); while the console is open, type in the following command string:


thirdperson; cam_idealdist 60; cam_idealyaw 115

If done correctly, your camera should now be in third-person and facing your character from the side and somewhat to the front. Run around for a moment (you may need to bind ‘record 1; stop’ to a key on your keyboard and hit it a couple times if your character is ‘floating’ or moving in slow-mo when you move), fire the weapon a little, and reload the weapon; if you were successful, the visible magazine should look like it’s staying in place the entire time. If your duplicate/dummy magazine is still visible or is receiving Source’s infamous purple-black checkered texture, or if the dummy magazine and visible magazine are both animated, make sure to go back into your world model’s reference .SMD and fix it up as you would normally by going over everything again and making sure to follow the information accordingly.

=========Cheating w_model consistency in Counter-Strike Source and using ‘appropriate’ w_model animations=========
This one is generally simple and is more-or-less driven by some changes to your .QC and a small change to a specific script for the weapon slot you’re compiling a world model for. You can apply the previous trick to this as well, so they sort of go hand-in-hand with each other.

As I’m sure some people know, there are quite a few old (and current) weapon skins for Counter-Strike Source that either don’t have a world model, or they have a world model included that seems kind of buggy because of the player model’s animations when using certain weapons for a given weapon slot (example: a FAMAS for the AK-47 slot). With this trick, you can at least cheat the game into being a little more lenient with your custom weapon compiles, but with just a tiny little more work to make it functional in-game. To save people the time of having to manually find and convert the weapon scripts though, I will include a link to my default script pack from 2011 (surprisingly, Valve hasn’t changed anything for these scripts since the date mentioned in the title of that submission).

The first thing you’ll want to do is decompile one of the default world models from the game that follows suit with the weapon model you’re using to replace one of the defaults (example: a bullpup weapon like the L85A2 would benefit from using the default FAMAS’s world model rigging). Replace the model as you would normally (possibly even consider doing the previous trick as well for aesthetic reasons), and then export your reference .SMD accordingly. Now, open your .QC file and go to the $modelname line, changing whatever it’s currently set to (in the case of the provided example: $modelname “weapons\w_rif_famas.mdl”) to the slot that you are intending to put the weapon on (for example: $modelname “weapons\w_rif_sg552.mdl” for the SG552 slot). Continue making the appropriate changes to your .QC as necessary (such as changing the $collisionmodel to your reference .SMD file) and compile your weapon model afterwards. After that, open the two scripts that would be necessary for your weapon skin (with the provided examples, you’d need weapon_famas.txt and weapon_sg552.txt) and examine them; both scripts will have a line that says “PlayerAnimationExtension”, followed by the name of the animation. For the script that will go with the weapon you compiled (for this example, weapon_sg552.txt), change the “PlayerAnimationExtension” line from “sg552” to “famas”; this will change the in-game player animation accordingly to use the animations and read the model positioning for the FAMAS by default on the SG552 slot. The final step before testing the model would be to place it in its correct location (considering how the SteamPipe setup works, you’d either place it in ‘Steam\Steamapps\Common\Counter-Strike Source\cstrike\custom<your custom weapon folder name here>\scripts’ for the loose-file format; if you pack it into a .VPK, it’s fairly simple to know where it goes before packing the compiled model, its textures, and the script into a .VPK).

Once you have everything in place for your world model and its associated script, go ahead and launch Counter-Strike Source, then create a server like you did in the previous trick. Either purchase the weapon or use the console to give yourself the weapon that you compiled the model for, and then use the console to go into thirdperson and move the camera around like you did before in the previous trick. Assuming you did everything correctly, you should be able to your character holding the weapon like they would be if you had grabbed the other weapon instead (in this case, you’re holding the SG552 weapon you compiled as if it were the FAMAS instead).

Please note: Some weapon skins have the view model rigged a certain way that might have it appear as left-handed or right-handed by default when viewed outside of Counter-Strike Source or the model viewer, and using these scripts might accidentally mirror them to the other side of the screen; if this happens, simply re-open the modified script for your skin, and change the “BuiltRightHanded” line to the opposite of what it currently shows (if it shows “0”, change it to “1” and vice versa).

#5

-snip-

#6

HWM Tip:

All the corrective shape keys, and more, are 100% essential if you want the standard DMXEdit scripts to run correctly.

You can find the base sets here: https://docs.google.com/document/d/12TK8AtbA9zBuLnuTOV491OUZnc7J8xWN5H1WbQ26MJY/edit

And the correctives here: https://docs.google.com/document/d/1YZ5ppKogGNixCuWU6OWNXmez7FtqYWTQpXfMjX_8z4I/edit

#7

Whoosh. There goes the point of this thread, right over your head. In all seriousness assuming something is general knowledge doesn’t mean everybody already knows about it. What’s the worst that could happen, somebody already knows about it? Someone might still learn from it anyway.

Edit: Speaking of which how about I post something that may or may not be common knowledge?

(ignore the tie artifacting)

Something I learned from Cra0kalo a while ago. Rather than merging an emissive mask with your diffuse mask in Photoshop and using $selfillum, you can just save it as its own mask and overlay it in-game with $detail. Using $selfillum basically means a part of a texture is fullbright. Opacities are only supported by 0 or 1. In other words, part of the material either lights up or it doesn’t. There’s no brightness really other than the texture itself. On the other hand if you use $detail masks, you not only get control over opacities, but you get control over brightness to an extent. With $selfillumtint, tinting the texture will basically just darken it between what it is and black. With $detail and lower opacities, the texture just has less of a glow in dark areas.



    "$detail" "models\captainbigbutt\vocaloid\miku_append\body_illum"      // The vtf for the emissive mask. It's basically only the lights on top of a solid black color
    "$detailscale" "1"      // The texture doesn't tile multiple times
    "$detailblendfactor" "0.4"      // This is the opacity of the mask (in this case, the brightness of the lights). 1 is too bright for what I wanted, so I used 0.4 instead
    "$detailblendmode" "5"      // This is the mode used for rendering. 5 means it renders after lighting is applied, turning the $detail mask into an emissive mask.
#8

Simple one, but worth it for people porting models from games or engines with really detailed models (you can even get CG-quality models into Source this way if you wanted to for some reason)

Break up your model into smaller portions of no more than 20k-25k tris, then export each part as a reference SMD.

Then when you are authoring your QC files you use the $model command to specify the reference SMDs you export earlier. So if the model is in 3 parts, you would put

$model “SMD_1.smd”
$model “SMD_2.smd”
$model “SMD_3.smd”

when the model compiles, it will be compiled as one model, allowing you to effectively bypass the ~25k poly compile limit on studiomdl.

#9

I’ll drop a few 3DSMax tips and tricks I’ve learned over the years in here, if people are interested. I’ll try to drop one every day or two, assuming I can think of one. Honestly I have so many tricks I use without even thinking (or I have automated with scripts :v:)

Will also drop a few Source and flex-related things, if I think of any and can’t think of a 3DSMax trick.

Moving Armature & Baking the Pose
So imagine this scenario:

*You have your model, fully rigged. You want to edit something - let’s say you want to fix the broken textures inside the character’s mouth. You rotate the jaw-bone down, and you can see into the mouth and see exactly what polygons you need to fix.

You select your “Editable Mesh” or “Editable Poly” modifier in the stack, go into “Select Faces” mode and - the model snaps back to its binding pose! Even though the bones are rotated! You click out of “Editable X”, and the pose snaps back to the pose you want to edit. That isn’t fair! Why can’t you edit that pose?!*

Fixing this is really simple:

1.) Rotate your bones into whatever pose you want to edit.

2.) Right-click the Skin modifier, and choose “Copy.”

3.) Right-click the Skin modifier, and choose “Collapse To.” This will collapse everything down to your “Editable X”, destroying your Skin modifier in the process. Don’t fret! This is why we copied it!

4.) Right-click in the space above your now-singleton “Editable X,” and choose Paste. Your skin will come back, but now all the rotations you made seem to double on the mesh! Don’t worry, that’s normal and fixed in the next step.

5.) Selecting the Skin modifier, expand “Advanced” and uncheck then check “Always Deform.” Your model will now snap back to the pose you were trying to edit.

6.) Select your “Editable X,” go to “Select Poly”, and revel in the fact your model no longer snaps back to the pose! You can now do whatever editing you wanted to do, without having to fight the model!

#10

This step alone is also absolutely lovely should you need to move the model or bones for adjustment purposes without needing to edit the pose.

Also, sorry, I never seem to run out of anime experiments and examples.

The lighting on a model can make all the difference. Stylized faces may look better with hand-painted or baked shadows and then flat lightwarps if the shadows on them make them look uncanny. This doesn’t apply to anime and anime-esque specifically, mind you. Lightwarps are really useful.

#11

Fun tip for blender users:

If you want to turbosmooth/subsurf a mesh with shape keys, you can! Just make sure both preview and render on the subsurf are the same, but don’t apply the modifier. Then, export as you would normally.

Second tip about subsurf:

Always convert to quads first. It looks SO much better!

#12

If you’re setting up complex materials for a model in Garry’s Mod, this may help you:

First of all, setting up all of the models initially in HLMV can save you a bit of time if you don’t do that already, but final testing should be done in Garry’s Mod in a couple of different maps / lights. HLMV doesn’t use all of the shaders to the same capabilities the actual game(s) do.

In the model tab, don’t forget to check whether or not you’re missing materials.

http://i.imgur.com/guwIqH2.png[/t]

If it says you’re missing materials, there’s a “Materials Used” bar in that same tab at the bottom left. It’ll tell you the names of the materials it’s looking for on the model which might help you find the culprit easier.

[t]http://i.imgur.com/bLchu7p.png[/t]

When you’re actually setting up the materials using mat_fullbright 2 and/or mat_diffuse 0 can help you see how your shaders are actually effecting your model.

(ignore the unfinished / missing materials)
[t]http://i.imgur.com/ECvua1X.jpg[/t]
[t]http://i.imgur.com/PsEurJR.png[/t]
[t]http://i.imgur.com/aQhf1yV.jpg[/t]

If your model doesn’t look lively enough, consider adding lightwarps on different materials. Use cool blue shadows for standard materials and warmer red shadows for skin to simulate sub surface scattering. As lighting leaves the skin after travelling through the blood vessels and skin pigments, it usually leaves soft red shadows. Simply adding red shadows to the skin on your model may help it look just a little bit more alive.
Ensure that your lightwarps are imported uncompressed and use Clamp S / Clamp T to avoid artifacting!

Lastly, when using cubemaps, ensure you test your model in poorly lit areas. The cubemaps may appear to “glow” in a manner that you don’t quite want without some proper adjusting.
[t]http://i.imgur.com/6L3bT3n.png