Model Optimizer and Converter v1.2.1

[eejin]

A very useful tool in theory, although I tried the linked LickKing2.mdx model and got no improvements.
1. downloaded the Lick King
2. Converted to .mdl with this tool
3. Used the most aggressive settings

4. Saw a moderate reduction in .mdl filesize

Converted back to .mdx I saw the same size as the input which makes sense for the decimals since its a binary format, but not for the other parameters.
Is this expected behaviour or am I using a wrong converter? You are citing a reduction of 98.7% (or is it a reduction of 1.3%?).

 

[loktar]

Hey, thanks for the feedback.

It's a reduction of 1.3% (2KB), so on my end I ended up with a 159kb file. The difference is very small right now as I haven't added many options yet. Building models (at least Blizzard models and edits) will probably benefit most because they tend to have a lot duplicate vertices.

It looks like no vertices were removed on your end, but 38 were removed here. When I disable that option I get 161kb too.

Could you send me both the mdl files (original and optimized) so I can take a look?
I've been using Mdlvis to convert, maybe the formatting is different somehow. Although I would expect an error to pop up if that was the case.

Or maybe the converter you used adds some random (very small) decimals to the vertex coordinates?
The number rounding happens only after optimization, I should change that
Edit: or maybe Mdlvis cuts off some decimals, I'll download the converter you linked later and test it out.
Edit2: they seem to handle float/double precision differently, some numbers have more decimals with one of them and some with the other. I'll do some comparing between them and Magos to see how best to handle these differences.

edit: made the description clearer

 

[eejin]

The reductions are indeed not big, but might grow in the future. Would be cool to at some point run this tool on the whole of the Hiveworkshop model database with safe settings. Approved!

 

[loktar]

Thanks! I found a newer version of MDLX converter in a post there, and it's possible to have my program use it to convert models. Apparently that's what Retera's model studio does too.
So in the next version I'll add MDX support ^^

 

[Lt_Hawkeye]

a update to date model optimizer is always nice but how does this compare to the Ghostwolf's mdx squisher?

 

[loktar]

If I understand correctly, it changes the precision of some of the binary data, which almost certainly won't be added in this tool.
The deleting of useless keyframes may be added here, and linearizing animations definitely will be. It depends on how much time I end up putting into this.

This tool optimizes by deleting useless data and merging duplicate data (e.g. identical vertices). Both tools can be used together.

 

[MaximBit]

Good)

 

[loktar]

Thanks! =) Working on reimplementing ghostwolf's mdlx parser, so next update will have mdx support (probably no mdl support though, because it's probably not worth the effort).
After that updates should come faster with more options =)

 

[Vinz]

Thank you for this.

 

[loktar]

Ooh, those are some nice results

 

[Unregret]

This is absolutely useful for heavy data map and testing.

 

[Macadamia]

Wow, how did I miss that.

Jumping on this right now as I use @Mythic 's Ember forge and other great models or model parts from the Starfall Empire !!!

This tool is amazing. One of the model I made by combining a part of one the models from the Starfall Empire and my rolling ball model ended up making a smaller MDL than the MDX file !

The final MDX went from 339kb to 87kb. It shows how much redundant data I had left over!!!

This said I have encountered a problem with a reforged model I heavily edited with Retera Model Studio and NotePad++ in MDL.

Your program threw an error :
"
----------------------

Loading Frostmourne.mdl ...

Line 5741: Unknown Geoset property: Tangents


----------------------"

Are you going to be able to add the support for them ?

Thanks, anyways in the meantime, well deserved +rep and rating.

 

[loktar]

Thanks! That's a crazy difference
Next version will have MDX support so any model should be able to load, including reforged models. I'm curious to see the results on reforged models.

It will probably be ready some time this month.

 

[Macadamia]

Great news, I can't wait !!!

Optimizing MDX directly seems to be for the best, even if I tend to do much of the work in MDL, just because we can so easily convert them.

