Transparency trouble with new renderer on 1.7.1.4, loading screen and proccessing bar both not shown only linux

[ginga81]

Old renderer is not happen transparency issue. Loading screen trouble is only on Linux, not happen on Windows.

This trouble happens at my tohoku-shinkansen route. http://midnightexpginga81.web.fc2.com/touhoku_shinkansen/route_data/Touhogu-Shinkansen-Routedata-fromSendai_v0.06.zip This screenshots are now creating new version, so difference. but most objects are the same, and also happens. The cars are all of my released outer-view object, Series-200, 925, E5 and E6.

I tested the daily-builds. OpenBVE-2020-04-20.zip:OK OpenBVE-2020-04-21.zip:NG

At objectViewer's options_ov.cfg, isUseNewRenderer key change also I tested at 1.7.1.4's. There are not differense about transparency. This object that I tested. Touhogu-Shinkansen-Objectdata-v0.15.zip https://onedrive.live.com/redir?resid=2E630AFCBBE39699%21159 Object/OpenOBJs/Dike&Wall&Roads/Shinkansen/Pole/PoleR.csv

Please check these troubles.

[leezer3]

Will do.

I suspect something funny in the drivers (default state maybe?) as I did quite a bit of testing on Mac with this and definitely didn't see any glitches :(

[s520]

When NewRenderer is enabled, ObjectViewer's key display is not correct to begin with. After April 21:

Probably the cause is https://github.com/leezer3/OpenBVE/commit/4ab05b45fde9df1663049bb94159956948268293.

The confirmed environment is as follows:

• Windows 10 x64
• Intel Core i5-10210U
• Intel UHD Graphics

ginga81 uses Radeon and I use Intel so I don't think the graphics driver is the culprit.

[leezer3]

It's typical, nobody notices anything broken until you push a release :)

I've fixed the key display for both viewers- Forgot to reset the blending type; The overlays are drawn with the old renderer. Need to sort out text drawing with the new renderer ( @LabRatAndy has done some on this in his branch)

The brightness issue turned out to be a rather more major oversight- We forgot to reverse the Z of the normal when adding it to the VAO.

[ginga81]

My PC's spec: OS:Ubuntu 18.04.4 LTS 64bit Memory:31.4 GiB CPU:AMD® Ryzen 7 2700x eight-core processor × 16 Graphics board:Radeon RX 590 Series (POLARIS10, DRM 3.33.0, 5.3.0-46-generic, LLVM 9.0.0) propraietary AMD Graphics driver

[leezer3]

OK, might have it nailed now- Give the latest a try when it builds in a few minutes.....

Partially reverted https://github.com/leezer3/OpenBVE/commit/4ab05b45fde9df1663049bb94159956948268293 after fixing the Z-normal issue, as now all of a sudden some things work somewhat better & more as expected. I hate blending ;/

[ginga81]

I tested OpenBVE-2020-04-26.zip rapidly. the result is as shown by below. around UV's area transparency is fine. the another UV such as this tree, overlaps the another texture is not shown. And transparent light color is not paint. But, these issue is already happen at 1.7.1.3. So, I think that this is the another issue.

[leezer3]

Which exact object file is that powerline please?

I can't immediately find it, and it'll be a lot easier to test if I can isolate it.

The tree looks like a Z-sort issue. I'm guessing the powerline is part of a somewhat larger object and overlaps it? These have always been problematic.

[ginga81]

Oh... I am sorry. This object is a new version for my route. So, current version is not bundle. Please test this sample route. This route is using two objects that is the same screenshot above. So, OpenBVE-2020-04-26.zip and 1.7.1.4 happens also. transparent-trouble-sampleroute.zip

[ginga81]

I and S520 both tested below. This test is using by transparent-trouble-sampleroute.zip. The result is shown below. One of problem, light's exposure UV texture affects transmission through. (Is this may be Z-order?) The another problem is Ground color is very brightness. These probrems, we doubt that the result by as below, causes by Route.AmbientLight and Track.fog.

These problems are by route's comand affects. So, these problems are cannot be reproduced at ObjectViewer.

Light's exposure UV texture affects transmission through

OpenBVE-2020-04-26.zip

• Route.AmbientLight: enable

  • NewRenderer: NG
  • OldRenderer: NG

• Route.AmbientLight: disable

  • NewRenderer: OK
  • OldRenderer: OK

1.7.1.4

• Route.AmbientLight: enable

  • NewRenderer: NG
  • OldRenderer: NG

• Route.AmbientLight: disable

  • NewRenderer: OK
  • OldRenderer: OK

Ground color is very brightness

OpenBVE-2020-04-26.zip

• Track.Fog: enable

  • NewRenderer: white
  • OldRenderer: green(normal)

• Track.Fog: disable

  • NewRenderer: green(normal)
  • OldRenderer: green(normal)

1.7.1.4

