DragonFF
DragonFF copied to clipboard
Parik27
Map import collisions
Hi there. I'm looking to add collisions to the map importer here. As well as a convenient way to mass export back to their container files. The map collisions are stored in a series of col files inside gta3.img but I just look for them in the dff extract folder. I think the commit comments explain it well enough but here are a few screen shots. Anyway I'm still new to collaboration on git so I just wanted to start a discussion on this while I worked on it.
Here's the shortcut to export all collisions back to their container.
And here's a map piece with its collision sitting on top of it (and z-fighting). The collisions are hidden on import, but you can edit them in-place this way.
I'd also like to re-arrange each map section to a top-level collection named for the ipl file from which it came. That will organize the scene better. What do you think?
This last commit was kind of a pain. So previously I was just loading the .col files that shared a prefix with the current region, but that left a lot of collisions out for anything generic or (I'm only assuming here) xref. So now it looks through all IPL instances and loads every referenced collision file first. This will have a heavy initial cost but subsequent loads for sections of the same region would obviously have their collision loaded already. Unfortunately with the way Blender performs scene updates around operators, as the number of scene objects grows the scene updates become increasingly expensive. To get around this I'm increasing the number of objects loaded at a time which comes at the cost of responsiveness, but significantly decreases overall load times. Obviously I'm open to any suggestions on how to improve this either on the Blender side or the GTA asset side. It might even be better to skip the timer altogether and just brute force load at the UX cost of an apparent (but not actual) total freeze while the import occurs.
Last few commits included changes to better support import/export of .col files with all of their features. By using Collision File Editor II and comparing stock .col files with versions exported with the addon, it appears they are similar enough that nothing is really lost now that face groups, empty collisions and bounds calculations are more accurate. There is no cone support, but CFEII doesn't seem to support that either? There will be differences in how bounds are calculated, and from what I've seen it appears a collision's overall bounds was being manually set in the stock files as some collisions have bounds that are not tightly fitted to the underlying objects. Collisions exported with the addon will be tightly fitted and I think that is probably better anyway.
@Parik27 Ok. I think this is pretty close if you'd like to give it a review. While I have ideas on how to expand the map importer more in the future it currently does what I need it to and these changes are pretty much focused on the original topic of map collisions. I would like to add some info to the wiki as well.
I'm working on the face groups feature for collision objects. I really don't know how important face group optimizations remain for running physics calculations on hardware that's 20 years newer than the release of the game, but as I'm intending to add lots of polygons to the map I think it might be useful. Here's a pic:
And here's another showing the unfortunate z-fighting that really starts to crop up when further away from the origin:
I'm not sure if it can be improved but any ideas are welcome. Seems from my own research to just be a consequence of Blender's handling of depth buffer precision. It's at least good enough to visualize the resulting face groups.
Okay I think this is ready to merge. I added some settings to adjust face group generation and I think it's pretty versatile now.
I'm not sure how much time I'd be able to spend on it in the next couple weeks if I did think of anything, but I'll probably like to revisit it at some point. Especially the shader for face group display which still has too much z-fighting. And I need to update the wiki to explain how to use this if that's okay.
Yep. Go ahead and merge it. I'll look for any issues that might arise but it's up to a good state right now I think. Could I have access to the wiki for documentation?
Yep. Go ahead and merge it. I'll look for any issues that might arise but it's up to a good state right now I think. Could I have access to the wiki for documentation?
Wiki write access is not restricted to collaborators. You should be able to make changes.
It seems that the way to export dff files has been changed. Seems like it will just export collections ending with .dff. What was the purpose behind this change? It makes it really confusing for normal users that do not use the map features.
Agreed, that is confusing. Sorry but this never came up as I was only dealing with imported assets when I tested, nothing original. It has to do with a change to support nested collections (which, originally didn't export at all which seems counterintuitive also imo). I'll post a fix later today after work. Sorry about that.