In the meantime, I will have to play around with the decimal depth, all my attempts were made with 6 decimals so far, I suppose I could use much less for models with a small scale, or where I suspect many coordinates have values very close to the nearest integer.

By the way do you round the values or truncate them ?

Anyways, wonderful job, really will be looking forward to your next release !!!

 

[loktar]

Great news, I can't wait !!!

Optimizing MDX directly seems to be for the best, even if I tend to do much of the work in MDL, just because we can so easily convert them.

In the meantime, I will have to play around with the decimal depth, all my attempts were made with 6 decimals so far, I suppose I could use much less for models with a small scale, or where I suspect many coordinates have values very close to the nearest integer.

By the way do you round the values or truncate them ?

Anyways, wonderful job, really will be looking forward to your next release !!!

They should be rounded not truncated.
Generally I would recommend 6 decimals as a safe setting, but yeah in some cases less could be fine, just be sure to keep a backup

I don't think the rounding itself makes much difference (if any) in MDX filesize though, any float takes up 4 bytes afaik, but it can influence the other optimizations, more so when I add more in the future.

 

[Macadamia]

Yes I completely understand what you mean. But if it can influence your other optimizations, it still remains useful.

To be honest, in tiny models, I often used to round some values for readability, like all these near null numbers like 1.123456e-07. I also suppose it can even slow (even if in a ridiculous scale) a 3D engine as I suppose it takes less time to process operations with a value of 0.0 than with such infinitesimal value, but I might also be wrong.

Anyways it still will help me greatly when doing MDL editing as the manual rounding can take a while, even with Notepad++ pattern searches.
This means that I might even keep using this old version (for models without tangents) when I will do MDL editing that does not require a tool like Retera Model Studio Hack or Magos Model Editor.

EDIT :

@loktar : it seems the precision can be altered for binaries, and has in fact an impact, like I just read there : MDX/M3 Optimizer

Now I realize my frostmourne edited model that your optimizer refuses to load also doesn't load in Magos's Model Editor or this Optimizer I linked.

I initially thought it was because the source was a reforged model, but for some reason the same issues appears with some older models. This is strange, errors are not verbose enough for me to trace the issue though...

EDIT 2 :

One of my models opens perfectly in Retera Model Studio or Magos Model Editor, but crashes your MDL Optimizer. I just attached the MDL file for you to have a quick look and try to figure out what is wrong.

 

[Macadamia]

Update !

All I wanted is give a small extra feedback :

- the MDL optimizer seems to crash when there are no optimizations needed...

 

[loktar]

Yeah, the optimization thread doesn't tell the main thread properly that it's done when there's nothing to do. It also crashes when you close the program while the thread is still busy.
Should be fixed with the next version, the converter doesn't have this problem

 

[iNfraNe]

Hello!

I'm liking the simplicity of the tool, cheers for making it.

The 'Merge Identical Vertices' does not seem to function properly. I have a very simple model exported from blender, which tends to give duplicate vertices. Here are the vertices:

Vertices 34 {
        { 38.4, -38.4, 0 },           <======
        { 63.003, -37.754, -2048 },
        { 38.4, -8.636, -2048 },
        { 70.330, -66.871, -2048 },
        { 63.003, -52.636, 0 },
        { 70.330, -66.871, 0 },
        { 38.4, -8.636, -2048 },
        { -38.4, -38.400, 0 },
        { 38.4, -38.4, 0 },          <======
        { -63.003, -37.754, -2048 },
        { -38.4, -38.400, 0 },
        { -38.4, -8.636, -2048 },
        { -70.330, -66.871, -2048 },
        { -63.003, -52.635, 0 },
        { -63.003, -37.754, -2048 },
        { -38.4, -38.400, 0 },
        { -63.003, -52.635, 0 },
        { -70.330, -66.871, 0 },
        { 38.4, -38.4, 0 },           <======
        { 63.003, -52.636, 0 },
        { 63.003, -37.754, -2048 },
        { 70.330, -66.871, -2048 },
        { 63.003, -37.754, -2048 },
        { 63.003, -52.636, 0 },
        { -38.4, -8.636, -2048 },
        { -63.003, -37.754, -2048 },
        { -63.003, -52.635, 0 },
        { -38.4, -38.400, 0 },
        { -70.330, -66.871, -2048 },
        { -70.330, -66.871, 0 },
        { -63.003, -52.635, 0 },
        { 70.330, -66.871, 0 },
        { 63.003, -52.636, 0 },
        { 38.4, -38.4, 0 },    <======
    }

