Conversation
|
@leezer3 what do you think? |
|
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. |
|
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. |
- Added early exit if no active lights. - Made spotlight attenuation calculations branchless. - Precalculated division constants. - Added frustum culling for active scene lights. - Added per-object closest 16 lights binding when total lights > 16. - Cached bound dynamic lights list and view matrix to skip redundant GL.ProgramUniform calls. - Removed unused CastShadow property and shadow = 1 parsing.
|
For reference, this is a MSTS / OpenRails light: I'm not sure on this, but it feels as if there are too many parameters exposed :) Honestly, I don't exactly know exactly where the roadmap is going, and I suppose that is some of the problem. 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. |
# Conflicts: # source/ObjectViewer/Graphics/NewRendererS.cs # source/OpenBVE/Graphics/NewRenderer.cs # source/RouteViewer/NewRendererR.cs
|
Coming back to this one after #1436 Thinking about this laterally, how about defining lights via their own XML file? Also allow attaching a light to a car, either via an XML tag in the 'new' format, or via additional say Lights lines in extensions.cfg etc. Your animated object class then holds an array of lights, as does the rail car itself. |
|
More thinking.... If we take a 'standard' train from the UK, this would need ~2 light sources as an absolute minimum. This would be:
A good number of trains will have 3 or 4 light sources, that being high / low level headlights plus tail lights. We also want to think about a hierarchy of light sources- The light source itself I think needs some sort of Type parameter. Something along these lines:
|
|
Japanese players have expressed a desire to see an effect where the shadows of lights are cast across pillars in subway stations. |
|
Further design thoughts: Going back to my list above, tail lights and ambient lights might well get away with not casting shadows at all. The other possibility I can think of would be to disable shadow-casting for short range lights (say under 10m or so). This would allow your streetlight with a small local cone to skip much of the shadow code. |
|
All of your suggestion is good. i also have thoughts for the static lights to have auto on/off based on time of day. but... i think this lights object pr is lower priority. i mean its obvious we will use a lot of light objects especially in routes if this pr done. but the underlying renderer not designed for this much of lights, need full rework... We need new renderer architecture, currently our renderer is a standard forward renderer, fortunately i have some resources for this, https://github.com/Angelo1211/HybridRenderingEngine , https://github.com/DaveH355/clustered-shading , https://www.aortiz.me/2018/12/21/CG.html all of them are MIT licensed, so its safe to use, just need attribution. My plan to use the forward+ or tiled forward rendering. But there also some sacrifice, like we need to limit some feature for macos because they cant use compute shader. |
3 participants
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:
Can use standard animation functions and parameters (Optional)
Parameter Details:
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 ?