Add Lights objects to .animated sections

[adfriz]

Add 2 type of light source, spot and point.

I follow how blender light object settings, so it may more physically correct

can be tested in .animated file with:

[Light]
Type = Point or Spot
Position = X, Y, Z
Direction = X, Y, Z
Color = R, G, B
Range = RangeInMeters
Visual = true or false
Power = Watts
Exposure = Value
Normalize = true or false
Radius = Value
SoftFalloff = true or false
Angle = Degrees
Softness = Value
ShowCone = true or false
Shadow = true or false

Can use standard animation functions and parameters (Optional)

TranslateXFunction = ...
TranslateYFunction = ...
TranslateZFunction = ...
RotateXFunction = ...
RotateYFunction = ...
RotateZFunction = ...
and others...

Parameter Details:

• Type: Light type. Point (omnidirectional) or Spot (focused). Default: Point.
• Position: Coordinates (X, Y, Z) of the light source.
• Direction: Directing vector (X, Y, Z) for the Spot light beam, accept decimal/float, can be negative for the opposite direction, can be mixed for diagonal direction.
• Color: Light color in RGB format (values 0-255).
• Range: Coverage boundary of the light in meters.
• Power: Light output in Watts. Default: 12.5663706.
• Exposure: Exposure adjustment multiplier for the light source. Default: 0.0.
• Normalize: Normalizes power distribution. Accepts true/false or 1/0. if set false, this should show how bright the power in the real life
• Radius: Physical size of the light source in meters for specular glow calculation. Non-negative. Default: 0.0.
• SoftFalloff: Enables smooth fadeout attenuation near the range limit. Accepts true/false or 1/0.
• Angle: Cone beam angle for Spot light in degrees. Default: 45.0. Internally calculates SpotCutoff = Cos((Angle / 2) * PI / 180). Sets how wide the spot light is.
• Softness: Edge penumbra softness for Spot light (0.0 to 1.0). Default: 1.0.
• ShowCone / Visual: Toggle showing the visual debug/helper cone in the scene. Accepts true/false or 1/0.
• Shadow: Toggle whether the light source casts shadows. Accepts true/false or 1/0. Currently not show any shadow....

Light Animation:
A [Light] block generates an independent animated object containing the light. It supports all standard animation script properties (functions, directions, and damping) defined directly inside the [Light] block.

preview:

Screen.Recording.2026-06-05.165220.mp4

Screen.Recording.2026-06-05.1902002.mp4

Although it works... this still very work in progress, like the settings light limit does not have label yet... and i put it under the max sounds section.

---

i feel like we must set a roadmap priority, i mean if we keep adding feature but the stuff under the hood not built for it, it feels not efficient.

like with this light object feature, although it works... the renderer not build for this kind of feature and from what i can understand the renderer still a basic forward render, if we need modern feature, we must change the renderer to maybe clustered forward?

or other priority like using newer opentk or moving to other bindings like silk net ?

[adfriz]

@leezer3 what do you think?

[leezer3]

Basically this is what in this country we'd call the chicken and egg paradox. (I'm never sure how well these translate)- You need working examples of something (or at least a specification) in order to design sensibly the systems needed to actually make it work; this is in part why I've been working on MSTS content, as this gives a set of features with an already dssigned specification.

If you don't have this, what you tend to end up with is a massive teetering tower where each new feature gets bodged on to the last.

[adfriz]

Thanks for the insight leezer3, i understand my PR could be a tech debt if i just submit it as working feature without a concrete base. i also don't want any of my PR to be a burden, like "here is a new feature, goodbye" and left it in the dust.

So, is openbve will follow MSTS specs as basis? like open rails?

---

A note: If anyone wants to improve or extend any of my PR, either still open or draft PR. The license should use simplified BSD-2 license.

[leezer3]

For reference, this is a MSTS / OpenRails light:

Light (
   Comment( light head Left )
   Type ( 0 )
   Conditions (
    Headlight ( 2 )
    Unit ( 2 )
    Control ( 2 )
   )
   Cycle ( 0 )
   FadeIn ( 0.5 )
   FadeOut ( 0.5 )
   States ( 1
    State (
     Duration ( 0.0 )
     LightColour ( ffffcb8d )
     Position ( 0.57 1.62 8.52 )
     Azimuth ( 0 0 0 )
     Elevation ( -43 -43 -43)
     Transition ( 0 )
     Radius ( 1.0 )
    )
   )

I'm not sure on this, but it feels as if there are too many parameters exposed :)
As you've noted above, the engine isn't exactly the greatest, and I wonder if we need these at least in the short term.

---

Honestly, I don't exactly know exactly where the roadmap is going, and I suppose that is some of the problem.
What I'm keen to avoid though is just ramming extra parameters into the existing files when it'd be more sensible to design something new for the job.

I'm intending to re-write the CSV / B3D parser soon into something more akin to the block parsers, both to make it read cleaner and to get it to a known good licence state.