Texture Issues - Traffic Signals (1 Viewer)

Mitchul

Some dude.
May 23, 2018
77
1
268
Melbourne, Australia
Pronouns
He/Him
Hey guys,

So I've created a set of my own traffic signals. I made my own as all of the other amazing third-party traffic signals that people have made for OMSI are too big for Australian standards. Plus Australia has specific signal set-ups that I'd like to mimic for a map I'd like to make.

Anyway, I'm having some issues with texturing and different times of days. Obviously traffic signals are meant to stay illuminated twenty-four-seven, however my textures dim with the daylight. How would I fix this? The illuminations on other signals created, including RoadHog's awesome UK signals, don't dim depending on the time of day. They stay illuminated at the same brightness regardless of the time of day. My signals also look brighter at night than they do during the day. I've attached some photos and included one of M+R's stock German signals for reference. And a sneaky one of my own of the signals I created.

nighttexture1.jpg

nighttexture2.jpg

nighttexture3.jpg


And a cheeky plug of what I made:
signalsdemo.jpg
 
Solution
In short, no - however, caution should be exercised as there are issues with the editor and attached objects. It is not normally a problem, but it can be the source of bricked maps in development if the parent object is attached to a spline, and that spline is corrupted in one way or another. There is no effect to the end user, though. If anything, it would help the end user as there aren't hundreds of unique objects to create every configuration, therefore reducing tile load time and memory use.

As an example, with Road-hog123's traffic lights, you can potentially have a pole with the bracket attached - the aspect attached to that, and a few supplementary signs attached to that.

Traffic lights would not normally need attaching to a...

Advertisement

Mitchul

Some dude.
May 23, 2018
77
1
268
Melbourne, Australia
Pronouns
He/Him
I put a light bloom on each aspect, but it didn't make much of a difference, if any at all. I looked at the .sco file of other add-on signals, and they seem to be the same as mine. I'll add my .sco file.

[groups]
6
CreationsByMitchul
Signage
Traffic Signals
200mm
Body
3 Aspect

[friendlyname]
Tram Points Left

[mesh]
200mmbody3.o3d

[trafficlight]

[mesh]
200mmtrampointstop.o3d

[visible]
red
1

[mesh]
200mmtrampointleft.o3d

[visible]
yellow
1

[mesh]
200mmtrampointstraight.o3d

[visible]
green
1

[script]
1
script\semafor3.osc

[varnamelist]
1
script\semafor3_varlist.txt

[detail_factor]
0.1

[new_attachment]

attach_trans
-0.000
-0.000
-0.000

[new_attachment]

attach_trans
-0.260
-0.000
-0.000

[new_attachment]

attach_trans
0.260
-0.000
0.000

[new_attachment]

attach_trans
-0.260
-0.000
0.254

[new_attachment]

attach_trans
0.260
-0.000
0.254

[new_attachment]

attach_trans
0.000
-0.000
-0.254

[new_attachment]

attach_trans
0.000
-0.000
0.762

[collision_mesh]
200mmsv.o3d

[complexity]
0

Regards,
Mitch :)
 

BlueOrange

Founder of Masterswitch Studios
Masterswitch Studios
Mar 22, 2016
510
4
3,846
23
masterswitch-studios.com
Ah, I can somewhat help here.

You're using seperate meshes with visible tags. However, you ideally want to be using a nightmap. This would be a seperate texture that has the lit lenses textures in the same location as they appear on the main texture.

For example, here I am using a lightmap to illuminate the MSID system in my bus: (you can ignore matl_nozwrite and matl_alpha
48378


2091 is the variable for the lightmap to use (what you've used for the visible tags) - you need to have a different material for each colour lense on the traffic lights too, and depending on the order it is in inside of blender or your 3d modelling program, would be the number you put on 2081 (the index).

I hope this somewhat points you in the right direction, though I can imagine Roadhog coming along and giving a proper explanation on how this system works.
 
  • Like
Reactions: Mitchul

Mitchul

Some dude.
May 23, 2018
77
1
268
Melbourne, Australia
Pronouns
He/Him
Ah, thank you - you're a damn legend! That fixed it! It wouldn't have been something I would have ever thought of.

updatedtrafficsignals.png


I have a secondary question. Will having too many things attached to one object cause an FPS/lag issue? Similar to the rest of the world, we use various different visor styles/lengths and louvres on our traffic signals. The way I've created my signals is in a modular-esque kind of a fashion. The signal bodies, the visors and signal accessories (target boards and louvres) are all separate objects.

So you would, for example:

Place pole -> attach mounting strap to pole via "Attach To" function -> attach signal body to mounting strap via "Attach To" function -> attach upper quadrant signal via "Attach To" function -> attach visor to signal body via "Attach To" function -> attach target board to signal body via "Attach To" function.

Which means that there's three separate objects anchored to one object, which is then further anchored to another, and then again anchored to another.

Regards,
Mitch :)
 

iomex

UKDT
Dec 10, 2015
1,548
39
2,528
In short, no - however, caution should be exercised as there are issues with the editor and attached objects. It is not normally a problem, but it can be the source of bricked maps in development if the parent object is attached to a spline, and that spline is corrupted in one way or another. There is no effect to the end user, though. If anything, it would help the end user as there aren't hundreds of unique objects to create every configuration, therefore reducing tile load time and memory use.

As an example, with Road-hog123's traffic lights, you can potentially have a pole with the bracket attached - the aspect attached to that, and a few supplementary signs attached to that.

Traffic lights would not normally need attaching to a spline, but it is something to bear in mind.
 
Solution
This thread is more than 4 years old.

Your message may be considered spam for the following reasons:

Users who are viewing this thread