Lighting issues with fabric-api-0.3.0+build.175
Pzkane opened this issue ยท 7 comments
Vanilla: https://imgur.com/a/wZgHsEU
API: https://imgur.com/a/jmWYy6I
This is actually a correct lighting outcome for the enhanced AO calculator. If someone made a modded block with that geometry they would probably never want/expect it to be lit that way.
Unfortunately Mojang and pack makers are exploiting the terrible lighting to achieve such effect because, well, they don't have any other options.
I see at least two ways to handle this, maybe we do both:
-
Make HYBRID the default lighting mode. (Prevents this specific problem at least).
-
Support a JSON listing, maybe via resource pack, of blocks/block states that should always receive a specific lighting treatment. Provides ultimate flexibility for pack makers who are dealing with a mix of models/modded content with different heritage. We could ship with defaults for known trouble makers.
Thoughts?
I think it should render the weird vanilla way by default and any block that wants otherwise should change it
You can change the lighting mode in the current build by updating indigo-renderer.properties in the config/fabric folder. Change it so ambient-occlusion-mode=hybrid
@Prospector Currently there's no way to know what the mod author intended unless we assume models that uses Meshes (which have to be created by the API) want enhanced lighting and models that are "vanilla" want vanilla lighting. That's what hybrid mode does.
Update: That wasn't quite accurate. There's a model method that can be overridden (isVanilla() or something like that, I forget the exact name) so it doesn't have to be a meshed-based model but it does need to be a custom model. That's probably fine.
You are then missing out on some visual improvements and bug fixes that come with enhanced lighting, but that will probably give the fewest bug reports.
Here's an example of the problems with the vanilla AO for blocks that aren't paths. Intention is to enable modded blocks to have lighting that is decent.