B Documentation 3D [Disc] Combine Low Poly Meshes + Crashing

[Leonion]

Alright, it may not be a revelation to you, but these random crashes during battles (my PC can easily handle a battle with 350 soldiers wearing 4k+poly armor without lods, but sometimes it suddenly crashed in much smaller battles where all soldiers wore lod-ed simple armor) have been giving me one hell of a headache during the last year, completely killing all the desire to keep modding, and now I just stumbled upon somethings that seems to cause them:
"COMBINE LOW-POLY MESHES" checked in material settings in Openbrf. With regular 720 it looks like 80720.
PURGE DIS CHECK WITH HOLY FIRE WHENEVER YOU SEE IT.

First it was an infamous twilight horse from spak_meshes OSP that constantly caused crashed in Perisno until I changed its lods (with different lods it usually - but not always - didn't crash), but today I have been editing amade's OSP and among other things changed the lods (made them in Blender). I launch the game to see if new lods look OK, and bump - it won't even let me enter a mission, it just crashes immediately. Three times I restart the game and three times it crashes. Then I examine the armor, uncheck the darned option, and voila - everything works like a charm.
I go to see if the twilight horse has the same setting (btw, in its case lods made in openbrf caused crashes, so it's not about Blender messing up something) - and of course it does!

SPREAD THIS WORD, BROTHERS AND SISTERS!
___________________________________________________

Now, jokes aside, I don't usually create such "attention whore" themes (and even bark at people who do), but in google quote search I found no mentions of "combine low-poly meshes" and neither did I find them here by using this forum's search engine, so I assumed it may not be a well-known thing.
And those crashes have been really maddening me, so if this thread helps even at least one person and saves them from going insane like I almost did, I'm willing to take this chance.
Thank you for your attention.
___________________________________________________

UPD:
Another cause of random crashes found: empty collision meshes.
This time it was my mistake - game reported missing collision meshes for a couple of bushes (but without them it was doing fine, as it seems, no mesh? no problems), so just to get rid of them I added empty collision meshes for them (since I didn't want small bushes to be "collidable"): just  bo_bush_blablablah entries with no polygons inside.
This started to cause regular (like 1 crash for 4-5 successful loads) random crashes while loading a battle scene and cost me several hours of my life to find the source of the problem.
This change was literally the last suspect among the changes I had done recently. I'd never expect a game to be unable to properly handle just a simple empty object.

UPD 2:
Another reason for ctds.

 

[NPC99]

Congratulations on cracking your problem & thanks for the heads up. I'll review my material settings.

 

[Gasset]

Thank you for your service fellow Blader.

Spoiler

 

[mtarini]

Interesting find.

I was notified of this thread so I came here. In case it helps, let me add what that flag might be doing.

It is just a guess really, but, if the flag does what its name suggests (which might be or not be the case, plus, the name could be wrong or outdated) then a likely interpretation is as follows:

Flag set = "Dear game, please activate this optimization for all meshes using this material:
when they are seen from afar, and you would normally use lod (say) 3, then do use it, but, when there's many of them, don't draw them one by one: instead, combine them automatically in a single unified bigger mesh and draw that mesh once instead, in place of all the tiny ones."

(the results is that the the same set of triangles are drawn, but as a single "draw call", not many. Reducing the number of "draw calls" can save a lot of time and so it is a good thing. But, it also imposes limitations: you now have to draw all the objects or none; for example you cannot skip the ones which happens to be offscreen anymore; plus, the objects cannot move any longer with respect to each other.)

Here is a scenario where this kind of optimization is almost a necessity: say you have a mesh for some vegetation. At LOD0, it is fairly detailed, but at LOD4 it is maybe just a few polygons, maybe as few as one or two. Does this mean that you can afford to have like hundreds of them, or even thousands, far away in the background? Well, drawing a few thousands triangles is certainly not a problem, but making thousands calls (each wasted to draw a few triangles) is. Most of the GPU time is lost in overheads. To fix this, that flag (from what I can be inferred by its name) would create a single mesh featuring a few thousands one-or-two-polygon plants, for the entire vegetation of the current scene.

The unification process is done by the game and many things might go wrong with it, hence the crashes  (maybe). Maybe that flag is not supposed to be used in conjunction with something else, eg. maybe it shouldn't be used with skinned mesh, or who knows. It certainly cannot be used with meshes that are supposed to be moved independently from each other inside the scene.

 

[NPC99]

....It certainly cannot be used with meshes that are supposed to be moved independently from each other inside the scene.

I'm glad you're still with us. OpenBRF is an invaluable tool we all rely on.

 

[Leonion]

There is certainly some kind of "hole" in the procedures that process what this flag is doing.
Like there is a certain kind of mesh structure it cannot process correctly, and it does not depend on general settings like skinned or not.

With original twilight_horse lods it always crashed when a certain lod was loaded (lod2 or lod3, afair) - i.e. an NPC used this horse and moved far enough from the player. However, players could use this horse safely.
With updated lods that were created in Blender it crashed sometimes - direct tests (i.e. entering a mission and just moving in the opposite direction from my cavalry, until all lods are loaded) didn't cause this, but still battles where riders, that used twilight_horse, participated sometimes crashed.

Amade's OSP items seemed to work fine until I changed the lods of body armor, and then it started to always crash whenever I entered a mission (I guess lod1 turned out to be "incompatible" with this setting).

Also amade's armor lod1 is more high-poly than twilight_horse's lod1 (which, afair, was working fine, unlike low-poly old lod2 and lod3), so these meshes don't have in common a large amount of polys.

So this setting kinda "hates" only particular meshes - like, I dunno, maybe it doesn't like when a mesh has an even number of vertices and an odd number of polygons, or has a vertex that is connected to 11 other vertices - something of that kind, I think... like some relatively rare kind of mesh structure was overlooked in the code.

 

[mtarini]

Yes, debugging is usually hard, even when you have the source code and tons of tools. On a closed box exe, it is hopeless

So this setting kinda "hates" only particular meshes - like, I dunno, maybe it doesn't like when a mesh has an even number of vertices and an odd number of polygons, or has a vertex that is connected to 11 other vertices

Who knows, that might well be the case, but let me offer a different hypothesis:
guessing from my interpretation above, this flag only makes sense for static objects, i.e. scene-props and little else. And it is only really profitable for objects which are repeated plenty in a scene, and are individually small (polygon-count wise), like plants and other background elements. So it is may well be that this is the expected case: scene props, and something unexpected goes wrong when it is used on other things, like horses and armors (which do change position with respect to each other all the times).
If that is true, then the vanilla brf should be found using the flag accordingly.

Keep in mind that when "something goes wrong" you are usually not guaranteed a crash: the game just uses a dirty part of the memory and anything can happen, from immediate crashes to nothing at all, or even long delayed crashes. Debugging is hard

 

[Leonion]

In Native this flag is used for weapon and shield lod materials.

 

[produno]

In Native this flag is used for weapon and shield lod materials.

I noticed this but these items do not have animations, the horse does. Maybe that's the issue.

 

[Leonion]

Another cause of random crashes found: empty collision meshes.
This time it was my mistake - game reported missing collision meshes for a couple of bushes (but without them it was doing fine, as it seems, no mesh? no problems), so just to get rid of them I added empty collision meshes for them (since I didn't want small bushes to be "collidable"): just  bo_bush_blablablah entries with no polygons inside.
This started to cause regular (like 1 crash for 4-5 successful loads) random crashes while loading a battle scene and cost me several hours of my life to find the source of the problem.
This change was literally the last suspect among the changes I had done recently. I'd never expect a game to be unable to properly handle just a simple empty object.