add triangle shape #350

juliapaci · 2024-05-29T11:25:57Z

Implements (at least starts to) a triangle shape, im not sure if this is useful enough to merge though.

Also while looking at the source i noticed that that places like here use Rect instead of Self unlike other parts of the codebase. And some parts of the documentation uses "[`Type`]" and other parts just use "Type". Wasnt sure to make an issue or not but should there be a cleanup of the codebase?

also there is alot of conversion between Vec2 and Point right now. is there a better way to handle these situations where i want to use Vec2 methods on a Point but will end up converting right back to a Point afterwards?

triangles have alot of opportunities for more specific methods so its worth noting that this can be heavily expanded upon which could come later. Aswell as this, i have made some decisions like using centroids as the origin of the triangle (https://web.archive.org/web/20131104015950/http://www.jimloy.com/geometry/centers.htm) which might not be the best? let me know.

ill continue working on this, specifically the TODOs (see inlined todos)

fix TODOS is_nan is_finite ellipses

juliapaci · 2024-05-30T08:35:10Z

Should we add an Insets for triangle?

juliapaci · 2024-05-30T09:44:16Z

src/triangle.rs

+        Point::new(
+            (self.a.x + self.b.x + self.c.x) / 3.0,
+            (self.a.y + self.b.y + self.c.y) / 3.0,
+        )


One of those situations where we could do this or:

((self.a.to_vec2() + self.b.to_vec2() + self.c.to_vec2()) / 3.0).to_point()

I do prefer the latter. Also, it would be more efficient to multiply by (1.0 / 3.0) but this is a matter of preference. Leaving the division in preserves the case where the resulting coordinate is, say, an integer, while multiplication might not.

Its less likely to be an integer so ill multiply by 1/3

more functions & start testing

juliapaci · 2024-06-01T03:19:26Z

i realise that changes to other source files like vec2.rs should be another pr but right no this pr depends on them so ill keep it here for no. if this doesn't get merged then ill split my fork and make a pr just for those other source files.

juliapaci · 2024-06-01T03:20:37Z

src/triangle.rs

+    /// Updates [`Triangle`]'s vertice positions
+    /// such that [`Triangle::a`] is topmost, [`Triangle::b`] is leftmost, and [`Triangle::c`] is rightmost
+    #[inline]
+    pub fn organise(self) -> Self {


should British spelling be changed? (probably)

add all necessary tests

src/point.rs

juliapaci · 2024-06-01T09:40:04Z

src/triangle.rs

    pub fn organise(self) -> Self {
-        Self::new(self.topmost(), self.leftmost(), self.rightmost())
+        let t = Self::new(self.topmost(), self.leftmost(), self.rightmost());
+
+        t
    }


(ignoring the bug which will be fixed, im just trying to find a clean way) there are a few issues / design choices that can be made here:

should organise() mutate self?

a lot of other functions assume an organised position so should we either let the user call organised before these functions OR call organise in these functions

juliapaci · 2024-06-01T09:43:15Z

src/triangle.rs

+    /// The perimeter of the [`Triangle`]
+    #[inline]
+    fn perimeter(&self) -> f64 {
+        self.a.distance(self.b) + self.b.distance(self.c) + self.c.distance(self.a)
+    }
+


we have general perimeter and area functions but we also have specific ones for right angled triangles. should we add more specific ones for equilateral triangles and stuff or is it too much clutter?

also, i dont see the need to implement perimeter and area here when its in the Shape trait? this is also done for Rect.

It should just be the Shape trait impls. I think the reason it's in Rect is historical, those methods were written before the Shape trait existed.

juliapaci · 2024-06-01T09:48:24Z

src/triangle.rs

+    pub fn from_centroid_sizes(centroid: impl Into<Point>, sizes: [impl Into<Size>; 3]) -> Self {
+        let centroid = centroid.into();
+
+        let mut points: [Point; 3] = Default::default();
+        for (i, size) in sizes.into_iter().enumerate() {
+            points[i] = centroid + size.into().to_vec2();
+        }
+
+        Self::new(points[0], points[1], points[2])
+    }
+
+    /// A new [`Triangle`] with vertex distances of `distances` from the `centroid`
+    ///
+    /// NOTE: the new [`Triangle`] does not keep `centroid`
+    #[inline]
+    pub fn from_centroid_distances(centroid: impl Into<Point>, distances: [f64; 3]) -> Self {
+        let centroid = centroid.into();
+
+        Self::new(
+            centroid + (0.0, distances[0]),
+            centroid + distances[1] * Vec2::from_angle(5.0 * FRAC_PI_4),
+            centroid + distances[2] * Vec2::from_angle(7.0 * FRAC_PI_4),
+        )
+    }


maybe a transition from from* to with* like in the builder pattern is better. although im hesitant to do this here because this would require a change for the entire codebase so maybe should be another pr?

we also wouldnt have to include the centroid param this way since users could chain with with_centroid()

juliapaci · 2024-06-01T22:48:06Z

src/triangle.rs

+    pub fn organise(self) -> Self {
+        let mut points = self.as_array();
+        points.sort_by(|x, y| x.rightmost(y));
+
+        let a = self.topmost();
+        let b = *points.iter().find(|&&p| p != a).unwrap();
+        let c = *points.iter().rev().find(|&&p| p != a).unwrap();
+        Self::new(a, b, c)
+    }


we probably can do a better way, we cant just do this though because of double ups.

juliapaci · 2024-06-01T22:49:17Z

and with 8b03193 this pr should be ready for a review!

src/triangle.rs

juliapaci · 2024-06-05T06:58:00Z

on a side note i also think it would be useful to have from/to_triangle/circle/rect(), cause we do it for Ellipse already we may aswell do it for all other shapes which would also be super easy to implement. prob should be another pr tho

raphlinus

Thanks for the PR, and apologies for taking so long to review. Triangle is a beautiful shape with useful special properties, and this PR is a good start. Some general thoughts.

A very large number of items are marked as "not justified." Basically, we want methods that are used by potentially a broad range of applications. If it's only going to be used once, or for a test, it doesn't belong in the public API. It's very easy to add methods, but unfortunately extremely difficult to remove them. In addition, a theme in kurbo is mathematical correctness, which means that some methods which might be convenient (like Point + Point or, recently Affine * Vec2) aren't present. So most methods that aren't present for other shapes are out. That said, when there's something really special to triangles, it makes sense. I like centroid, and I'm also open to incircle (and circumcircle). For other methods, I'm open to an argument why it should be included.

There should be an impl Mul<Triangle> for Affine. Fortunately, it's simple, you can pretty much cut'n'paste the one for line.

Looking forward to the revisions, then I'll do another review.

raphlinus · 2024-08-14T22:33:13Z

src/size.rs

@@ -336,6 +336,16 @@ impl SubAssign<Size> for Size {
    }
 }

+impl From<f64> for Size {


This is not mathematically correct.

i think i only did that for testing in one of the commits but forgot to remove it sorry

raphlinus · 2024-08-14T22:34:13Z

src/triangle.rs

+    /// empty [`Triangle`] at (1.0, 1.0)
+    pub const ONE: Self = Self::from_coords((1.0, 1.0), (1.0, 1.0), (1.0, 1.0));
+
+    /// equilateral [`Triangle`] identity


This is not in fact an equilateral triangle. And I don't think it's justified.

haha sorry about that

i think it is useful for the user though (atleast one out of Triangle::Equilateral and Triangle::ONE) because the user can just scale them and work with scalars instead of triangle data.
Not sure if that makes sense but i can defiantly see this as a use case however if you still want it removed then thats fine

also why is Triangle::ZERO alright to keep?

raphlinus · 2024-08-14T22:40:59Z

src/triangle.rs

+    /// The area of the [`Triangle`]
+    #[inline]
+    pub fn area(&self) -> f64 {
+        let ab = self.a.distance(self.b);


It would be more efficient to compute this using the shoelace rule, no trig necessary. Also, it's usual in kurbo to compute signed area (with the same sign convention as converting into a bezpath).

This should work: 0.5 * (self.b - self.a).cross(self.c - self.a)

raphlinus · 2024-08-14T22:44:03Z

src/triangle.rs

+        (self.b.distance(self.c) * (self.a.y - self.b.y)) / 2.0
+    }
+
+    /// Updates [`Triangle`]'s vertice positions


I'm not convinced this should be in the public API.

"vertex"

Also, the description doesn't clearly state what happens if, for example, a is both topmost and rightmost.

I'm not convinced this should be in the public API.

yeah im not sure why i did that.

now that the functions that relied upon this method are gone should we still keep this?

raphlinus · 2024-08-14T22:46:19Z

src/triangle.rs

+        most_ordering!(self, { |x, y| y.x.total_cmp(&x.x) })
+    }
+
+    /// Maximum x-coordinate of the [`Triangle`]'s vertices


I think these individual functions should just be combined into the Shape::bounding_box implementation.

raphlinus · 2024-08-15T00:43:14Z

src/triangle.rs

+        Self::new(points[0], points[1], points[2])
+    }
+
+    /// A new [`Triangle`] with vertex distances of `distances` from the `centroid`


