This is a read only copy without any forum functionality of the old Modcraft forum. If there is anything that you would like to have removed, message me on Discord via Kaev#5208. Big thanks to Alastor for making this copy!
Thanks for the suggestions. Indeed, the situation described is what I'm aiming for (using just the exterior geometry of some WMOs to fast-build lots of walls, walkways, etc). I think, on balance, custom M2s are the answer.
Scy
There is a problem with that too actually. M2s do not have a server navmesh suitable for that purpose on the current cores. So, NPCs, spells and everything is likely to go trough M2s as it works a little bit different than WMO. As for what I know, right now M2s are only used for pathfinding to compute the path of NPC around the object, not on it or in it. However, with some navmesh generator and core modifications, it is possible to achieve what you want. The example video is here:
WMO is simply not meant to be an M2 and vice versa. Besides geometry, WMOs contain vertex colors, portals, group types, lights, fogs, different batch types, bsp tree, convex hulls and more. On the other hand, m2s contain more simple geometry, animations, events etc. So, I don't recommend you doing that. If you just want to make a model smaller, you can use Blender to downscale a WMO.
Just look at custom WMO tutorials. It might not be on this website, however, you will definitely find it on google. You'll need to use Blender for conversion, though. There is no WMO plugins for Maya. But modelling in Maya would work if you prefer that.
Hmm, I think it is a weird idea to remove them. I often use the Load all tilesets function, so that it loads all the existing texture files. Then I remember I saw some required tileset in some zone and I use that filter. Could I reload Noggit? Yeah, possibly. Though why should I do it if there is a filter?
As much as possible is already multithreaded, but the problem is that most operations cannot run in parallel, each being totally dependent on the result of the last. The issue is simply one of bytes. One ADT requires 37120 floating point heights, 4194302 bytes of alphamap information, other data besides. For 12x12 ADTs this came to over 625 million bytes being manipulated or stored for each layer of work (I had five per ADT). Few machines can cope with that.
I am working on a code cleanup, which is freeing quite a lot of memory, some compression of data, moving a few routines around, and this is all helping. I don't think I'll get back to 12x12, but 8x8 is working well and quickly.
Well, if it does not run in parallel what is the problem then? Let's say on a powerful PC it takes 1 minute to generate the map, on a weak one it takes half an hour. If stuff is managed properly and the memory is freed when necessary, the app is not gonna crash because it is weak PC. It will just take longer to get the result.
Ok, some success with alphamap support, but there is a major snag... The immense quantity of data held by the tool for 12x12 ADTS (4.8 million heights per ADT, 4 million alpha values, AreaIDs, GroundEffects, etc) has resulted in a very slow tool that only works on high-spec machines. Even with a monster PC, it grinds to a crawl. As such, I have been forced to reduce the map size to a more manageable 4x4 ADTS (one ninth of the original area). Of course, it will remain possible to tile multiple sets of 4x4 to make larger maps (although there may be seam problems between maps if heights are not carefully managed), but the working area had to be scaled down.
Edit: OK, got it back up to 8x8, which is much more useful. I did this by reducing the 'undo' steps to just one (the last operation) and by squeezing some data that was stored in multiple integers as flags (a single byte).
You need to do some task through multithreading. It wil increase the capacity of the tool in a really big way. I assume even larger maps will be posassible to get generated.
Show Posts
Ok, some success with alphamap support, but there is a major snag...