Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Rotation #439

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
Mar 27, 2024
Merged

Rotation #439

merged 8 commits into from
Mar 27, 2024

Conversation

BalzaniEdoardo
Copy link
Collaborator

Added a rotation property and a setter to Graphic and a method to set a rotation of a given angle over one of the axis, with respect to the world.

closes #427

@kushalkolar
Copy link
Member

good to go after a test :D

@BalzaniEdoardo
Copy link
Collaborator Author

good to go after a test :D

Nice!!

@kushalkolar
Copy link
Member

@almarklein
Copy link
Collaborator

A general remark about transformations for the graphics object:

I think world_object.local makes more sense that .world. In that case it represents the rotation with respect to the parent. When the graphics are flat, its the same thing (possibly more efficient). And when there is a scene graph (graphics being children of other graphics) in the majority of cases you want to transform with respect to the parent.

@kushalkolar
Copy link
Member

Thanks! If all WorldObjects in a subplot exist within the same scene, then .local and .world have the same effect right? Is there a scientific visualization usecase where you might want to differentially use .local and .world?

@almarklein
Copy link
Collaborator

almarklein commented Mar 22, 2024

If all WorldObjects in a subplot exist within the same scene, then .local and .world have the same effect right?

Yes.

Is there a scientific visualization usecase where you might want to differentially use .local and .world?

The classic example is rendering a robot arm, consisting of several segments, each a child of the previous. If you rotate an element, all the child elements rotate along.

In this scenario, using .local specifies the rotation with respect to the parent, while using .world applies a rotation relative to the word. The first is more common. Many scenegraphs don't even support the latter. But .world can also be convenient, also e.g. to set rotations with .local and then checking positions/rotations in .world.

So practically: I'd recommend using .local everywhere now. And maybe at a later time, if/when fpl supports child graphics, add support for .world transforms.

@BalzaniEdoardo BalzaniEdoardo requested a review from clewis7 as a code owner March 27, 2024 22:48
fastplotlib/graphics/_base.py Outdated Show resolved Hide resolved
kushalkolar
kushalkolar previously approved these changes Mar 27, 2024
@kushalkolar kushalkolar merged commit 97168ff into fastplotlib:main Mar 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

method for rotating graphics
3 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.