Wall Worm Forums

Actually, never mind. I managed to figure out what I did wrong. It turns out I was doing it correctly the whole time. It had something to do with the scale command in the qc file that I didn't mentioned here. I solved it by scaling it inside Max.

Hi, I am having trouble trying to get the face flexes to work with my model.

Max:
http://i.imgur.com/frNJsa6.png
http://imgur.com/0xbqmTv

HLMV:
http://i.imgur.com/8UkZmmR.png

Note that the "MouthClose" slider is set to 1, so it's supposed to have the jaw to close, but it isn't in HLMV.

Now, I followed the Valve Developer Wiki on how to implement face flexes and I have tried pretty much everything there, but it resulted in the same result. And yes, I have set the MouthClose flex to 100% in frame 1 only, so I am not too sure why it isn't working.

QC File:
$cd "C:\Users\Dev\Desktop\Bayleef SFM & GMOD"
$cdmaterials "models\pokemon\Gen 2\Bayleef"
$model studio "Bayleef.smd"{

flexfile "bayleef.vta"
{
defaultflex frame 0
flex "MouthClose" frame 1
}

flexcontroller "phoneme" "MouthClose" "range" 0 1

%MouthClose = MouthClose
}
$modelname "yunpolmodels\pokemon\gen 2\Bayleef.mdl"
$bodygroup LEye
{
studio LEye1.smd
studio LEye2.smd
studio LEye3.smd
studio LEye4.smd
studio LEye5.smd
studio LEye6.smd
studio LEye7.smd
}
$bodygroup REye
{
studio REye1.smd
studio REye2.smd
studio REye3.smd
studio REye4.smd
studio REye5.smd
studio REye6.smd
studio REye7.smd
}
$bodygroup Leaf
{
studio Leaf.smd
blank
}
$bodygroup LLeaf1
{
studio LLeaf1.smd
blank
}
$bodygroup LLeaf2
{
studio LLeaf2.smd
blank
}
$bodygroup LLeaf3
{
studio LLeaf3.smd
blank
}
$bodygroup LLeaf4
{
studio LLeaf4.smd
blank
}
$bodygroup RLeaf1
{
studio RLeaf1.smd
blank
}
$bodygroup RLeaf2
{
studio RLeaf2.smd
blank
}
$bodygroup RLeaf3
{
studio RLeaf3.smd
blank
}
$bodygroup RLeaf4
{
studio RLeaf4.smd
blank
}
$texturegroup "skinfamilies"
{
{
"pm0153_00_BodyA1.vmt" "pm0153_00_BodyB1.vmt" "pm0153_00_Eye1.vmt"
}
        {
"pm0153_00_BodyA1_shiny.vmt" "pm0153_00_BodyB1_shiny.vmt" "pm0153_00_Eye1_shiny.vmt"
}
{
"pm0153_00_BodyA1_NoLW.vmt" "pm0153_00_BodyB1_NoLW.vmt" "pm0153_00_Eye1_NoLW.vmt"
}
{
"pm0153_00_BodyA1_shiny_NoLW.vmt" "pm0153_00_BodyB1_shiny_NoLW.vmt" "pm0153_00_Eye1_shiny_NoLW.vmt"
}
}
$surfaceprop "flesh"
$sequence ragdoll "ragdoll.smd" FPS 30 activity ACT_DIERAGDOLL 1

Quote from: wallworm on October 26, 2016, 02:50:16 PM
Sorry... I guess I skimmed some :)

Yeah, all I did was rotate the root node, assign the parts to the WWMT Helper and set the settings (explicit normal, concave, etc) in WW... then export :)

Note that I only rotated the root bone--and nothing else. Maybe that helps.

*facepalm*

All it took to fix was to rotate the root bone...

Wow, I am a very stupid person. I knew this should be simple, but I have overthought about it. As a matter of fact, I could have done this my own, but I didn't realize it.

Well, I learned something new I guess.

Anyways, thanks for helping out regardless.

Quote from: wallworm on October 26, 2016, 02:05:18 PM
So did you get the scene I sent to you? Did you test compiling from that WWMT Helper? You should get correct results. If not, then perhaps update to latest WW.

Yea, I did. I even had a picture as evidence in my last post. And I didn't even need to update WW for that.

Quote from: wallworm on October 26, 2016, 10:09:07 AM
This was all very straightforward.

Here are the steps I took:

