MSTS Lights

[leezer3]

#1328

Work in progress branch to try and get MSTS lights working with the implementation from there.

[leezer3]

2026-08-13.11-04-16.mp4

2026-08-13.11-06-25.mp4

I've now got basic lights working on MSTS models. Not added a lot of the conditionals etc. at the minute, but that's something that can be worked on.

@adfriz I'm wondering whether the lights would be better as a property of the car itself (or possibly an additional light list there?), rather than the animated object.
The thinking behind this is headlights which produce an effect visible from inside the cabview.

The current implementation would need a way to add a headlights light definition to the panel2.cfg (as the panel after all is only an animated object), and I'm not entirely sure how well the rotation would work, considering the lights would have to be rotated with the vehicle, not the cabview. (unlock the camera restriction and play with moving the rotation of a 2D cab to see what I mean)

Issue with that approach though is that unless you're keeping the animated object way as well, it'd restrict adding lights to train cars, and not scenery objects etc.

The other thing that needs to be worked on before merging this is that we currently re-create the light list every frame for both the MSTS models and the animated ones.

[adfriz]

Yeah you right.

That 2d cabview case is what i overlooked from the start, i was too focused to make sure its works on exterior mode.

But, I don't want to lose lights in animated object, that's the only way scenery objects get lights. So my plan is to keep that too. maybe support both way?

For that everyframe light list i agree, that's not efficient. Maybe I'll try make a reusable buffer and only rebuild the light when the active state actually changes, and do the same sort of version-check for the animated object lights. Or maybe group the lights by type? like other game engine, static lights only computed once when loading, others still per frame.

But idk if that going to make loading too slow.

[adfriz]

I will resolve #1328 conflict first.

Then maybe fix that light list after that

[leezer3]

Not efficient is relative at this point I suspect- it works perfectly well as a first prototype, and it's OK with a typical MSTS consist, but it's also showing where some of the issues are.

Scenery lights wise, I do wonder about something along the lines of static lights (no functions) allowed on scenery, dynamic lights with functions allowed on trains, but on the flip side we allow all animated functions on scenery.

Rebuilding the list wise, I suspect the best way to do that might well be in the object update itself, rather than on the per-frame basis.

Something along these lines:

Replace light list with a HashSet, accessible from object update.
If lights have changed in object, pull all old states and add new ones.
Set light changed flag for renderer to upload the new lighting list.

[ginga81]

I'm a little curious—for example, would it be possible to generate sparks through arc discharge, either randomly or at specific locations, from the collector shoes of a pantograph or a third-rail system?

[leezer3]

This branch wouldn't do that, but it sounds like a relatively trivial extension of particle sources, just would want the duration and conditionals tweaking a bit.

Will think & take a look next week.