War3 Model Editor

[CediFly]

10/10 but some model like reforge kel'thuzard(lich) can't open the file

 

[Ravager16829]

10/10 but some model like reforge kel'thuzard(lich) can't open the file

If you want to open Reforged models, you are going to need RMS. Magos can only open legacy ones.

 

[az0120]

I have been using this tool a lot recently to make particle effects. This tool is great, but there are a few imperfections. If it can be fixed, I will be moved to tears! 1, ribbon effect cannot be displayed, 2, tail effect cannot be displayed, and 3, fixed particles in model space cannot be displayed correctly. 4, XY phase time limit, particles and game effect is different, lack of random direction, 5, particles jet state is invalid

 

[Morticio]

Can i use this or some other editor to export the models to blender?

 

[deepstrasz]

Can i use this or some other editor to export the models to blender?

You might need something like this to go with that: Blender 2.83 MDL/MDX importer
Generally, make sure you search the site for what you need.

 

[Datnes]

Very usefull thanks

 

[Nour]

Can someone put video how to run this editor

 

[aeman]

the GOATED software

 

[tillinghast]

why does magos hate particle emitters 1, the green icon ones,"SuperSpray" bones/gutz? if you want it in your model you have to save in .mdl, otherwise they get deleted; but as far as i can tell it doesn't happen when you edit a blizzard model that had them by default
i copied it from a blizzard model, converted both to .mdl and looking at them side-by-side and the only difference i see is that default blizzard model's superspray has all numbers with six digits after a dot, even for visibility where it's usually just 1 or 0; but even that didn't help and it still wiped it clean off after saving as .mdx
is there just nothing to do? if i want it in my model i have to add it as the last thing ever?

 

[Hermit]

why does magos hate particle emitters 1, the green icon ones,"SuperSpray" bones/gutz? if you want it in your model you have to save in .mdl, otherwise they get deleted

I experience the same thing on my old Windows 7 PC, but not on my Windows 10 PC. I hope someone who knows more about computers will figure out why this happens.

 

[tillinghast]

I experience the same thing on my old Windows 7 PC, but not on my Windows 10 PC. I hope someone who knows more about computers will figure out why this happens.

hmm, for me it happens on windows 10 laptop
i'll check out if that happens on my older windows 8.1 laptop and report back day after tomorrow

edit: yeah, mdl-only on win 8.1 laptop too

 

[Kyrbi0]

Hey so I finally got this working on my PC & it's pretty great, but I ran into a little issue which is hard to describe...

Basically there are two different kinds of dialog windows that can pop up when I go to Open File; one is the "older" one (Windows XP-style skin (gray)), and the other is the "newer" one (Windows +7-style skin (dark mode)). Most importantly, the latter features an 'address bar' file-system thing, where I can copy-paste an entire address to find exactly which model I want to open (as opposed to the former, which only has a drop-down box & the "Up-Folder" button).

