The idea is for decals/textures to have light options that would either allow them to be affected by light or be static like GUI’s
Here’s an example in my case:
Made a brake light texture, the texture would be useful it imitated a light (GUI behavior).
You would need a light map to properly do that I think.
What about making the texture transparent in some areas?
If it even works that way.
Eh, not really.
Unfortunately that was a bug a while back and has been fixed.
Edited the OP, and I still think this could be really useful 
An emissive map would be even better, but yeah this is definitely something that could use improvements.
This thread looks like it might be a duplicate of my own. Append the LightInfluence property to Decal/Texture
Edit: It’s not, but it is very similar.
Edit 2: I do like the idea presented in this thread, and it will fit together with the proposed rework I stated in my own thread.
Rather, your thread is a duplicate of this one. Newer topics are the duplicates of the two.
It looks the same to me. OP is requesting LightInfluence, but not by name since it didn’t exist until later in the year.
Hey all. Just thought I’d suggest this idea. At the moment I’ve had several needs for decals to be unaffected by lighting, which are impossible to achieve with the current available properties.
My #1 example is a custom skybox object using a MeshPart. The MeshPart is a cube with smooth and inverse normals that takes 6 decals, one for each surface. Changing lighting’s properties does not offer enough. The primary use case of this mesh is the ability to change the color of the MeshPart when using some skyboxes as to create a custom hue in images with alpha.
The sky presented above is affected by lighting normally. Unfortunately, I can not change the ambient settings due to the need for shadows and other lighting in my game. Additionally, I can not use SurfaceGui as they are unaffected by surface normals and do not conform to the surface of a part as a decal would.
The list of use cases is one of the most important parts of a feature request. Please consider including the problem you are trying to solve in the first place rather than a consequence of it, that will allow staff members to understand better what you need to solve it. If you just give one particular solution, they cannot understand your actual problem and cannot work towards the best solution.
I’ve edited my post accordingly.
You could create 6 parts instead of 1 and then put SurfaceGuis on those. Why are you even making a custom skybox in the first place?
It’s so that I can use textures with alpha, as I said in OP. Also, using 6 parts does not work because you can clearly see the edges in the skybox. The mesh I have is a perfect cube but has smooth normals that remove those harsh edges.
…True! Didn’t check the post date. Whoops.
Just going to bump this as I still see a lot of use cases with this. On the other hand wouldn’t this be something fairly simple to implement considering particles, beams, and trails have light properties?
There are many good use cases for a feature like this.
For example, I am creating a game where multiple “Skyboxes” need to exist at once, with layers of transparency and rotation to help emulate a more complete day/night system as well as clouds.
My current best solution is to create a grid of parts that have SurfaceGuis in them with each part presenting a different portion of the total image, seamlessly blended in with the rest of the grid. On it’s own, this isn’t that bad, but when you start to try and apply rotations and other transformations to the overall structure every frame, it starts to cause issues starting on high-end machines.
An easy fix would be getting SurfaceGuis to cover the face of a brick SpecialMesh/BlockMesh so that a >2048 stud SurfaceGui can be positioned, however this can’t be done as SurfaceGuis do not respect SpecialMeshes/BlockMeshes and instead cover by the parts size property rather than the SpecialMeshes/BlockMeshes scale property.
Another implementation that I would’ve gone for is putting a decal/texture on a part with a SpecialMesh/BlockMesh or using an inverse cube mesh, which works fine with one caveat, the caveat being that the decal/texture is influenced by light and looks completely off and out of place.
That latter implementation would be best if decals/textures had a ‘LightInfluence’ property just like SurfaceGuis, this could be helpful in other situations like where the decal/texture is applied over a mesh and needs to wrap around the mesh.
Overall, seems like a simple feature that has been put off for far too long. I look forward to seeing this implemented one day.