I've shown some duplicates with <======, but there are many more (in fact, the model has 12 vertices in blender).

I've also tried running the optimized mdl through the program again, but still didnt catch the identical vertices.

 

[loktar]

Not at my computer now, but first thing that comes to mind is that maybe the UVs are different for these vertices?

In the future I will also add an option to skip duplicate vertices with different matrix groups, as that can bork animations in some rare cases.

 

[iNfraNe]

No, they all have the same TVertices =\. Would be cool if you could look into it when you've got the time! Thanks.

 

[Asssssvi]

Good result

 

[loktar]

No, they all have the same TVertices =\. Would be cool if you could look into it when you've got the time! Thanks.

Working on a totally new version right now (works with both mdx and mdl, and is integrated with my mdlx converter), hopefully that one will fix it, if not let me know!
Edit: actually, you provided the models so I'll test them before release =)

Good result

nice!

 

[Macadamia]

@loktar

Hello !

I realized your MDL optimizer does not round values in extents and in animations key frames, or in color properties of emitters / bones.

It would be nice to automatically be able to round values near 0 to 0 according to the chosen precision, not only for size reasons, but for precision.
I mean : what is the point of placing a model origin at { 1.15668849562551e-08, 7.33256646846848e-09, 4.8712465465466e-04 } when it should clearly be at { 0, 0, 0}
Same issue with colors or animations, when you have values like that, I feel like it's a bit stupid, like having 0.999999999987 instead of 1 as a value.

Do you think it would be possible to add this to your upcoming upgrade ?

Thanks !!!

 

[loktar]

I'm planning to implement it down the line, but I'm gonna focus on other stuff and only apply rounding to parts of the model that are being modified by the optimizer for now.
Anyway, I don't believe it has much, if any, impact on filesize. You can use GhostWolf's optimizer in conjunction with this one though.

 

[Macadamia]

Yes I tried it but it messed up the Kyrian Colossus model I was trying to optimize for some reasons.

As I said, it's not for the size but for the precision. I might be wrong, but maybe giving the engine 0 values in some fields helps rather than these extremely high precision values, unless the 3D engine rounds the values itself (who knows), but what I know is that I spend hours changing these values manually (damn perfectionist I am) in NotePad++ and it is really tiresome.

But that was just an idea, I understand how much work you have to do to get this new version up, so only implement this possibility if you feel like it is not wasted time, but moreover if you ever get enough spare time. Or maybe later after investigating on how useful or useless is this tendency I have of rounding the values.

After all maybe I just do it because I do a lot of MDL editing and rounding these makes it so much easier to read the MDL code ?

Anyways, don't get too distracted by my weird requests, and take care

 

[loktar]

I don't think it matters much for the game itself, but I may be wrong, I have no idea how the game handles these things
But for readability when editing it's definitely easier to round them down of course.
I think for the optimizer it's mainly useful in that it increases the amount of duplicate values when small fractions are rounded away, so anything it touches will definitely get rounded.
I will probably implement optimizations per object type, geosets first, so when everything I can think of has been, I'll make sure everything gets rounded too, such as extents, before moving on to the next thing.

 

[Macadamia]

Wow, thats an amazing answer

I really look forward to have the chance to test this new tool, it should really be godsend !!

