Question Best approach for handling single, hand-drawn sprites?

Hello, just wondering:
I'm currently developing a game, and I've been manually drawing sprites for them, not using pixelart, but software such as Clip Studio Paint.

I've yet to arrange my sprites into spritesheets, but one issue I've dealt with in the past are animators/animations being offset improperly due to sprites not having the same dimensions and pivot points.

My issue is that it can be a little difficult keeping the sprites consistent across specific drawings, at least in terms of canvas resolution. Hell, right now, my sprites have a large chunk of transparency that needs to be cut off. I've considered setting my singular sprites to 'multiple' and using the sprite editor to snip off the excess transparency perfectly, but I'm concerned that this may cause issues in future. It can be hard to keep track of the pivot points for that matter, and things may get a bit worse if I need to resize characters in-game.

For some context, right now my sprites are not truly animated, but singular still keyframes that bob up and down, akin to many visual novels.

Could I get advice or pointers on how I should handle my art in Unity?

 

You wouldn't even want same dimensions, for example a sprite for crouching and standing up shouldn't really have the same dimensions

There isn't a built-in way of setting the same pivot points to multiple sprites but you could use an editor tool or a sprite preprocessor to set the pivots; editor tool would probably be easier but the custom sprite preprocessor automatically handles the pivots on import(or re-import)

here is an example for custom sprite preprocessor(must be inside a class that inherits AssetPostprocessor):

Spoiler

Code (CSharp):

1. /// <summary>
2.         /// only processes textures
3.         /// </summary>
4.         void OnPreprocessTexture()
5.         {
6.             TextureImporter textureImporter = (TextureImporter)assetImporter;
7.             textureImporter.filterMode = FilterMode.Point;
8.             textureImporter.textureCompression = TextureImporterCompression.Uncompressed;
9.  
10.             //can't access sprite alignment via texture importer, need to use texture importer settings
11.             var importerSettings = new TextureImporterSettings();
12.             textureImporter.ReadTextureSettings(importerSettings);
13.             importerSettings.spriteAlignment = 7;//pivot = bottom
14.             textureImporter.SetTextureSettings(importerSettings);
15.  
16.             textureImporter.spriteImportMode = SpriteImportMode.Single;
17.             textureImporter.spritePivot = new Vector2(0.5f, 0f);//you could expose a variable for this
18. }

here is another snippet that I use for my character sprite sheet that contains all sprites for each animation etc:

Spoiler

Code (CSharp):

1.         Vector2 _characterSpritePivot = new Vector2(.5f, 0.3100442f);//this is a field of a class that inherits AssetPostprocessor
2.  
3.  
4. //this gets called somewhere in the OnPreprocessTexture method
5. void ImportCharacterSprites(TextureImporter textureImporter)
6.         {
7.             if (textureImporter.spriteImportMode == SpriteImportMode.Multiple)
8.             {
9.                 var factory = new SpriteDataProviderFactories();
10.                 factory.Init();
11.                 var dataProvider = factory.GetSpriteEditorDataProviderFromObject(textureImporter);
12.                 dataProvider.InitSpriteEditorDataProvider();
13.                 var spriteRects = dataProvider.GetSpriteRects();
14.                 for (int i = 0; i < spriteRects.Length; i++)
15.                 {
16.                     spriteRects[i].pivot = _characterSpritePivot;
17.                 }
18.                 dataProvider.SetSpriteRects(spriteRects);
19.                 dataProvider.Apply();
20.             }
21.         }

canvas resolution shouldn't matter as long as each texture has the same pixels per unit(ppu). For example a 100 pixel wide block that has 100ppu will occupy 1 world units while 175 pixel wide block with 100ppu will occupy 1.75 world units

If the sprites are in Tight mode, they will be cut automatically with default values or you can enter the sprite editor and edit the custom outline yourself; if you use more vertices to cut tighter outlines you'll increase the vertex shaders' total cost while reducing the fragment shaders' total cost; honestly don't worry too much about it until there is a huge overdraw problem.




Let me know if I missed anything

Cheers

 

you should import each frame of your art without cropping it, keep the same canvas size

then you can use the sprite atlas feature, it crops the sprites for you and creates a spritesheet automatically and keeps the pivot of the original (centered by default) even after it goes in the atlas

 