In your ( @BogdanW3 's) latest version, I only get the former ("older") one, and cannot seem to access the latter ("newer") one, which I really want.

Any thoughts?

 

[BogdanW3]

Hey so I finally got this working on my PC & it's pretty great, but I ran into a little issue which is hard to describe...

Basically there are two different kinds of dialog windows that can pop up when I go to Open File; one is the "older" one (Windows XP-style skin (gray)), and the other is the "newer" one (Windows +7-style skin (dark mode)). Most importantly, the latter features an 'address bar' file-system thing, where I can copy-paste an entire address to find exactly which model I want to open (as opposed to the former, which only has a drop-down box & the "Up-Folder" button).

In your ( @BogdanW3 's) latest version, I only get the former ("older") one, and cannot seem to access the latter ("newer") one, which I really want.

Any thoughts?

I don't remember seeing the old one when I last used my version, but I will give it a look tonight and see if it's something obvious and easy to change - having the new style dialog is probably better in general

 

[Retera]

Any thoughts?

It may be worth remembering that the user Magos who created the War3ModelEditor stopped publishing the source code of his program for some time before he disappeared, so the version of the code that I gave Bogdan that was used to build a more recent version is an "out of date" version of the code from the standpoint of Magos from back in the day. So there might be some cases where Bogdan or whoever is doing the updates today has to reinvent or re-introduce features that were added by Magos to his binary back then, but not added to his public code that was on his website before it went down.
(As I recall, the code that we have claims to be version 1.05 but the binary version that everybody used for over a dozen years or whatever calls itself 1.07)

 

[BogdanW3]

@Kyrbi0 ok, it indeed seems the code uses the very old dialog system, and making it use the newer one might cause some regressions. For now, what I can suggest is pasting folder or file paths into the "file name" box at the bottom, as trying to open a folder will instead position the dialog into that folder and trying to open a file via a full path will work regardless of the current folder

 

[Jet Black]

When trying to create an animation with a light intensity. Model can't be re-opened and can't be loaded in the editor... Any solution?
Unable to load "FilePath.mdx", unknown group "KLAI"!

 

[tillinghast]

View attachment 442066
When trying to create an animation with a light intensity. Model can't be re-opened and can't be loaded in the editor... Any solution?

a lot of beta models show similar errors and some (but not all) of them get fixed if you convert to .mdl and back
you can also try opening .mdl in notepad, searching for that "KLAI" and deleting that string or renaming it

 

[Jet Black]

a lot of beta models show similar errors and some (but not all) of them get fixed if you convert to .mdl and back
you can also try opening .mdl in notepad, searching for that "KLAI" and deleting that string or renaming it

Just saving in .mdl and not .mdx fixed the issue genius! What's the difference between those two file formats?

 

[tillinghast]

Just saving in .mdl and not .mdx fixed the issue genius! What's the difference between those two file formats?

.mdl can be opened in text editors and weighs a lot more, that's all i know

 

[stan0033]

I;ll to report 3 bugs of the program:

• associating a material with texture animation does not save it, as it remains unused. Only way is by editing the MDL file with nodepad.
• if a geoset animation has static alpha , sometimes that gets saved as 0 or near 0, which makes the geoset associated with that GA to be invisible. Use dynamic alpha instructions.
• What;s the point of having the option of creating a new geoset if when no data is entered, it crashes the app? and actually entering any data manually inside of that geoset is not enabled.
• when opening a model, if any layer has filter mode "modulate", is changed to "none". (saving with modulate works however)

 

[biridius]

when opening a model, if any layer has filter mode "modulate", is changed to "none". (saving with modulate works however)

I'm pretty sure this is an Mdl Vis bug. Saving with Mdl Vis turns modulates to none.
War3ME opens models with modulate properly for me.

 

[Rubellu Sidus]

Is there a way to open reforged models with this new versions of W3ME? I extracted the reforged Paladin Model with textures DDS for testing, but the program couldn't open.

 

[Ravager16829]

Is there a way to open reforged models with this new versions of W3ME? I extracted the reforged Paladin Model with textures DDS, but the program couldn't open.

Some Reforged models didn't work with this new W3ME. You can use RMS instead.

 

[BogdanW3]

Is there a way to open reforged models with this new versions of W3ME? I extracted the reforged Paladin Model with textures DDS for testing, but the program couldn't open.

If you mean HD models, they're rendered very differently so it'd be very hard to code that in sadly, and they're much more complex to parse too

 

[Rubellu Sidus]

If you mean HD models, they're rendered very differently so it'd be very hard to code that in sadly, and they're much more complex to parse too

Too bad. I dream of the day we'll be able to open HD models in W3ME and MDLVis. Retera's Model Studio is nice, but is too complex for my big-brain

 

[Dr Super Good]

Retera's Model Studio is nice, but is too complex for my big-brain

If you have usability suggestions you might want to feed them back to the developers. Effective UI design is very difficult and usually involves a lot of feedback and use by a broad spectrum of users.

 

[Rubellu Sidus]

If you have usability suggestions you might want to feed them back to the developers. Effective UI design is very difficult and usually involves a lot of feedback and use by a broad spectrum of users.

I love the RMS because it contains almost all tools we used in order to make high quality models. However, I'm used to MDLVis because it seems simple. Perhaps I will use RMS again. I just have to properly know how to, right?

 

[deepstrasz]

I love the RMS because it contains almost all tools we used in order to make high quality models. However, I'm used to MDLVis because it seems simple. Perhaps I will use RMS again. I just have to properly know how to, right?

You could use both for various purposes. There's things you can't do with one and do with the other.

 

[Rubellu Sidus]

You could use both for various purposes. There's things you can't do with one and do with the other.

I will start training with Retera's, though I think I should download it againt to properly work nowadays.

 

[FUJI]

Don't double-post, and the registry editor is a part of windows, just open the windows search bar and search for it

searching the path HKEY_CURRENT_USER\Software\Blizzard Entertainment\Warcraft III\ but unfortunately i don't have the Warcraft III folder there...

Spoiler

 

[BogdanW3]

searching the path HKEY_CURRENT_USER\Software\Blizzard Entertainment\Warcraft III\ but unfortunately i don't have the Warcraft III folder there...

Spoiler

View attachment 464616

If the folder is not there, you can create it

 

[Retera]

I was asked on Discord about a new bug in Magos War3ModelEditor 1.07 that now causes it to crash when opening some models but not others. I did not feel very useful; I have been trying to only run linux libre lately, and wine is not working on here.

Does anyone else have issues cropping up with recent updates to Windows causing War3ModelEditor to fail on some models but not others? How would I help someone reporting that problem?

 

[SadOnix]

If Size isnt a Factor and you want your Loading Screen to look even better this helped me a lot :

High Resolution Loading Screens

In this tutorial, you'll find how to get a HD Loading Screen. There's two methods available. ".dds" & ".tga" The one you choose is based on the Warcraft 3 version you have. Users on the Latest Patch can choose between either, although using a ".dds" import is superior as it uses a lower file...

www.hiveworkshop.com

 

[voply]

Hello!
Can anyone help me with setting up editor for correct spell animation?
For example, level up animation looks strange and I see obvious diffrence

 

[Retera]

If you pay me $200000 USD I can update Magos to match the View in 3D function of Hive Workshop, so that it will render spells much more accurately to the game

But the current binary software exists as-is, which is not fully aware of how Warcraft 3 art is rendered, because officially how it is rendered is a proprietary secret now owned by Microsoft. But the "View in 3D" from Hive utility, authored by Ghostwolf, is a close second.

 

[Jab1z]

The Only Wae to make wc3 models

 

[BogdanW3]

Pushed a small update for v1.08 to fix a problem with ribbon emitter handling, and improve v1100 saving.
If you've been using v1.08, the update might fix some issues you may've come across

 

[BogdanW3]

why does v1.07 has two different "Open Model or Texture" menus...

and @Kyrbi0 I think I just found out the cause - some undocumented windows API edge-case, where not nulling some fields makes the window depend on the last interacted-with element.
I think I fixed it in 1.08 now (another update released just now), give it a test and report back if you'd like, thanks in advance!

 

[Kyrbi0]

and @Kyrbi0 I think I just found out the cause - some undocumented windows API edge-case, where not nulling some fields makes the window depend on the last interacted-with element.
I think I fixed it in 1.08 now (another update released just now), give it a test and report back if you'd like, thanks in advance!

Wow, going back to fix ancient bugs like this, in 2024? You da man. : )

I barely recall the issue I was describing, but as far as my (limited) testing revealed, everything works fine! (It does seem like it 'saves' the same Windows folder/file location between the MPQ Browser & the regular Magos window, which is annoying when my MPQs & my models aren't in the same place. But I reckon that's not the same issue Tillinghast describes, nor is it fixable).

//EDIT// - Not to give you more to do/consider, but I remembered something that's bugged me for a while... Used to be I could put the 4 MPQs straight into the Magos folder & it could 'see' them (or at least, be 'routed' to see them properly). I have an unorthodox setup so it keeps looking in Program Files & not finding them.

Is there a way to fix that (either tell Magos where to look, or have it automatically check it's own folder, or both)?

 

[BogdanW3]

Wow, going back to fix ancient bugs like this, in 2024? You da man. : )

I barely recall the issue I was describing, but as far as my (limited) testing revealed, everything works fine! (It does seem like it 'saves' the same Windows folder/file location between the MPQ Browser & the regular Magos window, which is annoying when my MPQs & my models aren't in the same place. But I reckon that's not the same issue Tillinghast describes, nor is it fixable).

//EDIT// - Not to give you more to do/consider, but I remembered something that's bugged me for a while... Used to be I could put the 4 MPQs straight into the Magos folder & it could 'see' them (or at least, be 'routed' to see them properly). I have an unorthodox setup so it keeps looking in Program Files & not finding them.

Is there a way to fix that (either tell Magos where to look, or have it automatically check it's own folder, or both)?

Ideally you'd just set up the InstallPath registry key, unless you really need to have the InstallPath set to an invalid install for some reason, but I'll fixed both of these in the new release, I'll call it 1.09 to create extra confusion
Although seriously, being able to choose the War3 folder manually is a great idea, even having to do it by manually changing the properties file would've been great, but having a UI for it is even better.

 

[BogdanW3]

Ok, just released a new version, you can choose the War3 folder from the properties panel now, and the open dialogs should all work independently now!

@Kyrbi0 give it a shot, and feel free to report any new issues

 

[Kyrbi0]

Ok, just released a new version, you can choose the War3 folder from the properties panel now, and the open dialogs should all work independently now!

@Kyrbi0 give it a shot, and feel free to report any new issues

My computer's starting to become overflowing with versions of Magos... xD

I cracked it open & I love the new setting in the Properties menu, very nice. Unfortunately, it still isn't working quite right... But I'm willing to bet it's just my wacko file organization. (I tell it to use a specific version of Wc3 in a particular place, but upon opening Magos it goes through a seemingly endless series of error messages, starting with "that's not valid", and then a bunch of "texture file not found" ones).

I don't really think this is necessarily an issue outside my own computer, though. :<

 

[BogdanW3]

My computer's starting to become overflowing with versions of Magos... xD

I cracked it open & I love the new setting in the Properties menu, very nice. Unfortunately, it still isn't working quite right... But I'm willing to bet it's just my wacko file organization. (I tell it to use a specific version of Wc3 in a particular place, but upon opening Magos it goes through a seemingly endless series of error messages, starting with "that's not valid", and then a bunch of "texture file not found" ones).

I don't really think this is necessarily an issue outside my own computer, though. :<

Which patch of Warcraft III? Since I added 24 player capabilities and more replaceable textures, versions before 1.29 won't have all textures.
After painstakingly clicking on all the errors, you should be able to use it even with 1.26, but I really can't recommend.

 

[Retera]

Since I added 24 player capabilities and more replaceable textures, versions before 1.29 won't have all textures.

do you now if you could make it so like in this video it would render like the reforged models if thats what user picks in settings

but at the same time, keep backwards compat. So for example if the user picks patch 1.26 because they want to look at ballista

Can you make so they can do this with no error and it just lets them configure to any patch??

(I think is more convenient for users this way)

Edit; would also be great if it could preview Reforge particles. people want ot know what their models looks like!

 

[Kyrbi0]

View attachment 479185

do you now if you could make it so like in this video it would render like the reforged models if thats what user picks in settings

but at the same time, keep backwards compat. So for example if the user picks patch 1.26 because they want to look at ballista

View attachment 479186

Can you make so they can do this with no error and it just lets them configure to any patch??

(I think is more convenient for users this way)

Edit; would also be great if it could preview Reforge particles. people want ot know what their models looks like!

It would be nice, but I don't know if the 'juice is worth the squeeze'; how hard is it to do, versus how many people it would benefit (me)?

I mean heck, I'm trying to figure out how to shift my workflow away from Magos & into your program, so maybe fixing Magos up like this for me is simply wasted time. :<

Which patch of Warcraft III? Since I added 24 player capabilities and more replaceable textures, versions before 1.29 won't have all textures.
After painstakingly clicking on all the errors, you should be able to use it even with 1.26, but I really can't recommend.

I'm trying to point to v1.26, my natural primary working version (currently).

I'll have to poke around to see if I can find my v1.29+ (I have several versions, including the latest Reforged... but for some reason I had trouble finding the folder containing the MPQs).

 

[BogdanW3]

It would be nice, but I don't know if the 'juice is worth the squeeze'; how hard is it to do, versus how many people it would benefit (me)?

I mean heck, I'm trying to figure out how to shift my workflow away from Magos & into your program, so maybe fixing Magos up like this for me is simply wasted time. :<


I'm trying to point to v1.26, my natural primary working version (currently).

I'll have to poke around to see if I can find my v1.29+ (I have several versions, including the latest Reforged... but for some reason I had trouble finding the folder containing the MPQs).

For the part about Retera, he's trolling as usual, he knows well how much he had to restructure his tool, and he wasn't bound by Dx9 problems
On a serious note, the best way forward is to require as little time in any war3-specific tool, and being able to do most of the work in Blender.

For your part, 1.30+ versions don't use MPQs, but you can still point the W3ME to their main folder (it'll be the one containing a Data folder).
So yes, in the case of Reforged, there won't be any MPQs and you won't be able to use the MPQ browser sadly, as it's using CASC.
For a link to 1.29, check the downloads archive. 1.29 still uses MPQs so you get the best of both worlds: up-to-date texture paths and 24 players, AND the MPQ Browser working

 

[Retera]

he's trolling as usual

On a serious note

I mean, in my opinion what I was saying is accurate to the user experience and the interest of the end consumer. I think that if you actually provided the features that I was describing, people would most likely use them. Some people might really enjoy them. These ideas are/were based in features that I actually invested the time to support on my own program, such as the switching capability to read from 1.26 or 1.36 without issue (and a lot of things in-between).

When I edited the message and suggested rendering Reforged particles, though, I guess that part was actually trolling, because I consider them to be impossibly convoluted to a point that it is beyond the scope of any human's time to render them. However, in saying that you should have a preview for Reforged particles, I am parroting actual user requests. In particular I had a user complain to me that I couldn't preview particles on Classic Graphics before Reforged graphics were invented, then I spent many, many hours of my time copying the particle preview system from Ghostwolf, then Reforged released and the same user came back to me and said their Reforged particles wouldn't render. So I reached out to the gatekeepers of the PKB render code used in Reforged and offered to pay that company money so that Retera Model Studio could render the Reforged particles, and they told me that even if I paid them money they would not let me do this.

So, when our dark overseers make something prohibitively impossible even if we offer to throw money at them, and then I encourage you to accomplish the prohibitively impossible thing as I was once first encouraged by a non-technical user, maybe that part is trolling. But I think support for 1.26 and support for at least basic normal mapping are both much more humanly viable.

Generally though, I really struggle to endorse more additional codebases that parrot the same exact code in different languages. So the other side of what I'm saying, and you could decide from your perspective if you see that as trolling, is that maybe I am wrong to suggest that you update or maintain Magos at all. Because you can doesn't necessarily mean you should.

Tonight I was reviewing an inquiry from a user here and this is a very valid inquiry of something technically wrong with how the tools I use handle MDX format. What does Magos do in this case? How does the program you are propping up render this model in this case? Do you even care? I think that most likely I do not care. Ghostwolf copied from Magos's 2005-2008 project, and worked from like 2008 to 2021 on improving how closely his code matched the Warcraft 3 game. And what we see with things like that thread I just linked is that even after all that time, he still didn't get it exactly right.

And when I go into the code to try to really see and understand why he didn't get it right, I'm reminded how crazy the state of our understanding of MDX rendering is. Retera Model Studio's code at this point is garbage to me and I don't care about it because it won't match the game -- and yet it's the one that the largest number of people are using. And then on top of that I have the Warsmash render pipeline which is "my second time" porting Ghostwolf to Java -- basically in the same ecosystem as Retera Model Studio but with a rewrite of most thing (mdx parsing, mdx rendering, etc) to try to be 1:1 with Ghostwolf. Then, I kept adding stuff to it for the past 4 years that even Ghostwolf didn't have, such as light emitters.
When I read my code to compare against Ghostwolf to try to understand what's happening in that user thread above, I get distracted by red herrings. Tonight I was looking at how ParticleEmitter2 (PRE2) particles are sized visually, and even my "more direct copy" of Ghostwolf has diverged from his. I found myself looking at the subroutine for XYQuad -- not because I was sure it had anything wrong (it is notably a guaranteed red herring because the particles in Vinz's rocket model are NOT XYQuad) -- but because I wanted to review everything about the particle render. I was hoping that if I read through everything particles do, and get a mental picture of that, maybe then it would cause me to see the issue in that above-linked thread from earlier this week. It might even be something obvious, but I didn't see it yet.

