Bug: Odd Shader behavior on Disconnected Mesh (Keylight Direction terminology misnamed.)


I have a couple of support pillars with textures in my domain Center (or Centre, depending on how you spell it). Their shading seems abit… inconsistant, and it became visible to me after @MirceaKitsune reported issues with their shaders

The components are separate in mesh, but apart of the same object.

See following image:

The Left is the shot from Hifi, the Right is from Blenders OpenGL renderer (GLSL based)

Same sorta issue occurs if model is made into Dae and FBX, (this breaks bounding rotations) and as Obj (this breaks uv mapping).

Both textures are identical in color pallet and shader settings.


Thanks @Menithal I have reported this as a bug


@chris On further investigation: this seems to be most noticeable if a zone is present, where the keylight direction is 0,-1,0 such as Sunset Skybox from the marketplace: If this value is changed in anyway from the default, the shaders correct them selves to as is.

With this in mind, I think the shader behavior actually might be correct (the mesh are near vertical / below the surface that the light would hit to): It simply is missing the shadows cast on its surface, in areas where the light wouldnt reach to make it more sense. However the naming is incorrect.

The Key-light direction field for zones is actually currently the keylight’s unit vector, not the rotation

Was off put by having Jaw, Pitch, Roll in the edit fields.

So the actual bug is the fact that the keylight direction parameter is misnamed to use Jaw, Pitch, Roll instead of XYZ.
This would explain why 0,-1,0 would only be directly top down and that the shaders would behave as they did in the OP screenshots. or why 0,-0.1,0 has same effect as 0, -1,0, and so forth.

This also means that if the values of the vectors are any larger than 1, or smaller than -1, the value still would count as 1 or -1.
I suggest limiting the value from -1.0 to 1.0 and renaming: or having a static unit vector that’s direction is defined by an euler rotation, as calculating some of the vectors for some angles is too much work for an average content creator and would occasionally need square roots that are not supported by the system.

In short “as is” is currently too confusing, for them to presume its broken.


Seems like the same thing I reported around yesterday:


I can confirm this, including the diagonal division and shaders either working on one side or never working at all. Eagerly waiting for a fix myself.


The issue here is different though as I pointed out in the post above


Oh… sorry about that then. Got the impression it’s the same shader bug, and that rendering some meshes might be causing the screen to get split in that case. Maybe they somehow relate still.