Good luck with the coding, and thank you for you hard work !

 

[loktar]

I'm hoping it won't take too long, currently the free vertices deleter is deleting all vertices xD

 

[Macadamia]

Lol. I can imagine it is not always easy. A perfect challenge to teach your code to respect its author

 

[loktar]

I have taught it respect B) For now...

Edit: alriiiight, vertex merging is working, now only to implement float rounding and actually saving the optimized model (which is pretty important xD) and it's ready. Well, I'm also gonna make separate cmd .exes for the optimizer and convertor, so that too =)

It seems a bit faster, and the program doesn't crash when the old version did, and the UI doesn't stay disabled when no optimizations are done, so that's great

 

[iNfraNe]

Working on a totally new version right now (works with both mdx and mdl, and is integrated with my mdlx converter), hopefully that one will fix it, if not let me know!
Edit: actually, you provided the models so I'll test them before release =)


nice!

It seems that they have different normals. Apparently the exporter from blender treats all triangles as flat surfaces. Not necessarily a good thing... I guess this is not a mistake of the optimizer, so feel free to ignore. Thanks anyway!

 

[Macadamia]

This seems really promising, I will be there for an extensive test to help track potential bugs !

 

[loktar]

It seems that they have different normals. Apparently the exporter from blender treats all triangles as flat surfaces. Not necessarily a good thing... I guess this is not a mistake of the optimizer, so feel free to ignore. Thanks anyway!

Ah, that's good to hear. Well, annoying for you though

This seems really promising, I will be there for an extensive test to help track potential bugs !

Thanks! There's a few kinks to work out, but I expect it will be ready by the end of next week, maybe earlier.

 

[Macadamia]

Alright.

It is amazing that you finished this so fast, congratulations on the amazing job !!!

Now I have tested this extensively, and here is my report so far :

- I used it on a folder filled with MDL (all working in Retera, some with Reforged fields some purely Format 800)

Options chosen :

- General : all but process mdx files (obviously) are ticked and save as version 800 (compatibility is a blessing ^^)
- Optimize : everything ticked, Precision to 3
- Convert : convert ticked, reforged data unticked in MDL Options (obviously in this context)

Here is the procedure I followed :

1) Select the folder containing all MDL files
2) Chose the options I just mentioned
3) Click on process
4) Move all successfully converted MDLs and their MDX version to another folder
5) Remove the fields generating errors from the remaining MDLs and make a note of them
6) Back to 1)

In case of crashes (I could not trace the exact reason, does not seem to be strictly related to some models because in the end all models but one ended up converted.
I though it was the unsupported entries at first but in such a case the program usually just prints what went wrong.) :
- Move all successfully converted MDLs and their MDX version to another folder then back to 1)

Now the feedback itself (suggestions in yellow color) :