Anyway I was looking at the red herring of XYQuad just checking over my own work to see where it differed from Ghostwolf, and then I find myself looking at this. One of the reasons this caught my eye is that it was a difference between my supposedly 1:1 port of Ghostwolf and his actual code. But why is it indifferent, I ask? It's different because my copy of him split off in 2020 without contributing back to the original source material! So when I realized that naga units and Swim animations must preview with velocity applied as a rotation to XYQuad emitters, I modified Warsmash to accomplish this. But the math for how I did it is all weird. Ghostwolf uses a standard atan2 call to figure the facing angle in 2D of the XYQuad particle, then he does trigonometry on the graphics card in the glsl code using the provided facing angle. So in each GPU code when it's processing the location of a vertex in the vertex shader program, he uses sin and cos to apply this XYQuad rotation which he introduced after some Discord conversation where he probably asked me, "Did you ever have this problem?" and I told him yea I did and that I put in some hack to turn the particles to face with their velocity. But his solution isn't at all like my solution that I added to his code! So although he does standard trig, and then cos(facing) for the X component and sin(facing) for the Y component to construct vectors on the GPU to match particle orientation, mine instead is doing this

                "        if(a_p1[0] != 0.0 || a_p1[1] != 0.0) {\r\n" + //
                "          lightingNormal = vec3(0.0, 0.0, 1.0);\r\n" + //
                "          vec3 vx;\r\n" + //
                "          vx[0] = a_p1[0];\r\n" + //
                "          vx[1] = a_p1[1];\r\n" + //
                "          vx[2] = 0.0;\r\n" + //
                "          vx = normalize(vx);\r\n" + //
                "          vec3 vy;\r\n" + //
                "          vy[0] = -vx[1];\r\n" + //
                "          vy[1] = vx[0];\r\n" + //
                "          vy[2] = 0.0;\r\n" + //
                "          vertices[2] = - vx - vy;\r\n" + //
                "          vertices[1] = vx - vy;\r\n" + //
                "          vertices[0] = -vertices[2];\r\n" + //
                "          vertices[3] = -vertices[1];\r\n" + //
                "        } else {\r\n" + //

