Add Direction property to AtlasTexture to handle atlases with rotated members at the resource scope

[onesuchkeeper]

Describe the project you are working on

A game that dynamically loads in spritesheets.

Describe the problem or limitation you are having in your project

AtlasTexture does not support atlases with rotated members.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

It is common practice for Atlases to rotate some of their members 90 degrees to better pack them into a square for read effeciency. Because of this some of their members must be rotated back at runtime.

Add a 'Direction' property with possible values 'North', 'South', 'East' and 'West' to AtlasTextures describing the orientation its region should be drawn in. Typical sheets will only use 'North' and 'East' so the existing enum 'Orientation' could be used instead with 'Vertical' and 'Horizontal', but I feel handling all 4 will better in the case an abnormal sprite sheet is made.

This will allow these rotated members to be handled at the texture scope along with the 'region' and 'margin'.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

• add 'Direction' property to AltasTexture
• when drawing or getting the AtlasTexture's rect, swap position and/or size values according to the Direction property

If this enhancement will not be used often, can it be worked around with a few lines of script?

Since Texture2D cannot be extended, there is no work-around other than handling it per node rather than at the resource scope.

AtlasTexture could be ignored and replaced by a shader handling its region and margin functionality and that of rotation. Materials could then be set up for each atlas entry with the rect and rotation values. However, this does not account for passing the texture's size to the parent node which would need to be handled via script or another dummy texture.

Or the node using the AtlasTexture must rotate itself meaning it must have knowlege of the specifics of the texture its using.

Both options push the scope of handling this to the node which is not ideal and is what I assume the AtlasTexture is designed to avoid.

Is there a reason why this should be core and not an add-on in the asset library?

• This cannot be implimented as an add-on as Texture2D cannot be extended
• This feature is a natual extension of the exsisting AtlasTexture's function
• This feture would be very simple to impliment and would not impact existing projects using AtlasTextures