blender
/
blender-developer-docs
4
4
Fork 25
Code Issues 1 Pull Requests 7 Activity

Add docs for how object's stored transforms work #23

Open
Nathan Vegdahl wants to merge 4 commits from nathanvegdahl/blender-developer-docs:stored_object_transforms into main
pull from: nathanvegdahl/blender-developer-docs:stored_object_transforms
merge into: blender:main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Conversation 6 Commits 4 Files Changed 1 +55
Nathan Vegdahl commented 2024-02-15 14:34:54 +01:00
Member
Copy Link

The main point is to document how loc/rot/scale interact with
dloc/drot/dscale. But this also covers the parent-inverse matrix.

The main point is to document how loc/rot/scale interact with dloc/drot/dscale. But this also covers the parent-inverse matrix.
Nathan Vegdahl added 1 commit 2024-02-15 14:34:55 +01:00
9c964240e4 Add docs for how object's stored transforms work 
The main point is to document how loc/rot/scale interact with
dloc/drot/dscale.  But this also covers the parent-inverse matrix.
Nathan Vegdahl commented 2024-02-15 14:37:03 +01:00
Author
Member
Copy Link

My main questions:

  1. Is this the right section to put this documentation in?
  2. Is there a better term to use than "stored transforms"? The distinction I'm trying to make is between the base, source-of-truth transforms of an object vs those that result from applying parenting, constraints, etc. Not sure if we already have a term for that.
My main questions: 1. Is this the right section to put this documentation in? 2. Is there a better term to use than "stored transforms"? The distinction I'm trying to make is between the base, source-of-truth transforms of an object vs those that result from applying parenting, constraints, etc. Not sure if we already have a term for that.
Hans Goudey commented 2024-02-15 16:30:35 +01:00
Member
Copy Link

Nice to have documentation like this! Two thoughts:

  • I think the lines are meant to be wrapper at 100 (?) characters or so, that just makes editing a bit easier I guess.
  • Personally I find the text about how the different properties are combined with the delta properties a bit too details for the docs. They read more like a description of a function in the code. In that case the function itself should be well documented and easy to read. It might be better to sum it up in a sentence or two and then refer readers to the function docs/implementation for more detail.
Nice to have documentation like this! Two thoughts: - I think the lines are meant to be wrapper at 100 (?) characters or so, that just makes editing a bit easier I guess. - Personally I find the text about how the different properties are combined with the delta properties a bit too details for the docs. They read more like a description of a function in the code. In that case the function itself should be well documented and easy to read. It might be better to sum it up in a sentence or two and then refer readers to the function docs/implementation for more detail.
Nathan Vegdahl commented 2024-02-15 16:47:36 +01:00
Author
Member
Copy Link

It might be better to sum it up in a sentence or two and then refer readers to the function docs/implementation for more detail.

That's fair, yeah. In this case, I documented it because that specific question came up when we were trying to make a related decision, and it ended up being a bit annoying to track down. But the main challenge was finding the relevant functions. So I can just summarize "the components are combined individually before being assembled into a matrix" and then point to the relevant functions for when more details are needed.

I think the lines are meant to be wrapper at 100 (?) characters or so

Oh! I didn't realize that. For prose I personally find that hard wrapping actually makes editing harder, since I always edit prose with word wrapping on anyway. And hard wrapping just means I have to take the extra step to re-wrap things after I've made edits. But if that's already been decided, I'm happy to adhere.

> It might be better to sum it up in a sentence or two and then refer readers to the function docs/implementation for more detail. That's fair, yeah. In this case, I documented it because that specific question came up when we were trying to make a related decision, and it ended up being a bit annoying to track down. But the main challenge was finding the relevant functions. So I can just summarize "the components are combined individually before being assembled into a matrix" and then point to the relevant functions for when more details are needed. > I think the lines are meant to be wrapper at 100 (?) characters or so Oh! I didn't realize that. For prose I personally find that hard wrapping actually makes editing harder, since I always edit prose with word wrapping on anyway. And hard wrapping just means I have to take the extra step to re-wrap things after I've made edits. But if that's already been decided, I'm happy to adhere.
👍 1
Hans Goudey commented 2024-02-15 16:53:19 +01:00
Member
Copy Link

So I can just summarize "the components are combined individually before being assembled into a matrix" and then point to the relevant functions for when more details are needed.

Thanks, sounds great!

For prose I personally find that hard wrapping actually makes editing harder, since I always edit prose with word wrapping on anyway

Yeah, it's not easier for me either TBH. But it's nice to be consistent.

> So I can just summarize "the components are combined individually before being assembled into a matrix" and then point to the relevant functions for when more details are needed. Thanks, sounds great! > For prose I personally find that hard wrapping actually makes editing harder, since I always edit prose with word wrapping on anyway Yeah, it's not easier for me either TBH. But it's nice to be consistent.
Julian Eisel commented 2024-02-15 16:57:21 +01:00
Member
Copy Link
  • I think the lines are meant to be wrapper at 100 (?) characters or so, that just makes editing a bit easier I guess.

We indeed use a 100 character (actually 99) limit, see style guide. It seems like people expect a line limit, it kept coming up as question. Maybe relying on editor line wrapping is fine, but I'd hope that auto-formatting takes away any effort either way. That's why we have the .editorconfig in place now.

> - I think the lines are meant to be wrapper at 100 (?) characters or so, that just makes editing a bit easier I guess. We indeed use a 100 character (actually 99) limit, see [style guide](https://developer.blender.org/docs/contribute/markdown_style_guide/). It seems like people expect a line limit, it kept coming up as question. Maybe relying on editor line wrapping is fine, but I'd hope that auto-formatting takes away any effort either way. That's why we have the `.editorconfig` in place now.
👍 1
Nathan Vegdahl added 1 commit 2024-02-15 16:57:40 +01:00
Nathan Vegdahl added 1 commit 2024-02-15 17:14:25 +01:00
Nathan Vegdahl added 1 commit 2024-02-15 17:18:52 +01:00
Nathan Vegdahl commented 2024-02-15 17:34:05 +01:00
Author
Member
Copy Link

I've addressed the comments now.

Note that I wrapped to less than 100 characters for consistency, since the rest of this file does as well. (I somehow just didn't notice that it was hard wrapped at all before.)

That's why we have the .editorconfig in place now.

Not relevant to this PR, but the official EditorConfig extension for VSCode doesn't appear to support the max_line_length config option, which is annoying.

I've addressed the comments now. Note that I wrapped to less than 100 characters for consistency, since the rest of this file does as well. (I somehow just didn't notice that it was hard wrapped at all before.) > That's why we have the `.editorconfig` in place now. Not relevant to this PR, but the official [EditorConfig extension for VSCode](https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig) doesn't appear to support the `max_line_length` config option, which is annoying.
Merge conflict checking is in progress. Try again in few moments.
View command line instructions.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u stored_object_transforms:nathanvegdahl-stored_object_transforms
git checkout nathanvegdahl-stored_object_transforms

Merge

Merge the changes and update on Gitea.
git checkout main
git merge --no-ff nathanvegdahl-stored_object_transforms
git checkout main
git merge --ff-only nathanvegdahl-stored_object_transforms
git checkout nathanvegdahl-stored_object_transforms
git rebase main
git checkout main
git merge --no-ff nathanvegdahl-stored_object_transforms
git checkout main
git merge --squash nathanvegdahl-stored_object_transforms
git checkout main
git merge nathanvegdahl-stored_object_transforms
git push origin main
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender-developer-docs#23
No description provided.
Delete Branch "nathanvegdahl/blender-developer-docs:stored_object_transforms"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?