So, it was evident that the above string variable in Java which is used to generate glsl code that is then run on the graphics card hardware, in this case is a snippet of the section where p1 vector's X or Y component are nonzero. And so I was able to tell that I set these to nonzero in the case of XYQuad emitters, and so this code pasted above is the fundamental piece of code that rotates the ripples of the naga swim animations to face how the unit faces, i.e. to match the velocity of the emitted particle. But is that the same as Ghostwolf? It's totally different mathematically. His is that trig:

    vec3 v = u_vertices[int(a_position)];
    float cs = cos(a_p1.x);
    float sn = sin(a_p1.x);

    float x = v.x * cs - v.y * sn;
    float y = v.x * sn + v.y * cs;

    vec3 fv = vec3(
      v.x * cs - v.y * sn,
      v.x * sn + v.y * cs,
      v.z);

    gl_Position = u_VP * vec4(a_p0 + fv * scale, 1.0);

He reuses p1's X component as facing when it's running on the GPU. So instead of the X and Y of this p1 vector being the ground projection in 2D space of the velocity of the particle, like what I was doing, he's treating X as facing. That make sense. I don't know why he declares x and y and doesn't use them, but I think he was getting pretty fed up with our community by 2021 for the lack of appreciation of the unrewarding technical effort that he put into this stuff, so writing some variables and then forgetting to use them was probably par for the course for the upstream battle to get anything done.

