Each body group (Blender Object) should only be 9000 - 11000 verts (closer to 9000 and even then, depending on the complexity of the model, this limit may have to be decreased.) You have to watch for Model splitting or the dreaded Exception ACCESS (1) error, when you compile. If these occur, then the objects causing the split or fatal error have to be decreased in vert counts.

If your model has shapekeys/blendshapes (flexes) all flexes should be contained in one body group (blender object), it doesn't matter where they are on the model, they should be confined to one bodygroup.

As for MATERIALS (VMTs), a model can only have up to 32 (?? I think it is) materials. This includes all Texture groups (skins) you add to the QC.

A VMT may call multiple elemental Textures (VTFs like Basetexture, Bump./normal maps, environmental/phong masks, detail textures, etc..) and textures are limited to the textures required by the elemental calls from the VMTs.

All Textures must be to the power of 2 in dimensions, like 64x64, 128x256, 4096x2048, 2048x512, etc, The width and the height must be to the power (2,4,8,16,32,64,128,256,512,1024,2048,4096) and I'm not sure if a Valve model or the Valve programs support 8K textures (8192) pixels (but why would anyone want to use a monster like that in a model anyway, LOL!)

you have a max of 64k (65536) vertices per body group. the max face count for totally split triangles or in general is 21.845 faces per bodygroup. the compiler will split geometry typically into loose triangles. i dunno if it merges duplicates back together. that should in theory rasie the face limit. but stick to 21k. this is the correct limit.

you have a max of 32 materials. i'm not sure if a variable skin material of say 4 different colors are 4 or just 1 material, cause it's a replacement thing. you gotta try that.

the texture size limitations depends on the hardware and in dx9 the max is 8192x8192. i've never tried it but it should be possible to use those in sfm.

Originally posted by episoder:

- you have a max of 32 materials. i'm not sure if a variable skin material of say 4 different colors are 4 or just 1 material, cause it's a replacement thing. you gotta try that. -

A model can reference up to 32 VMTs total. So, Team Fortress 2's Spy is very close to that limit (due to all of the disguise masks for each class and such), even though it never uses more than 5(?) materials at the same time.

Originally posted by episoder:

- the texture size limitations depends on the hardware and in dx9 the max is 8192x8192. i've never tried it but it should be possible to use those in sfm.

I don't know for certain, but I also think that filesize is relevant here.
I definitely seem to remember an 8192x8192 VTF resulting in pink-black checkerboards when stored as a BGR(A)888(8) texture, but showing up correctly when stored as a DXT5 texture, but it's been years since I tried that, so I can't say for sure whether or not that's right.

But in either case, going above that shouldn't cause crashing instability issues.

Awesome! Couldn't find the exact limits for verts and textures, but everyone's answers helped a lot. Thank you, everyone

Originally posted by Pte Jack:

Each body group (Blender Object) should only be 9000 - 11000 verts (closer to 9000 and even then, depending on the complexity of the model, this limit may have to be decreased.) You have to watch for Model splitting or the dreaded Exception ACCESS (1) error, when you compile. If these occur, then the objects causing the split or fatal error have to be decreased in vert counts.

If your model has shapekeys/blendshapes (flexes) all flexes should be contained in one body group (blender object), it doesn't matter where they are on the model, they should be confined to one bodygroup.

As for MATERIALS (VMTs), a model can only have up to 32 (?? I think it is) materials. This includes all Texture groups (skins) you add to the QC.

A VMT may call multiple elemental Textures (VTFs like Basetexture, Bump./normal maps, environmental/phong masks, detail textures, etc..) and textures are limited to the textures required by the elemental calls from the VMTs.

All Textures must be to the power of 2 in dimensions, like 64x64, 128x256, 4096x2048, 2048x512, etc, The width and the height must be to the power (2,4,8,16,32,64,128,256,512,1024,2048,4096) and I'm not sure if a Valve model or the Valve programs support 8K textures (8192) pixels (but why would anyone want to use a monster like that in a model anyway, LOL!)

I'm saving this quote. Thanks.

Originally posted by Zappy:

I definitely seem to remember an 8192x8192 VTF resulting in pink-black checkerboards when stored as a BGR(A)888(8) texture, but showing up correctly when stored as a DXT5 texture, but it's been years since I tried that, so I can't say for sure whether or not that's right.

SFM's branch of Source doesn't like uncompressed textures that are larger than ~10 MB. I don't remember the exact error, but it was something along the lines of being unable to serialize the data.

Originally posted by Pte Jack:

I'm not sure if a Valve model or the Valve programs support 8K textures (8192) pixels (but why would anyone want to use a monster like that in a model anyway, LOL!)

Not Source engine, but someone made a joke mod[www.nexusmods.com] for Fallout: New Vegas that adds hi-poly spoons with an 8k texture.

Originally posted by Pte Jack:

You have to watch for Model splitting or the dreaded Exception ACCESS (1) error, when you compile. If these occur, then the objects causing the split or fatal error have to be decreased in vert counts.

It's worth mentioning that the $maxverts QC command can be used to override the point at which the compiler wants to split the model.

The ultimate upper limit before you cause fundamental problems with the model format is going to be in the region of 65,536, as episoder says.
The model format uses two bytes to store vertex references, and 65536 would be the largest number of vertices that could be individually addressed in those two bytes. (Although it's possible that for technical reasons the limit is slightly lower).

However, I'm not sure either whether the compiler merges vertices or counts them once for each triangle they contact. It's probably something I should try testing some time.

Thanks for the addition, Marco.

I guess I should add (by which I mean "I meant to, but forgot") that I don't know whether there are any side effects from using the $maxverts command to override the compiler's vertex limits, other than exceeding the limits of the format and ending up with a failed compile/completely broken model.

There are obviously some signs that pushing the model format can cause stability problems; the bug where a session crashes on playing seems largely associated with FNAF projects and, even being generous, the models created by the FNAF community can't honestly be called well optimised for a 15-year old game engine.

There being an actual causation to that correlation is however a guess on my part (unless someone has pieced together a better argument while I've been away).
In any case, if there is a causation, my gut instinct is that it's more likely to involve the very high numbers of meshes used, the tendency to piece these models together from dozens and dozens of individual parts.
After all, vertex data is not stored in the session file, but files obviously do need to track which bodies/skins are activated, so the latter is more likely to relate to file corruption.

As it is, I don't believe there will be any serious issue with overriding the vertex limits as long as you stay within the hard limits of what the MDL/VTX/VVD format can support per mesh.

The default limits on the compiler aren't always the same as what is reliable in-engine; I've over-ridden the $maxverts limit on several occasions, and I've been using models using the 5% weight link crack since we first figured it out; my personal models aren't exactly basic, but I've not had any obvious issues.

(If anything, I get almost no crashes out of the blue; it's almost always because of me doing something stupid.)

Ah, thanks! I don't think I'll need the $maxverts command for this project, as it's below the limit, but I'll remember it if/when I need it. Like, if I wanna make some crazy high vert model, just to mess with ole Source.

Originally posted by Marco Skoll:

- files obviously do need to track which bodies/skins are activated, so the latter is more likely to relate to file corruption. -

As far as I know, for bodygroups, it does this with a 32-bit or a 64-bit integer.
E.g. with two 2-option bodygroups, internal value 0 would mean "off and off", value 1 would mean "on and off", value 2 would mean "off and on", and value 3 would mean "on and on", or something like that (much like combineable "flags" in some software, except not "limited" to powers of 2 or such?). 1-option bodygroups would not contribute to this value.
There's simply a user-friendly GUI that helps set the scary internal value based on the mostly-user-friendly body group names.

So that's (probably) also not the problem.

Disclaimer: I may be wrong.

Originally posted by Zappy:

So that's (probably) also not the problem.

Yeah, it doesn't entirely fit with my understanding either, but thus far I can't actually recall anyone who isn't animating FNAF who's had that particular problem.

Given I don't know of any obvious cause, I'm left fishing for any vaguely sane explanations for why that's the case:

- there's just enough FNAF being animated that it's sheer statistics that an unconnected bug seems to be linked.
- large numbers of material overrides; after all, they do like their phongboost. (Probably more likely, but I'd expect to have seen at least one or two non-FNAF sessions).
- something about the way a lot of those models are made, of which "a piecemeal mass of meshes" potentially makes the cut as bodygroup information does get stored the session file in some fashion.

One way or another, I don't know, but it's one of the more plausible explanations I've got.

Originally posted by Marco Skoll:

- thus far I can't actually recall anyone who isn't animating FNAF who's had that particular problem. -

I can recall 2 or 3 involving Bendy and the Ink Machine stuff instead, but also 2 or so involving neither that nor Five Nights at Freddy's stuff. (But yes, by far most of it involves Five Nights at Freddy's stuff. I, too, don't know why.)

Originally posted by Zappy:

]I can recall 2 or 3 involving Bendy and the Ink Machine stuff instead, but also 2 or so involving neither that nor Five Nights at Freddy's stuff.

Well, that's either stuff I've missed or just plain forgotten then.

In any case, even if these crashes are model related, the fact it relates to session corruption means it's more plausible that something that does get stored in the session file (e.g. bodygroups) versus things that don't (e.g. vertex information) - so, as far as it relates to the original topic, I don't think that (possible) theory on this kind of crash raises any red flags regarding overriding vertex limits.

It won't necessarily be efficient, but I don't think it'll break SFM.

I have to redo all my guides because of the Blender update to 2.80 anyway, so when it comes to MMD and XNA type models, I may try that option out, just to see if the hair and faces work out. But, I usually just split the models down into manageable chunks.