• Opened Scene
• Rotated Root Bone by 90 degrees so prop facing vertical
• Opened WWMT Floater
• Clicked Pick Model and selected Mesh
• Selected extra mesh pieces and click Add Sel
• In WWMT turned off all options for the origin settings
• In WWMT made sure $staticprop was off
• Selected Hull mesh
• In hull Rollout, Clicked Add CM Sel
• In hull Rollout, turned on $concave
• Clicked Export VTF (made materials but no textures as you didn't send them)
• Clicked Export QC+Model

It compiled and is oriented as I'd expect along with the correct hull. Normals in Max and HLMV are identical. But I exported this with Explicit Normals option on... because your model has explicitly assigned normal. If your model has explicit normal, you should turn on explicit normal in the export dialog.

I don't know how this is straightforward. I can't seem to replicate your result without the result either being the model's lighting breaks or the collision hull's orientation is wrong.

And FYI, I did export my models using explicit normals though. I have always been doing that for every model I did.

And for the rotating, I did rotated and moved the model to the center in Max initially, but like I said, the model lighting will break if I did that. No idea how you managed to do that without the model lighting getting broken.

Result from rotating and centering the model in Max:
http://i.imgur.com/3aSwUEY.png

Result from using $upaxis "y":
http://i.imgur.com/Exi6S4a.png

Result from exporting your test model:
http://i.imgur.com/so2LuQX.png

Quote from: wallworm on October 26, 2016, 12:02:35 AM
Been pretty busy. Send me your original Max file (my email in WW readme). I will discover your conundrum.

Done. I have already sent the email to you.

Quote from: wallworm on October 23, 2016, 04:09:08 PM
OK, that is probably a good clue.

I think that aligning the hull's pivot to the pivot of the root of your model will help. That includes the orientations (so make the local x/y/z axis of the hull orient to the same directions as the root). You can do that by select the hull, clicking the hierarchy tab in the command panel, choose the affect pivot only, then use the align tool to align it to the root node.

Another possible option is to link the hull as a child to the root node.

Another possible option is to add a skin modifier to the hull and assign the root node as the bone to use.

FYI, this is how my collision hull looks like. It already has a skin modifier applied to it.

http://i.imgur.com/ryTPXp3.png

A question for you, what do you mean by assigning the root node as the bone to use? Do I assign the root node when I am exporting the collision hull?

Quote from: wallworm on October 23, 2016, 12:58:43 PM
Not sure what you mean 100%. It is not clear the entire process. Are you importing QCs first? Importing FBX? Where are the props coming from? Is the hull also being created externally or after imported into Max? But I will give some input.

When a prop is exported with $upaxis Y, the compiler will rotate the model on the X axis so that Y aligns with how the defaults are. I am not certain if this is an entire model rotation or just the root bones (bones with no parent). If it rotates each root bone, it probably means that you need to rotate the collision hull's pivot so that it is aligned to the root bone in the model.

Using an upaxis other than Z is not preferred when working inside 3ds Max. But if importing assets from other sources, you may have to accommodate it. One option (if importing FBX files) is to change the import axis in the FBX importer.

I guess I need to be more clear then.

I am not importing any qc files or fbx files. I am importing smd files and I created the collision hull inside 3DS Max.

I have been using $upaxis "y" to change the position of the model for some time. While it does work for the most part, I just found out that it doesn't apply to the collision models. As a result, the model always end spawning the sideways not upwards as it suppose to in GMOD

http://image.prntscr.com/image/16f6187ac41a4579bd814d797fe16721.png
http://image.prntscr.com/image/3db74c1cf4764fa889fe9d882bf4def9.png

Oh, and simply rotating and moving the model to the center doesn't work as it will result in the normals/model lighting breaking. I am suspecting it has something to do with the exporter since normals/model lighting looks fine in Max, but in game or HLMV, the normals/model lighting breaks.

In 3DS Max:
http://i.imgur.com/eLUTaG4.png

In HLMV:
http://i.imgur.com/tBdzaqS.png
http://i.imgur.com/MZ3QKjQ.gif

So, does anyone know how to change the way a model is spawned without encounter these issues?

Quote from: wallworm on June 12, 2016, 11:12:42 AM
Please look at the rollout at the bottom of the Models tab in the  global setting. When on, the weld will happen even with non-staticprop.

Note there is a quirk when using this on skinned models: the mesh will contain multiple "dead vertices". That shouldn't affect using the model to re-export, but it's not very clean. It's a known issue with the importer and skinned meshes.

Alright, looks like the weld went through as usual after applying this change. Thanks!

FYI, I am using Windows 10 and Max 2015.

So I was using the Wallworm importer as usual. When I imported the model into Max, the model loaded up very quickly, which made me suspect that something was wrong with the Weld Vertices function as it generally takes a lot longer to load the model into Max.

Then I decided to check out this issue by using Select Element and it turns out the vertices aren't welded even through I checkboxed Weld Vertices in the importer settings as seen below here.

Quote from: wallworm on March 30, 2016, 04:04:48 PM
I'd recommend watching some videos on skinning to make it familiar to you.

But a fast way is this:

• Select Mesh
• Open Skin Modifier in Modify Tab
• Click Edit Envelopes Button
• Click the bone you want to weight (in this case, REar2) in the Bones List
• Scroll down to Weight Properties
• Uncheck Paint Blend Weights
• Click Paint Weights button
• Hover over mesh. if the paint radius is too big, use CTR+SHIFT+LMB and drag up/down to change size
• Paint the vertices that you need to weight (in this case, the tips of the ears).

Note that since all of the meshes have this issue, you may need to do it to all of them if those meshes are used in the bodygroups. If the other meshes have exact same vertex count/ordering, you can use the Save/Load in the Skin Advanced rollout to do that fairly quickly.

It appears to be working fine, so far. It looks like I will have to reclone the meshes since the meshes are using the old messed up mesh. I will check back here to make a final confirmation that the process you describe works.

EDIT: Well, I can confirm that issue is fixed. Thanks wallworm for the assistance.

Quote from: wallworm on March 30, 2016, 03:48:24 PM

Quote from: Lopunny on March 30, 2016, 03:31:51 PM
And Carbink002 is the reference mesh.

The screen shot below is Carbink002. As you can see, the tip of the ear isn't weighted to the ear bone REar2. This is directly from the file you sent me and would explain the issue completely.

I'm viewing this in Max 2016 SP3. Perhaps there is a bug in your version of Max if you don't see this same issue on the model... check that you have the latest service pack installed.

I am using Max 2015 SP3. It's the latest version for Max 2015. It isn't a bug, I can confirm that the tip of ear isn't weighted at all somehow.
http://i.imgur.com/msGmIfp.png
However, I have never edited the weighting for a reference mesh before. So I am not too sure on how to approach this.

Quote from: wallworm on March 30, 2016, 03:04:22 PM
I looked at the file. I looked at all the hidden objects in the scene (Carbink001...10).

When I unhid one and looked at the skin, I can see clearly that the tips of the ears are unweighted. I have a feeling that this is the root of the issue. It's likely that the mesh you are exporting isn't actually the mesh you think you are exporting, or perhaps you are exporting all of the meshes.

I am hundred percent positive that I have exported each smd file with the correct mesh. Because I have done the same process with similar types of models and it work completely fine. And sometimes, the process doesn't work as intended like it is now.

Perhaps I didn't explain my processes enough.

I made clones of the mesh to make editing of the model much easier. So that I don't have to completely redo the import process again.

Each mesh clone (with the exception of mesh Carbink001) has a purpose.
The mesh Carbink010 is the physics mesh I exported.
Carbink005 - Carbink009 are meant for the bodygroups for the crystals.
Carbink003 and Carbink004 are bodygroups for the eyes of the models.
And Carbink002 is the reference mesh.
Carbink001 isn't used for anything.

Basically, how I export the meshes is that I export only one mesh at time. So say I want to export Carbink002, the reference mesh. I hide all of the other meshes (Carbink001, Carbink003 - Carbink010). Afterwards, I select all the unhidden objects and then I set up my exporter. Then I just export the mesh. And then just rinse and repeat.

I have specifically toggled the standalone exporter to export only the unhidden objects. It's basically impossible that any hidden objects will be exported at all.

Here let me give you some details about the settings I use for the standalong exporter.
http://i.imgur.com/xbwOwJ3.png

Quote from: wallworm on March 30, 2016, 12:35:32 PM
So notice that Carbink002, Carbink006 etc are the meshes. That is what their bone is coming from.

For $collapsebones to work properly, you need to include an animation sequences that tell the compilers that the bones you want to keep are actually used and should not be collapsed.

The next solution is to use:

$alwayscollapse "Carbink001"
$alwayscollapse "Carbink002"
etc

In the QC. If exporting with WWMT, this is automated with the $alwayscollapse checkbox.

That should solve the extra bones also. However, this will likely not solve the weight problem. Send me your original Max file (and if this started as a QC/SMD which I presume then send those as well).

Looks like your prediction is correct. It didn't. In fact, it led me to the same results as if I put $collapsebone in the .qc.

And I have already sent the email to you with the .QC and .SMD files attached as well.