None of this answers my question for whether it's relevant that this is one difference between my code and his. It's probably not relevant. It's probably totally unrelated to the problems that @Jaccouille is having in that other thread. I'm just comparing this difference for my own personal benefit, because I want at least one copy of this code that is always right. There's probably an edge case, probably something Ghostwolf knew or tested with, or something that I knew or tested with, that makes one of these two code segments above actually wholly better than the other -- which is to say matching the behavior of Warcraft 3 more commonly.

But which is it? If his is better, I want to change. If mine is better, then I don't care and I go back to solving Jaccouille's issue. One of the 10 particle emitters in @Vinz 's model that Jaccouille was asking about is XYQuad. So, we definitely are capable of running this code as part of the model. And in the difference between Ghostwolf's stuff and mine, there was this gap where it looked like I was leaking data possibly from one call to render an emitter to the next in the case of XYQuad, maybe. So, maybe, maybe, my code is overwriting something where one particle affects another and that makes it render differently. But probably not. Probably a red herring. Yet still I wanted to chase the red herring to at least answer whether Ghostwolf's code or my code to do the same thing is more accurate to the game, or if they are the same.

This led me to another question: what is the origin of the stuff on my side? Did I write it? I don't remember writing this. It seems quite gross. I like to name variables if possible. What is vx ? What is vy ? What do these represent?

