• Overwatch Model Thread v4
    297 replies, posted
Are you ok?
what do you mean?
Cannot understand what you saying. As with all updates, it will take some time before the tools are updated to support it.
I am sorry, my mistake. Is it possible to "roll back" client updates Overwatch?
No, we actively encourage everyone who uses the tools to make backups of your Overwatch install so you can continue to use the tools until they support the latest version. You cannot rollback updates or download old versions of Overwatch unfortunately. We should hopefully have an update soon or in the next couple days.
Not sure if you guys have explained it before, but what exactly do you guys do when a new update comes out? Do you need to manually input the new item IDs? Do you need to rewrite part of the software to support the new items, or is it as easy as changing some key in the code to make it work? I'm genuinely curious as to how it works.
Every update to the game changes the encryption on the files required to read data from the game, until a new decryption method is generated, the tools cannot function. Also new content in the game is also 'locked' behind keys that are sent from the server which also have to be discovered. Sometimes they also change how the data is stored, this takes a lot longer to figure out and can require a lot of code changes.
An updated DataTool has been released Release Notes: Fixed a crash that can occur when extracting certain skins. Added alias support to extract maps command so you don't need to enter the exact map name for common maps. See below for more info. Notes: The map alias support works the same as heroes, this means you can type horizon to get horizon lunar colony or gibraltar for watchpoint: gibraltar. This is just a hard coded list of map names for the most common maps. Other maps will required you to enter the exact name, same as before. You can view a list of supported aliases here. Important: This feature only works when running in the English locale, other locales will not work. Toolchain: https://ci.appveyor.com/api/buildjobs/bfraa4ai7s78qohh/artifacts/dist%2Ftoolchain-release.zip Other Artifacts: https://ci.appveyor.com/project/yukimono/owlib/builds/21908424/artifacts
And maps, HLC doesn't crash when extracting anymore
Maya tools release 0.7.1 is now available. This version adds support for loading maps! It loads all geometry and supports the textures as far as the current material options go. The default scaling for models is now cm instead of inches. This is good so modeling now has the same natural units, but you'll need to compensate if you load animations. Let me know if you need help with this. Menu-selectable support for Redshift and Stingray texturing https://github.com/mayasombra/maya_ow_tools
The most current update would be nice, it doesnt have to be i just would like the current models and cant get them at all in anyway i try
Also I have finally been able to extract the maps but I am unable to load them into blender without it crashing. Can anyone help? I don't know what more information I can give other than Ive tried all the maps ive downloaded (dorado and Hollywood)
Did not expect this so soon, thank you very much! I've noticed that importing maps takes quite a while and I know that instancing in Maya becomes increasingly slow, the more instances of an object you have. I've tested duplicating the objects instead and saw a 4-5x speedup when importing Castillo. I think that might be handy for troubleshooting, so you don't have to wait 10+ minutes to see if everything worked. You can give it a try by using this version of instance_with_prs, found inside import_owmap. I'm not aware of any workaround to speed instancing up, but one idea to optimize the map importer could be to only instance complex models. Seeing how simple the game assets are, I don't believe there are any performance or memory gains to instancing. However instances are still handy to have in case there is an issue with a model to fix. So I would suggest to only instance objects that have more than for example 50 verts. That would filter out the hundreds of card-like objects that are unlikely to be needing any touchups anyway and significantly improve import times since those would simply be duplicated instead. Not really critical, since you only import a map once, but I thought I'd throw it out there :D Also, I found that importing Castillo fails when getting to a particular model. The error is: "# Error: KeyError: file bla\OWMImporter\import_owmdl.py line 304: Skeleton_0000000029AF|bone_0001 # " Importing that model by itself in a new scene works fine. I've also tried importing King's Row, which was successful. I've uploaded Castillo here if you want to check it out. When saving the settings and thus prompting that line to be written in the userPrefs file, after restarting Maya, the importer places locators instead of importing the models. I've checked the line in the userPrefs file and it correctly says "MapImportModelsAs=1". Don't know why it's not working but deleting the line when Maya is closed fixes it for now. Thanks again for your work!
Thanks for the duplicating suggestion. My understanding was that instancing is preferable because it lowers the load of holding the scene in memory. Your rationale makes sense, and I can experiment with that. I'd been playing with alternative implementations of instance_with_prs, which is why it's in its own function now. I'll incorporate your version into my experimentation. Most of the time when things in the original importer were slow, using the OpenMaya APIs resulted in big speed boosts. I saw that in my experiments, but it wasn't making big difference in my runs, and the code wasn't quite correct. Your machine seems to behave differently than mine. My experience was that most of the slowness was texture loading, and not the geometry. I'll add metrics and if you can share your numbers, that'll help. I'll look into the 2 bugs later this week; thanks for the feedback!
https://files.facepunch.com/forum/upload/380947/c5735746-783c-4541-ac98-0ab7da39d62e/image.png Ignore the top part but when I try and load Ashe's model into Blender it says this. PLEASE HELP
Thanks for the quick fix, it works fine now! =) Nah you're right, instancing is preferable to duplicating for those reasons. Actually, forget I said anything! :D Since you only import a map once, I don't think the time it takes is really that important. And the solution with only instancing some of the objects would just be confusing to users and could potentially backfire in a case where you do actually need to make adjustments to one of the models that didn't get instanced. Yeah, I can provide you with some performance numbers, just tell me how! Oh, I thought that name clashing was taken care of already, but it looks like that's what the problem was. I had a look at import_owmdl and the fix was really simple. Just goes to show how clean your code is! :D change line 304 to jidx = jointLookup[boneName.split("|")[-1]] and line 228 to cmds.rename(meshshapename, "%sShape" % meshName) The first fixes that key error I also encountered in Castillo and the second takes care of giving each shape a unique name by using the unique name of the transform node instead of the base name. After this, all maps I've tested imported correctly. Importing the same model multiple times works too now - even if they have skinclusters assigned, they all work as they should. I noticed that none of the maps seem to import objects with skinclusters tho. Are those the OWEntities, that aren't supported yet? I guess it's a bit messy with the shapes and transforms having unique names and the bones all having the same name, but it works and I prefer this over namespaces tbh. In a professional pipeline, namespaces are probably the way to go, but I don't think that level of organization is needed here. Instead they'd just clutter up the interface and be annoying when we deal with namespaces of our own. I think this works just fine!
Which model file are you trying to load?
I was trying to load the winter skin for ashe, it was happening to all of the new models, but it turns out the blender addon for overwatch models needed to be updated. I also finally got dorado to load, but many of the other maps wont, and Im not entirely sure how it goes for coloring the maps? Its just wireframes.
It looks like you have an older version of the Blender tools installed, based on the information in your screenshot. I've verified that the Ashe (and BoB) models load with the latest version of the tools. If you update your tool versions and still have problems, please reply and include the following the exact filename you're trying to load (I'm guessing 89C0.owmdl) the stack trace (which your original screenshot included)
hey there! i was wondering if i could get a hand with importing some maps see, i updated the blender plug-in to the latest version. i can import some maps, but it seems totally random and i have to wait a really long time for anything to load. half of the time, it just straight up freezes and never loads in the model for the maya plugin (thank you very much for updating it, mayasombra!) for 4 maps i tried it says "unrecognized file type" and for the one where it didn't send this error (eichenwalde halloween) it just doesn't load anything at all
update io_scene_owm
Maya tools release 0.7.2 is now available. This version continues adding support for maps. There's now mostly complete support for OWENTITY files. This allows maps to load complex objects like Pachimari UFO catchers, cars, etc. into the map. What's missing is how the entities are connected via "hardpoints" because I don't understand it yet. Improved error handling for loading maps. One error won't break the whole load, but just skip that object. Fixed bugs around duplication of materials that made it hard to load maps. This version doesn't create extra materials. UI options menu support for the maps loader is now complete. Options actually do what they say! Future work will add the control options for model loading. I've tested this out loading Busan, Eichenwalde Halloween, Hanamura, and Blizzard World. If you find a problem, please let me know exactly what file caused it and the output from the console. This version should be pulling in all the understood data. Shaders are a work in progress, but you should have almost everything you need to use maps. If someone can explain, preferably with an example, how the hardpoints are used in a map, I can get that support done pretty quickly!
@naomi thank you so much for telling me about the console, i thought my blender was breaking everytime and my computer wasn't strong enough to handle it @mayasombra i'm really sorry for the confusion. it turns out it was entirely on my end, i thought it added the overwatch file types to import/export like it did on blender and was importing through mayas default system, it took me a while to realize like a dummy that it had a separate tab that imported it. all of them were working fine now that i'm doing it properly!
Yeah, the original code worked like a more traditional importer, which is what you were expecting. I had to migrate to this approach to work around a bug in Maya that Stingray shaders can't be created from an importer process. That's why the import has to run in the UI thread, so it can make those shaders. This does result in some confusion, and the complete freezing of the UI while it's running.
Working on Blender 2.8 support. Got model importing working, doing a test now on map importing. https://files.facepunch.com/forum/upload/116730/bd628532-23de-4729-9c11-34e34618478a/20190210083626.png https://files.facepunch.com/forum/upload/116730/281c7a61-6cfa-4e5a-86bd-5107ff359678/20190210131542.png Blender 2.8 has a ton of API changes so I had to drop 2.79 support. I'll be maintaining feature parity between 2.8 and 2.79 but I will not be fixing bugs with 2.79 once I release the addons for 2.8. SEAnim support will either be dropped and directly integrated into OWM, or it will be updated for 2.8.
https://github.com/overtools/io_scene_owm/archive/blender-2.8.zip For those who want to use the plugins now. Warning: It's unstable, animation importing definitely doesn't work yet. Model and map importing should be OK though. https://files.facepunch.com/forum/upload/116730/fe3fe5d0-505f-4e06-9678-7d1cc00967a6/20190210145627.png
I've stated previously that the update for io_anim_seanim will be released after the first stable release of 2.8.
I had code that allowed the imported skeletons to work in 2.79b. If you want, I can take a shot at it with the 2.8 code, allowing you to focus on other things? The workflow of deleting and reimporting the skeleton was clunky, and there's no good reason people should have to do it. It's a fixable bug and I'm offering to fix it. Also, I second the sentiment from SE2dev. Once the scaling constant is addressed in 2.8, rolling back the scaling hack in DataTool and using the SE tools for SEAnim will be consistent across Blender and Maya, the two tools with active development. Having them work similarly would be nice.
The sentiment being wait until 2.8 is released? There's no point. Half of the point for the beta is for addon authors to update their addons. Blender 2.8 Beta — Blender Developers Blog And sure, feel free to fix the code. As far as I can tell looking at the blender mailing lists all mesh and skeleton APIs shouldn't change.
I agree waiting for 2.8 isn't a great idea. The best idea I've come up with would be to introduce a command line flag for the scaling behavior of SEAnims. The default value of the flag now should use the 2.54 scaling to preserve the current behavior. Maya users and anyone who wants the new 2.8 behavior ahead of time could set the flag to a 1.0 value and then SEAnims would work in those contexts. When the new version of SETools drops undoing the scaling constant, the next DataTool release could change the flag default value to 1.0 so everything works "out of the box" with the latest version of tools, which is consistent with messaging in the forums. Then in a month or so, the flag could be deprecated and removed. If you're OK with this approach, I'm happy to make the changes. I'll send you a PR for the skeleton stuff soon, then.
Sorry, you need to Log In to post a reply to this thread.