1) It seems many Reforged specific fields are not supported yet :
- Unknown Num token: NumPopcornFxEmitters
- Unknown token in Layer: Emissive
- Unknown token in Geoset: LevelOfDetailName
- Unknown token in Helper: BillboardLockY
- Unknown token in ParticleEmitter2 Undershade: UnknownHeadOrTail
- Unknown token in Geoset: Skin
-> maybe just add them if target format is 900 or 1000 and just remove them if target format is 800
2) Attempting to select an MDL version of the Reforged NightElf Archer model and trying to convert it to format 1000 and as MDL with Reforged Data crashed the program.
-> Skip all unrecognized entries ?
3) No Hermite or Bezier to Linear transitions conversion.
-> please add this, removing thousands of
" InTan { 0.5, 0, 0, -1 },
OutTan { 0.5, 0, 0, -1 },"
by hand is a finger murderer.
4) JainaWithAlternate2.mdl refused to be converted while it works fine in Retera's and Magos.
-> here is the error :
- Unknown token in Layer: TextureID (WTF?)
5) Is this normal to have this when precision is set to 3 ?
"Geoset {
Vertices 2368 {
{ -94.3514, -10.2754, 41.7793 },
{ -133.193, -91.5592, 45.5573 },
{ -77.8483, -62.9678, 63.1268 },
{ -50.8489, 93.3967, 24.7171 },
{ -60.3102, 15.3411, 101.403 },"
-> if it is, please allow lower precision options (at user's risk ^^)
6) All resulting MDX worked perfectly in Retera's and in Magos, with a nice size reduction in both MDL and MDX. The attempts for just optimizing MDLs without converting showed a better reduction ratio that the old version !
Precision properly changed in Extents (seems to even remove extents when they have all wales set to 0), Bones, Pivot Points, Collision Shapes, etc... :
" Rotation 4 {
Linear,
2000: { 0, 0, 0, 1 },
4000: { 0, 0, 0.866025, -0.5 },
6000: { 0, 0, 0.866025, 0.5 },
8000: { 0, 0, 0, 1 },
}"
-> amazing job !
7) Trying to convert the BallWings4.mdl file attached to this message crashes the program.
Adding the buggy Jaina model next to the Ballwings4.mdl file, both as only models to convert and select folder as input and the program ended up throwing the usual error for Jaina and convert BallWings4 sucessfully. So as I said its not the model itself that crashes the program.
8) The new renaming / overwriting file name system can be confusing, especially with the option to convert or not to mdx.
-> add an option to chose the old "_opt" suffix with autoincrement

Thats all for now, thanks again for your hard work, I have the feeling perfection is at hand !!

nanoedit : sorry for all the colors, I need to compensate for not using VSCode ^^

 

[loktar]

Thanks a lot for the feedback!

• First about reforged MDLs:
  At the moment it's not compatible with retera's 0.4 reforged hack. The tokens RMS reads and writes were mostly just guesses, the ones used here are almost certainly correct (and compatible with ghostwolf's parser), and retera will hopefully update in the future.
  I will add a note in OP and tooltip to clarify this. I'll also ignore unknown tokens instead of aborting, but still display the error.
• Linearizing animations is planned, not sure when.
• Hmm, the correct tag I'm pretty sure is TextureId (lower case d), but I will make it recognize both.
• The crashes are probably due to uninitialized variables, I will make sure they have default values.
  I'll also see if I can better catch these errors before they crash the program.
  
• There does seem to be something wrong with the rounding, I'll check it out.
• Will tweak the filename system. May be best if I add radiobuttons to select between "confirm", "overwrite", "skip", "increment" and "suffix", something like that.

Thanks again for the detailed report, it will help a lot!

Edit: oh and by the way, the version changing is very simplistic, it basically just changes the version number and (tries to) write default values when converting to >800, or doesn't write data from >800 for 800. I recommend using Retera's version conversion tool.
This feature is currently very low in priority for me, especially since retera does it better, but I'll at least fix the crashes

 

[Macadamia]

Well thats all good to me, happy I could give some help.
It's a win-win situation as I believe your tool will help a lot of people, and that once finished, it will be the most complete and efficient model optimizer available for wc3, and that we definitely needed something updated on this side of things.

To be honest, most of the issues I found were minor ones, and yes I usually use Retera to convert from 1000 or 900 down to 800, but then I believe it doesn't gets rid of LevelOfDetail, nor popcorn emitters (well removing completely can't be done without fair warning) so there are still things I need to fix manually.

Not big deal though.
The Linear conversion is indeed an important step considering the lack of alternatives for it when MDXM3 Optimizer, the only current tool offering this options, has issues with quite a few models.

The great news is that your software works for the most important features though, and that it is so close to be completed. You really did a great job there !!!

Finally, for all the points you replied to, your plans just sound so adequate that I currently don't see anything I could add that would help.

So once again, keep up this amazing work, thats just godsend.
You can already count on my support and testing for the next release, when ever you can deliver it

