You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the interest in getting Penrose Pipes out the door, I implemented the Orient/Lock dot using the tile transform and rotation.
This is equivalent to the cube grid implementation, where the same transforms are applied to the g.pipe, since the dot uses the same coordinate system.
This has the following weaknesses:
The dot is squished according to the transform, and this means it's very squished on the skinny rhombs.
If I extrapolate the 3D planes of all these jumbled tiles, it gives me a touch of vertigo, but it's not nearly as bad as when the pipes did were in false perspective.
There is no animation on the dot.
The dot is not perfectly centered inside its arm - ideally it should be placed on the spline at a little distance from the edge, similar to Curvy edgemarks for Penrose pipes #7.
I'm not sure, but I think rotations would have to be passed into grid.getGuideDotPosition() and polygon.get_guide_dot_position() and the polygon would need to cache a dot position per direction.
It's also worth noting that this mode makes it easy to trigger #8 wrong animation for 180º turns.
In the interest in getting Penrose Pipes out the door, I implemented the Orient/Lock dot using the tile transform and rotation.
This is equivalent to the cube grid implementation, where the same transforms are applied to the
g.pipe
, since the dot uses the same coordinate system.This has the following weaknesses:
I'm not sure, but I think rotations would have to be passed into
grid.getGuideDotPosition()
andpolygon.get_guide_dot_position()
and the polygon would need to cache a dot position per direction.It's also worth noting that this mode makes it easy to trigger #8 wrong animation for 180º turns.
Previous discussion in #6.
The text was updated successfully, but these errors were encountered: