Here's a small update. I've been working through the BSR files a little because you have to use those files to get the BMS entries. I found some useful information that would easily allow for a rough dimension extraction from BSR files without having to go through the BMS files themselves. This dimension data is simply a AABB (axis aligned bounding box).
There are good things and bad things about this data. The bad things is that it's simply a maximal volume bounding data set, so objects will appear larger than their collision field might actually be. The good news is that it's ok since you couldn't feasibly generate a collision mesh efficient for player interactions unless you implemented your own model loader and had some simple physics for ray casting, so it all works out.
This means you can get the position of any BSR group (BSRs are like nodes of meshes) and get the dimensions that the total node takes up. You could then perform some secondary post processing on the data to change the size if it's a type of object you know will be too large, such as trees. Trees are huge and in game only their small trunks are collidable, so for any tree you can just use a fixed size that would best estimate the real size.
Here are some screenshots with the entities drawn to their AABB with trees set to a fixed size of 50 x h x 50. In addition, the entities are (should be) properly rotated to correspond to their in game rotations, which is very important!
[Only registered and activated users can see links. Click Here To Register...] [Only registered and activated users can see links. Click Here To Register...] [Only registered and activated users can see links. Click Here To Register...]
Some of the buildings look wrong, so I have to double check some things. Originally, my coordinate system was flipped, so I have to go back and change how everything is rendered to get it to correspond correctly in game. For example, when you are in South Jangan looking out from town, the hill that is on your right in game was on the left in my original images. My layers are backwards as well.
Another issue is that since there are so many BSR files and it's relatively expensive finding entries based on their files names, what would be more efficient is simply going through all BSR files and saving their name and dimensions into a new data file rather than trying to read in real time from the PK2s. Trying to do it in real time adds like 30s - 60s for each region load and that's just horrible. Using new data file loaded into memory would be a lot faster.
Lastly, since the AABB data is just a bounding volume around a group of meshes, the information is better used to help avoid collisions or get "unstuck". Trying to use it all to create some automatic path finding system and dynamic collisions avoiding system in real time seems really impractical now. There is just too much data and you would need to make an offline program that would generate binary data for your program to use so it's more memory and processing efficient.
But even so, the rough data is "good enough" to draw on top of your 2D minimap and create tools that allow for path generation while being able to see obstacles to avoid! For now I need to redo the coordinate system used and figure out some minor inconveniences. I don't have plans on parsing the entire BSR files because you only need them if you wanted to properly render all the BMS files, and the BMS->OBJ tool has some bugs in there which would indicate a rewrite is needed to handle some extra cases. Something I'm not going to spend the time on now.
Right now, terrain height + nvm layers + entity positions + entity AABB is certainly "good enough" for making more advanced pathing and collision avoidance systems, so we can make the best of this stuff. ;)
There are good things and bad things about this data. The bad things is that it's simply a maximal volume bounding data set, so objects will appear larger than their collision field might actually be. The good news is that it's ok since you couldn't feasibly generate a collision mesh efficient for player interactions unless you implemented your own model loader and had some simple physics for ray casting, so it all works out.
This means you can get the position of any BSR group (BSRs are like nodes of meshes) and get the dimensions that the total node takes up. You could then perform some secondary post processing on the data to change the size if it's a type of object you know will be too large, such as trees. Trees are huge and in game only their small trunks are collidable, so for any tree you can just use a fixed size that would best estimate the real size.
Here are some screenshots with the entities drawn to their AABB with trees set to a fixed size of 50 x h x 50. In addition, the entities are (should be) properly rotated to correspond to their in game rotations, which is very important!
[Only registered and activated users can see links. Click Here To Register...] [Only registered and activated users can see links. Click Here To Register...] [Only registered and activated users can see links. Click Here To Register...]
Some of the buildings look wrong, so I have to double check some things. Originally, my coordinate system was flipped, so I have to go back and change how everything is rendered to get it to correspond correctly in game. For example, when you are in South Jangan looking out from town, the hill that is on your right in game was on the left in my original images. My layers are backwards as well.
Another issue is that since there are so many BSR files and it's relatively expensive finding entries based on their files names, what would be more efficient is simply going through all BSR files and saving their name and dimensions into a new data file rather than trying to read in real time from the PK2s. Trying to do it in real time adds like 30s - 60s for each region load and that's just horrible. Using new data file loaded into memory would be a lot faster.
Lastly, since the AABB data is just a bounding volume around a group of meshes, the information is better used to help avoid collisions or get "unstuck". Trying to use it all to create some automatic path finding system and dynamic collisions avoiding system in real time seems really impractical now. There is just too much data and you would need to make an offline program that would generate binary data for your program to use so it's more memory and processing efficient.
But even so, the rough data is "good enough" to draw on top of your 2D minimap and create tools that allow for path generation while being able to see obstacles to avoid! For now I need to redo the coordinate system used and figure out some minor inconveniences. I don't have plans on parsing the entire BSR files because you only need them if you wanted to properly render all the BMS files, and the BMS->OBJ tool has some bugs in there which would indicate a rewrite is needed to handle some extra cases. Something I'm not going to spend the time on now.
Right now, terrain height + nvm layers + entity positions + entity AABB is certainly "good enough" for making more advanced pathing and collision avoidance systems, so we can make the best of this stuff. ;)
