[Coding] bf2 meshes python lib

[rPoXoTauJIo]

https://github.com/rPoXoTauJIo/BF2Mesh

Thing i've been developing for a while, using bytehazard reference and his direct help, initially started as a script to get textures names out of meshes.

I've been interested in what can i do with meshes directly without touching 3dsmax&re-export, so after tests on evil boxes i've attempted to merge kits geometries in single skinnedmesh:

So far that i'm not seeing reports on weird issues with canadian kits, merge been successful

Another thing i've been doing lately is trying to merge staticmeshes which is working so far:

However, in game it works a bit strange :



Apparently, if player camera doesn't see collision of object - it doesn't render it. As i've merged only visible mesh, and left object using stock collision, it's disappear once i look away from collision mesh.

Ultimate goal of this project is to make it automated script for mappers to merge their statics into bigger arrays, hopefully decreasing amount of drawcalls due to lego structure.
For now it's nowhere from being complete, and serves more of purpose me learning mesh structure, but by small steps i'll hope it will work flawlessly someday

[rPoXoTauJIo]

* Reserved for mesh struct explanation

[rPoXoTauJIo]

Some little progress on generating collision meshes.


Unfortunately, it's crashing editor for some reason.
For those mocked boxes i've set y/z/adata in collision lods to zeroes, but those are unknowns unfortunately.

[rPoXoTauJIo]

Works ingame, crashing when getting close to objects, weird.

[rPoXoTauJIo]

More weird stuff from exporter.



Technically those meshes should be equal in terms of vertex numbers(both 4 vertices & 2 tris for simple plane, it's just 2nd being with offset and smaller), but for "segmented" mesh there's additional strange faces:

face[2]: (0, 3, 3, 0)
face[3]: (3, 0, 0, 0)

Which corresponds to:

vertex[0]: -0.5, 0.0, -0.5
vertex[3]: -0.5, 0.0, 0.5
vertex[3]: -0.5, 0.0, 0.5

vertex[3]: -0.5, 0.0, 0.5
vertex[0]: -0.5, 0.0, -0.5
vertex[0]: -0.5, 0.0, -0.5

Makes absolutely no sense from geometry point of view for me

[rPoXoTauJIo]

So i disbanded idea of modifying colmeshes, as they doesn't seems to affect fps.
Merging visible meshes produced interesting results through.

Sample is T-city of 15x15 blocks, each 10 floors
1x housingblock_1_groundfloor_v2
8x housingblock_1_midfloor_v1
1x housingblock_1_topfloor

Starting fps would be ~50 on my testing machine(i7-6700hq + 960m)


For a test i merged merges meshes as follows:
Single mesh for all top&ground floors


Single mesh for blocks of middlefloors


Result were more than i expected, 50->180 fps.


===============================
shit code examples for anyone interested
https://pastebin.com/bQVYQuhK
https://pastebin.com/e23UXBeB
===============================
doc that i've read years later:
https://www.nvidia.com/docs/io/8228/batchbatchbatch.pdf

[Rabbit]

lightmaps will be shit

[AlonTavor]

lightmaps will be shit

y tho? why are they affected? aren't lightmaps just a 2d array of light-levels for the terrain?
or are you saying it'll take 20 years to generate them?

[Mineral]

Objects needs lightmaps too. One texture for each LOD. Which are all combined into atlas files. We have a maximum size limit of 2048 (can probably be 4096?) for out atlas files for lightmaps. Given you can't split a lightmap between atlas files it means that the maximum size for one 'object' is likely to be 2048 (or 4096). Using a single 2048 texture to lightmap extremely large combined statics such as one display here will end up looking rather crappy most likely.

But the T-Shapes are mostly a POC I suppose. Theoretically we could for example do it much better and for example perhaps split the maps into grids and merge them that way? Then a single 2048 'might' be enough.

I mostly worry about the filesize increase such a implementation would bring

[Rhino]

Ye this basically significantly cuts down the draw calls while the tri count stays the same and BF2 isn't very good at handling draw calls but still, not a realistic solution for most cases but there are some cases where combing objects into one objects is a good idea.

We have a maximum size limit of 2048 (can probably be 4096?)

I'm pretty sure you can go up to 4096 but would probably have to be done manually and I wouldn't advise it unless really necessary.


Also for merging all those buildings together means that when you get close to the edge of just one of those buildings, you will be drawing them all in LOD0 detail rather than only the nearest building/floor in LOD0 and the others drawing in much lower detail so for doing huge blocks like this isn't a good idea for that reason as a lot of PCs will really struggle with drawing all that high detail that the player can't appreciate since they are nowhere near the details to see them and will for some PCs, have a bigger negative impact than removing all the draw calls. So ye, I would limit how many objects you put together to really just one building, unless it was something like a surrounding terrain block of buildings that were already low detail to start with. There is also the small issue of losing the flexibility of having different types of floors done the original way but they are only different colours in the case of the T buildings, which are the only ones really to do this so not really much lost but ye, something to consider.

[Outlawz7]

This would be more useful for small, low-poly objects so you could have lots of details but very few drawcalls.

And yes, how do you handle lightmap UVs?

[rPoXoTauJIo]

Also for merging all those buildings together means that when you get close to the edge of just one of those buildings, you will be drawing them all in LOD0 detail rather than only the nearest building/floor in LOD0 and the others drawing in much lower detail so for doing huge blocks like this isn't a good idea for that reason as a lot of PCs will really struggle with drawing all that high detail that the player can't appreciate since they are nowhere near the details to see them and will for some PCs, have a bigger negative impact than removing all the draw calls.

I bet lods matter for crappy PC's only because they have less materials, so less drawcalls. I'm gonna tests on various crappy laptops anyway, but have a feeling even weak GPU wont be bottleneck.

So ye, I would limit how many objects you put together to really just one building, unless it was something like a surrounding terrain block of buildings that were already low detail to start with.

Main issue are stuff like Outlawz mentioned, my first aim is to reduce drawcalls from lots of small objects in small area. At the moment i'm selecting objects for merge by hand, but pretty sure will come up with some algorithm for analyze later.

There is also the small issue of losing the flexibility of having different types of floors done the original way but they are only different colours in the case of the T buildings, which are the only ones really to do this so not really much lost but ye, something to consider.

This could be easily done tbh - just have all textures packed in atlas, and have different UV offset on that atlas. But that's for later.

And yes, how do you handle lightmap UVs?

Didn't approached that yet, but i have full control over vertices parameters(everything you see in bfmeshview in vertex attributes, position/normals/tangents/uv's/etc), so i guess it's only a matter of properly recalculating them, if required.