Artfunkel, help?

I thought I was having a problem with Crowbar at the same time I found the truncation, but the symptoms are leaning more toward BleST as well. This is a video of both problems together.

When importing whole models using QCs I'm finding that rotations are wrong. When importing as single SMDs and VTA files, rotations are correct.

But in both circumstances Shapekey names are being truncated.

https://youtu.be/Vqis0QHeivc

I've left that link in the Crowbar Debug discussion for Zeq to look at as well.

As the problem seems to be trouble with rotations, I am starting to wonder if this OTHER problem I'm having is related to BleST on export of a DMX animation file as well.

https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=2012405066

I can provide Blend, SMD, DMX and FBX files as well if required.

Follow up...

I just checked Blender and found that the shapekey name textbox only accept 63 characters. No wonder why it's being truncated.

Most of the shapekeys that have over 63 characters are Corrective shapes. An example from the scout would be

OpenJaw_OpenLowerLip_OpenUpperLip_Platysmus_SmileFullL+OpenJaw_OpenLowerLip_OpenUpperLip_Platysmus_SmileFullR

This shape has the longest named and is 109 characters long. Iit's being truncated to

OpenJaw_OpenLowerLip_OpenUpperLip_Platysmus_SmileFullL+OpenJaw_

It's no wonder why the compiler can't find flexes and bailing when trying to compile DMX files.

I have no idea how this can be fixed.

A secondary cache holding real names with shapes being give pseudo variables as names??? But how could this be handled if the variable is changed or a new shape requiring over 63 characters is needed? Or how can we compare real names to pseudo names??

I really don't want to have to revert back to writing VTA data and defining Flexes in the qc... That would make DMX files redundant. LOL...

Please GrandMaster Artfunkel, Save Us with your infinite genius and your coding magic.

Originally posted by Pte Jack:

- I have no idea how this can be fixed. -

Blender is open-source (I think). One could make a self-made build of it with the shape key name length increased (it's hopefully just a single value that'd need to be changed... followed by then going through the trouble of actually compiling it...), or even make a merge request (along with an explanation about "why"), or at least a suggestion, for it to maybe be increased in official builds.


