[Traindude]

Weter, on 03 May 2023 - 12:49 PM, said:

A very appropriate idea.

You define number in *.eng/*.wag -file ORTSBoardNumber (XXYYZZ) and program draws it.
Maybe Font () and Size () paarameters too.

Yes! Perhaps the Font ( x ) parameter could reference an appropriate *.ace file (Example: Font ( "loconums.ace" )), and the texture is scaled according to the "borders" between numbers, letters and/or characters.

You could even specify the number in a *.con file as well.

[Weter]

Yes, as You advising - its more sophisticated.

[pschlik]

Pardon me if this isn't actually on-topic, but I believe this is related to the code going into the new shape format-yesterday I jumped from New Year to the current unstable build to check on some air brake simulation changes, and I was surprised and pleased to notice some lighting changes. Though I noticed one immensely annoying thing...the light cone effect on the TrainSimulations P42DC flickers like mad (I must give a very real epilepsy warning for the video)! I did a bit of digging and determined that setting the conditions for a sphere of lights to use Headlight ( 0 ) or Headlight ( 1 ) [ie: the light will activate with the headlight switch off] causes the light cone to flicker. If I modify the sphere of lights activation to require dim or bright light settings, then the flickering just doesn't happen.

I put up a video to illustrate the flickering, but this is not good for eye strain: https://youtu.be/eOBvYwEOhBQ

I did a bit more investigating, and I'm pretty sure the flickering happens when a light beam is loaded in while its conditions are already true. Loading in to a P42DC spawns you with the lights off, which activates the dim sphere of lights immediately upon loading, causing flickering. Using Alt + F9 to take over an AI ES44DC causes flickering; the AI set the headlights to bright, which activates the bright sphere of lights immediately upon taking over. The only thing that doesn't cause flickering is loading in a state where none of the spheres of light will immediately activate. I don't know why that would be the case, but maybe the code needs some sort of delay to not turn the lights on instantly when their conditions are activated.


I also noticed some locomotives lighting up from the inside, the lights were configured with the sphere of light originating from inside the locomotive body. So, to anyone out there messing with lights, don't do that. While this might have worked in MSTS and looked okay in the old lighting model, it really is unsightly in the new lighting.

https://i.imgur.com/d1IqbaV.jpg

[ErickC]

Traindude, on 17 April 2023 - 05:50 PM, said:

Something I brought up in the new lighting conditions thread but I'll repeat it here. You know how some models have things like illuminated interiors and backlit number boards that utilize "Bright" textures so they're illuminated at all times? It would be nice if we could use headlight controls to change the texture mode from "normal" to "bright" (and vice versa). Who else agrees?

I don't; switchable additive lightmaps (a la MSFS) would look and work better.

With respect to auto numbering - that only works if one of two conditions are met:

1. The reporting marks for every railroad are in the exact same spot (they're not)
2. If we can define a large area for numbers and then provide x/y coordinates (sort of like how MSFS handles VC gauges)

If there was a way to implement some sort of positioning system, then this would save a lot of the headaches of the current ways of doing things (i.e., either road numbers are baked into the textures or defined with decal shapes).

[Traindude]

Another question about the new shape format--more aninated doors--are they a possibility? I know currently, we can only have 3 doors per side--DOOR_A, DOOR_B, and DOOR_C for the right side and DOOR_D, DOOR_E and DOOR_F for the left. However, some passenger rolling stock have more than 3 doors per side (our friends across the pond will understand!), so in adding additional doors, then given the labeling:

Right Side:
DOOR_G
DOOR_H
DOOR_J (deliberately skipping letter "I" to prevent it from being mistaken for a number one "1")
DOOR_N
DOOR_P (deliberately skipping the letter "O" to prevent it from being mistaken for a number zero "0")
DOOR_Q
DOOR_U
DOOR_V
DOOR_W

Left Side:
DOOR_K
DOOR_L
DOOR_M
DOOR_R
DOOR_S
DOOR_T
DOOR_X
DOOR_Y
DOOR_Z

That's a total of 24 possible individual animated door elements! We may not need this many doors but you never know!

[Traindude]

Weter, on 11 May 2023 - 07:27 AM, said:

Wow!
Since carriages can have 9 passenger compartments, one service, one staff's rest and toilet...
Why no?

I was thinking mainly passenger entrance/exit doors from outside the vehicle to inside.

[Traindude]

Weter, on 11 May 2023 - 10:57 AM, said:

Old British carriages had doors to outside from every compartment.

Yup. That's an example I was referring to earlier.

[superheatedsteam]

I am having a problem with the way a material is displaying in a glTF model in Open Rails Unstable.

I have exported this model as glTF and it appears OK in the Microsoft 3D Viewer.



But in Open Rails Unstable the body and hand rails that share the same material appear as glossy black.



The frame, pilots and bogies use a second material and the cab interior uses a third material. Both these materials display the base colour / albedo as expected.

All the materials are setup the same way as as indicated in the Blender manual. https://docs.blender...cene_gltf2.html



There are no warnings or errors when exporting the model from Blender or in the Open Rails log file on exit.

The issue appears to be related to the geometry because if I apply the material that works on the bogies to the body the UV mapping is incorrect as expected and is displayed as such in the Microsoft 3D Viewer but still appears as gloss black in Open Rails. Vice versa if I apply the material that is on the body to the fuel tank it appears OK in the 3D viewer and Open Rails. I have tried other materials and different permutations but to no avail. Unable to determine what is different in the body geometry beyond the number of triangles so I split the body into 4 semi equal triangle counts and exported but still not displaying correctly.

Any suggestions on what else to look at or try?

Of interest, you can see an environment reflected in the body work but this is not the OR route environment or the environment map I am using in Blender. Where is this environment sourced from?

Cheers,

Marek.

[Rj Zondervan]

How is your directory structure build up? Note that the textures should be placed in a subfolder of the folder where your gltf file is situated.

[superheatedsteam]

Thank you for your suggestion. Is there a specific folder name that the texture files have to be located in?

I currently have the 3 png files located in the same directory as the .glTF and.bin files. The Blender glTF exporter does have an option to include a subfolder.

I tested with and without sub folder names using obvious candidates line TEXTURE and TEXTURES and Process Monitor shows that RunActivity.exe will read the location that you specify in the Blender glTF exporter. However the texture file location does not appear to cause of this issue.

I worked out the images section in the .glTF determines where the textures are located.

Oddly, having the textures located in a sub folder made the MS 3D Viewer unable to open and display the .glTF file.

I will leave the image files in the same folder as the .glTF and .bin files in the mean time as the MS 3D Viewer is a handy viewing program for my testing.

It also appears that Blender only exports .JPG or .PNG files. I added .DDS files with the same file name and RunActivity.exe did not attempt to access any .DDS files in the locomotives folder yet did check the route and .S rolling stock locations when loading as expected.

In a vain attempt, I manually edited the "images":[ section of the glTF file to find PNG and replace with DDS but that did not force RunActivity.exe to attempt to access yet alone read any dds files in the locomotive folder and it broke the MS 3D Viewer.

Testing continues.