Animated Model Plugin: Dynamic Texture Update

We hope openBVE can support dll plugins for Animated Model.

After messing around OpenGL, I managed to implement dynamic texture update by using glTextureSubImage2D in the Ats IRuntime plugin.
I shared this with a few other developers, and we agreed that this technique will enable us to implement quite a few new features, or to implement some animation in a easier way.
For example, a LED screen/destination board, a LED graph display would require numerous StateSwitch or TextureShift currently, but would only require writing a simple painting routine with GDI+ with this technique. Meanwhile, complex HMI screens with line charts such as LKJ2000 will be made possible.
I have made a video, demonstrating a real-time typewriter by using GDI+ to draw the text typed on the keyboard:


I initally thought its performance would be horrible, but it turned out replacing a few texture does not cause the framerate to drop significantly.
Of course, replacing too many textures, or replacing it too often will cause lag, but I think the upside of this technique is still worthy.
You can get the source code of the Ats plugin I wrote for the effect right here: https://drive.google.com/file/d/1oyW8CGy6rfhp1gasea_RZskKytVBwX6K/view?usp=sharing
The utilty class for texture updating is included.
The effect can be tested by using DynamicTexture\bin\Release\DynamicTexture.dll as the Ats plugin of a train, and placing a tex2replace.txt with the relative path of the texture file to replace to the Object folder written inside it. Modifying the code will enable achieving other effects.

However, if IRuntime Ats plugin is used for this purpose, the models will all break down if another train is used. Which makes this implemention imperfect.
So I think we can have plugins for Animated models, to control its render programatically, for more advanced visual effects to be implemented.
I personally think it is a nice feature for advanced developers to take. It would surely enable many fancier eyecandies to be developed.
We already had CSScript for flexibility, and I think giving the flexibility to control the texture would be more useful.

For example, maybe we can have a [Plugin] section in the .animated file, with the File attribute pointing to a dll, and Argument attribute for optional arguments.
The dll will contain a Elapse method, which takes the argument along with the reference to the ObjectState of the .animated model loaded.
In that way we can update the model programatically.

That's a marginally neat trick, but I can't really see too many actual sensible uses. It's also highly likely to go spectacularly wrong, searching for a texture in memory by it's filename is not a good idea
I suspect you're probably overestimating the number of people who can write GDI plus too.....

If you're going to go down this sort of route, a far more sensible way to do things would be to extend the plugin interface a little and allow plugins to return a bitmap array, in exactly the same way as per the current panel numbers.

Map these bitmaps to a set of textures, and add appropriate plumbing in the object parsers.

Might also be able to do something similar with an API function call, which would probably be marginally faster, but that'd depend on passing and holding references.

leezer3 wrote:If you're going to go down this sort of route, a far more sensible way to do things would be to extend the plugin interface a little and allow plugins to return a bitmap array, in exactly the same way as per the current panel numbers.

I actually do not think this should be implemented with the train IRuntime API. Because it is controlling the appearance of the model, using another train would break the models in the route.
So I think we should have some way to bind a plugin to something in the route. For example, load a plugin from the animated model.
And if we load a plugin from the animated model, we can have a interface which receives the ObjectState of the model. That would locate the material in a more elegant way.
The problem that I can think of is that the same texture file shares the same OpenGL texture, so we cannot control the individual objects individually.

leezer3 wrote:I suspect you're probably overestimating the number of people who can write GDI plus too.....

You are probably right on that.
I thought GDIplus was not difficult, as I once managed to write a program out of it during elementary school...
But it seems otherwise for many developers.

For its usage, I think it can simplify the implementation for the ones who knows how to write GDIplus...
As I have said in the previous post, for example, something like [This stuff] would require tons after tons of StateSwitch or super large texture with TextureOffset. This kind of device is especially common here. Considering there are 8 of them for each car, and the rich variety of the display state of this device, StateSwitch would require tons of state models and create many faces, while TextureOffset would require a really large texture map.
And something like [This stuff] would not be possible to be made using current animated feature.
Also as Ginza81 have said, many trains in japan got really smoothly and complexly animated display screens for indicating the next stop.

I think that using this technique and include to the main program, animated GIF movie can include to the animated object.
For example,

[Object]
Moviefile = xxx.gif

If this can, LCD next station movie includes to the animated object.

This is a rather experimental build allowing the use of animated gifs as textures:
http://vps.bvecornwall.co.uk/OpenBVE/Experimental/AnimatedGif.zip

I don't think anything else is broken, but this *may* cause higher memory usage on some things.
Using any number of animated gifs is also probably likely to get laggy.
No variable framerate support either (duration / number of frames)

I don't know how to use.
To use is this have I said?

.animated
[Object]
Moviefile = xxx.gif

Just replace any texture in a B3D, CSV etc. with the animated gif of your choice.

Nothing more complex than that, a silly example in the attached file.

I still think there should be a way to load a dll from a route file, or a model.
There are many interfaces exposed by OpenBveApi, and I think the usage is not limited to train.
That makes loading a dll from a route file or a model, to affect something like game system or rendering, a reasonable behavior.

I tested the test-version.
But not display as shown below.


At 1.7.1.5, the same route is as shown below.

I also think that need to draw directly into the game window.
Because of the Japanese TIMS monitor is very wise, have to a lot of information can displaying as realtime.
Touchelements can most of action as this movie.

But not perfectly.
If more drawing and control can do by programing, I think that more good.

After reported, I built and run this.
https://github.com/leezer3/OpenBVE/tree/AnimatedGif

The errors that is a lot of objects error to the errorlog such as showing below, and displaying white objects.
22:45:26  Plugin Texture.BmpGifJpegPngTiff.dll raised the following exception at LoadTexture:A null reference or invalid value was found [GDI+ status: InvalidParameter]
22:45:26  No plugin found that is capable of loading texture ...pole_metal.png

That's odd; I can't think how.
I didn't test overmuch, but it worked at this end, although at the minute its terrible code.

Does the sample load at all in Object Viewer?

Might be Linux related, will try and look closer today or tomorrow.

I don't know why it happen.
Because of the same route.
Sorry about checking this by you.

It's no trouble- It's my code

Newer build, which may work a little better this time (no idea why it didn't seem to like BMP files):
http://vps.bvecornwall.co.uk/OpenBVE/Experimental/AnimatedGif2.zip

I tested the new version, but not show at driver's view.
and the outer-view is as also as below.


The errors as shown as below.
10:01:03  Plugin Texture.BmpGifJpegPngTiff.dll raised the following exception at LoadTexture:A null reference or invalid value was found [GDI+ status: InvalidParameter]
10:01:03  No plugin found that is capable of loading texture .../Railway/Object/TFO_sample/Rail.png
10:01:03  Plugin Texture.BmpGifJpegPngTiff.dll raised the following exception at LoadTexture:A null reference or invalid value was found [GDI+ status: InvalidParameter]
10:01:03  No plugin found that is capable of loading texture .../Railway/Object/TFO_sample/formC.bmp

Try this build please:
http://vps.bvecornwall.co.uk/OpenBVE/Experimental/AnimatedGif3.zip

Seems to be a difference in Mono's libgdiplus implementation.
I've tested this one on both Windows and Linux and it appears to be OK at this end. It's also got a little more caching in place so that it doesn't reload the texture from disk every frame. (It can still be somewhat optimised- It uploads the new texture state to openGL whenever the frame changes, but I want to get this working first)

(n.b. The animation speed *may* be off, I haven't tested this on anything other than a VM, on which openGL is laggy)

I tested AnimatedGif3.zip.
Works very well on my Ubuntu!
animation change timing is about  4 frame per seconds