256 with DMX files

How many bones does the armature(/bone skeleton) have?

thing is when i decompile with crowbar i get smd files and a .qc
when i import the qc it gave the bone error
and model has around 200 bones
maybe i used wrong setttings for decompiling

Originally posted by Usagimi:

thing is when i decompile with crowbar i get smd files -
when i import the qc it gave the bone error and model has around 200 bones -

If what Pte Jack implies is true (SMD meshes can't have more than 128 bones, while DMX meshes can have 256), it's possible that the original model used DMX meshes when being compiled. There's just currently no Source engine model decompiler that generates DMX meshes, only SMD meshes, which means something along the lines of this being the process:

DMX > StudioMDL (model compiler) > Source engine model > Crowbar (model decompiler) > SMD
(Again, with DMX supporting 256 bones, but SMD only supporting 128 bones.)



Though if the Blender Source Tools can't import SMD meshes with more than 128 bones, I'd say that that's probably not so good behaviour; In my opinion, it would be better for it to import and export SMD meshes without a fuss, but give a warning if exporting a SMD mesh with more than 128 bones (but still import such SMD meshes without a fuss, and also still export them).

The SMD mesh format itself isn't technically restricted in such a way, so putting such a restriction on a SMD importer/exporter seems fairly silly to me.

Originally posted by Zappy:

The SMD mesh format itself isn't technically restricted in such a way, so putting such a restriction on a SMD importer/exporter seems fairly silly to me.

You have to remember that the SMD format has been around forever with Valve models growing in size and version (TitanFall I believe is a Vers 53 type model) and we saw the breakdown in the model decompilers as the versions changed (cannonfodder's and the hexed version of cannonfodders, etc.) Rather than edit StudioMDL to have the SMD type grow with the models versions, Valve went to the new model type that was less restrictive and hence the DMX model was born and was added to the StudioMDL compiler. I think we're lucky they didn't come out with a brand new compiler or we'd still be stuck.

We need a decompiler that will actually create a DMX source model, but I don't think that is going to happen any time soon. Crowbar is currently the best decompiler out there and Blender Source Tools is the best modeling tool we have for editing models.

Zeq and Artfunkle are dedicated coders and keep their tools up to date with the changing technology AND they keep their work free to us users. I don't think there is any we can complain about with these tools and they require our deepest thanks for their efforts.

By the way, for those that don't know, Artfunkle has updated BleST to 2.10 and it now works withthe newest version of Blender 2.79a .

Originally posted by Pte Jack:

You have to remember that the SMD format has been around forever -Snipped to keep the quote short-

I know, but that's no reason to actually prevent people from importing and/or exporting SMD models that are still completely valid syntax-wise. It doesn't stop you from importing or exporting DMX models with more than 3 bone links per vertex for Source 1 games, for example.

And again...

Originally posted by Pte Jack:

- We need a decompiler that will actually create a DMX source model, -

Exactly. We don't have one, so we instead get DMX -> VTX(?) -> SMD, and if the DMX has more than 128 bones, the Source engine model will too, and so will the decompiled SMD, and then the Blender Source Tools can't import the SMD, because it has over 128 bones and Source doesn't suppor that, despite there being no bone amount restriction in the SMD format itself. There's not really any reason to prohibit that (unless there are, like, over 2^32 bones or something like that, or something else that Blender itself doesn't support).

In other words, provided the SMD importing is coded in a "dynamic" way (checking the amount of bones in the SMD rather than using a hardcoded 128 value), the only thing that would really have to be done is remove the stuff that says "if there are more than 128 bones, give and error and don't import it". (The same might go for exporting.) And if a hardcoded value is used, increasing it to at least should be enough.


Note that when I'm saying the Blender Source Tools aren't importing it, I'm presuming that based on Usagimi using the word "error", not "warning", while an error is something not being able to be done while a warning is just some "hey, you should know this" kind of stuff.

Originally posted by Zappy:

It doesn't stop you from importing or exporting DMX models with more than 3 bone links per vertex for Source 1 games, for example.

It doesn't?? Any time I have a model that has over 3 influences and I try to export it, BleST will throw a "Warning" and not do it until I either cull out the influences on a DMX export or fix the influences on a SMD export by limiting the number or deleting the overages. If I decompile a Valve model and import it, there aren't any influences over 3. At least not in any model I've worked with. So I'm not really getting what you're trying to say here.

Originally posted by Zappy:

Exactly. We don't have one, so we instead get DMX -> VTX(?) -> SMD,

DMX or (MDL/VTX/VVD) > SMD/VTA

Originally posted by Zappy:

and if the DMX has more than 128 bones, the Source engine model will too, and so will the
decompiled SMD, and then the Blender Source Tools can't import the SMD,
because it has over 128 bones and Source doesn't suppor that, despite there being no bone amount restriction in the SMD format itself. There's not really any reason to prohibit that (unless there are, like, over 2^32 bones or something like that, or something else that Blender itself doesn't support).

And i don't know what your're talking about here either.

I ported this Batman model that has 207 in it using the DMX export process culling out the over 3 bone influences. The resulting Valve model ended up with 171 bones because StudioMDL culled out the bones that were not directly connected to another bone or had no mesh attached to it in the optimization process.

I used Crowbar to decompiled the MDL/VTX/VVD combination (which it did happily and with warnings or errors) and reimported the decompiled SMD files back into Blender using BleST.

I used the QC as the import option and here's the result...

https://i.imgur.com/HY4SYvT.png

The only "non"- problem I had was BleST "warning" me that SMD Format does not support over 128 bones, but the model imported correctly, all 171 bones are there and weightpainted correctly.

Originally posted by Pte Jack:

Originally posted by Zappy:

It doesn't stop you from importing or exporting DMX models with more than 3 bone links per vertex for Source 1 games, for example.

It doesn't?? Any time I have a model that has over 3 influences and I try to export it, BleST will throw a "Warning" and not do it until I either cull out the influences on a DMX export or fix the influences on a SMD export by limiting the number or deleting the overages. If I decompile a Valve model and import it, there aren't any influences over 3. -

No, it doesn't. (The Blender Source Tools will give you a warning on export, but still lets you export it. StudioMDL itself will prohibit you from compiling models using DMX meshes with more than 3 bone links for a vertex, however.)

Originally posted by Pte Jack:

- I ported this Batman model that has 207 in it - The resulting Valve model ended up with 171 - I used Crowbar to decompiled the MDL/VTX/VVD combination - and reimported the decompiled SMD files back into Blender using BleST. - The only "non"- problem I had was BleST "warning" me that SMD Format does not support over 128 bones, but the model imported correctly, all 171 bones are there and weightpainted correctly.

If that's the case, then Usagimi has just used the word "error" instead of "warning" while never mentioning that the model actually imported, which made me think that it was an error and not a warning. In that case, I'm unsure whether the fault lies with Usagimi or me.

Originally posted by Zappy:

No, it doesn't. (The Blender Source Tools will give you a warning on export, but still lets you export it. StudioMDL itself will prohibit you from compiling models using DMX meshes with more than 3 bone links for a vertex, however.)

Ok, now I understand what you're saying and you are correct. However, "as an experienced user", I know that if I get that "Warning" I have to fix it before the model will compile.

The "Influence Over" warning should actually be an error and BleST should punch out without exporting. But this would be a workflow process and would only save the amount of time that it takes to do the export the bad SMDs. I have no problem with it the way it is. The model is either going to compile or not and I'll get the "Error" from StudioMDL if it doesn't.

Originally posted by Pte Jack:

- The "Influence Over" warning should actually be an error and BleST should punch out without exporting. -

Absolutely not. Even outside of Source 2-related things, there are several cases where having a DMX file with more than 3 bone influences for a vertex is useful (e.g. for exporting... well, a DMX file with more than 3 bone influences per vertex).

For most of this thread, I've fought for the argument that the Blender Source Tools should import (and also export) SMDs even if they're not going to be compatible with Source as long as the SMD format itself is valid, and the very same definitely goes for DMX in my opinion.

Originally posted by Zappy:

Absolutely not. Even outside of Source 2-related things, there are several cases where having a DMX file with more than 3 bone influences for a vertex is useful (e.g. for exporting... well, a DMX file with more than 3 bone influences per vertex).

Where? If you try to compile a DMX or a SMD where there are influences over 3, StudioMDL will belch and the model won't compile. I don't see your logic in that statement.

The model has to be fixed either by culling out the influences on a DMX export or limiting or deleting influences through weigh painting on SMD exports.

Over 3, No Compile, the SMDs created in the export are usless and you already have the model open in Blender for editing. So what's the point of creating bad SMDs/VTAs?

What I would like to see is a influence culling slider in BleST for SMD exports. That would be my only request on this matter.

Originally posted by Zappy:

For most of this thread, I've fought for the argument that the Blender Source Tools should import (and also export) SMDs even if they're not going to be compatible with Source as long as the SMD format itself is valid, and the very same definitely goes for DMX in my opinion.

I thought I just proved that it does.

Originally posted by Pte Jack:

Where? If you try to compile a DMX or a SMD where there are influences over 3, StudioMDL will belch and the model won't compile. I don't see your logic in that statement. -

By "even outside of Source 2-related things", I put the "even" there to imply that I didn't mean in Source 1-related things. Granted, that may not have been very obvious, but still...

SMD and DMX aren't limited to StudioMDL. That they can be imported into other modelling tools (for example Blender) means that they can also be useful for other purposes. Purposefully restricting such freedom makes no sense at all. The best comparison I can make would probably be like making a video editor, but only allowing things in it to last for multiples of 0.01 seconds rather than an arbitrary amount (e.g. 0.0166666... seconds, or a 60th of a second).

Originally posted by Pte Jack:

- What I would like to see is a influence culling slider in BleST for SMD exports. That would be my only request on this matter. -

Why? StudioMDL itself culls SMD meshes (yes, even though it doesn't cull DMX meshes).

Originally posted by Pte Jack:

Originally posted by Zappy:

For most of this thread, I've fought for the argument that the Blender Source Tools should import (and also export) SMDs even if they're not going to be compatible with Source as long as the SMD format itself is valid, and the very same definitely goes for DMX in my opinion.

I thought I just proved that it does.

Yes, you proved/explained that it does import/export SMDs that the Source engine doesn't support, and then you immediately went on about saying "it should not be possible to export DMXes that the Source engine doesn't support", to which I replied that there's no reason to prevent people from exporting completely valid DMX files just because the Source engine doesn't support them.

nope, I said the Influences Over condition should abort and not produce SMDs, nothing about the things not compliant to the source engine at all. But, the tools currently does what you want it to and I said I'm happy with it the way it is. So, nothing to complain about. (LOL)

Originally posted by Pte Jack:

- I said the Influences Over condition should abort and not produce SMDs, -

Exactly. (And by that, I mean "yes, exactly, that's what you said", not "yes, exactly, that's how it should be".)