I have the feeling that many are actually watching this thread carefully from the modelers community, even if they're much more discreet than I am^^

Take care, and again, thank you !

 

[loktar]

If I have it ignore unknown tokens, leftover reforged data should be filtered out automatically, so there would be no more need to manually delete them after vrsion converting with reteta's.
Maybe I'll also add the mdl reforged tokens from retera's to the MDL reader.

As for linearizing animations, mdlvis also has this feature, but it also changes animations with no interpolation to linear, so those have to be changed back.

Thanks for the kind words, helps keep me motivated

Edit 4: I'll write a small progress report with maybe some questions as I go:
Crashes:

• Edit: hmm, the ballwings file doesn't seem to crash the program for me when optimizing and/or converting.
  But it does crash when I try to optimize the MDX version.
  Edit again: wow, I'm confused. Sometimes it crashes, sometimes it doesn't, it doesn't seem to be consistent.
  Edit 3: I believe I've fixed it. It was a dumb change I made before release related to thread management.
• Is it possible the reforged archer was also caused by the above? Could you test it again? Or send the file.

Retera MDL tokens:

• I've decided not to add support for these. I don't want to clutter the code, so you'll have to use Retera 0.4 to convert back to MDX.
• Processing a file will no longer fail when there are unknown tokens, just an error. So tokens unsupported by the selected format will be filtered out.

TextureID:

• I had this backwards. TextureID is the correct token, and it's correct for static TextureID, but for animations I had it as TextureId. Fixed.

Rounding:

• Should be fixed. Note that scientific notation is still used when it's shorter than fixed-point notation.

 

[Macadamia]

Hello again !

You're not hanging about for sure Thats quite nice fixes.
Yes I believe extensive conversion features are not the main concern with your program, even if thats quite handy, so focusing on optimization will be for the best.

As for the archer, I attached it here, it's the untouched original from the Casc storage.
As or the scientific notation, yes of course, I wouldn't expect anything different

Thanks for doing all this !!!

 

[loktar]

Hello again !

You're not hanging about for sure Thats quite nice fixes.
Yes I believe extensive conversion features are not the main concern with your program, even if thats quite handy, so focusing on optimization will be for the best.

As for the archer, I attached it here, it's the untouched original from the Casc storage.
As or the scientific notation, yes of course, I wouldn't expect anything different

Thanks for doing all this !!!

Yeah, I might work out the conversion further if I've almost every optimization I can think of, but then it will depend on the state of Retera's version, if it's working and up to date, I won't bother
The update is almost finished. I've streamlined the UI layout a bit, and active tab is now saved between sessions. So now only to add radio buttons for file conflict handling, and I'll probably also clean up the messages a bit, and add a message with filesize differences when optimizing (but not when also converting of course).
I'll also remove the need to check at least one of optimize/convert, so you could just change the version and/or make it magos compatible if you wanted to. Or just copy the file I guess xD

So if all goes well, it'll be ready tomorrow. After that I'm probably gonna take a little break and make WC1 lumber mills


Thanks for the file.

Edit: the archer model seems to be working properly, so the crash was probably also due to the thread safety violation.
Edit: ah, it works when converting (both ways), but crashes when optimizing. I'll check it out tomorrow.
Edit: it seems to crash (or fail) on all reforged models Hopefully not too hard to fix.

 

[Macadamia]

Nice decisions, really.

As for messages, I did not find them invasive. Actually, showing the major results of optimizations felt quite comforting. You could also add a choice for the level of verbosity, but probably not a major concern right now.

I hope the Reforged models are not going to ruin your time, they can be tricky.
I also must admit they added lot of features that "look" great but are not easy to manipulate. Like popcorn sfx emitters : we simply can't change them and thats really bad.

The thing I find annoying is that in the Casc storage they also modified all classic models to add stupid emissive properties and empty level of details for example. I doubt they had any real good reason for this, as third party classic models work perfectly in the game !!!