I sat for 5 minutes and did a little sketch and was able to understand that vy is a simple perpendicular vector. This makes sense -- it's constructed with a basic x2=-y1 and y2=x1 from middle school math class. Okay, great. But why do I create the sum of the inverses of vx and vy together? Burned another 20 minutes trying to mentally picture it. I don't remember writing this code. That probably means I copied it from someone. But if I didn't copy it from Ghostwolf, where the dickens is it from? My mind starts to wander: Was Ghostwolf looking at "my" solution when he wrote his, making his the definitive best (minus the stray variables that are apparently unused)? Or had I started with something like what he's got and hacked it some late night that I don't remember for some reason? He's probably right that a facing angle and standard trig are more readable, and make more sense whenever we try to maintain code. What is the code even doing on my side?

And then I make a breakthough. Colloquially, I say to people, "I copied the shoreline waves on Warsmash from the RivSoft modified version of Ghostwolf's viewer." It's been years, but sure enough, it's right there: wc3data/src/mdx/viewer/handlers/mdx/particle2.js at master · d07RiV/wc3data

So in the case of RivSoft's (now defunct) web page for viewing Warcraft 3 maps with Ghostwolf's viewer, in an older version of Ghostwolf's viewer that he copied from, he himself (according to Git Blame) added the following subroutine in 2019 before Warsmash was even created (or when it existed in some primordial form that is not worth considering to have existed technologically):

      if (modelObject.xYQuad) {
        let vx = vec3Heap[4], vy = vec3Heap[5];
        vx[0] = velocity[0];
        vx[1] = velocity[1];
        vx[2] = 0;
        vec3.normalize(vx, vx);
        vy[0] = -vx[1];
        vy[1] = vx[0];
        vy[2] = 0;
        vec3.add(vec3Heap[2], vx, vy);
        vec3.sub(vec3Heap[1], vy, vx);
        vec3.negate(vec3Heap[0], vec3Heap[2]);
        vec3.negate(vec3Heap[3], vec3Heap[1]);
        vectors = vec3Heap;
      }

