More of a question than a request

[Clocksmasher]

So I came to the Modeler's Resource looking at the new Pokémon rips, when I'm curious to know what anyone here does with them. I mean, do you mess around with them in Blender/Maya? Can you use the rips from here and put them directly into SFM? Actually, shouldn't one try to set up a rig for them first before utilizing them in SFM? I'd like some closure of this sort of thing, since 3D models are clearly a world apart from just simple sprite editing.

[Filler]

Most of the Pokemon models are rigged, if anything.

My Profile picture (Porygon-Z) is a ripped model, exported to SFM myself and then rendered.

[Clocksmasher]

Most of the Pokemon models are rigged, if anything.

My Profile picture (Porygon-Z) is a ripped model, exported to SFM myself and then rendered.

"Exported"? You meant "imported," right? Anyway, so if you say these model rips are already pre-rigged (say I downloaded Golisopod's model from Sun & Moon), how do I import them into SFM? And under which file type?

[Filler]

You'd need to compile them.

The models are indeed in a Source-friendly format (Source uses .smd for models), you just need to write a QC file to compile it, and use tools such as Studio MDL, or Crowbar to compile it.

Textures need to be edited into the .vtf format, which could be done with Photoshop, or even GIMP with the right plugins installed.

[Clocksmasher]

You'd need to compile them.

The models are indeed in a Source-friendly format (Source uses .smd for models), you just need to write a QC file to compile it, and use tools such as Studio MDL, or Crowbar to compile it.

Textures need to be edited into the .vtf format, which could be done with Photoshop, or even GIMP with the right plugins installed.

It's very broad of you to assume I know how to write a QC file--let alone know what that is--or even compile something. In fact, all of what you said is beyond my talent or skill level. Basically I just wanted to know what various purposes or programs most people come to Modeler's Resources for. If I could mess-about with a set of models in Blender or Maya that'd be cool.

[Yunpol]

Basically I just wanted to know what various purposes or programs most people come to Modeler's Resources for. If I could mess-about with a set of models in Blender or Maya that'd be cool.

AFAIK, people usually use the models in the Model Resource for making games, animations, renders, and porting to other games/programs like MMD, Garry's Mod, or Source Filmmaker.

It's very broad of you to assume I know how to write a QC file--let alone know what that is--or even compile something. In fact, all of what you said is beyond my talent or skill level.

Then, I highly recommend you check out the Valve Developer Wiki if you just starting out in Source porting.

Here's some information about qc files and compiling a model.
Information about the QC file type
QC Commands
Information about compiling a model

[Filler]

Just to add some more light to it.

The easiest (and cheapest) way to make Source models is with Blender, using the Blender Source Tools extension.

Valve dev wiki link to it

For older versions of Source, everything is made in SMD models (This includes animations, too). Only vertex animation and QC files are not SMD files. Modern Source uses DMX files.

For an example of how a QC functions. Just look at this snippet of code I used on the Porygon-Z model. Stuff in Bold is not apart of the code, and is just rules to help understand how QCs work.

---

$modelname "Porygon_z.mdl" (This is the model name when compiled. Can cause issues when changed without a recompile)

$bodygroup "PRGZ" (This is the model SMD itself. It just references the SMD)
{
studio "porygon_z_reference.smd"
}

$cdmaterials "models\porygon_z\" (This is where to tell Source to find textures under the game's "materials" folder.)

$texturegroup "skinfamilies" (These are settings for texture changing. Source has a hard-coded 32-texture limit per model, though)
{
{
"body.vmt"
"eye.vmt"
}
{
"bodyshiny.vmt"
"eyeshiny.vmt"
}
}

$surfaceprop "metal" (This is the sound/visual effect used when the model is hit/moves around)

$contents "solid" (This refers to how Source will handle the model's collision)

$eyeposition 0 0 70 (This provides the eye rotation position. Didn't bother to add eye textures on the model, so it was rendered unused. Shouldn't of done that)

$sequence "ragdoll" "porygon_z_anims\ragdoll.smd" {
fps 30
"ACT_DIERAGDOLL" 1
}

(This is the model's animations. Multiple animations can be provided. But are capped at 30 FPS)

$collisionjoints "porygon_z_physics.smd"
{
$mass 15
$inertia 10
$damping 0.05
$rotdamping 5


$jointconstrain "Tail" x limit 0 0 0
$jointconstrain "Tail" y limit 0 0 0
$jointconstrain "Tail" z limit 0 0 0

$jointconstrain "RArm" x limit 0 0 0
$jointconstrain "RArm" y limit 0 0 0
$jointconstrain "RArm" z limit 0 0 0

$jointconstrain "EndRArm" x limit 0 0 0
$jointconstrain "EndRArm" y limit 0 0 0
$jointconstrain "EndRArm" z limit 0 0 0

$jointconstrain "EndTail" x limit 0 0 0
$jointconstrain "EndTail" y limit 0 0 0
$jointconstrain "EndTail" z limit 0 0 0

$jointconstrain "LArm" x limit 0 0 0
$jointconstrain "LArm" y limit 0 0 0
$jointconstrain "LArm" z limit 0 0 0

$jointconstrain "EndLArm" x limit 0 0 0
$jointconstrain "EndLArm" y limit 0 0 0
$jointconstrain "EndLArm" z limit 0 0 0

$jointconstrain "Head" x limit 0 0 0
$jointconstrain "Head" y limit 0 0 0
$jointconstrain "Head" z limit 0 0 0
}

(This is the model's physics hitbox. Used for ragdoll collision and whatnot. It's best to keep these models far lower poly than the actual model to reduce lag)

---

[Yunpol]

Just further add on to what Filler said, you don't actually have to put in the $collisionjoints part as Source Filmmaker doesn't really need physics to begin with, but it's required for Garry's Mod if you want to make it a ragdoll.

[Clocksmasher]

Just further add on to what Filler said, you don't actually have to put in the $collisionjoints part as Source Filmmaker doesn't really need physics to begin with, but it's required for Garry's Mod if you want to make it a ragdoll.

I have to say, I don't know what I expected as a response. It looks like a myriad of coding and 3D modeling knowledge that I would probably need to take a college course to understand. That is to say, I hope you don't find me the whining sort when I mention that. It's just pretty overwhelming, and seems there's really no simple solution to it. For instance, and from what I understand, Filler hinted that I need to know the exact mesh measurements to determine what's smaller than that, so the collision model doesn't eat up so much memory. That could take months of research due to my poor learning ability.

But I won't be thankless for your help. Hopefully this information will be at the end of a fruitful Google search for somebody.

[Yunpol]

I have to say, I don't know what I expected as a response. It looks like a myriad of coding and 3D modeling knowledge that I would probably need to take a college course to understand. That is to say, I hope you don't find me the whining sort when I mention that. It's just pretty overwhelming, and seems there's really no simple solution to it. For instance, and from what I understand, Filler hinted that I need to know the exact mesh measurements to determine what's smaller than that, so the collision model doesn't eat up so much memory. That could take months of research due to my poor learning ability.

But I won't be thankless for your help. Hopefully this information will be at the end of a fruitful Google search for somebody.

I understand how you feel. Everyone including me who has worked Source are going through this process. Source may look complicated at first, but as you learn more about how the Source Engine works, it's actually not too hard. All I can say is just take your time to read the Valve Developer Wiki, so that you can understand more about how the Source Engine works.