I don't think this is justified.

raphlinus · 2024-08-15T01:31:25Z

src/triangle.rs

+        self.as_array().iter().find(|&v| v.y == y).copied()
+    }
+
+    /// The topmost vertex of `self` as a [`Point`]


I don't think these are justified, I think it's fairly specialized and users can write it themselves. In addition, there's a naming problem, as "topmost" implies a y-down coordinate system, and one of the conceits of kurbo is that it's agnostic to whether the coordinates are y-up or y-down.

Oh right, their useless now anyway because the organise is useless

raphlinus · 2024-08-15T01:33:42Z

src/triangle.rs

+        )
+    }
+
+    /// Returns the [`Ellipse`] that is bounded by this [`Triangle`].


As mentioned elsewhere, I think incircle and circumcircle are the methods that should be included.

src/triangle.rs

src/point.rs

juliapaci

4d8f906

ill update the tests once you check it out

src/point.rs

juliapaci · 2024-08-15T03:07:45Z

src/size.rs

@@ -336,6 +336,16 @@ impl SubAssign<Size> for Size {
    }
 }

+impl From<f64> for Size {


i think i only did that for testing in one of the commits but forgot to remove it sorry

juliapaci · 2024-08-15T03:09:19Z

src/vec2.rs

@@ -31,6 +31,9 @@ impl Vec2 {
    /// The vector (0, 0).
    pub const ZERO: Vec2 = Vec2::new(0., 0.);

+    /// The vector (1, 1)


I only used this in one of the prior commits so i can just remove it entirely

juliapaci · 2024-08-15T03:10:50Z

src/ellipse.rs

+    ///
+    /// [`with_rotation`]: Ellipse::with_rotation
+    #[inline]
+    pub fn from_triangle(triangle: Triangle) -> Self {


Yeah you're right

juliapaci · 2024-08-15T03:28:26Z

src/triangle.rs

+    /// empty [`Triangle`] at (1.0, 1.0)
+    pub const ONE: Self = Self::from_coords((1.0, 1.0), (1.0, 1.0), (1.0, 1.0));
+
+    /// equilateral [`Triangle`] identity


haha sorry about that

i think it is useful for the user though (atleast one out of Triangle::Equilateral and Triangle::ONE) because the user can just scale them and work with scalars instead of triangle data.
Not sure if that makes sense but i can defiantly see this as a use case however if you still want it removed then thats fine

also why is Triangle::ZERO alright to keep?

juliapaci · 2024-08-15T03:53:39Z

src/triangle.rs

+        )
+    }
+
+    /// The euclidean distance of each vertex from the centroid


Like alot of these, im not sure why its needed either haha.

juliapaci · 2024-08-15T03:59:07Z

src/triangle.rs

+        (self.b.distance(self.c) * (self.a.y - self.b.y)) / 2.0
+    }
+
+    /// Updates [`Triangle`]'s vertice positions


