[Solved] Fixing SinisterX's Blood Elf Hall

[Michael Peppers]

Hello there! I've been using SinisterX's Blood Elf buildings in my project for a bit and noticed some models have a bunch of glaring issues (guess that comes with the released pack being version 0.9 and all), I fixed most of them (Towers not having portraits and bad overhead attachments, Sanctum and Vault lacking all attachments) but I don't think I have the skills to fix his Town Hall 100%. Currently it has 2 issues:

1. A bunch of parts from the model (saws, planks etc.) detach themselves during the "build" animation and attach themselves to nearby units
2. Upgrading from tier 1 to tier 2 shows the birth animation instead of "upgrade first", while upgrading from tier 2 to 3 shows "upgrade first" instead of "upgrade second"

I don't know if 2 can be fixed through the Object Editor (if so please explain me how), I'm mostly using the HU townhall values for showing its animations, I think merging all 3 models of the townhall into one or moving those model animations to the right models would fix it.

So... what do you get from helping me? Good boy karma points, a +rep from me and you'll be credited for fixing this model in my map/mod's credits.

I'm attaching the town hall models to this request, in case you're interested this thread has the whole unedited building pack in it. (with the "broken" Towers, Sanctum and Vault)

 

[Retera]

First pass trying to help with these using low effort suggestions:

1. In 95% of cases if you open a model and then save it again using Retera Model Studio, just the act of simply opening it and saving it again should run the automatic cleaning algorithm that fixes the parts sticking to other models. I think over the past 8-10 years of using my custom software for this, there was like 1 case when it didn't fix it, and your model is not that special
2. I'd guess (without knowing since you didn't specify) that the problem you are facing here is the UpgradeInProgressIdChange setting. It's a gameplay constant but I think it was forgotten to expose it in the gameplay constants menu UI possibly when WorldEdit was made. Anyway basically the way this setting works, if it's toggled to 1 then the moment a unit starts upgrading into a different unit, the model is replaced with the new model. But if this constant is set to 0 then the model for the unit doing the upgrading is not replaced with the new unit's model until the upgrade completes. It also affects more than the model, and impacts the "GetUnitTypeId" jass native when run on the upgrading unit, and possibly some other things. Although this gameplay constant is invisible to the user, the bad value that's bad for custom maps is the one that you get when your map is set to "Melee (latest patch)" game data set, which has its own set of gameplay constants. While your game is set to that data version, it is assumed that you are using melee models only so it's OK for a building to keep the same 3d model until the upgrade to the new unit type entirely completes. (Accordingly, if you have a Tier 1 model and a Tier 2 model, and then when you upgrade to the Tier 2 model you see the Tier 1 birth animation, it's not an animation issue but rather an issue of which model is loading.) If you want to remain on this data set but avoid the problem, then whenever you have an upgrading structure like this town hall then you should format the MDX model for the 3 structures together into one model in the same manner as the original town hall models. As an example i clicked merge in 2 minutes in my software so I'll include how that might work as the result of the automation etc but I didn't test it in game, obviously you could try to do that and maybe tweak anything that the automation merging did wrong

 

[Michael Peppers]

In 95% of cases if you open a model and then save it again using Retera Model Studio, just the act of simply opening it and saving it again should run the automatic cleaning algorithm that fixes the parts sticking to other models.

As an example i clicked merge in 2 minutes in my software so I'll include how that might work as the result of the automation etc but I didn't test it in game, obviously you could try to do that and maybe tweak anything that the automation merging did wrong

Nice! I'll definitely do it myself next time, RMS is such a neat tool

I'd guess (without knowing since you didn't specify) that the problem you are facing here is the UpgradeInProgressIdChange setting. It's a gameplay constant but I think it was forgotten to expose it in the gameplay constants menu UI possibly when WorldEdit was made.

the bad value that's bad for custom maps is the one that you get when your map is set to "Melee (latest patch)" game data set, which has its own set of gameplay constants.

"Default" gives me 1.07 constants and object data as far as I can tell, I imagine there's a way to change UpgradeInProgressIdChange outside of the map, guess I'll look for it in the game data.

Thanks for your amazing knowledge Retera!

 

[Retera]

Nice! I'll definitely do it myself next time, RMS is such a neat tool

Thanks! Mdlvis also does some kind of optimization on saving a model, but sometimes I felt like it was losing data. This problem of dealing with the model stretching was a case where I felt it was OK to automate because when I used the original blizzard software to make models (War3ArtTools that Blizzard published -- the software used to make all the MDX files in the 2002 game), in that original software I never had the problem. And that was how I came to realize that they had automated it as well. Although I did not have their code to see how they implemented it, once I was convinced that it was OK to implement it, then solving it ended up quite easy.

I could explain the technical details if you're curious, but I haven't really given them much thought since about 8 years ago when I developed the automated solution. It's all about performance; inside models there is cached information used to determine when to "unload" parts of the model for performance. If it unloads your model's Bone(s) during the wrong animations -- while they are in use -- then the 3d mesh attached to that bone will not load a valid location for where to be, so it goes to an error value/undefined location instead.
The solution is a tiny computation that can be roughly summarized as:

for each bone:
    clear optimization data
    for each geoset attached to this bone:
        set bone to be loaded by the graphics engine in all animations when this geoset is visible

It's slightly more complicated than that, but that's the idea.