BVE WorldWide
Would you like to react to this message? Create an account in a few clicks or log in to continue.

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

Go down

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

Post by Dexter Sat Jul 13, 2019 10:44 pm

Hello,
I would like to verify one thing. Which of the two is more demanding for the use HW? Having a massive .csv object, or having an .animated object composed of smaller units? Both showing the same result...
I would expect the .animated to be in disadvantage here, since in the .csv you have to hardcode everything exactly (therefore there are no additional calculations), while in the .animated you will obviously help yourself with a little rotate function here and there...
Thanks. Cool


Last edited by Dexter on Mon Jul 15, 2019 3:48 pm; edited 1 time in total
Dexter
Dexter

Posts : 2102
Join date : 2011-07-08
Age : 35
Location : Brno, Czech republic

http://www.brnobve.eu

Back to top Go down

Massive *.csv object vs. composite *.animated object Empty Re: Massive *.csv object vs. composite *.animated object

Post by mrknowitall Sat Jul 13, 2019 11:03 pm

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?
mrknowitall
mrknowitall

Posts : 822
Join date : 2011-07-09
Age : 29
Location : W. Yorkshire

https://www.pioneertrains.co.uk/

Back to top Go down

Massive *.csv object vs. composite *.animated object Empty Re: Massive *.csv object vs. composite *.animated object

Post by leezer3 Sat Jul 13, 2019 11:31 pm

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.

leezer3

Posts : 1785
Join date : 2011-08-23

http://www.bvecornwall.co.uk

Back to top Go down

Massive *.csv object vs. composite *.animated object Empty Re: Massive *.csv object vs. composite *.animated object

Post by Dexter Sun Jul 14, 2019 8:27 am

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.
Dexter
Dexter

Posts : 2102
Join date : 2011-07-08
Age : 35
Location : Brno, Czech republic

http://www.brnobve.eu

Back to top Go down

Massive *.csv object vs. composite *.animated object Empty Re: Massive *.csv object vs. composite *.animated object

Post by leezer3 Sun Jul 14, 2019 9:15 pm

That does sound familiar Razz
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 Sad
When I've got it so they load as a single common plugin, will try and do something further at improving stuff.

leezer3

Posts : 1785
Join date : 2011-08-23

http://www.bvecornwall.co.uk

Back to top Go down

Massive *.csv object vs. composite *.animated object Empty Re: Massive *.csv object vs. composite *.animated object

Post by Quork Sun Jul 14, 2019 10:38 pm

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.
Quork
Quork

Posts : 1388
Join date : 2012-05-05
Age : 29
Location : Hofheim a.T., Hessen (Hesse), European Union

Back to top Go down

Massive *.csv object vs. composite *.animated object Empty Re: Massive *.csv object vs. composite *.animated object

Post by Dexter Sun Jul 14, 2019 11:12 pm

I believe this should not be too difficult to implement... at least as far as my coding knowledge goes anyway. Very Happy 
Let's say we can add a variable to the animations. The variable will be of a boolean type (yes/no) and will be called "indefinitive". When set to yes (that would equal 1), the animation needs to be evaluated continually. When set to no (or 0 in that case), then the sim will only evaluate it once. This quite a simple logic.
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)?


Last edited by Dexter on Mon Jul 15, 2019 8:06 pm; edited 1 time in total
Dexter
Dexter

Posts : 2102
Join date : 2011-07-08
Age : 35
Location : Brno, Czech republic

http://www.brnobve.eu

Back to top Go down

Massive *.csv object vs. composite *.animated object Empty Re: Massive *.csv object vs. composite *.animated object

Post by Quork Mon Jul 15, 2019 12:26 am

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

Posts : 1388
Join date : 2012-05-05
Age : 29
Location : Hofheim a.T., Hessen (Hesse), European Union

Back to top Go down

Massive *.csv object vs. composite *.animated object Empty Re: Massive *.csv object vs. composite *.animated object

Post by Dexter Mon Jul 15, 2019 8:06 pm

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. Smile
Dexter
Dexter

Posts : 2102
Join date : 2011-07-08
Age : 35
Location : Brno, Czech republic

http://www.brnobve.eu

Back to top Go down

Massive *.csv object vs. composite *.animated object Empty Re: Massive *.csv object vs. composite *.animated object

Post by Delsin Tue Jul 16, 2019 2:24 am

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...
Delsin
Delsin

Posts : 283
Join date : 2016-08-20

Back to top Go down

Massive *.csv object vs. composite *.animated object Empty Re: Massive *.csv object vs. composite *.animated object

Post by Sponsored content


Sponsored content


Back to top Go down

Back to top


 
Permissions in this forum:
You cannot reply to topics in this forum