Massive *.csv object vs. composite *.animated object

I thought its the animated objects functions that can cause the FPS to drop, more than just the use of a .animated composing of multiple .csv's to build one main object?

That's basically correct, although the animated object would load marginally slower. (It first builds the 3D meshes and then applies the rotations to the result, as opposed to the single object which does it as it goes along)

The engine is smart enough to optimize (most) functions returning a static result out, and would then store both identically internally.
Dependant on your number of verticies there could be some small differences after de-duplication, but notjing that would have a meaningful effect.

Functions which don't return a constant result are the killer.

Thank you, that's what I was thinking. I know that you have made an optimisation to the code regarding functions with constant output as previously it was re-evaluated per every single drawn frame. I think we were discussing a similar topic when I was surprised with the fps drop chased by static bushes in an animated file.

That does sound familiar
IIRC the original behaviour worked when it was a single number (e.g. RotateXFunction = 0.5 ) , but not when it was an actual sum (e.g. RotateXFunction = 1 / 2 )

There's still a lot of mess in the way animated files work internally though
When I've got it so they load as a single common plugin, will try and do something further at improving stuff.

It might be worth thinking outside the OpenBVE box and taking a look at others: LokSim3D took the easy and yet elegant way of setting an additional attribute to composite files (*.l3dgrp in their case); it tells the sim that the object's states don't change during the simulation. When it's set, the sim calculates everything, removes unneeded components from memory etc. and never touches the results again during the simulation. Maybe, if you want, you could just ask Lukas how exactly they tackled the issue; IIRC it's a rather new feature, so he might remember.

I am not entirely sure if we can look into the parameter "RefreshRate" to help us in this case - probably tell the sim if RefreshRate = 0 then do not refresh (ie. don't recalculate)?

Nope, but maybe there are some fringe cases and nontrivial conflicts in specific circumstances.

Quork wrote:Nope, but maybe there are some fringe cases and nontrivial conflicts in specific circumstances.

Yes, there are always such cases. Everywhere, you can't escape them.

I think using [include] rather than [object] helps when you need to only move the included object. I haven't noticed significant fps drops of .animated with parts vs whole object in one csv/b3d (I use multiple static parts in .animated a lot, I make window frames separately and then "insert" them several times. I don't like leaving edges of texture transparency open).
I've noticed an interesting effect though. I modeled a rather complex window (more like, 2 windows, left and right. I avoid using Translate(all) and Rotate(all) as much as possible for optimization) in one b3d. I did this before working on the rest of the car and just placed them where they're supposd to be in the car's .animated file. There are 5 of them per car (though 2 are slightly different, they're shorter and lack a few very simple parts, but this shouldn't affect performance much), 6 cars in test consist, plus bogies that are .animated files, with a couple of b3ds added with [include] and 2 rotating axles. This test train has good fps (lowest I got was 25). Then I was building another train with the same technique, first bogies and windows, then the rest. I reused bogies and windows from the previous train, didn't change them at all. There are 6 cars there as well, but there are 9 window b3ds + 4 b3ds that have a single narrow frame and TranslateAll applied to the whole file once (for car ends) this time. This train runs at 15-20 fps. Quite expected, as there are more "heavy" window objects now. However, after I modeled the rest of the car, it didn't drop any further. It stayed at this level even after I added doors - not only they were quite detailed, but they're "folding" (think of class 141) - 4 b3ds per door and 2 of them use trigonometric functions to operate properly, there are 4 doors (2 on the left side and 2 on the right) in each car. This seems somewhat illogical (and pleasing, I expected less fps) to me...