Integer direction problem

Bugs
, ,
1

There is a problem with meshes that are perfectly aligned. Somehow they appear black even though they have an emissive color. Here are two lines with one of them being tilted ever so slightly:

2

It seems to have more to do with StandardMaterial itself than emissive.

Also, you need to disable it after declaring it as wireframe enabled so that the colors are displayed correctly.

3

Interesting. But only the combination of PBR material and wireframe disabled seems to not show this problem. Odd.

4

With standard useEmissiveAsIllumination should be used: https://playground.babylonjs.com/#MF6IXX#16

5

I see. So this is not a bug? What is the purpose of this black line under that specific angle with emissive texture? But somehow hard for the standard user to know, that this flag has to be on.

6

emissive has two mode by design, the second is a true emission like a light bulb whereas the first is impacted by some other properties of the light.

7

We don’t consider it to be a bug, because line meshes don’t work properly with lit shaders: they don’t have normals, so lighting doesn’t/can’t work as expected. The easiest way to fix your problem, I think, is to set disableLighting = true for your material:

2 Likes
8

Thanks for the explanation and suggestion. I clearly don´t understand enough about the internals of Babylon.js. However, from a user perspective, an “emission” texture does not sound that it necessarily needs normals, except for a possible Lambert-Emission property, but this is not applicable to lines I guess.

But more importantly it is still unclear to me why exactly he zero or ninety degree direction break down so suddenly, rather than having any form of smooth disappearance if you are really using normals.

One can even observe some presumably precision-related issues happening with such lines. If they come close to such a direction, some pixels are “missing”, whether the others have full brighness. This sounds a lot like a division by zero problem or alike. Accounting for normals first and then undoing it by a post-correctin step?

Anyway: To avoid that other users fall into the same trap as me, does it make sense to change the default for such line-like textures to “disableLightnig = true”?

I oberved that the splines have a problem that they often disappear at closer distance, even though they are still behind the front clipping plane of the view frustrum. Is this problem related to the same issue?

9

Your material not only has an emissive texture, it is also lit by the light(s) of the scene (in fact, another fix would have been to remove the light from the scene, but then the ground is not lit anymore). The problem of not having a normal is that the result of the lighting calculation is undefined: in the default position of the camera for your PG, when I debugged it, I could see that the lighting result was negative. That’s why the line was darker green / full black, and not full green.

Indeed, see above, not having a proper normal is not supported when lighting is enabled, the result could be anything.

I think it does, even if it’s a “breaking change” (but I don’t see why we would not set disableLighting for the material of a line mesh). cc @Deltakosh and @sebavan for their opinion.

I don’t think so, if you can provide a repro, we can take a look.

10

I see no problem to change it

11

Here it is:

1 Like