I really hope you'll manage to get all these little issues fixes without too much work, and that you'll be able to make an army of wc1 lumber mills as a retirement plan

Take care !!!

 

[GolluM_KoMe]

Incredible job sir

 

[loktar]

As for messages, I did not find them invasive. Actually, showing the major results of optimizations felt quite comforting. You could also add a choice for the level of verbosity, but probably not a major concern right now.

Ah, good, thanks. I did improve it a bit. I removed the reduced vertex count etc because it will get too much as I start adding options.

I hope the Reforged models are not going to ruin your time, they can be tricky.
I also must admit they added lot of features that "look" great but are not easy to manipulate. Like popcorn sfx emitters : we simply can't change them and thats really bad.

Fixed it I also discovered Reforged data was ONLY being written to MDL files when converting (and the checkbox ticked). Oopsie! Fixed it now.
New version should be ready tonight.

I really hope you'll manage to get all these little issues fixes without too much work, and that you'll be able to make an army of wc1 lumber mills as a retirement plan

Take care !!!

Hehe thanks

Incredible job sir

Thank you


Edit: updated =)

 

[Macadamia]

Nice, you definitely are not hanging about as I said ^^

First of all the current program current layout is quite satisfactory, the choice of options is really nice, and there is much less confusion for options (although I would grey out options that are not used, like the convert options when you untick convert).

Next good thing is that it indeed managed to convert and optimize the reforged archer. Well done, thats really nice.

This said, for some weird reason, it failed to load the "Classic" version of the archer model from reforged.
I attached this model.
Note : after removing Shader"", static Emissive 1, LevelOfDetail entries, the optimization and conversion then worked.

Now it seems the optimizer does not like my Ball's flapping wings, because all variations of my models using these wings actually crashed the program.
I have attached both the most simple and the most complete of these models as they both trigger the crash.

After ruling out all these problematic models, everything seemed to convert and optimize perfectly, with or without conversion, and from MDX to MDL or MDL to MDX.
Quite impressive.

Now there is a MAJOR issue with the name collision options.

For example, whatever option I chose in case of conflict, even if I chose overwrite, the program will add the suffixes twice !
If I chose convert + optimize, i get a resulting file like "CapturedBall_conv_opt_conv_opt.mdx".


So far, these problems should be pretty easy to fix, I would advise to keep the current layout (maybe greying unused options).
I don't know why the classic version of reforged archer created problems when the reforged version was handled like a breeze, thats quite surprising !

As for my flapping wings, I hope you will identify what part of them crashes your program.
- I have noticed this though :
When starting to process these models, you program seems to enter an infinite loop because the memory usage grows very fast, and the crash happens around 75% of total memory used (I have 24Gb). Might not be too much of a big problem then.

Anyways, this is really getting close, I can feel it, thank you for your hard work again.

PS : don't give up on Hermite and Bezier to Linear

Take care !!!

 

[loktar]

This said, for some weird reason, it failed to load the "Classic" version of the archer model from reforged.
I attached this model.
Note : after removing Shader"", static Emissive 1, LevelOfDetail entries, the optimization and conversion then worked.

That's indeed surprising. Was the attached .mdl converted from mdx with my tool? I guess probably yes.
Edit: ah, I see it's converted with Retera's. Hmm, it's supposed to just ignore the unknown tokens. Although it reports an "unknown block: }" which is really weird.
Edit: ahh, I see, unknown tokens are ignored, but their values aren't, which causes them to be read as tokens instead. This causes the unsupported block error.
Edit: alright, fixed.

Now there is a MAJOR issue with the name collision options.

For example, whatever option I chose in case of conflict, even if I chose overwrite, the program will add the suffixes twice !
If I chose convert + optimize, i get a resulting file like "CapturedBall_conv_opt_conv_opt.mdx".

Oh damn, that's not supposed to happen I think I actually encountered this IIRC, but forgot about it.

