Open gomtuu opened 5 years ago
Note that this will have to be a migration - it's extremely impractical to the level of basically impossible to have the same code base work in 2.80 and 2.79.
Hi, Is the version for Blender 2.80 still in development ?
Sorry to say this, but I haven't worked on this project in over a year. I never really made an attempt to upgrade it for Blender 2.80+. Maybe some day, though!
Maybe I could try it too, since I did some work on this addon in the past, and recently made a from scratch 2.80+ importer for Dishonored 2. Of course, it's a question of time and motivation...
P.S. Doing the conversion could be fun though, because it would allow implementing generation of Eevee and Cycles materials that replicate the game look more closely - I did some experiments on designing such materials a year ago or so, but they are, obviously, based on nodes, and require 2.80+.
Ok, I will use blender 2.79 for the moment.
So, I converted the addon to 2.83 on my computer, but the material side needs some more work so I'm not uploading it yet.
@gomtuu Btw, how exactly did you investigate the meaning of the material data? It seems the flags are not always interpreted correctly, and there are a lot more unknown fields in the structure, so I want to try to have a look to see if I can figure out more myself.
@angavrilov That's great! Thanks for doing that!
Are the materials any worse than they are in 2.79? If not, I don't think that should hold up the 2.80+ release.
To figure out the materials, I just tried to find examples of materials that didn't look right, then compared their data to other materials. Trial and error, basically. It was frustrating, because sometimes the material data didn't seem to correlate with the way the materials needed to be rendered.
I saw your pull request with the normal map detection hack, and while that's not a bad idea, I thought I'd rather try to use that method to do more reverse-engineering so a hack wouldn't be required in the importer itself. But then I never got around to it. That's why I never accepted the pull request. (Sorry.)
I have a script called valk_ls that iterates through all the files you pass it on the command line and recurses through their sections, producing various output depending on which functions you call. One of the functions prints VC4 material data in a concise way (one material per line) to make it easier to compare different materials. It's pretty ad-hoc and rough, but maybe you'd find it helpful?
Of course, with VC1 and VC4 both on Steam, another option would be to edit the material data for a known model and see what happens in-game. I haven't tried that, though. That'd be easier with VC1 than VC4, because VC1's files are all separate and uncompressed.
Since that material 'flags' thing didn't make a lot of sense, I did a bit of poking, noticed the system/shaders/WIN/*.shbin files, searched in the game executable, and found a lookup table listing the names of those files: https://pastebin.com/hdypAMVt It seems the 'flags' field is actually just some kind of 'shader id' to be referenced in that table, and although there certainly are certain patterns, the assignment of the values is definitely not based on bit flags.
Ah, that makes a lot of sense! I wish I'd thought of that. Totally explains why there were patterns that held for some models but not others.
So here's what I've got, but I'm certain VC4 support is broken because I didn't even test it (currently don't have it installed, or the necessary free disk space): https://github.com/angavrilov/import_valkyria/tree/blender-2.8
P.S. I could send you some scripts for disassembling those shbin files if you want.
Thanks so much! I'll try to take a look soon. And sure, the disassembly scripts sound interesting.
Well, I finally got around to sorting out VC4 and pushed the code into the branch. VC4 was also using a 'shader id' field, although there it was a 64-bit hash of the shader name rather than an arbitrary number. I tested a majority of characters and maps and it seems to work OK. There are a lot of material fields of unknown purpose, and the logic for deciding which alpha mode to use is a lot of quesswork that doesn't work that well in VC1 maps especially, but that's nothing new. I also added a few features to reduce memory usage, since I had trouble running out of memory when testing some maps.
The
import_valkyria
add-on will need to be updated to work in Blender 2.80.