Shadows

Short but to the point, are there any plans for OpenBVE in the future to have rendered shadows?

I would like them as well, but I think it will be quite hardware demanding. Let's put this in the program section as well...

Chris is doing a fantastic job ATM, just a thought, maybe an option to activate them in setting for those with a high end set up?

Could be... we'll se what he says about that.

no crossing my fingers,promise.

LOl. I think the GTX 1060 should have no problem with a bit of shadow rendering... we'll see
.

Its copes well with most things! just about 

I think you guys are exagerating a bit - the simplest of shadows is completely feasible and adds a small, but unfortunately noticeable, footprint: playing Minecraft on my laptop, an i5-3320M with 8GB RAM, at native resolution, without shaders, I can easily get to 60 FPS. Applying a midweight shader that's configured only to display dynamic shadows, drops the FPS counter to around 35 FPS, sometimes 40.

I chose Minecraft as an example because both it and OBVE use a virtual machine (Java and C#/.NET are comparable), both use relatively lightweight libraries (LWJGL and SDL iirc) and both use very few polygons compared to big name games (though MC has a much crustier codebase, it seems).

Well. Not all persons on this world have "First world Computers".

As my case. I'm a great modeler... But with hardware limitations. I'm using a GT620 with a 775 socket on a E4600 processor. 

I've developed also on Trainz. And they got a method really interesting to render shadows and it's totally applicable to OpenBVE.

I will like implementation of a concept like this one

[meshbuilder] <- this one will represent shape model

[shadowbuilder] <- this one is another shape model EXCLUSIVE TO Shadow

Why?
Most train have a box shape form so... it's unnecesary render a whole train with all kind of accesories and stuff.

Scenary objects could do the same.. In fact . I think .csv and .b3d objects form need more information that just a model information. Per example. In some future OpenBVE will grow a lot... Lights it's another "headache" with a tiny solution.

I've thinked a lot this... Without any kind of direct conexion with OpenBVE development and Staff. 

The solution was creating another command for lights. 

First i was thinking on implementation of this on .animated files. But.. on Routes will have a lot of animated files. So it will be a bit confusing with spread of animated files associated with models and i don't think it's correct this form.

So.. Why not on model ? - Like this...

[meshbuilder]
SHAPE INFORMATION

[shadowbuilder]
SHAPE INFORMATION WITHOUT TEXTURES AND COLORS (just vertex and faces)

[lights]
Position of light. = X,Y,Z
Intensity = Who now how this is meassured
Light Color = R,G,B
Rotation = Yaw,Pitch,Roll
Purpose = please read down

Where purpose is
STATIC = a static light
FRONT = a front light of the train.
REAR = a rear light of the train.
ELECTRIC = a electric spark.

And this can't just even be shadow... Lights... Could also be Steam and Diesel Smoke!

The shader in question isn't just for shadows... It also has blur, reflection, refraction, ambient occlusion, waving objects, etc.
Hell, I should probably have mentioned it before but when I'm playing Minecraft without shaders and fast render and fast math OFF, the game stays at some mid 50's FPS as it struggles to get to 60. Still doesn't help my argument a lot, but you've got to understand that Minecraft has to render a world that can considerably change at any time, and also thousands of blocks are in viewing distance at any time, some of them may be partially transparent like leaves and render blocks behind them.
I partially agree with you that performance impact will be noticeable on high detail.. routes? such as the animation test, the suijin line? with a lot of lights and a lot of moving parts with a bit of detailing, even worse on stuff like the Birmingham X-City South v2 for the OB2 render from many years ago. But I disagree on lower detailed routes, like the chashinai railway, a dwindling majority of bve 5 scenarios, early openbve exclusive content... Performance won't be impacted much because there will be fewer polygons and details to cast shadows upon.

I will, however, eat several hats if I can't play a shadow build with reasonable framerate on the same computer.

Shadows aren't on the short-term list, but in and of themselves they're actually simpler than you might think.
At the moment however, the focus is very much upon moving stuff to a single set of shared libraries.

TLDR:
Rendering a shadow (essentially) requires a twin-pass render, where we render the pixels once with full-lighting, and again with occlusion applied.
It's not actually too-different to a transparent color, just applying the lighting properties. As we've already calculated the object positions etc. it's not likely to actually add a great deal in the way of load.

The problem is that we haven't really got any material properties in-game, and the fact that a large amount of stuff uses transparent color based faces, as opposed to discrete polygons.
Minecraft gets away with a lot in this regard, as everything really boils down to a cube.