As a little note, both Future and ShadowMap lighting technologies don’t take part transparency into account iirc, so this is a non-issue as of currently, however this could change in the future.
I do however, heavily support this feature request, I have had to resort to using an incredibly hacky forcefield material glitch (that does not work on mobile because of the rendering for forcefield being different there), just to obtain this behaviour.
Okay, a picture says a thousand words:
The solution you’re describing would work when Transparency was 1 and LocalTransparencyModifier was anything else, but the results become confusing when you begin working with Transparencies less than one.
On paper this isn’t an issue, as you said anyone can just use a proxy part for the shadows. But from a practical standpoint this is just weird- and I’d dare say it’s simpler from a developer’s view.
I’m curious why you’re so insistent to not adding a new property because of serialization and performance reasons when ironically your proposed change would require LocalTransparencyModifier to serialize and replicate like a new property anyways? Even then, properties get added to instances all the time and we barely see any consequences to performance.
This feature request is only suggesting a behavior change to shadow rendering with respect to LocalTransparencyModifier. The property would remain local. The primary use case is shadows for your character being unaffected when you go into first person. This would “just work” for all camera scripts that use LocalTransparencyModifier to hide your character.
The reasoning is that LocalTransparencyModifier is primarily intended for use with the local player or camera obstructions, and thus the shadows should be preserved in those cases. The current behavior and my proposed behavior would both be valid, as it still modifies the transparency. Shadows are simply preserved as a practical feature. There’s no other way to achieve this, and first person shadows is a perfectly valid use case. I don’t believe changing serialization behavior or adding an additional property would be worth it for various reasons I’ve mentioned in my other responses.
This is true. In the future I think it’s likely to be added if it becomes practical from a performance/engineering perspective. I was using this case as a reason why not to add a “force shadow” bool/enum property.
Having the ability to have parts that cast-shadows yet are invisible is a MUST in order to create high-quality first-person games on-platform, I’ve had to resort to weird and funky rendering-bugs (that generally get patched, in-which I then I have to find a new bug that causes the same effect) to simply have a part render shadows while not visible, this is unacceptable for what should be such a simple and basic feature.