And so, he executes this man on the CPU -- obviously bad for performance -- but we can see I was not the originator of this math. All I did was apparently flip the first two vectors. That... that I do remember doing. That rings a bell. I was having a problem where Naga units had their swim animations render the waves going the wrong direction. For some reason that i don't remember, this code was fine with the shoreline waves but on the spinning and multi directional Naga units (NOTE: shoreline waves only appear in cardinal directions for the most part), it would bust. By flipping the vectors, some textures get oriented the correct way in some cases. I don't remember which cases, but I think they do.

So now I know the origin of the code I was looking at, and we understand the general history was probably:

• 2019 the guy Riv invents this in his copy of Ghostwolf
• 2020 I copy from him an use it in Warsmash gameplay
• 2021 Ghostwolf chats me about it and writes his own solution to the problem after confirming there was actually need to upgrade his viewer

This of course doesn't tell me whether Ghostwolf's solution does something "right" that mine doesn't, or whether it runs faster or slower on the GPU than mine (which would both be good to know but now I know how this code came to be, and I know the reasoning behind 1 difference between Ghostwolf's viewer and my stuff.

It's still probably not THE difference that is causing Jaccoulle's issue and the difference in previewer outputs. It's this totally random technological tangent. But so for my own curiosity, I fire up the program in those videos attached to my preview post on this thread -- which is to say, a very experimental program with the Animation Controller that pretends to look like Magos -- but it previews models using this Warsmash technology that is in a Retera Model Studio style of ecosystem, but is ahead of Retera Model Studio in terms of capabilities. That is to say, I run my latest and greatest code and the vector math pasted above.

And lo and behold, when I try rendering the Flamestrike model that Ghostwolf was interacting with, it renders some random crap. I thought I already fixed this! I remembering fighting with this on a Warsmash render years ago, but here again it regressed back to rendering incorrectly. Why? I don't even remember.

So I know this has been a really long stream of consciousness, and it didn't fix issues for Jaccoulle, and it didn't help improve Magos. But if you can understand my thought process a little bit, and the understanding of these last 16 years since 2008 when Mr Magos himself last updated Magos, and how there were 16 years of evolution since then and the increase in understanding and the technical work undertaken to mimic the game... when you try to go back to that, and you try to maintain that, the ultimate evolution of that work is to read and consume the understanding of the work Ghostwolf was doing and then put that same behavior into your program, or else re-derive it from Warcraft 3 in another many multi year process.

Why do that? It's crazy to me. We have multiple authors that try to distill how to render this stuff, and we don't always have good software management to collect up what we know so that everybody is using the best technology possible. By supporting another technology that died 16 years ago, and trying to put it on life support as if we were suddenly going to maintain it, don't we make that problem of many solutions to the same problem from people who don't succeed at sharing knowledge and information, probably into an even worse problem? Maybe the person who begins to seriously undertake the effort to do that is actually the troll.

Edit:

The reason for the visual difference in my test render was here: Possible Reforged campaign menu screen restoration [need help]

For that thread, to improve parity with Warcraft 3, I changed the orientation of all particle emitter textures based on the dandelion or cottonwood or whatever it is that's on the RoC menu, and the leaves in the Human campaign menu. The particle orientations previously didn't match Blizzard in my stuff, and I think not even in Ghostwolf but maybe I'm misremembeirng that and it's just wrong on Retera Model Studio.

 

[BogdanW3]

...

I agree, especially the part where you call out how our attempts at replicating the MDX behaviour are still incorrect 20+ years later... The way I look at the current state of afairs, I'm only doing compatibility and accessibility updates to W3ME, I don't really have much interest in making another competing tool again. If there's one "percieved positive" out of Reforged changing the model format (other than the new functionality), it's that there's no longer a million MDL formats that barely match because all the tools got killed. RMS was the first to revive, and it supports HD too, this is monumental.
This W3ME maintenance project of mine won't be supporting HD anytime soon both due to me not having enough time to delve into it, and due to this likely meaning I'd have to rewrite so much of the code that regressions are neigh impossible to avoid.
If anything, I'd much rather have everyone who can write clean code instead focus on a singular Blender plugin which would do both importing and exporting, with this process also being self-invariant (importing into blender then exporting with no edits should produce an identical model). This would mean we can use Blender as the end-all be-all of model editing, and even if some things aren't displayed in an "initial release", it would mean we can modernize the workflow and take advantage of the plethora of tutorials and resources for Blender.

 

[Retera]

This would mean we can use Blender as the end-all be-all of model editing

