Fix Blender "In front" option
Blenders "in front" option has never worked correctly and the documentation doesn't really state what is going on. Implied knowledge / assumed knowledge is never good for anybody.
So errrrm, forget hold my beer and passing it of as a limitation. If Blender can't or you can't do it then just tell the community, "I don't know how to do it", and make the corrections to reflect where Blender is at. Its going to be O Kayeeeee. OK.
There are a couple of ways this can go:
- Fix the documentation (This is probably harder than writing the code and making it more confusing - I don't know, I could be wrong).
- Update the UI so the option isn't available in the other render modes (Not kool because the user has to remember that and Blender is changing thing something on the user that the user may not know).
- Make it do what it actually says.
Bug reports:
- projects.blender.org/blender/blender-manual/issues/104664
- projects.blender.org/blender/blender/issues/116117
Twitter discussion: twitter.com/MrAdamEarle/status/1734938666211152327
4 Comments
To communicate the full context for others, the in-front option is in the "Viewport Display" panel of object properties - meaning it's a display option only affecting the viewport. It's meant for use for managing objects within/clashing with each other, such as armatures inside of objects. It's not about parity between the viewport and render, it's to be helpful in the viewport view outside of rendering.
The official documentation in the Blender manual (maybe this was what they changed, not sure) says "The Viewport Display panel is used to enable extra display options for the 3D Viewport." It specifies that it's only applying to the viewport. When using the rendered or material preview modes, those are not using the viewport's render engine, but Cycles and Eevee respectively. This is also the case with their respective culling settings.
You mentioned your use case would be line art, ie ensuring an object is always placed on top of the render. As a compositor, I run into this problem. It's commonly resolved using view layers and passes in the compositor. And it can be done automatically as part of the rendering process. The nice thing is when saved separately, it can even save re-renders, which you mentioned as another issue too! :)
I think the fix should be to make the name more descriptive. I did a test on the twitter thread that AdamEarle created and noticed that while I thought the panel affected the viewport (the area of the screen that displays the 3D scene) it is actually a specific setting of the workbench engine (which seems to be the same displayed in solid mode), I confirmed that with the twitter test in which the hierarchy of the "in front" setting remains almost the same in the viewport and the image already rendered in the workbench engine (not the viewport), except in the others modes. So I think that rather than being a feature that "doesn't work" as AdamEarle says, it is specific to an engine as you mentioned and also on the development page.
The problem is that some of the additional options in that panel "do work" for the other rendering engines, but only in the viewport (the area of the screen where the 3D scene is and only as a preview), for example "display as : bounds, wire". I feel that there is a confusion between viewport (the area of the screen that displays the 3D scene) and viewport (the render engine that uses the solid mode and the workbench render mode), the functions that are grouped in that panel are a mixture of that which makes others people think it's broken and I don't blame them since I was just believing that too. Thus, I think a review is necessary in terms of UX and UI that can help separate or, if possible, rename these functions so that we can understand what they really do. Documentation is also very necessary in this case, even more so to clarify which of the two "viewport" mentioned above the panel options refer to.
I'm not into lineart and I never used this option appart from rigging, so my point of view is not really fundamented. But, in any case, what I can see is that the documentation is not updated and that the best scenario is that the front option should work in several views.