I get the confusion, but this follows the naming conventions for other gizmos like .rect() and .rect_2d. The basic idea is to provide a gizmo to 2D users who don't want to engage with quaternions just for the sake of drawing gizmos. I have not seen a 'cubic grid' (gizmo) used anywhere so far, but if there is interest I will add it.

Sorry if I wasn't clear, but my point is I don't think we need a gizmos_2d just gizmos is enough.

Yes, this would still provide all the functionality, but isn't approachable for new users. Imagine someone building a 2D game: they have only dealt with Vec2 positions and f32 rotations. If they want to draw a gizmo, they should continue to be fine with that and not be forced to learn about quaternions just for gizmos.

In reality, would be good to have a cubic grid IMO. And one could find good to be able to change the space between X lines and Y lines. (In the cubic grid example, we would have Z lines)

And one could find good to be able to change the space between X lines and Y lines.

I'm not sure I understand this . You can have different spacings for x and y lines already. Simply pass something like Vec2::new(2., 1.) as the spacing argument. Am I missing something?

And one could find good to be able to change the space between X lines and Y lines.

I'm not sure I understand this . You can have different spacings for x and y lines already. Simply pass something like Vec2::new(2., 1.) as the spacing argument. Am I missing something?

Not really, I'm saying thats good, sorry, wasn't clear.
The only thing that I think deserves to be there is the cubic grid in reality, as Users can find good use in it for debug purposes

And one could find good to be able to change the space between X lines and Y lines.

I'm not sure I understand this . You can have different spacings for x and y lines already. Simply pass something like Vec2::new(2., 1.) as the spacing argument. Am I missing something?

Not really, I'm saying thats good, sorry, wasn't clear.
The only thing that I think deserves to be there is the cubic grid in reality, as Users can find good use in it for debug purposes

But as follow-up PR, right? Because I think a cubic-grid is out of scope of this PR, since this can be controversial, since the implementation can be trick IMO.

Can we maybe change the color of the grid lines in the example? It was a bit hard to me to see at first. Maybe we can use white?

White was a bit overwhelming, but it should be better now.

But as follow-up PR, right? Because I think a cubic-grid is out of scope of this PR, since this can be controversial, since the implementation can be trick IMO.

Yea, we can track this in #9400

But as follow-up PR, right?

I think I could add this here, if that is ok. It would be just adding another axis to the existing implementation and something like gizmos.cubic_grid(...)

I think I could add this here, if that is ok. It would be just adding another axis to the existing implementation and something like gizmos.cubic_grid(...)

If we implement in the same way that is now, I think that's okay, but might be good keep this as uncontroversial as possible and do this in a follow-up? Not sure.
About the cubic_grid part, wouldn't be better call it "grid_3d" or only "grid" to keep the convention?

If we implement in the same way that is now, I think that's okay, but might be good keep this as uncontroversial as possible and do this in a follow-up? Not sure. About the cubic_grid part, wouldn't be better call it "grid_3d" or only "grid" to keep the convention?

Ok, fair enough. As for the name, we already have .grid which we could just extend to include a third axis or we could do something like .lattice? I don't think grid_3d would be a good idea though, as it suggests (at least to me) that it is the same shape as .grid although it is different/more general.

Keeping .grid(...) to do that function is better IMO.

Keeping .grid(...) to do that function is better IMO.

Ok, so we will add that functionality to .grid in a future PR, right?

The Drop pattern is a little too clever for my taste, and doesn't appear to be used elsewhere in gizmos. Can we find a simpler solution?

oh, I thought it was a standard for gizmos so I didn't question it
In that case agreed

I'm a little confused, isn't the drop pattern used in multiple gizmos builders? Or is there something different here? For starters, arc builders use this

isn't the drop pattern used in multiple gizmos builders?

Yes, the Drop pattern is used for all primitives, ellipses and arcs.

Ah my apologies, I did a search for impl Drop, which didn't reveal anything because of the intervening generics.

@solis-lumine-vorago can you rebase (the examples got moved) and I'll give this a final pass before merging?

@solis-lumine-vorago can you rebase (the examples got moved) and I'll give this a final pass before merging?

Yeah sure, it appears that Color was renamed but it should be all good now.

@alice-i-cecile Could you enable Auto-merge again, please :)

thx :D