Hi! Thanks for the detailled explanation, I'm really trying to learn and understand everything I need for visual processing in Unity, though there's a few things I'm a bit confused by in your post.

I do agree with the sprite dimensions thing actually, since that was part of the issue I've had in past development situations, where I'd make a crouch sprite but the crouch sprite was significantly misaligned with the original sprite. I imagine this has to do with the pivot points or something?

I'm also sorry to say but I've got absolutely no idea what's going on with that Sprite preprocessor, it's nothing I've ever seen before and if I'm honest, it seems too complicated for me to use reliably for my own development purposes. All I really want is a way to keep the positioning of my sprites consistent throughout my different, simple animations.

I also do not think that the "tight" setting actually causes the sprite to be cut properly; on the previews in Unity it is still clearly possessing a giant chunk of transparency that changes the sprite's boundaries. This normally wouldn't be a problem but it would make it look strange or heavily offset when instantiated via code down the line.

I tried making use of the Sprite Editor and the 'Generate Outline' mechanic, but that doesn't actually seem to do anything. It generates the outline but even after I press 'apply', I go back to the sprite and it is still the same dimensions, with all the transparency still on it.

I've attached a picture of one of my placeholder sprites, which has a similar issue of 'excess' transparency on it. I just want to minimize the amount of transparency so that its more intuitive to instantiate and manipulate within the game space.



Thanks in advance!

 

Yeah, you can test how the pivot point effects your sprite by placing the pivot to the right of the sprite -> placing the sprite in the scene -> placing the pivot to the left of the sprite.

I agree that it is a bit complex. Have you tested what karderos suggested?

What you posted is actually the texture, not the sprite. One of the common misconceptions about sprites are that they are textures, this isn't the case; a sprite has an underlying texture and the vertex points for where in that texture the drawing should happen and some additional information like pivot point etc. . You can even change the underlying texture of a sprite in runtime. So, a sprite being tight or tighter wont actually cut out the texture or change its dimensions or even change anything on the texture, it will just tighten the area where the sprite renderer draws the texture.

To visualize the sprite's outline, drag and drop it to the scene, go to shading mode and select shaded wireframe. there you'll see the actual outline of the sprite:

Spoiler: images

tight mesh type creates an outline automatically:


higher extrude edges:


custom outline:

Cheers

 

Hi! Thanks again for the detailled reply, I've looked a bit more into the situation around the sprites and I have a few more thoughts to add.
First, the SpriteAtlas does seem to at least crop the sprites in a way that satisfies me, but I'm not quite sure what it has actually done.

According to some of my quick searches, when a sprite is packed into an Atlas, you still just refer to the sprite as normal?
Obviously, if I drag my texture into the scene, it'll show the whole transparent field of worthless data that's still defined in the image.
I guess my question is how I properly make use of this altered sprite asset? I'm not used to using Sprite Atlases for anything besides tilemaps, so this is fairly new to me right now. I can see in the atlas itself, the sprite is cropped perfectly, but I don't actually know how to refer to it or even plug it into the script. Weirdly enough, typing 'SpriteAtlas' into my scripts also does nothing, I can't refer to it or put it into a scriptableobject for my tastes.

While I'm a little concerned about my base textures still having that incredibly large sized chunk of transparency on it, my main concern is ensuring that the pivot points end up in the right places so that animation doesn't have strange 'jumps' in position. Much thanks for the tutorial on the sprite 'polygons' though, while my game isn't very intensive right now, that'll be useful in future!

Part of why I've been fixated on the transparency of the textures is because the texture itself also affects resizing ratios (ie, 10% of a 1000px texture is much larger than the 500px art inside of that texture), not just the pivot points. Are the Sprite Atlases going to fix that? Or should I be cropping them still?

Thanks for your patience in responding to my questions, I'm just trying to grasp all of these concepts. Can't be a good visual engineer in Unity unless I make a good effort to do so, right?

 

the atlas fixes everything

will you still see the transparent pixels when you drag it into the scene? well no because they are transparent, technically yes you will see them if you use the rect tool, but in the build they wont be there

resizing wont be affected by the size of your canvas at all

if you have 1 pixel and you double its size, it will become 4 pixels, whether it has a 1000 pixel transparent canvas or it is perfectly cropped

 

Have fun mate, just try to keep the threads shorter and separate though; most people don't like reading through walls of text