I'm not convinced this should be in the public API.

yeah im not sure why i did that.

now that the functions that relied upon this method are gone should we still keep this?

juliapaci · 2024-08-15T04:03:03Z

src/triangle.rs

+        self.as_array().iter().find(|&v| v.y == y).copied()
+    }
+
+    /// The topmost vertex of `self` as a [`Point`]


Oh right, their useless now anyway because the organise is useless

juliapaci · 2024-08-15T04:12:00Z

src/triangle.rs

+        area / s
+    }
+
+    /// Expand the triangle by a constant amount (`sizes`) in all directions


Oops i forgot to update this. is 4d8f906 inflate fine?

juliapaci · 2024-08-15T04:12:55Z

src/triangle.rs

+        )
+    }
+
+    /// A new [`Triangle`] with each vertecie's ordinates rounded to the nearest integer


me neither, i just took alot of these helpers from rect

fix old tests + add new circle tests

juliapaci · 2024-08-15T08:05:48Z

Ive double checked and it looks like my incircle and circumcircle implementations are correct yet when i check them in desmos.com the incircle radius is too small and the circumcircle radius is too large. Have i done something wrong?

also can the circumcenter function be more efficient?

raphlinus

This is looking pretty good, thanks for all the progress. And apologies again for the slow turnaround on review, I'm juggling too many things. I think not much more is needed to land it.

