kion
Arukoitan
@kion_dgl
Posts: 193
|
Post by kion on Mar 4, 2018 5:10:54 GMT -5
Going back and taking a closer look, it looks like ST0D is the dock area. So if it is in the game, it will be around there. But that seems like an obvious thing for people to miss, to yeah, it might have been cut from the game even though it's there. Right now I'm working on mapping more textures to meshes, but if it really bothers you, I could try replacing an NPC model with the frog reference and see if the game will draw it.
Edit: Another progress update. I've added textures for the models with separate faces. So Roll, Tron, Teisel, Juno, ect. all have textures. So now I need to debug Megaman in scenes ST0E_00, ST14_00A, and ST18_00 since it looks like the developers added in something in his hand or something. And I need to debug Roll in scenes ST17_00A and ST17_00C, since the wrong texture gets mapped to her face. Aside from that I have a little cleaning up to do for a few cars, cat, bird, and kick-the-can which have hard to locate textures.
|
|
|
Post by xinus22 on Mar 4, 2018 6:28:14 GMT -5
Oh also. can we expect an export option to something besides GLTF? because i was only able to find an Blender GLTF importer that gives me errors when i try to import models with animations. some format that supports bones like FBX would be awesome.
|
|
kion
Arukoitan
@kion_dgl
Posts: 193
|
Post by kion on Mar 4, 2018 9:06:35 GMT -5
Oh also. can we expect an export option to something besides GLTF? because i was only able to find an Blender GLTF importer that gives me errors when i try to import models with animations. some format that supports bones like FBX would be awesome. That's the ironic part about working with undocumented formats from twenty years ago. You go through all of the trouble to debug, parse and display them, and when you get the point of exporting you realize that that was the more enjoyable part of the experience. Model formats are a mess and it seems to center around Autodesk making too much money from extorting money from businesses to actually make the documentation of their format available. You have to use their C++ SDK, and since only a few large companies actually jump through the hoops to do that. The only viable open source option in .dae, and that is a horrible pain to deal with. It's a poorly designed, poorly implemented xml format with tons of cross referencing id's and attributes and not many programmers want to touch it with a ten foot pole. GLTF is supposed to be the non-retarded new standard that Collada is working on, and Threejs seems to shifting their focus to use that primarily, so my hope is that in a few years it will be a pretty well adopted standard. As for options, I added threejs's JSON format and STL. There is a MMD exporter for Threejs, except it doesn't seem like it has bones or animations implemented yet. In general everything seems to use glTF or Threejs as an end point, and there aren't a lot of resources for going from either of these two back into Blender at the moment. The easiest option would probably be to use an older version of threejs so that it exports their old 3.1 JSON format, as I think there was a Blender Importer that could actually handle that. The ideal solution would be to have a .dae exporter, but if the .dae format wasn't such a huge pile of flaming monkey poop, then someone would have done it already. Edit: Fixed the few Megaman instances that weren't loading. There are still two instances of Roll where the texture is mapping to the wrong image, but there isn't anything unique in those scenes, so it doesn't need to be fixed. Overall in terms of implementation I think it's at the point of "good enough" that there's not too much more I want to implement in the animation viewer. So I'll poke around with formats some more and see if there is some workable option for getting models into a more widely supported format.
|
|
|
Post by xinus22 on Mar 11, 2018 7:58:57 GMT -5
Okay, I'm having some issues. So as i said when i try to use the Blender Gltf importer on the models that i downloaded from the site blender just gives me a bunch of errors and the only thing that gets imported is the bones without animations. even though the importer worked perfectly fine when i used models that were converted with the node.js script. i thought that this is just the problem of the importer. so i tried to open them in the this gltf viewer gltf-viewer.donmccurdy.com/ it seems that it works a bit better (it did open some models but still gave some errors) but most of the models still won't open and show those 3 errors TYPE_MISMATCH Type mismatch. Property value null is not a 'integer'. /skins/0/joints/17
MESH_PRIMITIVE_ATTRIBUTES_ACCESSOR_INVALID_FORMAT Invalid accessor format '{VEC4, FLOAT}' for this attribute semantic. Must be one of ('{VEC4, UNSIGNED_BYTE}', '{VEC4, UNSIGNED_SHORT}'). /meshes/0/primitives/0/attributes/JOINTS_0
UNRESOLVED_REFERENCE Unresolved reference: -1. /skins/0/joints/17
Any ideas?
|
|
kion
Arukoitan
@kion_dgl
Posts: 193
|
Post by kion on Mar 11, 2018 8:44:13 GMT -5
The problem with the gltf exporter is that it's an off-the shelf module I was hoping would work. So I decided to bite the bullet and start working on a .dae exporter. Right now it just does basic geometry, once I add in vertex weights I was going to upload it to the live version. As for animation, I'll have to see how long that will take, or if I die from bloodloss from repeatedly bashing myself with a keyboard in the face. If you want to check what I have so far, you can look here: pastebin.com/raw/6VPTZrfy. One side effect of using dae is that I don't think I can include the texture in the model internally, so I'll have to add in some option to download the texture as a separate file. Not a huge problem on the programming side, I'm just a fan of having textures being embedded into the model file as it's a lot cleaner to work with. And a funny side note is that originally I tried to use the latest collada version 1.5.0, but that caused Blender to crash from just opening the file. So I switched to version 1.4.1 which worked fine, even though the only thing I changed was the version string at the top of the file. Edit: Quick rant on why .dae is a stupid file format. Megaman Legends has a file format for the PSX from 20 years ago but the basic layout of the file is over all pretty simple. For each mesh you have a header which defines the number of draw calls. The texture used, the vertices used and the faces for each draw call. Each draw call is linked with a bone which provides a position for the t-pose. And then for the animation for each frame, a (euler) rotation is provided for each draw call to define how the mesh moves. So even while the file is not is a very human friendly format, everything has a specific function and the layout of the file isn't too difficult once broken down. dae on the other hand is a pile of flaming monkey poo. So this is part of the example for a simple rigged mesh on the Collada's github page. So to add in weights (in addition to lots of other random crap), we have to define a source. What's a source you might ask? I have no idea either, I have no idea that rather than defining specific tags to do a specific function, they provide general tags and force the person writing the file to define absolutely everything. You have some stupid tag called a source, and then you have to tell the file that the id of that tag is the skin weights. So then you have to define the skin weights using a float array. And basically for each vertices, there is going to be a weight from 0 to 1 which defines how much a given bone affects that vertex when performing movement. But the problem is that .dae doesn't actually know what's going on, since all we did was define a source and an array. So the next tag is technique common? I have no idea. The complete existence of this tag is a mystery to me. If you just had an array tag, which provided some data and then an accessor tag which defines how to read that data, that would make a lot of sense. But that would be too simple, so the technique common tag is there to confuse you and add another level of indentation which no one ever asked for or needs. You then have to tell that accessor tag that the thing its reading is the id of the tag directly above it. So it's like a source tag provides some kind of data and there's a list of data, and an accessor inside and that's assumed, because that's the only way possible to do things in the file. No, you have to create id's everywhere and link all of the things with the other things to the point you have no idea which thing is actually being linked because of the need to slap an id on absolutely anything even when it's actually detrimental to the structure of the file and readability. And then you have to define a parameter, give it a name and define a type. And we wonder where god went to allow such an abomination of a file type to even exist. Because again, it's not like with a lot of these concepts there are very specific concepts that don't have a lot of guess work. Like look at the following. Would provide the exact same functionality and not require a dozen lines of redundant and meaningless tag clouds that all intermingle and reference one another when you could just have one tag, with one id that does something very specific using a functionality that works in a very specific way. Edit: Found the syntax to add bones, to Blender now recognizes there is an armature. Unfortunately it isn't linked to anything. Next I'll have to figure out the syntax to add a controller tag to define the weights for the mesh. Edit: I thought i was going to be able to move on to skin indices and skin weights tonight, but apparently .dae had other plans. For the armature syntax it looks liked all that needed to be done was order them in order from parent to child, so that children were listed inside of their parent tag, and then simply declare either there local or world transformation matrix, but something is going wrong and they're all just bundled up at the origin, so I'll have to try and find a model that I can compare what .dae expects, versus what I'm exporting to try and troubleshoot how it wants the values to be declared. Edit: Okay, looks like it's working now. I had to take the transpose of the local matrix. Next step is figuring out what I need to do for skinning. Edit: The mesh is now attached to the armature, so blender recognizes the mesh and bones as one hierarchy. Next step is figuring out how to add indices and weights. Edit: Spent some time adding in the inverse pose matrix, only to find that I don't need it? The file type definition doesn't do a very good job of describing the values of the matrices that it wants there. Which there are only so many values it could be, either the inverse of the local matrix or the inverse of the world matrix. After looking through the Collada loader code for Threejs, i found that it passes these values directly into the skeleton as the value for the boneInverses attribute. So going the other direction from Threejs to Collada, it looks like I can just use these values directly. Though after writing the values to a file and loading it into Blender I found absolutely nothing changed. Which I thought was weird so I put in values that are definitely not right and tried again and no change again. In terms of threejs, if the boneinverse values are not included, they are simply calculated by the library. This could be the case with blender as well, since it really doens't make too much sense to include a value that ca just be calculated from the bones. Why read a value from a value that could potentially be wrong when you can just read the transformation values from the bones (which you know are correct) and then just calculate the inverses yourself. So right now it looks like these values don't have an effect, but they are referenced later on in the file. So I'll have to do more testing, since I don't think these values will really come into play until I start adding in animations. So for right now even if I'm not using these values, I figured it's better to have an idea of what's there and identify it as a potential point for debugging rather than risk jumping over it completely and not knowing why stuff doesn't work. In terms of testing I might be able to load a file into blender without the pose, then export the model and see if blender includes its own calculated values in the export. Then I'd be able to compare the values I have versus the ones provided. Otherwise I can just use trial and error to see which values are included. But for right now I'll skip over it and see if I can add in vertex weights without the pose matrix. As for the weights, the syntax doesn't look too bad. It looks like I need to declare a list of weight values to be referenced by index. In this case since only a single bone affects any given vertex, that value will always just be 1.00. Then I need to declare a list of how many bone weights apply to each vertex, which again is only one. And then from there provide a list of indices for which weight and which bone is pared to each index. Which should just be a list of 0 0, 0 0, 1 0, ect. Basically pairing a single bone to the 1.00 weight index at 0.
Bump for visibility. Model viewer now supports rigged .dae and texture export.
|
|
|
Post by xinus22 on Mar 14, 2018 5:00:22 GMT -5
Have i already said that you are freaking amazing? i'll say it again. Kion you are freaking amazing! now we need the same but for MML2 and you will became MML hacking god.
|
|
kion
Arukoitan
@kion_dgl
Posts: 193
|
Post by kion on Mar 14, 2018 10:14:26 GMT -5
I have some more cleaning up and testing to do with MML 1. I'll see what I can do with MML 2 from there.
|
|
Trege
Poh
oro?
Meddling with Legends 1, Legends 2 and Mega Man 64 data.
Posts: 463
|
Post by Trege on Apr 6, 2018 9:16:56 GMT -5
I have to say I'm sorry I didn't see your threads sooner, I really need to check the forums more often, but man this is some amazing work right here. Those models could easily be used for projects now. Ugh I feel like I should slap myself now for slacking off so much on checking back here.
|
|
|
Post by Avegodro on Apr 11, 2018 18:10:34 GMT -5
I read through the thread twice, a majority of everything was over my head since I only dabble in a little art now and then. This is some amazing work thus far Kion, I'm glad to see this project.
|
|
|
Post by blayze16 on Apr 22, 2018 5:32:05 GMT -5
I'm impressed with the work you have been doing! May I ask where are you getting these assets? Are they from the PS1 or PC version?
EDIT: Also if its possible to edit these models, would someone add a smile to Roll's model? She really needed to smile more in this game.
|
|
kion
Arukoitan
@kion_dgl
Posts: 193
|
Post by kion on Apr 22, 2018 8:44:53 GMT -5
I'm impressed with the work you have been doing! May I ask where are you getting these assets? Are they from the PS1 or PC version? Models and textures are from the PSX version. You can access them too if you goto mml.dashgl.com/anims/, click on "Upload" and select all of the files in the "DAT" folder on the PSX disk. Xinus22 has also made several models available on Sky Pirate Arcade: arcade.legends-station.com/?sp=resourcemodelsCheck around for modding threads on this forum and potentially try bribing someone, maybe?
|
|
|
Post by murdertrain7848 on May 18, 2018 10:51:07 GMT -5
Hey guys. Y'all are doing an amazing job. I love this game so much (big shocker right). I wish I knew more about how to mod. Maybe I could help. So, is anything finished that we could use now? I have the PS1 and PC version. I also might have some ideas if anyone's interested.
|
|
|
Post by uradamus on Oct 16, 2018 19:49:31 GMT -5
So glad to have found this project. Unfortunately it only partly works for me. I can load my bin files just fine and the models get listed when I pick a bin and when I select a model I see its armature in the display, but I'm not seeing any textures nor most of the meshes (a very small portion of models show up with that flat normal map looking appearance I saw in a few of the earlier screenshots in this thread.) I can export to .dae which will import into Blender, but again with no textures, but the armature is included and working just fine.
I don't know if this is related to me using this on Linux or not, but I did notice when I took a look at the source files that all the lookup addresses used the windows-style backslashes, in the paths for all the texture and palette locations, instead of the standard forward slashes. I've done my best to avoid JS when possible, so I don't know if that's actually an issue or not, but it was the first thing to catch my eye with a quick overview. Though it would make sense if it couldn't find the files because of issues with the paths that I wouldn't have that stuff being displayed. Also when I try to use the export image option I get just a blank alpha image, which again supports the idea that it never got around to properly loading any images in the first place, so it has nothing to write to the output.
|
|
kion
Arukoitan
@kion_dgl
Posts: 193
|
Post by kion on Oct 17, 2018 20:59:47 GMT -5
So glad to have found this project. Unfortunately it only partly works for me. I can load my bin files just fine and the models get listed when I pick a bin and when I select a model I see its armature in the display, but I'm not seeing any textures nor most of the meshes (a very small portion of models show up with that flat normal map looking appearance I saw in a few of the earlier screenshots in this thread.) I can export to .dae which will import into Blender, but again with no textures, but the armature is included and working just fine. @xinus2 brought this to my attention on discord. It looks like I was stupid and used "ctx.drawRect" instead of "ctx.fillRect" for rendering the images for the textures. Which is maybe because the browsers left this function definition in the Context2D api, and then recently removed it in an update? Hopefully it's a simple fix, I'll try updating the page tonight. I don't know if this is related to me using this on Linux or not, but I did notice when I took a look at the source files that all the lookup addresses used the windows-style backslashes, in the paths for all the texture and palette locations, instead of the standard forward slashes. I've done my best to avoid JS when possible, so I don't know if that's actually an issue or not, but it was the first thing to catch my eye with a quick overview. Though it would make sense if it couldn't find the files because of issues with the paths that I wouldn't have that stuff being displayed. Also when I try to use the export image option I get just a blank alpha image, which again supports the idea that it never got around to properly loading any images in the first place, so it has nothing to write to the output. The file references are internal to the .BIN archive files in the game. I guess the development team was using Windows or something, and they left the file references were left in there. I really don't like working with back slashes with files, and was tempted to use regex replace to force forward slashes, or even dashes, something that would be easy to use. But I figured it would be better to not to invoke "magic", where one thing is written inside export program, and a separate string entirely is found inside the game files. As for the files, only the .BIN files are stored with their base filename and extension are copied and stored inside IndexedDB. If you want to take a look inside the .BIN files, they're mostly just a way to loosely pack assets used together into a single file that can be continuously read from the disk. You can view the files using: xxd -g 4 <archive.BIN> | vim -R -
|
|
|
Post by uradamus on Oct 18, 2018 2:48:29 GMT -5
Wow, thanks for the quick reply. Glad to hear that it's down to something pretty simple. I'll be looking forward to seeing this in fully working order. I've been wanting to find a way to grab stuff from MML for ages now, it's been one of my all time favorite games and I've always really wanted to mess around with remaking a lot of the assets from scratch with higher fidelity, but always wanted to get the original models out for reference. I don't know if you are still planning to work on this further, but a .bvh exporter would probably be a good way to go with getting animations out into a useful format for import into stuff like Blender and the like. If you aren't familiar, .bvh is a very simple hierarchy based format where you create a reference with children bones nested within parent bones to define the armature structure followed by a section where you dump the ordered animation data. Here's a link that gives a decent overview of the basics: www.mindfiresolutions.com/BVH-biovision-hierarchy.htmOne thing I was wondering about - is there any plans to eventually have a way to view and export the assembled stages? I've been able to kinda get them from the Megaman64 version of the game using an emu with a vrml dumper, but that uses smaller/inferior versions of the maps due to the restrictions on the cartridges. Plus I hate the control scheme used by that, especially when trying to map it to a non N64 controller, which always leads to me giving up on trying to dump everything pretty early through a run. I did kinda find an interesting way to approach remaking maps in Blender though, with the help of a really cool add-on, SpryTile ( chemikhazi.itch.io/sprytile ). So it would be possible to just make a new tile atlas for each stage including just the important full size bits from the various textures to use with that add-on to allow for pretty quick recreation of the maps through side by side observation running the game in a PSX emu and pausing a lot. Would have to do a bit of guess work with adding slopes and hills to the outdoor field areas, but otherwise it would be possible to get very accurate results with minimal effort if it turns out that a more direct approach to ripping the stages doesn't become available.
|
|