Page MenuHome

Fix T100595: Lineart screenspace thickness ignores Resolution Percentage
AbandonedPublic

Authored by Philipp Oeser (lichtwerk) on Aug 25 2022, 1:05 PM.

Details

Summary

When changing the Render Resolution Percentage, screenspace thickness
ignored this, leading to different appearances of line thickness.

Would assume this is what artists expect, did not check if similar
lineart screenspace effects exist (and if so, if these are respecting
Render Resolution Percentage).

Diff Detail

Repository
rB Blender
Branch
T100595 (branched from master)
Build Status
Buildable 23521
Build 23521: arc lint + arc unit

Event Timeline

Philipp Oeser (lichtwerk) requested review of this revision.Aug 25 2022, 1:05 PM
Philipp Oeser (lichtwerk) created this revision.

The change looks logic, but I would like to hear the opinion of @Clément Foucault (fclem) before changing anything in the Draw Engine code.

Clément Foucault (fclem) requested changes to this revision.Aug 28 2022, 7:19 PM

Well, that's quite a breaking change. Things like wireframe shader also do not respect the scaling factor. So i am unsure if we should fix this. But it does make sense.

However I don't like where it gets injected.

source/blender/draw/engines/gpencil/gpencil_cache_utils.c
393–403

Readability

This revision now requires changes to proceed.Aug 28 2022, 7:19 PM
Philipp Oeser (lichtwerk) marked an inline comment as done.Aug 29 2022, 10:50 AM

However I don't like where it gets injected.

Got a hint for a better place?
(we are already messing with gpThicknessWorldScale in a similar way in the same function here https://developer.blender.org/diffusion/B/browse/master/source/blender/draw/engines/gpencil/gpencil_cache_utils.c$276)

Things like wireframe shader also do not respect the scaling factor. So i am unsure if we should fix this

Would assume the wireframe shader deserves to be fixed as well then (separately)? Cannot think of a scenario where you would actually want the current behavior.

However I don't like where it gets injected.

Got a hint for a better place?
(we are already messing with gpThicknessWorldScale in a similar way in the same function here https://developer.blender.org/diffusion/B/browse/master/source/blender/draw/engines/gpencil/gpencil_cache_utils.c$276)

I'm sorry, I didn't meant to send that in the end. But if that's something we want to fix for all screen space radii, we better put it in the ViewInfos instead and do the multiplication in the shader.

The scaling you mentioned is a workaround that was introduced to keep compatibility with old grease pencil when we refactored the engine.

But if that's something we want to fix for all screen space radii, we better put it in the ViewInfos instead and do the multiplication in the shader.

If that is the only way forward, there is probably no point in keeping this.
Might check on that solution as well, but for now, will abandon and step down then (until doing it in ViewInfos proves to work on my side).

But if that's something we want to fix for all screen space radii, we better put it in the ViewInfos instead and do the multiplication in the shader.

Just checking: this should still only affect rendering, right? (we dont want to change anything for the viewport when changing render percentage if I am not mistaken)

Just checking: this should still only affect rendering, right? (we dont want to change anything for the viewport when changing render percentage if I am not mistaken)

Yes. But this does pauses a question about viewport camera view + zooming in-out in it. Should this also increase the screenspace size? Should it be proportional to the render size? For me, it should.

But I would also check with @Brecht Van Lommel (brecht) if we can also change the behavior of the wireframe shader in cycles so that it is kept in sync with what EEVEE does.

I'm not sure it's worth doing this for wireframes?

If you use them for NPR purposes it could be useful, but for a typical render to show off topology I expect a wireframe with just enough thickness to be readable is what you want at all resolutions.

@Brecht Van Lommel (brecht) I took the wireframe node as an example, but to me anything labelled as in pixel units inside the shader system should behave consistently. IIRC it is the only shader node that has a pixel unit property.