alpha-trimmed atlas sprite has the wrong dimension

[loopyllama]

Hello,
I am using NGUI 3.0.4. I have a bunch of images that are fullscreen 2048x1536, like a small arrow, a button, etc. I add these images to an atlas and trim their alpha. This workflow allows me to precisely place the images in photoshop (as opposed to using anchors in NGUI). With this latest version of NGUI the dimensions of the sprite say 2048x1536 rather than the actual size of the button which is 128x128. Because the dimensions are 2048x1536, the collider is fullscreen. I have to manually figure out the center and size of the collider. for every single clickable thing. I opened an old project with an older version of NGUI and it used to not be like this. In the older version there was no "dimensions" for the UISprite child, and the parent with the button code had the correct center and size for the collider.

Is this a bug? How can I have a small button on a transparent fullscreen image, add the image to an atlas with alpha trimming, and have NGUI have the correct dimensions and collider size and center when I create a widget using the image from the atlas?

[ArenMook]

This is intentional, and is designed this way with sprite animation in mind. When you're doing sprite animation, the character moves around the allocated area (a box), and should always be relative to the center of that box.

You should not use 2048x1536 source texures. That's just crazy.

[loopyllama]

It is crazy to use 2048x1536 source textures?

My task is to create an app with many overlay graphics with precise positioning for my client. The only way to sanely and precisely place each graphic they have given me is to export the graphic as a full screen image and automatically trim off the texture when placing it in the atlas. This places the graphic in the exact pixel perfect location and has the tightest border possible. This is hardly crazy. NGUI also used to support this. As shown in your videos, the source textures are deleted anyways, so what does it matter what size they are? Please help me, I really need this functionality.

[ArenMook]

Select the atlas, choose the sprite, and just edit its padding values. When pixels get trimmed, they get replaced with padding.

You should consider looking into FastGUI. It's able to export Photoshop layouts into NGUI.

[Nicki]

Using a full screen sprite for each single sprite on screen is downright insane.

[loopyllama]

@Aren I will look into FastGUI. It is a shame that I have to pay for something NGUI used to do

@Nicki you didn't read my post

[Nicki]

Heh clearly I didn't read it entirely.

Why don't you trim the source files yourself? You can do a photoshop action for it so that the atlaspacker knows what size it's supposed to be in the end. Alternatively, have the artists do that.

[loopyllama]

Trimming the alpha isn't the issue. The real issue for me is having 50+ UI pieces that need precisely placed in NGUI, exactly as they are placed in a photoshop file. This means I want to avoid anything that requires I write down the coordinates of each piece, add the center of the sprite width, and type that in NGUI for each sprite.

Older NGUI to work like this: export small sprite as a fullscreen image. Import that image into Unity and drop it into an NGUI atlas. NGUI atlas was smart enough to trim the alpha, use that info to offset the sprite for you (!!!!!) and make the bounds of the sprite as tight as possible! Done! want to reposition the image in photoshop? go ahead! export image, update in the atlas, and whammo...the new position is calculated. All my previous projects used that workflow. Now I updated NGUI and whoa, it does NOT do that anymore. Now I have to read the padding info, write it down, zero it out, make the widget, add an anchor, set the anchor gameobject container to a fullscreen object, add half the sprite width to the padding, add half the sprite height to the padding, set the anchor reference, type in the x pixel offset, and the y pixel offset. For 50+ sprites.

Now you see why I am miffed. It used to do this. FastGUI doesn't support the latest Unity/NGUI, and it costs money when NGUI used to do this :/

[ArenMook]

You have to realize that most people don't use the UI like you do. The accepted workflow is "use the original texture's dimensions as the widget dimensions" -- this makes far more sense most of the time. So if the original texture's dimensions happens to be 2048x1536, then that's exactly what the sprite will be when you instantiate it. The actual drawn area may be much smaller, but that's not what's important.

[loopyllama]

I understand what you are saying.

This workflow is highly useful to layout complex GUIs with perfect precision from a 2D package.
It was a great feature of NGUI.