Pixel 5 and 7 phones, Bézier trimmed bezels, camera bar support, soft buttons rework

[louisrousseau]

• Added entries for both the Pixel 5 and 7.
• Updated BOSL2 dependency.
• Support for camera "bars" as found on later Google Pixel models, the bar can serve as part of the shell generation.
• A solution to have a thinner lip on the edges for devices using gesture-nav, using BOSL2's Bézier features.

Here is a case printed in TPU for my Pixel 7, gyroid infill at 30% works pretty great.:

Don't mind the left lip corner looking weird, that was Cura being a bit stupid with how it handles settings (here: retraction distance) coming from so many different places and me not catching it in time.

[maave0]

This is sweet. Thanks for contributing. Pixel 4a doesn't build as-is so I'm playing with the buttons. I'll merge it soon

[louisrousseau]

I'm afraid there's a breaking change in b3bb987 - button_recess changes meaning and the formula for button_protrusion_compensated doesn't work either.

The names could be changed but ultimately there should be a way to adjust the button's elevation/protrusion from the rest of the phone body so the soft_button positive model sits flush on the device and an option to set different protrusion values on the outside of the case as well.

The old button_recess reads like it is meant to start from the phone body to the outer edge of the buttons with typical differences of 0.3mm between it and case_thickness in the JSON file.

I think I have an idea... I could add a dropdown and have both the "old" and "new" button codes co-exist.

Somewhat related: I have another work branch going for the Galaxy Tab S7 and S8 11 inch models, those have integrated fingerprint readers in their power buttons and you need a protrusion value distinct from that of the volume buttons if you want a solid button there.

[maave0]

I'd like to avoid duplicate code if possible. We'll figure out how to get them all on the same style of button.

"button_recess" is how tall the phone's real button is. That variable name is bad .... I draw the case's button at the edge of the phone (positive) overlapping the real button, then cut out the space for the real button (negative).

"button_protrusion2" was how much the case's button extends past the case, so 0.0 is flush with the case and 0.8 sticks out.

So button_protrusion2 should be configurable and renamed to "button_protrusion". button_recess should be configurable per-button and renamed to "button_height" or something. Does that cover your bases?

[louisrousseau]

Thanks for the variable clarification.

I had gone the duplicate code route to support both versions and allow a migration, but should be able to take another look at this in the next few days, aiming to refactor it all in one unified button code while not breaking the existing values in the JSON.

Going from memory, my code just does two prismoids from the wall, no need to subtract the device button from the case so long as the size touching it makes sense. I moved the wall closer to the outer edge of the case than in your earlier design - less wiggle room in the Z axis that way. (I'm on the third iteration of my daily driver case and it's working pretty well so far.)

I'm second guessing the buttons overhang angle values as well; I still like the idea of a "safe maximum" based on printer capabilities but am unsure on the implementation.

[louisrousseau]

I tinkered with the button code some more - debugging with the # and ! prefixes - and I figured out why the results of my button code didn't line up with what's in the master branch: on master, the "backing" and "negative" prismoids anchor arguments are missing a +BOTTOM so they end up closer to / inside the phone by button_recess / 2.

This also explains why the values for button_recess in the JSON looked oddly large to me - I don't know of any phone with buttons sticking out the sides 1.8 or 1.9mm.

Leaving myself another TODO in this refactoring pass: move the soft case button code out of manual_supports_();

[louisrousseau]

Err, that wasn't ready to merge

[maave0]

Oops. It's mostly good ... I like the new buttons and I need a new Pixel 4a case. Can you make a new PR for more changes?

[louisrousseau]

I was planning on finishing it tonight (Eastern Daylight Savings) and have a habit of making aggressive interactive rebases to tidy up the history.

May I suggest the following: make your 4a model, start your print, then reset the master branch to what it was prior to this merge + force push it back here.

I'll properly unify the button code and tidy the commit history then make a PR with that.

Sounds like a plan?

[maave0]

Sounds good. I'll wait a minute for the case 😁