(The "self-made build" option is probably pretty unfavourable, since it'd only apply for you, and you only, plus whoever you'd give the special build. It's still an option, though.)

That is true Zappy, however, I think maybe we need a champion with some pull with the Blender Dev team and request an update so everyone gets the added functionality.

Checking Blender, the 63 Character limit is hard coded into the Blender Shapekey name text box itself and that limit has been around forever (looking back at previous versions). I'm actually surprised that this issue hasn't been brought up long before now.

https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=2013230767

But I may have stumbled on something while comparing the QC to the VTA that might be the source of this dilemma and maybe a possible fix.

In the flex definitions of the qc, Flexes and Flexpairs are being defined with flex names less than 63 characters.

For example In the Scout QC the flex #30 is defined as:

flexpair "OpenJaw_OpenLowerLip_OpenUpperLip_Platysmus_SmileFull" 1 frame 30

This is a flex pair and a corrective shape but the definition is only 53 character long, dangerously long but not over the 63 character limit. I believe this is the actual name of the flex used by the model (Corrective or Real) in game.

VTAs are not loaded onto a model in Blender until we import the VTA onto the mesh. Looking at the VTA now, we find Time 30# being defined as:

OpenJaw_OpenLowerLip_OpenUpperLip_Platysmus_SmileFullL+OpenJaw_OpenLowerLip_OpenUpperLip_Platysmus_SmileFullR

This is the name that is being given to the Shapekey on import. It is 109 Characters long and is the name being truncated.

Not knowing how this all comes together on Import, export and compile I can only ask, is there some way for Cowbar (through some sort of written variable into the VTA file) or BleST (on import) to use the actual and real name vs the VTA name as the shapekey name in Blender when the VTA is imported as still have the flex work as intended?

@artfunkel

FYI.

I've receive some info in regard to the 63 character limit and this might be huge for both Crowbar and for BleST in future developments (maybe more on the DMX side because of long name).

Anyway, one of my contacts has a connection into the Blender Dev circle. He has had minor tweaks made to Blender during the past development and is alpha testing 2.83. He had made a suggestion to have shapekey names extended to be larger and this is the answer he got back.

This is not such a simple change.
It's not just shapekeys that have this 63 character limit.

All makesdna structs names have this limit set (#define MAX_NAME 64)

RNA functions often work with that defined name size.
For example, for some cases a hash for the name is created for quick access.
Also, saved files have a struct size defined for each datablock, so it is good to avoid changing this size between versions.

Therefore, unless it is an essential change, this request is unlikely to be accepted.

And they have avoided this all the way back to Blender 2.6x and maybe earlier. LOL

Anyway, it looks like add-on devs are going to have to start screaming for changes or have to find some way to program around the MAX_NAME limitation.

Not sure if you already knew about this limitation but I thought I'd just throw it out there in case you weren't aware.

My contact has followed this response up with a formal change request and has also reached out on other unofficial channels as well, but judging from the initial response, I'm doubtful that anything will be done about it unless the voices of add-on and 3rd party devs who are creating software that creates content to be used in Blender join the plea for change.

Another FYI, my contact says this about 2.83...
"wow lots coming". So, one can only wonder what?

Stand-by to Stand-by!

Don't hold your breath. I can add name remapping on export to work around this, since long shape key names are a hard requirement.

Originally posted by Artfunkel:

Don't hold your breath. I can add name remapping on export to work around this, since long shape key names are a hard requirement.

That sounds nice. The problem is just that it's less intuitive than if Blender's shape key names were allowed to be longer.
(But it's of course still better than nothing; I've run into this issue at one point too, when dealing with lots of concurrent corrective flexes, so a workaround is nice and appreciated in any case.)

Thanks Artfunkel, I think that coding around the problem would be the best. These hard limits have been there for ages and looking at the response gotten back, I don't think things are going to change (at least anytime soon) in Blender proper.

That being said and if you have any contacts into the Blender Dev Circle, you might want to make a request as well. Being a programmer, you would be the best at explaining the circumstances and the consequences if these hard values aren't increased. As you say, long names are a hard requirement and will remain so.

Now would be the perfect time for Blender to make the switch. 2.8x was a major update and is still evolving. We're seeing that in each new update or release now.

I've pushed some changes to the repo[github.com] which fix this problem. The exporter will now derive a corrective shape key's name from its animation drivers, if there are any.

The importer will now automatically generate drivers for corrective shape keys. To generate them for an existing import, use the button in the Flex Properties sub-panel. And of course you can edit them yourself through the normal Blender UI.

Tell me if this works for you.

Sorry Artfunkel, Either I'm not getting the proper download from the GitHub, or I'm screwing up the import someway.

I completely removed 3.0.3, downloaded the version from the GitHub. On install I had to move the files out of the master into the Add-on Folder for Blender to find the new install. Activated the new install. Decompiled the HWM Sniper from the SFM TF_movies models folder using Crowbar 0.67 and Imported the result using the QC as the importer.

Sniper imported face down on the floor (fix coming as per your other discussion) and the VTA Vertices standing with Z Up.

This is the result of the imported VTA animations. (Note, names are still truncated at 63 characters.)

What am I doing wrong to test this for you?

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

Follow up:
Even though the actual shapekey names are still truncated in Blender, I continued the test by exporting the sniper as SMD files and used the decompile QC to compile it.

Other than a couple of things being renamed in the QC (ie the VTA file name and the Animations folder location for the exported sequences) the model compiled without the usual errors about not being able to find flex names. (No errors or warning in the Blender log on compile). ALL shapekeys (flexes) are present and work as they should and like on the original model.

So, I would say other than the names being truncated in the shapekey name blocks, MOST EXCELLENT FIX!

I am not sure how things will work if new shapes are added using the truncated named shapes as there bases. (If you know what I mean, defining the flex in the QC may be complicated if the proper name is not known)

https://i.imgur.com/55DX7a9.png

Now to test on another couple of models.

The names will always be truncated, there is no way for an add-on to avoid that.

Names are only generated for corrective shape keys, which I don't believe are ever referenced in a QC file.

Unfortunately, I do not know if that is so. However it may be something that Zeq might know. I think he is following this thread, maybe he'll respond to that.