I get the impression that would probably be a good idea, especially so that people who bother to learn wc3 model work can leave to go make models for some other game. But as someone who has hardly ever used blender myself, other than a few occasions sitting for an hour and trying to draw a model without reading much of a tutorial, it certainly seems like a program with a lot of buttons that easily might not be relevant to Warcraft 3 and I would imagine it might be difficult or time consuming to coerce blender to render a Warcraft 3 model in its exact form (particles, ribbons, priorty planing of blend geosets, etc). It's certainly a good fit for Reforged models where we can never preview the details anyway because of Activision's tomfoolery of buying a third party render system from a company unwilling to sell to a guy like me, wherein the third party system was designed to store particle scene graph data in unlabeled binary chunks of unlabeled sizes expressly so that the mere concept of parsing first requires an application level understanding of which chunks have which meanings.

But I wonder if for the classic models, there might always be a benefit to a program someone can pop open to just view a model with a near 1:1 likeness to how War3 would render it. Even Blizzard apparently appreciated this, which is why War3Preview.exe existed as a standalone app if I recall for users who download the official 3ds Max Plugin used to create Reign of Chaos and TFT models.

Unfortunately, in my experience, War3Preview.exe was not as good a program as Magos because they compiled it against an unfinished version of the War3 renderer or something like that, so in practice the model render didn't always match their game code. But it was a close second, and was obviously useful before Magos or the prophet viewer existed, and it points out that even Blizzard appreciated having something like that.

So I guess contrary to my ranting and raving last night, unless Blender makes it easy to have a 3D view that renders with custom shaders written to match ancient War3 style, there's probably some utility to a program that nearly matches how War3 renders, at least for Classic users. Back in maybe 2014 or 2015, I myself was using Magos for that purpose, but I have dropped support of it because Ghostwolf and derivative works of his code are better and more accurate, such as Sanity Test

If we imagine a world where we have blender and ghostwolf's viewer as the two tools that people use, and if they ditch Magos or Retera Model Studio or Mdlvis for editing, obviously at the moment there would be some group of users who would complain and say that they want a GUI for making quick model edits. I don't much support it in the version of Retera Model Studio that I maintain because I could always just hack the MDL file with a text editor, but it seems like a major pull for users to want to use the Twilac fork instead of my original program so that they have GUI buttons that modify simple tabular model data. So until/unless the user could trust your hypothetical perfect blender plugin to perfectly match and manipulate all Warcraft 3 model properties, there will probably be this tendency to pull back towards custom programs for editing.

But when that happens, it might be better if we have only one to maintain instead of several. Maybe that's me being too idealistic.

But a lot of times, whenever we have somebody making or updating an MDX tool, you can always count on them to do something wrong. I had a guy the other day who was telling me that he was doing some basic edits to his models and then the models would just break and he didn't understand why. I ended up figuring out that when he used Twilac fork of Retera Model Studio, it would save GeosetAnim blocks with an extra 0x2 flag in binary due to a bug, and when he used Magos he was downloading your version instead of the version from Mr Magos himself, which then is actually compiled against 1.05 source code and not 1.07 because of how Magos didn't give us the code for 1.07 so we don't know how to upgrade it. So there were regressions.

So by giving him this history lesson of how people fell into two categories -- the anti change people using magos 1.07, and the reforged people who might be unaffected by extra flag 0x2 -- i was able to get him to where he could solve his problems. But that's a super frustrating dumb place to be as a user

 

[BogdanW3]

...there would be some group of users who would complain and say that they want a GUI for making quick model edits...

That's what Blender would be, there's a lot about modelling that shouldn't be taken for granted, and knowing even the basics of Blender translates well into knowing how stuff works: Blender's animations can do more than War3SD, that's true, but most of what you'd want in a game like War3 is exactly doable in both Blender and War3; skinning in Blender is more sophisticated not to make it harder to understand it, but to make it easier, the "many buttons" can translate really well to War3 stuff, I've just yesterday made use of Blender to fix a model with multiple broken animations and very broken skinning, but do players of War3 even know what skinning vs rigging is, and then again, why texture-swaps shouldn't be called skinning?

Anyway, I got carried away there, the main thing I wanted to say is that it took only a few basic commands to fix those animations, the largest part being to even find the bone, which is the same chore in any tool. And the part that I'd love to get fixed up in the very near future is that I had to redo materials a bit manually, nothing daunting though, just took a min

But yes, your last statement stands its ground... until there's a plugin that even claims to do this, let alone that users trust not to break, there will always be those that stay with old tools, afraid of change or just happy to keep doing their thing their way. And that's fine - we just can't help them in ways other than try to keep at our respective maintenance positions for a while longer.