src/triangle.rs

raphlinus · 2024-08-26T19:26:59Z

src/triangle.rs

+    /// The area of the [`Triangle`]
+    #[inline]
+    pub fn area(&self) -> f64 {
+        0.5 * (self.b - self.a).cross(self.c - self.a).abs()


I disagree that there should be an abs here. We default to signed area in kurbo, and by taking the absolute value we'll have situations where the return value of this function doesn't match the area of converting into shape first.

not exactly sure the use of this cause i dont know of any benefits for signed area but ill just do it if its the norm.

should the area test be updated to be negative now?

Yes, or permute the order of vertices. Converting to shape and evaluating area gives a negative result, so that's confirmation that the sign conventions are consistent. And in fact, you can make a good argument that this should be tested explicitly.

Converting to shape and evaluating area gives a negative result, so that's confirmation that the sign conventions are consistent

but doesn't the shape implementation default to triangles pre-existing signed area function?

no problem though, ive changed to test the original and one with a vertex permutation

src/triangle.rs

one with and without permutated vertices

juliapaci · 2024-08-27T10:41:05Z

do you think there should be an as_triangle in "shape.rs"?

raphlinus · 2024-08-27T23:25:02Z

do you think there should be an as_triangle in "shape.rs"?

Probably not needed. The main purpose of those methods is fast paths for renderers, and triangle is not (unlike circle, rect, etc) not a common specialized shape - for example, it's not in SVG or the Canvas API.

src/triangle.rs

`is_zero_area`, `is_nan`/`is_finite` docs, typo

see \linebender#371

wasnt supposed to be committed at all

derekdreery

I like this PR and think it would make a good addition to kurbo, but I think it needs some changes first. The biggest suggestion in my review is to add functions inscribed_circle and circumscribed_circle and remove the functions that calculate radii/centers for these circles.

Feel free to push back if you disagree with any of my suggestions, and we can have a discussion.

src/point.rs

src/triangle.rs

derekdreery · 2024-09-22T17:38:17Z

src/triangle.rs

+
+    /// A new [`Triangle`] from three float vertex coordinates
+    #[inline]
+    pub const fn from_coords(a: (f64, f64), b: (f64, f64), c: (f64, f64)) -> Self {


I don't think you need this function because new already works with the same arguments. If you like you could give an example in the new docs using coords, if you think the functionality needs to be more discoverable.

Ive used it to keep the constants ZERO and EQUILATERAL.

Maybe there is a way to use the non constant new() since we can assume the arguments are already of Point. If there isnt another way then should i remove them or maybe i can make from_coords() private?

The easiest way is probably to just inline this function at the definitions. I.e. const ZERO: Triangle = Triangle {a: Point::new(...), ...}.

I do agree that there should be some consistency here, but I'm happy just using the already-exposed "fieldwise" constructor as the const constructor for now to unblock progress.

Yeah im happy to do that. should we quickly do it now or wait for @derekdreery's input?

Hmm I hadn't realised that this function exists for const. In that case I think it's good to have 2 functions, but perhaps put a note in the docs explaining that this function works like new, but can be used in const contexts.

src/triangle.rs

derekdreery · 2024-09-22T18:05:25Z

src/triangle.rs

+    }
+
+    /// Expand the triangle by a constant amount (`scalar`) in all directions
+    pub fn inflate(&self, scalar: f64) -> Self {


I'd consider adding a #[doc(alias = "offset")] here because we use the term offset generally to describe offsetting paths like this. The Rect type does also use this language IIRC.

sorry, did you mean to comment this under Triangle::offsets()?

derekdreery · 2024-09-22T18:08:21Z

src/triangle.rs

+    use crate::{Point, Triangle, Vec2};
+
+    fn assert_approx_eq(x: f64, y: f64) {
+        assert!((x - y).abs() < 1e-7);


This is quite a loose bound for f64. I'd use something closer to machine epsilon e.g. 1e-13. Out of scope for this PR, but we really need to standardize this (I like float_cmp because it allows big epsilons as long as the expected and actually are <n representable numbers apart in f64).

I copied the bound from "rect.rs" i understood that it was loose but knew that it was only a temporary solution.

i could change it to be more strict but even with 1e-13, Triangle::area() tests are already failing from precision. i still could arbitrarily restrict the bound or could just wait for it to be standardized as you said, which would you prefer?

Just leave it as-is for now - what you have is fine.

src/triangle.rs

Co-authored-by: Richard Dodd <richard.o.dodd@gmail.com>

juliapaci

Thanks for the review and sorry for the late response.

All suggestions have been implemented (4f17103, 3da32b7, 4d0afb9) except for those which i further commented on, please see those!

src/point.rs

juliapaci · 2024-09-23T07:16:02Z

src/triangle.rs

+
+    /// A new [`Triangle`] from three float vertex coordinates
+    #[inline]
+    pub const fn from_coords(a: (f64, f64), b: (f64, f64), c: (f64, f64)) -> Self {


Ive used it to keep the constants ZERO and EQUILATERAL.

Maybe there is a way to use the non constant new() since we can assume the arguments are already of Point. If there isnt another way then should i remove them or maybe i can make from_coords() private?

juliapaci · 2024-09-23T07:18:06Z

src/triangle.rs

+
+    /// The circumcenter of the [`Triangle`]
+    #[inline]
+    pub fn circumcenter(&self) -> Point {


i looked a bit through the compiler explorer for some small optimizations and cleanups but i fear that i am missing a faster algorithm in general. Also any thoughts on this (specifically the first paragraph)?

juliapaci · 2024-09-23T07:30:52Z

src/triangle.rs

+    /// Circumradius of [`Triangle`] (the smallest radius of a circle such that it intercepts each vertex)
+    /// with center [`Triangle::circumcenter`]
+    #[inline]
+    pub fn circumradius(&self) -> f64 {


Yeah i have no problem either way.

The only argument against is that we might be computing extra information...

I think its more likely that the user would want the center and the radius rather than just one of them

juliapaci · 2024-09-23T07:38:18Z

src/triangle.rs

+    }
+
+    /// Expand the triangle by a constant amount (`scalar`) in all directions
+    pub fn inflate(&self, scalar: f64) -> Self {


sorry, did you mean to comment this under Triangle::offsets()?

src/triangle.rs

juliapaci · 2024-09-23T07:40:26Z

src/triangle.rs

+    use crate::{Point, Triangle, Vec2};
+
+    fn assert_approx_eq(x: f64, y: f64) {
+        assert!((x - y).abs() < 1e-7);


I copied the bound from "rect.rs" i understood that it was loose but knew that it was only a temporary solution.

i could change it to be more strict but even with 1e-13, Triangle::area() tests are already failing from precision. i still could arbitrarily restrict the bound or could just wait for it to be standardized as you said, which would you prefer?

Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>

private `from_coords` and instead of `*radius` use `*circle`

juliapaci added 2 commits May 29, 2024 21:20

init

d8fc124

chore: format

0878d60

juliapaci mentioned this pull request May 29, 2024

Arrow shape (WIP) voxell-tech/bevy_motiongfx#49

Closed

juliapaci added 2 commits May 30, 2024 17:34

path iterator

c5b255e

extend api

8bfd8f4

fix TODOS is_nan is_finite ellipses

fix ci

8403950

juliapaci commented May 30, 2024

View reviewed changes

TODO completion progress

a8360f0

more functions & start testing

juliapaci commented Jun 1, 2024

View reviewed changes

juliapaci added 2 commits June 1, 2024 15:59

tests

be6ed8d

add all necessary tests

bug fixes

a2527bc

juliapaci commented Jun 1, 2024

View reviewed changes

working organise\(\)

8b03193

juliapaci commented Jun 1, 2024

View reviewed changes

juliapaci marked this pull request as ready for review June 1, 2024 22:49

proper ellipse size

e40449c

juliapaci force-pushed the triangle branch from 592b2c0 to e40449c Compare June 1, 2024 23:02

juliapaci commented Jun 1, 2024

View reviewed changes

src/triangle.rs Show resolved Hide resolved

juliapaci changed the title ~~add triangle shape (WIP)~~ add triangle shape Jun 1, 2024

juliapaci added 2 commits June 2, 2024 11:04

fix ci

30d9e1c

chore: format

5580aef

waywardmonkeys added this to the August, 2024 Release milestone Aug 6, 2024

raphlinus reviewed Aug 15, 2024

View reviewed changes

apply suggestions

4d8f906

juliapaci commented Aug 15, 2024

View reviewed changes

tests

0438fae

fix old tests + add new circle tests

raphlinus reviewed Aug 26, 2024

View reviewed changes

juliapaci added 2 commits August 27, 2024 06:41

apply cleanup suggestions

7d1e41d

signed area test

8bac853

one with and without permutated vertices

waywardmonkeys reviewed Aug 30, 2024

View reviewed changes

src/triangle.rs Outdated Show resolved Hide resolved

src/triangle.rs Outdated Show resolved Hide resolved

src/triangle.rs Outdated Show resolved Hide resolved

match new style

8da1a8c

`is_zero_area`, `is_nan`/`is_finite` docs, typo

waywardmonkeys mentioned this pull request Aug 30, 2024

Release 0.11.1 #374

Merged

juliapaci added 2 commits August 31, 2024 18:34

add is_zero_area doc alias

b2f4739

see \linebender#371

remove from Line

57b4cb0

wasnt supposed to be committed at all

DJMcNab requested a review from derekdreery September 10, 2024 08:16

xorgy modified the milestones: 0.11.1, 0.11.2 Sep 14, 2024

derekdreery requested changes Sep 22, 2024

View reviewed changes

Apply explicit suggestions from derekdreery

4f17103

Co-authored-by: Richard Dodd <richard.o.dodd@gmail.com>

juliapaci commented Sep 23, 2024

View reviewed changes

juliapaci and others added 2 commits September 23, 2024 17:46

remove point comparisons

4d0afb9

Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>

apply implicit suggestions

3da32b7

private `from_coords` and instead of `*radius` use `*circle`

add triangle shape #350

Are you sure you want to change the base?

add triangle shape #350

Conversation

juliapaci commented May 29, 2024 • edited Loading

juliapaci commented May 30, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

juliapaci commented Jun 1, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

juliapaci commented Jun 1, 2024

juliapaci commented Jun 5, 2024

raphlinus left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

juliapaci left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

juliapaci commented Aug 15, 2024

raphlinus left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

juliapaci commented Aug 27, 2024

raphlinus commented Aug 27, 2024

derekdreery left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

juliapaci left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

juliapaci commented May 29, 2024 •

edited

Loading

juliapaci left a comment •

edited

Loading