profezzorn / ProffieOSDocs

Documentation for ProffieOS
GNU General Public License v3.0
7 stars 11 forks source link

Ressurect PR #55 | Added image and additional description for ORIENTATION_ROTATION #60

Open ryancog opened 2 months ago

ryancog commented 2 months ago

Closed after old account was deleted: https://github.com/profezzorn/ProffieOSDocs/pull/55

This is a duplicate picking up from where that PR left off.

profezzorn commented 2 months ago

I think the image is confusing. Does the arrow mean "it turns it this way", or does it mean "if your board is mounted this way" ? Also, rotation around the Y axis is most common, so I think that is the most important one to include in the image.

ryancog commented 2 months ago

Does the arrow mean "it turns it this way", or does it mean "if your board is mounted this way" ?

Well, the define specifies how the board has been moved from "zero" (if at all) and the logic accounts for it, so it only makes sense to me that the arrows mean "if the board is mounted this way", reflecting the nature of the define.

Also, rotation around the Y axis is most common, so I think that is the most important one to include in the image.

I'll have to create some of my own renders to do that then. Like I said there weren't any great references out there already. Do you have a good way of generating renders with a transparent background? I know KiCAD will do a render preview, but I'm pretty sure it's got a gradient on the background (so I couldn't just color select and remove it)

profezzorn commented 2 months ago

I think in KiCad you can make changes to the background, and I think you can make it solid.

ryancog commented 2 months ago

Erm... well, you're right about being able to make the background solid (really able to change gradient start and end colors, but same difference), but I don't have any of the 3D models, so it makes for a rather unimpressive render...

ryancog commented 2 months ago

Forgive me, but tracking down and linking every STEP file is not something I've got planned for today, so that's not an option.

IMO the images on the right are more meant to be examples of how things move and how that correlates with values in order to strengthen the indication of the arrows on the main image on the left. So not having images for all three axes on the right isn't that big of a deal. It's an illustration of how to use the diagram more than an exhaustive set of examples, if that makes sense.

profezzorn commented 2 months ago

I'd prefer to have an illustration that says: if your board is mounted like this, try this value, for a couple of common ways the board may be mounted.

ryancog commented 2 months ago

I guess I'm not sure how that's different to what's already there, bar explicit explanation?

I could add an explicit note explaining that...

profezzorn commented 2 months ago

I think the biggest difference is putting some sort of representation of the hilt in the image. I think it's particularly important when you have the USB mounted towards the blade, so you end up with angles like 225 degrees or something...

ryancog commented 2 months ago

Wouldn't it be more ideal to use #define ORIENTATION ORIENTATION_USB_TOWARDS_BLADE and then also ORIENTATION_ROTATION in conjunction?

It seems to me like you'd want the ORIENTATION define to get things as close as possible to what's representative, then use ORIENTATION_ROTATION to tweak from there? Specifically so you don't end up with values like that.

profezzorn commented 2 months ago

Not sure which is better really. I see your point, but it can also be confusing to use both.

ryancog commented 2 months ago

Hmm