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
* Fixed RuleTile instantiatedGameObject rotation/scale
Performed fixes to the math in `RuleTile`'s `StartUp()` method so that instantiated GameObjects match the rotation and scale transformations of sprites (done internally by Unity's SpriteRenderer). The desired intent here is that if you create a RuleTile with 3D GameObjects and 2D Sprites that are visually a flattened version of the 3D art (imagine 3D walls in a maze, and 2D sprites showing the top-down outlines of the walls), they should _always_ match up with each other in the Unity Editor and Player.
* Added application of the `Tilemap`'s `orientationMatrix` to the `transform` matrix. This is necessary for GameObjects to to be rotated correctly when using any of the `Tilemap` `orientation` & `Grid` `cellSwizzle` modes beyond the default `.XY` & `.XYZ`.
* Now setting the `instantiatedGameObject.transform`'s `localPosition` and `localRotation` instead of using the `Tilemap`'s `LocalToWorld()` method for (world) `position` and setting (world) `rotation` unconverted. This fixes a variety of issues that occur when the `Tilemap` or `Grid`'s GameObject (or any parents) have a non-identity rotation or scale.
* Adding the calculated translation from the `orientationMatrix` to the `instantiatedGameObject.transform.localPosition`. This enables the `Tilemap`'s Orientation: Custom: Position values to apply properly.
* Also, setting the `instantiatedGameObject.transform`'s `localScale` to the Tilemap's `orientationMatrix.lossyScale`. This ensures that Orientation: Custom: Scale affects the GameObjects. Also, if a parent Transform has a scale in any axis, the `instantiatedGameObject`'s scale ends up with an inverse value of the parent.
Again, the end result of all of the above modifications/fixes are to match what Unity's `SpriteRenderer` does— that's the ground truth I've thoroughly tested these calculations against.
* Revised instantiatedGameObject position/rotation/scale to include flipped transform
Revised the math in `StartUp()` to decompose the `transform`'s translation, rotation, and scale all separately and apply those each to the `instantiatedGameObject.transform`.
This fixes an issue where negative scale values applied to the `transform` in `RuleMatches(…)` used to flip tiles weren't being applied to the `instantiatedGameObject`.
This is also more uniform and easier to understand than how I had it before— using `orientationMatrix.MultiplyPoint3x4(…)` for position, `(orientationMatrix * transform)`-derived values for the rotation, and `orientationMatrix.lossyScale` for the scale. Now the T, R, & S are all `(orientationMatrix * transform)`-derived with just T getting an additional `CellToLocalInterpolated(…)`-based offset.
* Fixed instantiatedGameObject to just use the orientationMatrix if no rules match
* Added a `bool ruleMatched` flag to check if none of the `m_TilingRules` matched— in that case, we set `gameObjectTranslation`/`Rotation`/`Scale` to just the `orientationMatrix` (instead of `(orientationMatrix * transform)`).
* Minor: Copied the `orientationMatrix` into a `orientMatrix` local instead of calling the accessor repeatedly.
0 commit comments