Fabric API

Fabric API

106M Downloads

Rendering changes from 0.2.7-127 to 0.3.0-170 API

lordrius opened this issue · 10 comments

commented

Hi!

I was using my custom resource pack along with Fabric API 0.2.7-build.127 and everything was working fine, but when i installed the latest build, 0.3.0-build.170, something is wrong with the rendering of tree leaves. My tree leaves have custom model with cross inside cuboid, here are the pictures:

0.2.7-127 API
https://i.imgur.com/erGtpWf.png

0.3.0-170 API
https://i.imgur.com/fijoNFi.png

Is this a bug? Can i do something to fix this issue?

Many thanks!

commented

Set always-tesselate-blocks=false in config/fabric/indigo-renderer.properties, for now.

@grondag what did you dooooooo

commented

Wait. I think I know what's up.

You see, Fabric's rendering patches fix bugs in Mojang's implementation of the ambient occlusion logic; and I think that's why the cross inside cuboid becomes lighter outside of the cuboid.

You could also try ambient-occlusion-mode=hybrid, which will only apply the fixes to Fabric mod models and not vanilla-type models.

commented

Tested both suggestions:

First:
always-tesselate-blocks=false
ambient-occlusion-mode=enhanced

Works fine for me... fixed
https://i.imgur.com/w4qy8cq.png

Second:
always-tesselate-blocks=auto
ambient-occlusion-mode=hybrid

Mmm something strange... not good :(
https://i.imgur.com/18y7sJw.png

Many thanks for the help!

commented

Could you please post your model JSON for those leaves?

From the screenshots, the issue does appear to be ambient occlusion lighting. Vanilla leaf models do have AO enabled, and by default Indigo uses an AO model that is better (in most cases) for non-cubic models, with the side benefit of being faster.

The AO changes in indigo would normally not affect cross-type models at all, because the parent model for grass, etc. (tinted_cross.json) has ambient_occlusion=false. It must, because the vanilla AO calculator isn't capable of correctly lighting cross-type models at all. (Or at least it shouldn't be.)

One limitation that both Indigo and Vanilla have in common is an inability to correctly light quads that extend outside the block boundaries. The limitation is inherent in the approach. (The lighter only has complete and reliable information about the block corners and the space within.) A more sophisticated lighting model would be out of scope for Indigo.

The thing that stumps me is how vanilla is not messing up those blocks if they have AO enabled. My guess is that its failure mode just looks better (and may be something we could replicate) or perhaps there's a bug in Indigo that is incorrectly applying AO to models that have it disabled. (Which is why I'd like to see the model file.)

For now, setting either of these should fix it:

always-tesselate-blocks=false
ambient-occlusion-mode=vanilla

If I'm correct, then setting ambient_occlusion=false in the model would also work, but that may be impractical or undesirable for other reasons. Edit: It would give you flat shading without these artifacts, but it probably wouldn't replicate vanilla.

commented

Hi!

Here are the files:

Vanilla leaves:
https://pastebin.com/NUvwusiy

Modified leaves:
1/2 https://pastebin.com/T7GNsn0B
2/2 https://pastebin.com/Nc1Ewnbh

Thanks!

commented

Yep, looks like it’s applying AO outside the block boundaries. Best guess is that Vanilla is clamping and Indigo is extrapolating. Really wasn’t something I tested for. Will look into it.

commented

Update: I've isolated the problem - Indigo is classifying these quads differently. Vanilla handles them as full faces and Indigo recognizes them as partial faces and thus uses a weighting function to assign brightness to each corner. The weighting function doesn't clamp to block boundaries so you get this effect.

At a minimum, the fix will be to classify quads consistently with vanilla for vanilla models. I may also improve the weighting function more generally for non-vanilla models to give less bad results for quads that exceed block boundaries. (Make it clamp to the block boundaries, essentially like a cube map texture.)

In short, should have a patch up tonight or tomorrow.

Fortunately the problem doesn't seem to affect other common model types. Running the lighter in emulate mode with debug comparison on and smooth lighting fix off found no discrepancies other than leaves. I'm using this resource pack for testing because it has this kind of leaf model.

#223 is far more serious, IMO, which I why I patched that one first.

commented

Many thanks for your help grondag!

commented

You're welcome. And thank you for the great bug report. Please don't hesitate to report anything else you notice. We want Indigo to be absolutely reliable.

commented

Guess we forgot to close this when it was merged.