GeezerVison

good to go after a test :D

good to go after a test :D

Nice!!

Some notes on testing here: https://github.com/fastplotlib/fastplotlib/blob/main/CONTRIBUTING.md#running-tests

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.

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?

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.