• Track.Fog: enable

  • NewRenderer: white
  • OldRenderer: green(normal)

• Track.Fog: disable

  • NewRenderer: green(normal)
  • OldRenderer: green(normal)

[leezer3]

Try the latest- This should be somewhat better. (We were incorrectly transforming the normals in the shader; Should have been untransformed)

There's still something funny going on with the normals on your lights (Will investigate later- going to work), which means the color is still missing, but both renderers are now I believe identical.

[ginga81]

I tested at OpenBVE-2020-04-27.zip. NewRenderer option is on or off, both option is crashed. The train is https://github.com/leezer3/OpenBVE/issues/435 And the route is transparent-trouble-sampleroute.zip

OpenBVE Crash- 2020.4.27[22.36].log

[s520]

Variable type is not defined. https://github.com/leezer3/OpenBVE/blob/32376c5a5a1a05fad4c330db99665e68c3221edd/assets/Shaders/default.vert#L52

I think the problem with Fog is that the Fog expression in the shader is wrong. I am investigating it.

[leezer3]

That's odd, it works on Windows.

I think the fog issue is likely normal related though- Turn on the normal display and toggle between renderer types in route viewer.

[s520]

Error log is output on my Windows. (F9) The screen says "New (GL 3.0)", but this only reflects the option settings, not the fallback to legacy.

[leezer3]

Dunno.

Maybe I had an uncommitted change? Either way, needs sorting.

[s520]

Perhaps I was able to fix Fog. I will open PR...

[leezer3]

Now, this is what I see with the normal display active in Route Viewer before the new renderer was introduced:

Using the GL1.2 render path (verified by stepping in the debugger), I now see this:

Reading the code says that there have been no changes to the normal rendering. Thus, I think we're either applying or missing a transform somewhere when we create the object.

[leezer3]

Interesting- With a basic test object in Object Viewer, I'm wondering if we're somehow loosing the Y co-ordinate of the normal.

[leezer3]

Aha: https://github.com/leezer3/OpenBVE/blob/master/source/LibRender2/BaseRenderer.cs#L1427 Typo in this line for the normal display in the old renderer.

[leezer3]

I'm confusing myself again.....

I've now pushed some changes to your branch. See what you think; I think the main issue is the light now?

This is an issue with our blending in the fragment shader somehow (the texture uses alpha channel transparency), which I can't get right at the minute :(

[leezer3]

Done a bit more messing on your branch, see what you think now.

This has sorted the light (at least i hope so.....) The main issue now is that there's a halo around some textures using alpha- See the insulators and stuff on the pylon. ?? http://www.realtimerendering.com/blog/gpus-prefer-premultiplication/ ??

[leezer3]

@s520 Another branch here with a bunch more fiddling around on: https://github.com/leezer3/OpenBVE/tree/FogFix2

At the minute, I can't get the alpha to play nicely with the border of the texture, but otherwise it's decent, and the lights look relatively good. The other issue is that the houses on the left are considerably darker. This is an issue back to 1.7.1.3 and prior.

Something is off somewhere with the lighting calcs....

[leezer3]

@s520 When you get a minute, please take a look at the new branch. I've fixed the alpha borders on the textures by applying the lighting results after the texture. This leaves the issue that our houses on the left are darker.

Interestingly, reversing the X-cordinate of the normal gets us closer to correct in this regard, but makes other things off.

Can't explain it at the moment, but I'm tempted to merge this new branch into master (and push a further release), as it makes things much better with the stuff above.

Edit: Interesting... Negating the view normal gets lighting to look nearly right. Need a second pair of eyes though.

[s520]

I don't have a lot of time today, so I'll check back tomorrow.

[leezer3]

No trouble- This can wait I'm sure :)

[s520]

I built and tried your branch.

I'm a little confused. The issue with this comment looks the same in v1.7.0.3. https://github.com/leezer3/OpenBVE/issues/466#issuecomment-619619294

I give him the built program and ask him to see it.

[leezer3]

I thought the light color was now yellow / white as opposed to black :/

That was the major issue; The transparency is the same with both renderer.

I'll test once home.

[leezer3]

See if these images help to explain (tested just now): This is how the light now looks with my fix (correct):

The GL3.0 renderer in all previous cases has looked like this: (From your branch)

However, the houses on the far left currently look like this:

With the old renderer, they look like this:

[leezer3]

The tree / light interaction at the minute I haven't touched, and are the same in all renderers.

This is a drawing order issue- In order for correct transparency, we need to draw from far to near; This seems to be being calculated from the enclosing object not the face itself. Might be able to redesign this, but probably a major job....

[s520]

I asked him for confirmation. In addition, I asked him to sort out the problem.

[leezer3]

No trouble, thanks!

[leezer3]

I've merged my branch into master.

Intending to put out a build on Wednesday with this, as there are several important improvements in this.