There are many studiomdl versions

[magic drum]

Hi, would you say it’s better than NekoMdl?

[white pulsar]

Each is better in its own way, I'm not replacing other studiomdl, but maybe someone will find this project interesting :^)

[jolly dagger]

This compiler got my attention since someone pointed it out. And, I started using this compiler instead of the SFM Compiler, and currently. This compiler saved my ass a lot of time.

And now, another version came out. I’ll be trying it too. I hope the Excess_Violation error is gone in this preview version.

If this compiler is stable in the current build. I might add this compiler to my guide for people to use instead of SFM compiler.

[white pulsar]

Excess_Violation is a common exception that can cause a crash... (I'd need the log context to understand at what stage the crash occurs), but it's more stable now than in version 0.2 or the previous preview build.

But if you encounter any problems, feel free to write about them so that I can fix them or help to solve it :^)

[jolly dagger]

Sure. It's not in 0.2. But, I’ll try 0.3 later.

[white pulsar]

[jolly dagger]

0.3 seems stable. This compiler is going to be my main compiler xD

[white pulsar]

Glad to hear

[proud galleon]

very nice

[empty pelican]

Is "vertex welding" fixed for facial flexes? Been trying to edit HL2 citizen models and vertices around the lips get stuck together when compiling

[white pulsar]

Based on my experience, if we use the old vertex mapping code, it simply takes the nearest vertices and does not always do so correctly... Now it works like in CSGO, based on spheres that are created from vertex animation points and search for the nearest vertices of the model (in my case, it searches not from the bine pose, but as they were before processing), and this has at least fixed most of my personal problems with this.

But the only thing that cannot be solved is if BST has already imported VTA incorrectly and they are broken on export.

[empty pelican]

Gotcha

[white pulsar]

At least with correct VTA data, I haven't encountered any problems. As I've heard, starting with some version, BST began to break VTA imports or even cause some anomalies during exports

If all blendshapes look correct in Blender, you can send some examples from scenes where everything is correct so that I can take a look and maybe come up with something

[stoic sand]

this hasn't gotten enough attention, this is super cool

nekomdl is nice, but I think this has greater potential

@white pulsar quick q, does this fork support the jigglebone parameter is_boing?

[white pulsar]

may next build will support the is_boing parameter (since I have already received personal reports about a "problem" with support for this)

I will let you know when this build is released, if necessary, or you can follow the updates on GitHub

[white pulsar]

The only thing that complicates support for this right now is that version 49 of MDL doesn't have parameters in the jigglebone structure, so I'm thinking about a temporary hack for this... and I don't know how Garry's Mod will behave (in other engine branches that natively support version 49 of MDL, it will probably crash).

Ideally, I would need to finally add commands for compiling into older versions, at least 48

[stoic sand]

is_boing support would be awesome, I really need it for a project I'm working on.
My model needs a modified studiomdl to compile(currently using nekomdl, but it doesnt support is_boing)

[stoic sand]

@white pulsar Oh also, does it preserve vertex colors? I know some modified studiomdls do, but not sure which. I don't think neko does

[white pulsar]

There is no information about vertex colors in VVD structures in the usual form, from 44 to 49 (if we are talking about the original versions of the format from Valve) - there is none. Are you referring to some custom versions of MDL?

If there is an example where the MDL/VVD/VTX structures themselves contain information about vertex colors, I would appreciate it if you could provide it so that I can look into it and possibly add support for it (if Garry's Mod supports it).

When it comes to "vertex colors" on static props such as CSGO maps (e.g., de_nuke), UV channels are used, which are supported by default in this studiomdl, but it seems that not all SMD exporters export all UV channels. (Not tested with DMX)

[jolly dagger]

Sometimes, this compiler seems to be stuck at "Processing LOD..." after compiling the same model a lot for me. Not sure if the compiler gets stuck like that when compiling a lot or smth.

[white pulsar]

hmm... It seems like it got stuck at one of the "simplify" steps (in your case, possibly at UnifyLOD). Is the same thing happening on the x86 version of the compiler? 🤔

Or if you start compiling again, will everything be fine?

[white pulsar]

If you have examples that can be used for debugging and where this problem can be reproduced, I would be thankful for such examples (If the compiler gets completely stuck)

[jolly dagger]

I'm always using the x86 version. And it's fine if I close Crowbar and compile again.
And, it can happen randomly.

[white pulsar]

On screenshot is x64

But it seems memory leak, can you provide example model for debug (in DM), please?

Because personally, I am not yet able to reproduce the problem

[white pulsar]

Or does this happen with any model, even if we decompile one and try to compile it?

[jolly dagger]

Umm. Currently. I’m working on a very high-poly model. That bug happens very randomly and it also takes a while to happen.

Not sure if it's only an issue with very high poly models or smth.

Happens when I try to compile the same models a lot.

like a lot of times.

It's not very annoying tho.