#OMSI 2 LONDON BUS MOD CODE#

So pay close attention to that, as it can be easily missed! When browsing these objects (vertex groups), I found that new copies of the same material were assigned to each of them, rather than one material instance being linked between all of the objects / vertex groups. I have an O3D -> Blender importer plugin that separates the vertex groups within a single o3d file into separate objects, just as they would be in Blender if you selected multiple objects, then hit export. I tested this on some of my other maps, and found that objects imported from the Google Sketchup 3D Warehouse are especially prone to excessive materials. Quick edit to add some important details: You likely already know all this, but - as the number of material instances increases on your map, the number of drawcalls that have to be performed increases, which increases stuttering / load on the game engine.Īlthough at first, OMSI clearly seems to be able to load these objects (since people are able to at-least launch it without these serious errors), eventually the engine gives away after a period of gameplay.Īs in my experience, this threshold is way below the average length of most routes in this map, ranging from anywhere between 10-50 minutes.Įven if the game manages to run, this is far from ideal and is likely having a severe impact on performance / FPS. Take a look at the filenames, and judge for yourself whether they are worth checking or not - e.g., routearrows / routehelpers should be okay. You will need to check the following objects manually. I have run out of time to try and account for these edge cases. My script is still not perfect, and it encountered some errors with certain o3d files, and was not able to process them properly, likely due to being incompatible with a different format.

Ensure you do the same for textures!Īny o3d file with a material count of above 30-40 should be considered a serious & unnecessary detractor of performance and be treated as a priority. I'd advise reducing the material count as much as possible, and removing all orphaned materials. In my opinion, no more is required for a Sceneryobject - the less, the better. I would suggest fixing all o3d files with a material count of 10 or above. I'd advise giving them a look manually.Īs for the other models, however, I am confident that these are accurate readings they seem to match the readings from opening the files in 3D Object Converter. It's possible the bytes that hold the material count got corrupted somehow on export. Viewing them in 3D Object converter shows 17 materials in the details bar, but actually scrolling the list shows a lot more, oddly.

Both importer plugins seem to report buffer overflows. I can't seem to import them into Blender using several different plugins on 2.79 and 3.0, so I think there is something wrong with them anyway.

#OMSI 2 LONDON BUS MOD CODE#

With regards to the top three entries, I'm not 100% sure if these are erroneous or not, but I don't see how my code could cause that. Unfortunately I am not able to share the actual script as it currently makes use of private code from another script. If you would like me to run the script on any additional Sceneryobject folders, please do not hestitate to let me know. As far as I could tell, these are the only Sceneryobject folders used by Grande Porto 2022 that were created by you, that you have the rights & ability to modify the model files of.

Omsi 2 london bus mod