Allow easier translation/rotation of groups of primitives

[SuperCuber]

Problem

There's no easy way to translate+rotate a group of primitives that represent a single object.

In ProcessingJS for example you would be able to translate and rotate the coordinate system itself, then draw the primitives, then restore the state to what it was before. Right now you need to calculate the position+rotation of each primitive yourself.

Proposed solutions:

• Copy ProcessingJS's approach and allow manipulating the coordinate system (+ adding a builtin ability to push and pop the current state of the coordinate system to a stack)
• Create some Canvas primitive that can be drawn to, and then drawn using a position+rotation onto the real screen

---

I am not completely familiar with this project so if I missed the intended way to do it, then I'd love to be pointed to docs of it. (Couldn't find any example of such a thing)

[mitchmindtree]

Thanks for opening this!

Totally agreed there needs to be an easier solution for rotating multiple primitives at once!

While the processing approach of using a global rotation is very easy to add in and is easier to use with small sketches, it can be tricky to keep track of as programs grow and it can get easy to unexpectedly break things by adding or removing rotations or refactoring.

Maybe we can achieve something similar that feels as easy to use by adding in some explicit translation/rotation types (matrices under the hood) that can be chained together and used to position primitives as an alternative to the positioning and orientation methods.

[SuperCuber]

@mitchmindtree I haven't personally encountered the problem of losing track since most usage of that feature goes along the lines of:

push_current_coordinate_system()
rotate(...)
scale(...)
translate(...)

draw_primitives()
draw_primitives()
draw_primitives() // Relative to 0,0

pop_coordinate_system()

Note that that code above doesn't need to start from an "identity matrix" state, it can be put in a function and used to draw sub-objects of objects for example. I think it would be useful to enforce/automate this pushing/popping using a constructor and destructor though.

[freesig]

I agree that that global translates are easier with simple projects but they can get hard to track as the project grows. Especially with multiple threads.
It would be ideal if we could find a solution almost as easy to use but without the global state. We want nannou to be great for tiny sketches as well as large projects

[SuperCuber]

@freesig Have you considered the Canvas solution? What do you think would be the pros/cons of that? To elaborate, Canvas can mimic the API of Draw and also have some sort of .canvas(...) function that allows drawing a canvas onto another canvas (Draw can be a Canvas too?).

So you would do something along the lines of

let draw = ...;
let my_object = /*some way to get a canvas? maybe Canvas::new or Canvas::from_wh()*/;
my_object.primitive().position(...);
my_object.primitive().position(...);
my_object.primitive().position(...);
draw.canvas(my_object).position(...).rotate(...).scale(...);

[mitchmindtree]

@SuperCuber I really like the idea behind this and will certainly keep it in mind when I get around to addressing this :)

[mitchmindtree]

We've just been discussing this a little more on the slack.

Here's a little rough snippet of what I'm imagining:

let draw2 = draw.rotate(r).translate(xy).scale(s);
// You can now use all the same methods as draw but they will be translated/oriented/scaled via an inner transform matrix.
draw2.line().points(a, b);
draw2.rect();
// Then we can easily continue drawing with the original, untransformed draw.
draw.polygon().points(ps).color(red);
//etc

Transformations could be nested by calling the transform methods on the already transformed draw instance.

[SuperCuber]

Possible use case to consider: having a function that draws an object.
With @mitchmindtree 's proposal it would probably look something like this.

impl CustomObject {
    fn draw(&self, transformed: /*the type*/) {
        // All drawing is relative to (0,0)
        transformed.primitive().xy(...);
        // Can also draw sub-custom-objects
        self.custom_sub_object.draw(transformed.translate(...));
    }
}

Another proposal that I haven't considered before (and might be already implemented in some form?) is to let structs implement a Drawable trait that is something along those lines:

trait Drawable {
    fn draw(&self, draw: Draw) {
        // draw relative to (0,0)
    }
}

And then you can do something like

let draw = ...;
let my_object = ...;
draw.drawable(my_object).xy(...);

Maybe there is a way to even combine those two approaches...