Self-illumination even though Directx-Obj is not set

[ginga81]

Description

If we prepare a DirectX object with a header of 'xof 0302txt 0032', it will be affected by light in RouteViewer whether or not you assign a material to it, but in OpenBVE it will always be bright even at night, the same as if it were self-illuminated.
DirectX converted by assigning materials in Blender 2.79 -> metasequoia 3LE will be displayed correctly.
However, objects exported using Kusaanko's X exporter in Blender 4.0 or later will be affected.
https://github.com/kusaanko/Blender_XFileSupport_BVE
test.x was exported using Kusaanko's exporter.
The version of OpenBVE is 1.10.1.1.

Reproduction

Please use this sample route
x-self-illuminating.zip

Route

Please use sample route above.

Train

Maybe any.

Logs

This issue don't crash. So, no log.

Related information

[leezer3]

This is an exporter issue, not our bug.

Your X file has a emissive color set of pure white (255,255,255)
To get correct lighting, it should have an emissive color set of black (0,0,0).

X files don't allow you to enable / disable emission on a per-material basis, only set the color AFAIK,

[ginga81]

I see, that's how it is.
A user contacted me saying they couldn't disable Emissive, so I exported a dummy file, tested it, and submitted this report.
So the only solution is to make it emit light on the exporter side and assign black.
Indeed, if you assign a black material it will change to look like this image.


Left(on the rail):test.x(sample zip's)
middle:Black emmisive material
right:White emissive material

When using this exporter, it doesn't become pure black even if you assign black emissive, so it looks like I have no choice but to give up for now.
I was thinking of using this exporter to export it as an X object, but I think I'll continue with CSV.
If the specifications change, I'll export it as X.
It was a good opportunity to receive this report from a user.
I'll close this as it's resolved for now.

[ginga81]

I found a way to set the brightness correctly in Kusaanko's exporter.
By assigning materials in Blender and setting the Specular's 'Tint' and Emission's 'Color' as desired for each, I was able to control the self-illumination.
I'll write this down as a solution if someone encounter any lighting problems with X objects.

[ginga81]

I received a report from a user that the issue is still not resolved. I gave him test.x, which worked fine on my Ubuntu+wine, but unlike me, it did not display properly at his OpenBVE.
So I reopened it and attached his test data.




csv x object test.zip
It worked fine on my Ubuntu 22.04+wine (it still doesn't progress beyond 0% on mono), but on his Windows this data appears as shown in the screenshot.

[leezer3]

This seems OK to me at the minute on Windows. The main game is producing what I'd consider to be the 'expected' effect.

The difference in lighting between the CSV and the exported X cubes is because of the vertex normals:

(Screenshot in night mode simply as you can see them more easily)

Please can you ask what he's using in terms of ambientlight, directionallight and lightdirection values?

Also, are there any in-route changes of lighting values?
I'd have to check exactly what happens if objects are placed on either side of a lighting value change :/

[hotdamndel]

I've also found out that b3d objects are somehow much more performance-costly than x even if it's the same object converted into the different formats. Which does imply using x is better, but with the lack of support for its features (like selectable parts similarly to railsim) together with bad editability (impossible to scale/rotate via simple commands either appended to the model file itself or via commands in .animated and set certain things manually) it's not feasible currently - many model parts need to be removed completely and readded as separate models because Openbve can't use texture swaps, selective texture scale/shifts, part selections, etc

b3d + high object optimization:

x + NewXParser:

so tl;dr:

• b3d is way too performance intensive despite being a native format
• x offers significant performance improvement, but Openbve can't use it properly, making it unsuitable for train models with lots of functionality despite these being the most detailed, meaning these bottleneck the fps the most

[leezer3]

There is absolutely no difference internally between B3D and X.

Any performance differences are going to be solely down to the model exporter.
Specifically, I think it's likely to be a case of duplicate vertices being culled better & faces squashed more by whatever exported the X.
Unfortunately, there's no really easy way to dupe check 20k vertices

[ginga81]

According to his report, it only affects the 'Brightness' command.
Here is a screenshot of the 'ambient light' results.

[leezer3]

There's something very funny going on somewhere :/

The brightness command will have absolutely no effect on the lighting of the cubes you supplied above.
This controls the day / night texture blend (which these aren't using) and cab brightness.
It's not even passed to the render pipeline at all.

The screenshots look slightly odd (I'd expect a clear R,G,B tint), but this may be due to the directional light value, and the way the blending interacts.

Can he check to see if the old renderer has the issue?

[ginga81]

Do you mean you want screenshots with RGB 3 colors in the same ambient light using OldRenderer?

[leezer3]

I'll take a proper look next week.

Don't necessarily need any more screenshots at the minute unless I can't reproduce then.

[leezer3]

OK, I've tested on both GL1.2 and GL3 on this PC and on a VM.
This produces what I'd consider to be expected results, with a distinct R,G,B tint with each light type, which are nothing like what he's seeing.
Both GL1.2 and GL3 should be consistant, albeit with a slight brightness difference.

If his system does not produce the corresponding images with the attached files, then there's something seriously wrong, and not with the program.

255,0,0:

red.csv

0,255,0:

green.csv

0,0,255:

blue.csv

If these work, please can you attach the routefile he's using?
I can see it's the animated object demonstration route, but I'm interested in exactly how / where he's placed the lighting commands to get that result.

[ginga81]

I told him to follow this link, do a CSV test and submit the sample demo route data.

[leezer3]

I actuallly now know how he's caused that lighting glitch, although that was an accidental find......

It's being caused by an incorrect separator character in the routefile.

.AmbientLight(0,255,0)

This is incorrect, and causes the bug.

He should be using the semi-colon to separate the light components, e.g.

.AmbientLight(0;255;0)

I'm not sure whether this explains the rest of his issue, but I'll add an appropriate error message for this case in a minute.

[ginga81]

He has just told me that there was a spelling mistake, just like you said.
And that the sample showed up fine.

[leezer3]

Great.

I don't think we have an issue here then.
The slight lighting difference between the two cubes is just because they've got differing normals, and is absolutely to be expected.