Now it seems the optimizer does not like my Ball's flapping wings, because all variations of my models using these wings actually crashed the program.
I have attached both the most simple and the most complete of these models as they both trigger the crash.
...
As for my flapping wings, I hope you will identify what part of them crashes your program.
- I have noticed this though :
When starting to process these models, you program seems to enter an infinite loop because the memory usage grows very fast, and the crash happens around 75% of total memory used (I have 24Gb). Might not be too much of a big problem then.

Whoops, that's some major memory leak. Hopefully easy to locate.

I assume all attached models work ingame and/or are converted with my tool from MDX files that work ingame?

Disabling parts of the UI when certain things are unticked is a good idea, I'll do that.

Thanks for the report!

 

[Macadamia]

Hello ^^

Well all these models were originally converts by Retera MSRH that I optimized with your old optimizer IIRC.
But I can't be 100% sure as I played with your new tool a lot

I don't expect these issues to be really hard (or at least I hope not), and sincerely the tool has become really great.

Once the few little hiccups will be gone and the Hermite & Bezier to Linear implemented (in fact I believe you just need to remove the InTan and OutTan lines, so the animations looses a little precision but not something very noticeable ingame).

Oh I forget, yes all these models work in Retera and in the Game. all the 800 format ones have also been tested in Magos (sometimes just to recalculate extents).


Getting really close !!!

 

[loktar]

I'm happy to report that the program doesn't crash anymore on the Balls models, it actually displays a helpful error
So now I know where the problem is approximately, so I'll be able to fix it soon hopefully.

Filenaming has been fixed, it was a silly mistake

 

[Macadamia]

Really great news !!

Remember to take a break, even if I know the feeling of not being able to stop at times, because I am straight in the middle of it

I also understand there is a huge potential scope to improve this kind of tool in the long run, this said once we'll have a fully functional optimizer, the goal will be reached.
I believe the community really needs this, as there is no fully functional alternative.

Some people will argue that with current technology, this could seem futile, but they are damn wrong.
First, not everyone has access to the most advanced tools the technology has to offer.
Also, optimization should never be neglected, as it can greatly participate to a seamless gaming experience, without too much loss on the visual side of things.

EDIT :

I encountered a strange issue with one of @Mythic models that I'd like to implement as a replacement for summoning my "Balls Hunters" (doomguards).

The optimization went well, but there was one static color removed for some reason :
original model :

GeosetAnim {
   Alpha 3 {
       DontInterp,
       1000: 0,
       1200: 1,
       4000: 0,
   }
   static Color { 0, 0.019607799127697945, 0.749019980430603 },
   GeosetId 1,
}

optimization :

GeosetAnim {
   Alpha 3 {
       DontInterp,
       1000: 0,
       1200: 1,
       4000: 0,
   }
   GeosetId 1,
}

I fixed it manually, but that is quite strange as all the other numerous static color fields of the model have been properly handled.

Just wanted to bring this to your attention

 

[loktar]

Remember to take a break, even if I know the feeling of not being able to stop at times, because I am straight in the middle of it

Yeah, I get a bit obsessive sometimes I don't think I can stop until all the bugs are worked out xD

Some people will argue that with current technology, this could seem futile, but they are damn wrong.
First, not everyone has access to the most advanced tools the technology has to offer.
Also, optimization should never be neglected, as it can greatly participate to a seamless gaming experience, without too much loss on the visual side of things.

I agree, for multiplayer games it can save a lot of time in downloading/uploading maps to eachother/the server. Especially with Reforged models I think there is a lot of potential to save space.


Oh damn, I wrote the DropShadow flag as a condition to write colors (animated and static), so I guess only texture animations with the dropshadow flag were getting their color written. Fixed.
I think the Ball crash has been fixed too, but I'm not 100% how xD Will do some more testing first though.
Edit: nope, the ballwings model seems to be working, but the flyingball one crashes the program.