[Csantucci]

Steve,
no, it's not simply transplant from the 2D cab code. In 2D you change standalone textures that have a specific tratment, in 3D you use the standard scenery shape/texture coding. And moreover I wonder whether in a 3D cab a "light" feature should only change textures or really foresee one or more beams of light, which would make things quite more complicated (at least for me).
***
I've gone a further step forward.
Here are the .exe files to be replaced in x.3792 to have the 3Dcab night texture applied also in tunnels

and here is the source patch. I'd like to get an OK by James on this, because it adds a couple of flag values


IMPORTANT NOTE: To get the night texture activated in tunnels, in the .sd file of the 3dcab shape file instead of line

11/2/2017: attachments removed because feature uploaded.

[James Ross]

Csantucci, on 11 February 2017 - 05:54 AM, said:

I've gone a further step forward.
Here are the .exe files to be replaced in x.3792 to have the 3Dcab night texture applied also in tunnels
Cabs3DInTunnel.zip
and here is the source patch. I'd like to get an OK by James on this, because it adds a couple of flag values
Cabs3DInTunnel.zip

I think you've got the wrong second attachment. :)

[Csantucci]

True, sorry
 3Dcabtunnel1.zip (1.54K)
Number of downloads: 201

Corrected also the post above.

[James Ross]

Csantucci, on 11 February 2017 - 05:54 AM, said:

I've gone a further step forward.
Here are the .exe files to be replaced in x.3792 to have the 3Dcab night texture applied also in tunnels
Cabs3DInTunnel.zip
and here is the source patch. I'd like to get an OK by James on this, because it adds a couple of flag values
3Dcabtunnel1.zip

IMPORTANT NOTE: To get the night texture activated in tunnels, in the .sd file of the 3dcab shape file instead of line

	ESD_Alternative_Texture ( 512 )

you must insert line

	ESD_Alternative_Texture ( 768 )

.

Very apprehensive about this change, due to the new flag in a publically-exposed file format. I've read this thread lightly, but can you explain simply what the problem being solved here is?

[Csantucci]

The main problem being solved by this last patch is that without it within tunnels the night texture of the 3Dcab elements (and in particular the .s file) is not activated, because as a standard night textures are enabled only at night and not when being underground. The secondary is that generic night textures are enabled in a pseudorandom way when the sun goes under the horizon, while the cab3D textures are enabled all together when the sun angle is at a specific angle that is a bit under zero, as it is for the cab2D textures. So I need a way to pass to the SceneryMaterial class an info on how to behave with the enabling of the night textures (standard way or cab3D specific).

Moreover making available to the content creator the further flag value for ESD_Alternative_Texture allows extending this for other desirable cases (e.g. enabling night textures within tunnels for trainset .s files).

[James Ross]

Csantucci, on 11 February 2017 - 09:55 AM, said:

The main problem being solved by this last patch is that without it within tunnels the night texture of the 3Dcab elements (and in particular the .s file) is not activated, because as a standard night textures are enabled only at night and not when being underground. The secondary is that generic night textures are enabled in a pseudorandom way when the sun goes under the horizon, while the cab3D textures are enabled all together when the sun angle is at a specific angle that is a bit under zero, as it is for the cab2D textures. So I need a way to pass to the SceneryMaterial class an info on how to behave with the enabling of the night textures (standard way or cab3D specific).

Hmm, right. I would like to activate night textures when the 3D cab is underground, without any extra flag in ESD_Alternative_Texture, as that is a set of flags for which textures exist. I guess that's tricky? Could we instead add the flag automatically when the 3D cab is loaded ("SharedShape.LoadContent")? If so, let's give it a value like 0x80000000 (the highest bit) so it's far away from the ones used by ESD_Alternative_Texture.

[Csantucci]

OK, I have inserted in LoadContent a check on the texture path to decide whether the flag is set.
The check is whether "\Trainset\" is present in the texture path. This way the feature can be used also for other trainset shapes (up to now trainsets use standard day texture when in tunnels, which is not nice to see).
This way the line to be present in the .sd file remains the standard

	ESD_Alternative_Texture ( 256 )

The flag bit is 0x40000000. With 0x80000000 I got complaints about impossible conversions from uint to int :)

Feature uploaded in x.3793.

Manual updated with short description of feature in x.3794.

[Eldorado.Railroad]

Csantucci, on 11 February 2017 - 01:09 AM, said:

Steve,
no, it's not simply transplant from the 2D cab code. In 2D you change standalone textures that have a specific tratment, in 3D you use the standard scenery shape/texture coding. And moreover I wonder whether in a 3D cab a "light" feature should only change textures or really foresee one or more beams of light, which would make things quite more complicated (at least for me).

Well really I was thinking of Jejun's 3DCab (DF11G3DCab, downloaded via Elvas) which has a directory called "cablight" in the "CABVIEW". From what I can understand the textures in the "cablight" directory are used when the "L" key is pressed. Would it not be as simple..to use the a "cablight" directory in the CABVIEW3D directory to hold the "light" textures? This is exactly what is switched on right now for night textures and 3D Cabs (Thanks!). I would leave it up to the modeller to modify those textures to resemble a cab light being switch on. No...I am not thinking about any fancy extra lights being used for an illuminated 3Dcab...that is for version. 3.0x of Open Rails!

Thank you,
Steve

[disc]

Using pre baked lit textures in game is very wasteful, as you need two texture sets for cabs, one for day, one for night. Nearly in all games this is done simply by supporting multiple light sources, which are dynamic, have realtime shadowing, and simulate the reality.
But in OR currently the only real light source is the sun, and the headlights are quasi light source (but that wouldn't fit as cab lights, as no shadowing).

[Jovet]

disc, on 20 February 2017 - 02:35 AM, said:

Using pre baked lit textures in game is very wasteful, as you need two texture sets for cabs, one for day, one for night. Nearly in all games this is done simply by supporting multiple light sources, which are dynamic, have realtime shadowing, and simulate the reality.

It isn't that wasteful, since only one of the texture choices needs to be loaded at any given time. Plus, the texturing model is pretty simple. There aren't displacement maps, bump maps, specular maps, normal maps... just color. That can't be too wasteful.

In the future, some day, hopefully, when those different types of maps can be utilized and more-realistic and complex lighting systems are otherwise available, then I am sure the current methodology can be ditched.